From nobody Mon Oct 3 14:02:40 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7889E129545 for ; Mon, 3 Oct 2016 14:02:38 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 TxCI3qAMCG4L for ; Mon, 3 Oct 2016 14:02:37 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 CBAE5129550 for ; Mon, 3 Oct 2016 14:02:36 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id t7so175351310qkh.2 for ; Mon, 03 Oct 2016 14:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=uQwDQ7YAiTeZ1n5VuHcczGupHbHMRR/tll5t1cvZfJY=; b=ZQQEHQXLjO1l0VMQpxmO15WfDHDZEDQfyZIr7JSmIBEDc7ZWhyPwdxxVNOZea/7qUg DROFzrr9WcHloe9qkIlsWftAXdDqb1iL1hw69FkQKznfC1uNWwaXb1nUW4jQ7Xa9sLbl bLpOefCz8IIDJSSL8FTvkseqME+YkGLFlr+vAFn5togWlD0012f7YuXwBG/sDkx1/Ziq W0uqca+KWj2CtMZp3m7SxYFr2afB04fXfh1Kt/HxDTWf8GgUeagX2PHK56lgCaCrlooq aLer05C5s/tzNf0EELm8Rev+r6ekCQ9ucFo00hjasscyArerugElU+W7e5YFqy/p2iAQ ZKBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uQwDQ7YAiTeZ1n5VuHcczGupHbHMRR/tll5t1cvZfJY=; b=Y9F9vCmnLvSzDBWvmPZkj35j2kbIWVLrHVcD/yn0DSsNaKwJs3BH8qBFifs6Ch6n1Z /qYJamlSj3byw0j12gs4O99oJuxefBAsYsQA+MyzHqsS+l3+I3mY6r+D4JabfYdxwag9 RA9CZJ8wAGoQ3zR+szjFFX7PlJB3w1fWJV/25Kkw+Sb6ya07zzCAmwcctr1gJ/Ci7WT9 J2CoCwhDH1TddKBMhnuqBPada+D1bQGEZ/9QWYdFkJ/2WYlD+pPpiIKqePkca7FDTe9v o7t2jne81MRdFDXrczEIqQQbD6FgZ4TOEEs4acxU5CUjSET2HiNabsgOSzfHxuLqJQLx Uozw== X-Gm-Message-State: AA6/9Rmwvx5aMK5HMC2oOuUZ3PaYj8V1uwtgSjpz50NmOspX7hcQD+VCccQpA09Da1nCraFXPU8F/NIQKCNigmco X-Received: by 10.55.188.195 with SMTP id m186mr74799qkf.180.1475528555646; Mon, 03 Oct 2016 14:02:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Mon, 3 Oct 2016 14:02:05 -0700 (PDT) From: Warren Kumari Date: Mon, 3 Oct 2016 17:02:05 -0400 Message-ID: To: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 21:02:38 -0000 Dear OpsAWG WG, The authors of draft-ietf-opsawg-tacacs-05 have indicated that they believe that the document is ready, and have asked for Working Group Last Call. This WGLC ends Mon 17-Oct-2016. Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. Please note that "Yeah, I reviewed it, it looks great!" is a useful comment (well, more useful than silence). Please note that this document is primarily describing an existing protocol, *NOT* designing a new one. This means that comments of the form "Ick, this uses MD5?! You *so* should replace it with [SHA-512|BLAKE2|GOST|SWIFFT|]" or "flags should be 16bits, not 8, what if we want to extend this?" are not helpful. Also, we already know that this protocol has security issues. The plan is to publish this document, finally documenting (after 19 years) one of the core protocols used by network people. Once this is done, there will be a new document published, extending this to be more secure. There is some history behind this decision... The draft is available here (for easy clickin'): https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-05/ In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-opsawg-tacacs-05? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as OpsAWG WG co-chair) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Oct 3 14:14:13 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F44129568 for ; Mon, 3 Oct 2016 14:14:12 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 7wG2aCIBFDEO for ; Mon, 3 Oct 2016 14:14:12 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 BDE98129566 for ; Mon, 3 Oct 2016 14:14:10 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id m5so29544010qtb.3 for ; Mon, 03 Oct 2016 14:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=F0DVPy0S9GZSjqadJ9Dj8v9IU/tzTBUI2+kZ1sQjrbQ=; b=LJchVAxcJD5ieaQdMY5UZZolRBqrOUkwUakq5uanuY8LUwBNrLvlkD9Pbdwn4zsDx/ QQZwig80sS/bwV9w+aNjD9S1zP1ehNPttKEga5+GeMkj4tYgNgvX1pzY7agED2Yn0P/L 3DvHYGn4PpjyB4qjheyPH8DFngxtaKd5sXLiOzWlg8tnGPR5U6zwJzfHum3y2d/ysli4 GXRydEAzBbi/Exsebq2LBPPGT1gJnrHx/aKlsdfVG5Z1GGgQ+9NMckkVQ9SnBV9woqdv OviXrN3ltA1OFhhmrWReSEXNexO+T4edJde101zauSFsOvTM/oiMaPBKcF+1X4INxkVk RVbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=F0DVPy0S9GZSjqadJ9Dj8v9IU/tzTBUI2+kZ1sQjrbQ=; b=Q5byb7EyDGq+ff+PCmrH3cL6wnRdfn1M46Ml3EqL8tYh3CyccJiE7u0Tc4tseLxD18 t0W8Uku2GuoNTsHsbYxZdrXGROOS+p6wI0qW51qHRI6vOeHBiziNNu7byq6FrwP7qqJi MvWapqiV1DAKCiZXR8U4VpLqj2yadNSRTVDz3KUii8bI/VP9ID5RDgzgKOyp/y8+LQAo c6wOpD4UZb/VbopHSWBj8NwPOZFk+Tizlr8NJU0R12U7qPVSetBeLmrwSUqY1bTH7PGb bBp32dmyiXaHHn5lKjIe5+KoZXxIacTx1fZfIGgin3uWiw1dkgZjEMDYa6WuMlfyRGKU 0m+Q== X-Gm-Message-State: AA6/9RnHMdTTqfdx8s3sKQG5Kc0uVpFWeykQ8aTs129ymzSpWDQZtEQhSxVy8Ai/nkKQXd6P80VHjmbWbbX8D3Xn X-Received: by 10.200.44.213 with SMTP id 21mr87814qtx.91.1475529249776; Mon, 03 Oct 2016 14:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Mon, 3 Oct 2016 14:13:39 -0700 (PDT) From: Warren Kumari Date: Mon, 3 Oct 2016 17:13:39 -0400 Message-ID: To: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [OPSAWG] OpsAWG meeting in Seoul - Call for Agenda items. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 21:14:13 -0000 Dear OpsAWG Working Group, We are planning on meeting at IETF97 in Seoul; if you have anything that needs discussion time, please let us know, by replying to this mail, If you want to mail the chairs alias directly instead, please include "[SCHEDULE]" in the email subject - we get lots of mail before meetings, and don't want any agenda requests to slip through the cracks. Meeting time is best used for discussing open issues on drafts, not simply restating what is in your draft. If we happen to have some extra time at the end of the meeting we *may* allow presentations on new work, but in general we require that the draft has been published and has had significant discussion on list, so make sure you publish and get feedback early. Thanks, W A few reminders / tips to help your presentation be effective: ---------------------------------------------------------------------- 1: Please rehearse your talk, make sure that it fits within the allocated time slot, and that you have left some time for questions. It is very impolite to the working group to run over your allocated time, and we are likely to simply cut you off if you do. 2: We require slides at least *3* days before the meeting; you can revise them after this point if needed. Please include the version number on the first page of the slide deck. Please send them to the WG chairs alias - sending them to just one of us leads to confusion. 3: Please send these in PDF format - we=E2=80=99ve had a number of instance= s where the convertor doesn=E2=80=99t handle certain fonts, etc and the presenter becomes sad. 4: Please include slide numbers on all slides - it=E2=80=99s much easier to ask someone to go back to slide number 5 than =E2=80=9Cthe slide that was a couple after the second diagram=E2=80=A6 no, not that one, the next one=E2= =80=A6 erm=E2=80=A6 next?" 5: Slides are a summary of what you want to say - please don=E2=80=99t just put everything on the slides and read them verbatim (we all know how to read!) --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Oct 3 14:50:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854F8129598 for ; Mon, 3 Oct 2016 14:50:26 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 NaBlaFFcwOwk for ; Mon, 3 Oct 2016 14:50:24 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 9871712955F for ; Mon, 3 Oct 2016 14:50:24 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id t7so176383832qkh.2 for ; Mon, 03 Oct 2016 14:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dv8HAyClS+IKFzLOSppK0fDP1jNhFSsWnm7PiX3Euf0=; b=fpJVR/NAE6l2UvB2m8tdjGCDFEPOZtj409QdCnJR3U5R4QGkBkCtVHcY10UApdYZKg /qLlhIV7CqXA5cqB2imqPpky2N+TTv8X0eDVIVhVDIs5kbHxl41lJQKhs5lzIduaJzUw k5Yt+Skz9wNNj7B5dGsALTuwGWP1/mA/pBxVSSBUvceF0DJusyZdm1B5H6dVsuPaD2o5 XW7UReWH0NZqiXuhkhgZgaVUtDzJA7Rt+U9vN5ro5ne3aaXNBpdhh06BRiSBJk4RxMPc zVMDCTJ+OuLtpxYXguqdHbask+EvJi0bXQB8b726N90sfUNetuXNiTS2I9uRqfxlEiEC 0yDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dv8HAyClS+IKFzLOSppK0fDP1jNhFSsWnm7PiX3Euf0=; b=fumSNkYCLkWFS0eLRIYLTIqUv+TvV4yrzDl5egq9SeS0zIlJqG+Q0+z/s+EQrta4UG 9nVLbsd9p2hn6SvhTDSsYUxsvHjRnHK89W1u5af8zjpuGori/GCxzRZTjrbUCEt8QVB2 bLA1K7/Y9RnhEQVBiumXS293Nz6TPBQGdBqR7r4K7cPgdoIFyygtLJgJbWTgkwOQHVfG +SgBFG00G0aTfk+E7fTLvZXUL/plTeZwKb7c/I93dboxPj7Jm0x3+q8O9s3d+o7luqo+ aVQLfrhSd7ZScydjEClI6e/zfXXaarPDJI4ko43ucIEvtNzjgMw2nap4QgcTz0lfKV4Z TAsQ== X-Gm-Message-State: AA6/9Rm+H5N/Ok401lTCvMBDSdZmTqUD4FvVF4XLTYOkOpfvCiH4B7mM9t8NLgG16nE+D/DBeMtwKZwHi/J9JCVX X-Received: by 10.55.175.134 with SMTP id y128mr271729qke.134.1475531423794; Mon, 03 Oct 2016 14:50:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Mon, 3 Oct 2016 14:49:53 -0700 (PDT) In-Reply-To: References: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu> From: Warren Kumari Date: Mon, 3 Oct 2016 17:49:53 -0400 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 21:50:27 -0000 [ - Discuss, tsv-art (first for clutter, second because I'm not subscribed) ] Dear authors, I just wanted to make sure that you had seen these are well... W On Mon, Sep 26, 2016 at 5:36 PM, Joe Touch wrote: > CC'ing tsv-art... > > > On 9/26/2016 2:34 PM, Joe Touch wrote: > > Hi, all, > > I've reviewed this document as part of the Transport Area Review Team's > (TSVART) ongoing effort to review key IETF documents. These comments were > written primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address any > issues raised. When done at the time of IETF Last Call, the authors should > consider this review together with any other last-call comments they > receive. Please always CC tsv-art@ietf.org if you reply to or forward this > review. > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-opsawg-capwap-alt-tunnel > Title: Alternate Tunnel Encapsulation for Data Frames in CAPWAP > Reviewer: J. Touch > Review Date: Sept 26, 2016 > IETF Last Call Date: Sept 16, 2016 > > Summary: This doc refers to existing tunneling specifications, many of which > are inconsistent or incorrect. In particular, there are potential > complicatinos with MTU support and signalling that could affect transport > protocols. > > Major issues: > > As already noted in draft-intarea-tunnels, many existing tunnel mechanisms > are inconsistent or incorrect in their support for IPv6 MTU requirements, > both as transits for IP packets and as IP endpoints. Although this document > cites existing standards, the inconsistency and incorrectness of these > standards should be addressed. It might be sufficient to indicate that any > tunneling mechanism selected MUST support the minimum IPv6 MTU requirements > independent of this signalling mechanism (i.e, the signalling mechanism > doesn't address or correct any errors or inconsistencies in the tunnel > mechanism selected). > > Regarding IP endpoint requirements, it might be useful to consider whether > this protocol could be extended to indicate the receiver payload reassembly > limit when indicating support for each tunnel type, to assist the source in > determining whether the resulting tunnel will be IPv6 compliant (rather than > becoming a black hole for valid packet sizes). > > Additionally, for the transport protocol-based tunnels, it would be useful > to consider whether the protocol could indicate not only the endpoint IP > address but the port number as well. > > Minor issues: > > It might be useful to consider IPsec TLS, and DTLS tunnels as well as those > already listed. > > --- > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Oct 4 08:02:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA701298B0 for ; Tue, 4 Oct 2016 08:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, 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 tlVZCcrVgE8H for ; Tue, 4 Oct 2016 08:02:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A449129555 for ; Tue, 4 Oct 2016 08:02:40 -0700 (PDT) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B4C6E40414 for ; Tue, 4 Oct 2016 11:02:39 -0400 (EDT) From: "Marc Blanchet" To: opsawg@ietf.org Date: Tue, 04 Oct 2016 11:02:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Subject: [OPSAWG] bof proposal review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 15:02:42 -0000 Hello, the bof proposal below have been sent to OPS ADs (and INT ADs) and posted on the BOF wiki page. Benoît asked that this to be discussed here, since there is no public mailing list yet for this topic (we shall soon). The primary purpose of the BOF is to extend the discussion to more operators (and other parties obviously) than the initial set to get an (hopefully) common set of requirements and identifying possible protocol work. It is a non- wg forming. Regards, Marc. =========== Name: IP Provisioning for SDN/NFV (ipprov) Description: With the dynamic nature of SDN/NFV networks, providers and data center operators have to manage more dynamically the IP addressing and provisioning of network nodes, including various network transition scenarios such as IPv4 as a service, where IP address and prefixes consumption are critical and require timely and dynamic reallocations. An initial set of providers have expressed requirements, but with different scopes (eg: only IP addressing and prefix management and delegation, vs larger provisioning scope). Some initial prototyping of solutions and field trial has started. The intent 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. Status: not WG-forming Drafts: draft-xi-ps-centralized-address-management draft-sun-i2apm-address-pool-management-arch draft-sun-i2apm-address-pool-management-yang The responsible Area Director (AD): OPS or INT BoF Chairs (or the ADs as placeholders): Marc Blanchet and ... Proponents: Chongfeng Xie(CT), Ying Cheng(CU) Number of people expected to attend: 100 Length of session: 1.5 hour Conflicts to avoid (first priority): sdnrg, nfv, intarea, nfvrg, opsawg Conflicts to avoid (second priority): dtn, sunset4 From nobody Wed Oct 5 09:15:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3975129540 for ; Wed, 5 Oct 2016 09:15:52 -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, 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 f76tbZ5058O3 for ; Wed, 5 Oct 2016 09:15:50 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7D501129463 for ; Wed, 5 Oct 2016 09:15:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id AC67F1F38; Wed, 5 Oct 2016 16:15:49 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07yeP7Gz1SNZ; Wed, 5 Oct 2016 16:15:49 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id F045E172E; Wed, 5 Oct 2016 16:15:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 5 Oct 2016 12:15:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 16:15:53 -0000 Some comments. Mostly little nits and clarifications. The major points for me are related to security. The "Security = Considerations" section is almost empty, and will certainly not pass a = review from the security area. They will in all likelihood block = publication until substantive comments have been added. ------=20 3.3. Single Connect Mode The packet header (see below) contains a flag to allow sessions to be multiplexed on a connection. * it would be good to name the flag here. If the server sets this flag in the first reply packet in response to the first packet from a client, this indicates its willingness to support single-connection over the current connection. The server may set this flag even if the client does not set it, but the client is under no obligation to honor it. * what happens if the client does not honour the flag? The flag is only relevant for the first two packets on a connection, to allow the client and server to establish single connection mode. The flag MUST be ignored after these two packets since the single- connect status of a connection, once established, must not be changed. The connection must instead be closed and a new connection opened, if required. Why would it be required to change the mode? It would be good to = explain the use-cases, and why (or not) they make sense. TAC_PLUS_UNENCRYPTED_FLAG :=3D 0x01 If this flag is set, then body encryption is not used. If this flag is cleared, the packet is encrypted. Unencrypted packets are intended for testing, and are not recommended for normal use. * it would be good to have a pointer to the security considerations, = with a discussion of the implications. * Also, it's odd that a completely insecure mode is just "not = recommended for normal use". I would suggest more panic-inducing = phrasing. e.g. ."Unencrypted packets offer a complete compromise of all = security related to the protocol and MUST NOT be used outside of a = testing environment" TAC_PLUS_SINGLE_CONNECT_FLAG :=3D 0x04 This flag is ussequernt, ed to allow a client and server to agree = whether multiple sessions may be multiplexed onto a single connection. * I find the "agree" phrasing odd. I've mentioned before that the tone = of the document is often philosophical. Perhaps saying instead "this = flag signals whether the client and server are capable of performing = session multiplexing" * i.e. the flag is a signal, not a capability for the systems to agree. session_id The Id for this TACACS+ session. The session id is to be selected randomly. This field does not change for the duration of the TACACS+ session. (If this value is not a cryptographically strong random number, it will compromise the protocol's security, see RFC 1750 * it would be good to update the paragraph to be more prescriptive. = i.e. The Id for this TACACS+ session. The session id MUST be taken fro a cryptographically strong random number generation. If not, the protocol's security will be compromised. See RFC 1750 for further information ... length The total length of the packet body (not including the header). This value is in network byte order. Packets are never padded beyond this length. * Why is the text on "padding" there? The TACACS+ packets are sent over = TCP, not UDP. So any "padding" would be outside of the scope of the = current packet, and be seen by the other end as a subsequent, but = invalid, TACACS+ packet. 3.5 ... - Unused fixed length fields SHOULD have values of zero. * what happens when they don't? I suggest adding text saying that the = fields are ignored. - There will be no padding in any of the fields or at the end of a packet. * I wonder again what "padding" means here. 3.6. Encryption The body of packets may be encrypted. ... * Which is not a standard encryption method. Security people will = complain here. I suggest (as before) using the term "obfuscated". With = a note that for historical reasons, the flags / fields / etc. refer to = TACACS+ "encryption". ... This document does not discuss the management and storage of those keys. ... * there should be some discussion in the Security Considerations section = about this. Otherwise, this subject will be brought up in the security = review. ... It is an implementation detail of the server and client, as to whether they will maintain only one key, or a different key for each client or server with which they communicate. For security reasons, the latter options MUST be available, but it is a site dependent decision as to whether the use of separate keys is appropriate. * those sentences seem to disagree with each other. It's an = "implementation detail", but it MUST be supported. I suggest requiring = the capability of per-server and per-client keys. ... The session id is used in network byte order. * nit: if the session ID is a 32-bit opaque token, it's not in any byte = order. Maybe just "as taken from the packet header" ? When a server detects that the secret(s) it has configured for the device mismatch, it MUST return ERROR. The handling of the TCP connection by the server is implementation independent. * I repeat my objection here. There is just no reason for the TCP = connection to remain open after the connection has been determined to be = fraudulent. This subject also came up in the RADIUS over TCP drafts. = The consensus there was the same: if it's not a real / known / good = client, there is every reason to close the connection, and zero reasons = to keep it open. After a packet body is decrypted, the lengths of the component values in the packet are summed. If the sum is not identical to the cleartext datalength value from the header, the packet MUST be discarded, and an error signalled. The underlying TCP connection MAY also be closed, if it is not being used for other sessions in single- connect mode. * This last sentence is confusing. Are there different secrets for = different packets in one TCP stream? If so, nothing in the document = says so. If not, then there is every reason to believe that the secret = is mismatched. And, the *next* packet will decrypt incorrectly. Which = means (again) you might as well just close the TCP connection. If an error must be declared but the type of the incoming packet cannot be determined, a packet with the identical cleartext header but with a sequence number incremented by one and the length set to zero MUST be returned to indicate an error. * this mix of clear-text and encrypted signalling opens up the protocol = to an attacker. Since this "NAK'" is not protected, an attacker can = forge the NAK at any time, and force the connection to be closed. * this attack (along with all others) should be noted in the Security = Considerations section. ... Packet fields are as follows: action This describes the authentication action to be performed. Legal values are: * what happens if a client/server receives values outside of the legal = range? I suggest sending ERROR, and closing the TCP connection. * similar comments apply for other fields with "legal values". While = it's good to define what happens when things go as planned, it's also = good to define what happens when things *don't* go according to plan. * review of 4.2 and subsequent sections will follow in a later message.= From nobody Wed Oct 5 09:45:20 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FFC1297B2 for ; Wed, 5 Oct 2016 09:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996] 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 VnkU9HvTcSya for ; Wed, 5 Oct 2016 09:45:16 -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 19AA012979E for ; Wed, 5 Oct 2016 09:45:16 -0700 (PDT) Received: from mbp-2.local ([IPv6:2601:647:4201:9e61:79fb:7186:ee57:fbf5]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u95GjESF011374 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 5 Oct 2016 16:45:15 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:79fb:7186:ee57:fbf5] claimed to be mbp-2.local To: Marc Blanchet , opsawg@ietf.org References: From: joel jaeggli Message-ID: <2c3f565a-0ef3-e18d-8b1e-8edf02d0bbfa@bogus.com> Date: Wed, 5 Oct 2016 09:45:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Thunderbird/49.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C6OPvexfRblb6CNf5D2mugmcir48Lv2OV" Archived-At: Subject: Re: [OPSAWG] bof proposal review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 16:45:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C6OPvexfRblb6CNf5D2mugmcir48Lv2OV Content-Type: multipart/mixed; boundary="8cxWa77PvOcPtbFTpxwBl1NSt1CjtudLq"; protected-headers="v1" From: joel jaeggli To: Marc Blanchet , opsawg@ietf.org Message-ID: <2c3f565a-0ef3-e18d-8b1e-8edf02d0bbfa@bogus.com> Subject: Re: [OPSAWG] bof proposal review References: In-Reply-To: --8cxWa77PvOcPtbFTpxwBl1NSt1CjtudLq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/4/16 8:02 AM, Marc Blanchet wrote: > Hello, > the bof proposal below have been sent to OPS ADs (and INT ADs) and > posted on the BOF wiki page. Beno=C3=AEt asked that this to be discuss= ed > here, since there is no public mailing list yet for this topic (we > shall soon). So, I think we dicussed this is little bit back in march when the drafts were initially submitted. I think generally I'm postive on the idea of working on a yang model for data interchange between ipam systems or ipam systems and agents. Where I get into a little trouble is with the architecture, because it describes a couple of particular scenarios and my experience of carrier ipam systems doesn't really jive with that. In my experience, carrier ipam systems are part of a software stack associated with resource management of which address management is a component, not just ipam, and they tend as a result to be somewhat idioscratic. to my mind allocating resources for transition technologies is about the least interesting application I can imagine for such a tool and a very small portion of what it does, ours deals with v4 and v6 assignment simply as a matter of course. even on a somewhat smaller scale our ipam system has adopted json input and output so I think there is certainly a great arguement for standardizing the interchange format. thanks joel > > The primary purpose of the BOF is to extend the discussion to more > operators (and other parties obviously) than the initial set to get an > (hopefully) common set of requirements and identifying possible > protocol work. It is a non- wg forming. > > Regards, Marc. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Name: IP Provisioning for SDN/NFV (ipprov) > Description: With the dynamic nature of SDN/NFV networks, providers > and data center operators have to manage more dynamically the IP > addressing and provisioning of network nodes, including various > network transition scenarios such as IPv4 as a service, where IP > address and prefixes consumption are critical and require timely and > dynamic reallocations. An initial set of providers have expressed > requirements, but with different scopes (eg: only IP addressing and > prefix management and delegation, vs larger provisioning scope). Some > initial prototyping of solutions and field trial has started. The > intent 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. > Status: not WG-forming > Drafts: draft-xi-ps-centralized-address-management > draft-sun-i2apm-address-pool-management-arch > draft-sun-i2apm-address-pool-management-yang > The responsible Area Director (AD): OPS or INT > BoF Chairs (or the ADs as placeholders): Marc Blanchet and ... > Proponents: Chongfeng Xie(CT), Ying Cheng(CU) > Number of people expected to attend: 100 > Length of session: 1.5 hour > Conflicts to avoid (first priority): sdnrg, nfv, intarea, nfvrg, opsawg= > Conflicts to avoid (second priority): dtn, sunset4 > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --8cxWa77PvOcPtbFTpxwBl1NSt1CjtudLq-- --C6OPvexfRblb6CNf5D2mugmcir48Lv2OV 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 iEYEARECAAYFAlf1LhkACgkQ8AA1q7Z/VrJSCQCeMk2nK8X9L/y70842DiWNdx+5 AvcAn2iShuyPRaSnLwJTRlmF7ZDq1DQI =w+/Z -----END PGP SIGNATURE----- --C6OPvexfRblb6CNf5D2mugmcir48Lv2OV-- From nobody Wed Oct 5 10:25:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDF129498 for ; Wed, 5 Oct 2016 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, 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 AJmfvOFdd3pD for ; Wed, 5 Oct 2016 10:25:30 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE012961D for ; Wed, 5 Oct 2016 10:25:30 -0700 (PDT) Received: from [206.123.31.226] (h226.viagenie.ca [206.123.31.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9C92047685; Wed, 5 Oct 2016 13:25:28 -0400 (EDT) From: "Marc Blanchet" To: "joel jaeggli" Date: Wed, 05 Oct 2016 13:25:26 -0400 Message-ID: In-Reply-To: <2c3f565a-0ef3-e18d-8b1e-8edf02d0bbfa@bogus.com> References: <2c3f565a-0ef3-e18d-8b1e-8edf02d0bbfa@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] bof proposal review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 17:25:32 -0000 On 5 Oct 2016, at 12:45, joel jaeggli wrote: > On 10/4/16 8:02 AM, Marc Blanchet wrote: >> Hello, >> the bof proposal below have been sent to OPS ADs (and INT ADs) and >> posted on the BOF wiki page. Benoît asked that this to be discussed >> here, since there is no public mailing list yet for this topic (we >> shall soon). > > So, I think we dicussed this is little bit back in march when the > drafts > were initially submitted. I think generally I'm postive on the idea of > working on a yang model for data interchange between ipam systems or > ipam systems and agents. > > Where I get into a little trouble is with the architecture, because it > describes a couple of particular scenarios and my experience of > carrier > ipam systems doesn't really jive with that. In my experience, carrier > ipam systems are part of a software stack associated with resource > management of which address management is a component, not just ipam, > and they tend as a result to be somewhat idioscratic. to my mind > allocating resources for transition technologies is about the least > interesting application I can imagine for such a tool and a very small > portion of what it does, ours deals with v4 and v6 assignment simply > as > a matter of course. > > even on a somewhat smaller scale our ipam system has adopted json > input > and output so I think there is certainly a great arguement for > standardizing the interchange format. > in some ways, you are exactly stating the purpose of the bof: having other operators (than the original set) to chime in and provide their input and requirements. With more open forum, we shall be able to get a better set of common requirements and more focus and scope. Regards, Marc. > thanks > joel > >> >> The primary purpose of the BOF is to extend the discussion to more >> operators (and other parties obviously) than the initial set to get >> an >> (hopefully) common set of requirements and identifying possible >> protocol work. It is a non- wg forming. >> >> Regards, Marc. >> >> =========== >> >> Name: IP Provisioning for SDN/NFV (ipprov) >> Description: With the dynamic nature of SDN/NFV networks, providers >> and data center operators have to manage more dynamically the IP >> addressing and provisioning of network nodes, including various >> network transition scenarios such as IPv4 as a service, where IP >> address and prefixes consumption are critical and require timely and >> dynamic reallocations. An initial set of providers have expressed >> requirements, but with different scopes (eg: only IP addressing and >> prefix management and delegation, vs larger provisioning scope). Some >> initial prototyping of solutions and field trial has started. The >> intent 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. >> Status: not WG-forming >> Drafts: draft-xi-ps-centralized-address-management >> draft-sun-i2apm-address-pool-management-arch >> draft-sun-i2apm-address-pool-management-yang >> The responsible Area Director (AD): OPS or INT >> BoF Chairs (or the ADs as placeholders): Marc Blanchet and ... >> Proponents: Chongfeng Xie(CT), Ying Cheng(CU) >> Number of people expected to attend: 100 >> Length of session: 1.5 hour >> Conflicts to avoid (first priority): sdnrg, nfv, intarea, nfvrg, >> opsawg >> Conflicts to avoid (second priority): dtn, sunset4 >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > From nobody Wed Oct 5 12:16:37 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68093129815 for ; Wed, 5 Oct 2016 12:16:36 -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 9E3ATFkOB2pU for ; Wed, 5 Oct 2016 12:16:34 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 D05DC12977F for ; Wed, 5 Oct 2016 12:16:34 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e6so36277499pfk.1 for ; Wed, 05 Oct 2016 12:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1OvbgMne+01Vj/w9iqp9PjNZD9P8VOFKIGr+4jypfRo=; b=HbsaA2yICpPfdWrMiA23/n82v4kZG6SquX9UECslurvW301+gpnMjJzlpPmQ1Tc3gF niCaLOHw+aGR+BThVSrf1WWtUqBsI/A00+CtitOn2SPOxNBgQ2WCi3RQ+lR2KIxviNgU ixiqrcgSMEczLLA3OFsoDtbh6qJtm4DYa+P/vskOSK6nKHTvoJzH9rbzLm0kqtYePfPz Z3u9k46TPNKw0+IOERLXnYFHFpLujc66+KukZaH9IIPckwjAqdPbiflJFGvJ11tHQkla TzD2NPvQG6tOmwz0dcZIe1iQV22ZDWERlGRmQ48qSQU6Va6nV7mruK3l2Sl+PyZKmyEq rdJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1OvbgMne+01Vj/w9iqp9PjNZD9P8VOFKIGr+4jypfRo=; b=hEtkIb+vBRTWwdkbxnTYJtBjrUdBk+XpfFLOX6unPJU4R4OXh4odj9tGWOZseuu9wm qNy17CaCLS8MeTV32XqkL6OZgPfK0Y7XGquUGzCBwd5WJ/9SbwJQwQvvy2DK/YwWLf2j VOAU4q3Mz69NJjePwX02PiDLozucnzNfDLgc5T0q7Oo26Bq9c4aD3P5EwUaVzpQ0o9X3 i4577Jn4lnXjXKFGsacYdxJN5vhG+gX/0KcCDdRqGzxe+e+3f3GDiEzeEFPXMdpeoltx Kp4d3WmByDyrA79jFGClBZP2u1HcWvLjonwFkYGh/z3HVjcqT0mUBXTc3vUdrGQQ9y5N Mtrg== X-Gm-Message-State: AA6/9Rm9qGe1fqKXMvP8rFsnicde55eAVsCQjBubByUHzQJTzutI7atGwCvoLq9IumpHkA== X-Received: by 10.98.98.193 with SMTP id w184mr11125713pfb.120.1475694994200; Wed, 05 Oct 2016 12:16:34 -0700 (PDT) Received: from ?IPv6:2406:e007:4ce3:1:28cc:dc4c:9703:6781? ([2406:e007:4ce3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v24sm65484751pfd.1.2016.10.05.12.16.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 12:16:33 -0700 (PDT) To: opsawg@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 6 Oct 2016 08:16:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] bof proposal review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 19:16:36 -0000 > Description: With the dynamic nature of SDN/NFV networks, providers and > data center operators have to manage more dynamically the IP addressing > and provisioning of network nodes, Undoubtedly true. I would like to mention that this is clearly a target area for autonomic networking too; in fact one of the Anima use cases is a subset of this problem area. Not that I propose to derail the BOF with this comment, but the word "centralised" in one of the draft names suggests a specific approach and it may not be the only one. The model in https://tools.ietf.org/html/draft-ietf-anima-prefix-management is definitely not centralised (apart from policy). Regards Brian From nobody Wed Oct 5 12:21:42 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6577129828 for ; Wed, 5 Oct 2016 12:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, 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 K2EyIbWPYBi9 for ; Wed, 5 Oct 2016 12:21:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB5129446 for ; Wed, 5 Oct 2016 12:21:39 -0700 (PDT) Received: from [206.123.31.226] (h226.viagenie.ca [206.123.31.226]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 31B0047758; Wed, 5 Oct 2016 15:21:37 -0400 (EDT) From: "Marc Blanchet" To: "Brian E Carpenter" Date: Wed, 05 Oct 2016 15:21:36 -0400 Message-ID: <0A7F4797-78BF-4343-9876-6B041B45BFD9@viagenie.ca> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] bof proposal review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 19:21:41 -0000 On 5 Oct 2016, at 15:16, Brian E Carpenter wrote: >> Description: With the dynamic nature of SDN/NFV networks, providers >> and >> data center operators have to manage more dynamically the IP >> addressing >> and provisioning of network nodes, > > Undoubtedly true. I would like to mention that this is clearly a > target area > for autonomic networking too; in fact one of the Anima use cases is a > subset > of this problem area. certainly to add anima in the conflict list so we can have anima people in the room to flesh out the overlap or not. > Not that I propose to derail the BOF with this comment, > but the word "centralised" in one of the draft names suggests a > specific > approach and it may not be the only one. The model in > https://tools.ietf.org/html/draft-ietf-anima-prefix-management is > definitely > not centralised (apart from policy). thanks for the notification. Regards, Marc. > > Regards > Brian > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed Oct 5 13:54:52 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B86129475 for ; Wed, 5 Oct 2016 13:54:51 -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, 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 WTXEv36blZzD for ; Wed, 5 Oct 2016 13:54:48 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 567B2129474 for ; Wed, 5 Oct 2016 13:54:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 8550A1F48; Wed, 5 Oct 2016 20:54:47 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM7JZlW2uAeZ; Wed, 5 Oct 2016 20:54:47 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id C1BC4C15; Wed, 5 Oct 2016 20:54:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> Date: Wed, 5 Oct 2016 16:54:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 20:54:51 -0000 Continuing... Summary: the spec is still fairly descriptive / philosophical instead = of prescriptive. Many optional parts of the protocol are described, "A = and B are allowed", but there is often no description of what to *do* = when either A or B is present. I've suggested descriptive text, or = places where descriptive text can be added. The larger worry here is what happens if the descriptive text conflicts = with existing implementations? This is a topic which should be = discussed in the "Security Considerations" section. i.e. the spec documents the existing protocol, with recommendations = for security and inter-operability. As the protocol has historically = been poorly specified, implementations are likely to follow the broad = requirements of this specification. They are also likely to not follow = many of the newly-clarified behaviours / requirements. The hope is that = this specification can guide implementors towards a common understanding = of the protocol. Also, vague requirements and open options in a protocol spec are ripe = for implementation bugs and security issues. That worry drives many of = my comments. ----- 4.2 ... server_msg, server_msg_len c A message to be displayed to the user. This field is optional. If it exists, it is intended to be presented to the user. US-ASCII charset MUST be used. The server_msg_len MUST indicate the length of the server_msg field, in bytes. * The last sentence is atypical of RFC 2119 language. Then language is = typically about system behaviour or inter-field comparisons. I'm not = sure what it means that a field MUST indicate a length. * i.e. the "server_msg_len" field is *defined* to encode the length of = the "server_msg" field. No "MUST" is necessary. * similar comments apply to many of the other "foo_len" fields, = elsewhere in the document rem_addr, rem_addr_len An US-ASCII string this is a "best effort" description of the remote location from which the user has connected to the client.=20 * perhaps instead of "best effort", just re-use language from the "port" = description. The contents of this field are the clients description of = the remote location... 4.4 ... When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, then authentication continues and the SHOULD provide server_msg * editorial: the WHAT should provide... ... quest for more information to flexibly support future requirements. If the TAC_PLUS_REPLY_FLAG_NOECHO flag is set in the REPLY, then the user response must not be echoed as it is entered. * the implicit assumption here is that there is a person who is entering = text on a terminal. It would be good to have a bit more explanation of = this expected use-case. NOTE: Only those requests which have changed from their minor_version 0 implementation (i.e. CHAP, MS-CHAP and PAP authentications) will use the new minor_version number of 1. All other requests (i.e. all authorisation and accounting and ASCII authentication) MUST continue to use the same minor_version number of 0. * that's an odd phrasing of the requirement. Perhaps something more = prescriptive would be useful. e.g.: NOTE: Authentication requests which use ASCII login or chpass MUST use = minor version 0. Authentication requests using PAP, CHAP, or MS-CHAP = MUST use minor version 1. All authorization and accounting packets MUST = use minor version 0. 4.4.2... This section describes common authentication flows. If the options are implemented, they MUST follow the description. If the server does not implement an option, it will respond with TAC_PLUS_AUTHEN_STATUS_ERROR. * It's not typically required to say that implementations MUST follow = the spec. * also, perspective terminology is better than descriptive. Not "will = do", but "MUST do". * I suggest re-phrasing: This section describes common authentication flows. If the server does not implement an option, it MUST respond with TAC_PLUS_AUTHEN_STATUS_ERROR. This is a standard ASCII authentication. The START packet may contain the username, but need not do so. =20 * what happens when the username is / is-not included? i.e. what do = implementations *do*? * if this is a valid protocol flow, then it should be described. e.g. = "Any username in the START packet is ignored", or "any username in the = START packet MUST match the username in subsequent packets" ... The data fields in both the START and CONTINUE packets are not used for ASCII logins.=20 * what happens if there is data in the fields? Is it ignored? * RFC 2119 language is recommended here. "any data (if present) MUST be = ignored", or "the data field MUST NOT be present" * I have no idea how to make these requirements compatible with existing = implementations. Sorry... CHAP: The length of the challenge value can be determined from the length of the data field minus the length of the id (always 1 octet) and the length of the response field (always 16 octets). * it would be good to recommend a minimum length for challenge. 1 octet = is clearly insufficient, but is (silently) allowed by the spec. I = suggest at least 8 octets/ * also, the challenge MUST be derived from a cryptographically strong = pseudo-random number generator, and MUST change on every CHAP request. = Otherwise, the spec allows (also silently) a fixes challenge. To perform the authentication, the server will run MD5 over the id, the user's secret and the challenge, as defined in the PPP Authentication RFC 1334 and then compare that value with the response. * again "server WILL run". As opposed to "calculates..." MSCHAPv1 / MSCHAPv2: The length of the challenge value can be determined from the length of the data field minus the length of the id (always 1 octet) and the length of the response field (always 49 octets). * RFC 2433 says that the challenge is 8 octets. RFC 2759 says that the = challenge is 16 octets. It would be good to re-iterate that here. * i.e. smaller challenges are insecure, and should be forbidden ... To perform the authentication, the server will use a the = algorithm specified RFC2759=20 * editorial: "specified IN RFC ..." ... ASCII change password request * I suspect that the security area review will recommend that this be = removed. Even RADIUS had "change password" removed at the behest of the = security people.=20 4.4.3. Aborting an Authentication Session The client may prematurely terminate a session by setting the TAC_PLUS_CONTINUE_FLAG_ABORT flag in the CONTINUE message. If this flag is set, the data portion of the message may contain an ASCII message explaining the reason for the abort.=20 * again, what happens if the field is / is-not present? * what does the server do with this message? Should it be logged = somewhere? ... The session is terminated and no REPLY message is sent. * what happens to the TCP connection? Does it remain open? It may be = good to say "The session is terminated, and the session Id is no longer = valid. However, other sessions on the same TCP connection may = continue..." The host is specified as either a fully qualified domain name, or an ASCII numeric IPV4 address specified as octets separated by dots ('.'), or IPV6 address test representation defined in RFC 4291. * editorial ".. text .. "representation, not "test" If a key is supplied, the client MAY use the key in order to authenticate to that host. The client may use a preconfigured key for the host if it has one.=20 * so the server is pushing keys to clients? The security implications = of this should be discussed * what happens if the client gets pushed a key, and then also has a = pre-configured key? Which one takes precedence? Why? ... that's it for today. More later.= From nobody Thu Oct 6 03:02:38 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A374112959F for ; Thu, 6 Oct 2016 03:02:37 -0700 (PDT) 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=btconnect.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 5U0ckv3jSjJr for ; Thu, 6 Oct 2016 03:02:33 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0120.outbound.protection.outlook.com [104.47.2.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119FD12959D for ; Thu, 6 Oct 2016 03:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S+1+0Gn54+lQtrbGPiMw36C5OEfztdEXkdRoCwDbbC4=; b=iPZjHxVoRH4MXTzf403Vk0c4nUvkYduxfhSeYkZFeYczqDdsR5IHqGE0sCuBpO65RZs5eJT/v1stGyYdxK3E1n+8UTnO+XcEIpDwDXckvxHKK8OsqbhPRpnZBWOAsUGy2CVD0y3yywqrmiC4ywTbsiM113t2TVt/QU7SI8uNUz0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by DB6PR0701MB2997.eurprd07.prod.outlook.com (10.168.84.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Thu, 6 Oct 2016 10:02:27 +0000 Message-ID: <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> From: t.petch To: Alan DeKok , Warren Kumari References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> Date: Thu, 6 Oct 2016 11:00:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: HE1PR06CA0054.eurprd06.prod.outlook.com (10.164.28.150) To DB6PR0701MB2997.eurprd07.prod.outlook.com (10.168.84.135) X-MS-Office365-Filtering-Correlation-Id: 4958d8c4-5f4f-4988-ac52-08d3edcfe13a X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 2:Sa85ebpgwgjRCtyLDWylSjFLSXLAyGK5zaCaOFB3C8c8/iUR2BB7O0Hw3Z3qUdMPD+ahQ4BTW+3ISIFZ0o/jQ76qpD+67lhHQHbetTYPvkXgyAc+amlTdWQgFXcf3UXyvffnic4ZYYjAsqvPxyFCiQX/fZejXH8R44M4RvyEpkjci0ij9mjG5AwRlFulR2osN0n1wXKd8zzYqlQVaxA66g==; 3:npTPJ0r3waZ8SJo6ggPG0SOU6x8vUDUsRg7oA11cNvUG1b6JeWS0PLlM/OhulfKIc5sRcyZ8VSYK4+hc8A6rSPOMqDFHQmoQiOBxoR03BMyXeTDUt9yec97R3o3uHRclU0UET6o89Lcsfetj8XV1/Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 25:VlLmvq8JSABWaYcGV5TB5r4F7ogZtiyBTC6na3hrpdGLzwVJNJN2FngakHaKLXLrbKKyo3gfQWeSx+p765cHB7m6FZF1IWzLNoftaqmCSH13SIdQIUxwZHXuP3pdR2gB4YSbEsM3wmhcDkjesyZJFbgZVT/s+BoxH9EQpa70Bv+0yKnxi4BDbtjun5veTpTH7E2JsDuTqarx6bkHWmPmOM1feKGC7WFu8RNTbNo4AHoJMJNx/kIFgQTMTw1QgUa32zQk72Zgq1jvRJLmk6jR61sAsq+X6Z54h46WAxf5ArPHckCZj2uIGUvUrvjip4R7Yhuvja5hYGQ+jewK/TBbw+INpj8KKPa1HRZlbA7lvGgo9OllhlL5lv/zxu07ACe4Z3jISPLpfCWIOW8VLXmE/QlHbmkFfkVmcNhDsqfoOeta/2ZC6vLD8mxQPEf6e9EDk39kKF9BK/cVL3TQi5eg6wVdfIDpG6rxMXP8v8NJwRhtyuHH7uKX5vrAqQvLJpOqQ3eSEbRJoZbIanDtLNQGz0RNJo/B0S1wzrfaDYxan+QmyOOa0LzOgp8LCWkxzxRvtp965lXQZiZfoCX9bSJzev6mL2L6i/i7Ij4CFN0fV+nLudsy+MFIenIa+YQuQr16xSHSke90DROYNBFeEp0BKIG+8bIi+UZrTrkeQi1Fr3yGu19wlb3vQTPNyq+Prh3GHn05XNXGJLvZRaD96qwMQrOyddCuuk7AiVALXTf8v+wvzuIA8RevxkwGE1Pdbxjp X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 31:zT04zwg0c3zwL8cHUZuOLbkXaf2r8u7Y1DVhcHOZK2tNdQvd86V47C3b6kg8hcu+6hVqxgcZHTHEnJZHWXG5MxSxZwea2cRs9Km/uNdfLCWkY472m6u7oQ0kU0zqSmkJObJ0OXnKKILZvaA8nmw+1bTqy4IQPfnVoY0QzkTd0DnQLfK9F5GQcuL8U2l0s738CplzRk83hdTeN+WCHBVz6X/sHht7FBaFlclgudwptgrFijjxlm6+Obf3c+YF+xio; 4:CTzM6TBKNwTOQ74m8Us8B+8hYeOzJlGfWu/rNs0NyiXhqF/DtqfHqfVciR0k6Sory5Iy3NfPz0k7rSeOLCZ/8C3GDo/a1DYzNNtKAAew6HMk6asYBEVA+tUxrnB+BB6cWSpcfILxXnQHBlhF44UjNby6Fap3Pu1JKeOofGc7XF1xNE2VpiPlcAYdzGTRTDcXWGmPEDc+QOsfAtRCedV+02ZbonbgYW1RaGSZV/9EqBQ7UzcdI+iJXWTVOU5Elis/pjtRyNGZFkOXj8003ytBAIxWf0xxQqAE6iKWAr9FpWRHKJYW58yQNJxsWo7r0lvw/9zk9R7iJOGcS9XDMDYlCiVskBJmxt7jD4+jNmbJBOLRm0N7NFvlOVAVvLc2rB2ChQk+OVZ4TwO3JvrpyEBTrjEke7E0kTp8izOWmqqwwTyWzFhnqD7wNWtPN9avsKoSgEkow3QYf+jMJxfeFku2UQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2997; X-Forefront-PRVS: 00872B689F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(13464003)(33646002)(116806002)(61296003)(7736002)(1456003)(7846002)(1556002)(305945005)(5660300001)(81166006)(230700001)(6666003)(81156014)(77096005)(19580405001)(62236002)(42186005)(86362001)(50466002)(586003)(19580395003)(2906002)(6116002)(66066001)(84392002)(4326007)(68736007)(81816999)(23756003)(8676002)(81686999)(105586002)(92566002)(14496001)(44736004)(50986999)(4720700003)(76176999)(47776003)(9686002)(189998001)(5001770100001)(106356001)(97736004)(44716002)(101416001)(50226002)(3846002)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2997; 23:Jy07QRqebIhlRRHfpPetkPxoBWBGuqj+/K9rU?= =?iso-8859-1?Q?fIe0FaGRRlH4DVSEeT9LHSFrKFsILh7xqkPwvpNgXH/Zr7Y1cscejV0ND9?= =?iso-8859-1?Q?mYlF7mJ07ymvFo95F9BlSufF/kTG12DcHcw/COhBamNHdTvCUSmPmv78fd?= =?iso-8859-1?Q?twPLdE0yK82M1d7/SDmkK3+arRtF/bCXXbaj0oy83tqBE3jNgvL733iAPg?= =?iso-8859-1?Q?heTomNTgh77aLNcAXb9F2DuNJDRdrrJWqzzoELnjx8LXDkW8bxXTJhnEiB?= =?iso-8859-1?Q?9ugEBxI4eDaTnh754fvJTBLjrWbqv23SJcIOS3CaE5y618/KVFnEZi57IX?= =?iso-8859-1?Q?7VMiKT/ReXGfrKO5krYqd/Mdc44Tx6JUzZJydMhZ4MrQ1gC3Fy2EFgb7US?= =?iso-8859-1?Q?NG04D32c7y9qtks0SphIGR0VdV9V8fyCTG+ulIabiCH65fTzQRPvEPqlps?= =?iso-8859-1?Q?C35B2n3tLFQ0DcRcKwJGuxhaztsudIwoFfrJ++RnoKx0iWzn9KIq/SAYWa?= =?iso-8859-1?Q?lqQrAlzmu9UaQ4mSbP9lElNCD4IxISENHs4WPL0vuKYNj+thq58oyEHv5T?= =?iso-8859-1?Q?4AGcLWoMFJnZNFEkESKTAZyV1+Z8gIlteq1BeVLFPPEv0rnX3mKF+NQz1N?= =?iso-8859-1?Q?Hj+/Z+lU0XcZaS+nJZzc9tdNzV23rpBv2FJ6uDGjKABEVmNqYbwAYWa6ir?= =?iso-8859-1?Q?RsosOoWPteueI9mB415sWjXGrmEdFQ+KfY6J4Q2M5VAMvX3J14OFt9dhCU?= =?iso-8859-1?Q?AcKWXmaSTRs5K65lFJR0/n1LnnNq8TrBDyEV4q5ksKxGXbWI5IYRvKxJBL?= =?iso-8859-1?Q?vQIJmQ0SeSaaCwOLgxbT8mKZNk+yt2sMcXo82KEmVL+CZUTsCcJxkoSB5M?= =?iso-8859-1?Q?vCxKd2A3vPAVrWeJs+X2liOpU53p/iRhacDP8+Z0mHclMVnwo5HyidLW+L?= =?iso-8859-1?Q?zlPCm08BxlG76mcAF3phSCJWZ7VJS4fV+UXGBW6jN0M21VYnyByIkxYDPD?= =?iso-8859-1?Q?Bp5XMm91Dy0Mjuf/85OKDHRdB4ZIgJGBRQTkL5URyDXb+W/iyHe5k+PCKt?= =?iso-8859-1?Q?woWWGtqrkqrI8qu6ispcaz5R8CwZB+ttEz5LzLBLs9jux+k3vb/WUZonR3?= =?iso-8859-1?Q?tkfgjE1OMjFwaxWMOwAJve5FEitK3p5d4nViyWWnK/CpW1uP/uExFcHK89?= =?iso-8859-1?Q?3ywFV/46CWyWuIbJfqXNhHNYK3gNnY8W55QNBeGgCvXKiF8wdE79ykj6lg?= =?iso-8859-1?Q?uiXAUeC8UtOjv/8TA8YsHhi0jt4GHjaHd1F9uIPUzWWQR93NffPCXGvIH4?= =?iso-8859-1?Q?3i0dh1gviAieNPY8ot/bCq4Jw7e6WnWYUAole4UAMgs2nV0eYe8rB5ZxKr?= =?iso-8859-1?Q?Sw823EVvH6G9D/+Yc3n9XpVNKZp8gMtm1ThVUCMCCNbsH9fPEUHZkkkYZs?= =?iso-8859-1?Q?zu2OBEuNhgWHQl0w=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:Dn2ZSuKI59Y27exXUXgUt0t+vIK21fbD7LcixYRuVLW77slKZdUXxueTMmj6Lvnot7hNM4NGO4jAT6yuuOI3jNh42NEIgom+/4IPp6YuEgSrwgwmoyJjjS0Q8J/Y6GB8MtN/8uQB1TH0zdOoh9NI+x2gX3oevfLxsyVf60qyEfBbUjsCC6vTnpx9sr7jJ9J4AAwXnVW+OCqgfplQf5fjvppZFSbLGMVE03ib0badUsVXs1QHmPwqIBEvijaXpremESunKpPNrc8WwxROIrRXurJZb1o5NPGxXVwZ5sMfgkBYiigzrZ3bEwoeUb9dOG8w; 5:VD+Nkcf4vpXdgtzELxReb9fkRsT4WWX6Z1spGTbJvHkZ4/soXhwy9nqc/JbHqkgs5/yDPjtMhGwVlYc2sSHO9DT0kcc8XgCoHLb6n4/1yUi3SvpKgPEyNFJB0SAC2SYyvrJ6h5dfnD3/j9KuomtfceNhZ9dL5K+8mVjsppjkB70=; 24:wUUoRUEv8r/HMvxt6RjQuknpQgSSTgnzAsSYQNyR6DekKeJhtgE4lvPUObMrEvTjZjWIw0RtcR/LPE7uq26rWZR3I09xGC/7O5N1Yvp5scA=; 7:RXmlrZoDTQUg4jT6uN5WbZ64CC4kFg9KMZRPrudhAkCgRrXu1VZvAw+pH1EvMpRrvKw+W8JaMOjWQhsf1CmcMXD0axrNQ20KWhqW9ygMONT4UMKYB99qyU+MsKmij7Xbe5BJtXYfMeLgmiHh3qmko4cfz6x3juMaNC34dvjOfUMqkYZHf0Gtjd37Yc6czLxrbzXW6Teq2yxZLDFZiZbNGxn4EkqFHYGQ7gokr2zVURca1lc2A7MWDSHsv3oiRbwywww1sLcNFU7ZGjz5U9HilM2QSDvPpcJB+qlM/qKBk9ZdT3id9gD6DOZkvpQ1X2DicXYGXy7jioh3qpx8zMNgoQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2016 10:02:27.3456 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997 Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 10:02:37 -0000 Um Alan is right to pick up on the style - philosophical - and the security - lack of. But do we want to change it all at this time? This is an Informational document describing the state of play as of some time past, perhaps not as far back as 1997 but not for 2016. It would require many changes to make it a 2016 Standards Track document but that is not what I see us doing except that is how I take Alan's comments. The analogy I have in mind is when SSL v3 was published, long after it had been superseded by anyone who took security seriously, but was needed as an RFC to refer to, although it would not pass muster because the security thereof was too weak. It would not have met the standards of the day but was published despite that. Tom Petch ----- Original Message ----- From: "Alan DeKok" To: "Warren Kumari" Cc: "opsawg@ietf.org" ; ; "opsawg-chairs@tools.ietf.org" X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99FB12965A for ; Thu, 6 Oct 2016 06:57: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, 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 kfq6rbvTaTIu for ; Thu, 6 Oct 2016 06:57:09 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 11BD3129685 for ; Thu, 6 Oct 2016 06:56:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 465AF1F02; Thu, 6 Oct 2016 13:56:48 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP8vabv6shDd; Thu, 6 Oct 2016 13:56:48 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 7F01E131C; Thu, 6 Oct 2016 13:56:47 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Alan DeKok X-Priority: 3 In-Reply-To: <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> Date: Thu, 6 Oct 2016 09:56:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:57:14 -0000 On Oct 6, 2016, at 6:00 AM, t.petch wrote: > Alan is right to pick up on the style - philosophical - and the > security - lack of. >=20 > But do we want to change it all at this time? Please show where I'm trying to change the protocol. > This is an Informational document describing the state of play as of > some time past, perhaps not as far back as 1997 but not for 2016. It > would require many changes to make it a 2016 Standards Track document > but that is not what I see us doing except that is how I take Alan's > comments. Then you're not reading my comments. I would like to implement historical TACACS+. I have *NO IDEA* what = to do for huge swaths of the protocol. I would like to deploy historical TACACS+. I have *NO IDEA* what the = security implications are of using it. > The analogy I have in mind is when SSL v3 was published, long after it > had been superseded by anyone who took security seriously, but was > needed as an RFC to refer to, although it would not pass muster = because > the security thereof was too weak. It would not have met the = standards > of the day but was published despite that. I'm not asking that the protocol be *fixed* in this document. I'm = asking that it be *documented*. That shouldn't be hard to understand. = I've been saying it for about a year now, for anyone who bothers to read = my messages. I'll note that RFC 6101 is "Category: Historic", and has substantial = text about the security (or lack thereof) of the protocol. It has = substantial text about how the historical protocol works. I'm suggesting = we do the same here. I'm suggesting the the TACACS+ protocol be documented as designed, in = sufficient detail that someone can read the document and create an = inter-operable implementation. I'm suggesting that the TACACS+ = protocols security (or lack thereof) be documented. Which is (so far as I'm aware) still IETF practice for informational = specifications. If the goal for the document is something else, fine. Update the = document to say that. Something like: "This document attempts to specify the historical TACACS+ protocol. = However, there are many portions of the protocol which are = under-specified or unspecified. We cannot second-guess twenty years of = practice here. As a result, this specification is incomplete, = under-specified, insecure, and should not be used by anyone to implement = anything. Please wait for the Standards track document to get the = actual TACACS+ specification that people can implement". If the document can be updated with such text, I'll withdraw all of my = review comments. But I predict that the document won't pass security = area review. And they'll make all of the same comments as I've made = here, with a recommendation that the document not be published until = it's fixed. Alan DeKok. From nobody Thu Oct 6 08:06:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0611129688 for ; Thu, 6 Oct 2016 08:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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=-2.996, 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 Sbaz-VmApDtA for ; Thu, 6 Oct 2016 08:06:28 -0700 (PDT) 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 A83EA1296A4 for ; Thu, 6 Oct 2016 08:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3211; q=dns/txt; s=iport; t=1475766373; x=1476975973; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+/T3rm4iTVqDgdmTW5BghW1clCJG9BngMWxZaVuul9Y=; b=GjFiwHkf2elpExdn7/t40KxGTpL7/xLFgP5GxKwGEJSRFwVva0sLkice Vphi0Icy2HrVZ5PpUa9sRFemg4o3EaD+r4QeS+W6jjAajOG9xNP1dB8Rp pGui4LpZhjQv/g4bYPR1BQ/j/ezbYJ+DH85Bdqmt1FoG6anqi2KiAv0y9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AwBDZ/ZX/49dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz0BAQEBAR6BUwekKZIdgg+CC4YgAoFyORMBAgEBAQEBAQFeJ4RiAQE?= =?us-ascii?q?EeRACAQgYLjIlAgQBDQWITr5MAQEBAQEBAQEBAQEBAQEBAQEBAR+LEYoJHQWOd?= =?us-ascii?q?YUwhVoBj3qBboRngzeFaIcPhWiDfgEgAjJLhFpyh0CBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,454,1473120000"; d="scan'208";a="331756047" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2016 15:06:12 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u96F6C2m027986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Oct 2016 15:06:12 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Oct 2016 10:06:12 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Oct 2016 10:06:12 -0500 From: "Douglas Gash (dcmgash)" To: Alan DeKok , "t.petch" Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. Thread-Index: AQHSHbl9KZdR5oDUSkK9CBlvcR3x3qCaX9MAgABN84CAAMn/zYAAd7GA Date: Thu, 6 Oct 2016 15:06:12 +0000 Message-ID: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> In-Reply-To: <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.93] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 15:06:32 -0000 Hi Alan, Thank you for your detailed review so far. When we get the last instalment, we=B9ll categorise the comments and respond. Best regards, Doug. On 06/10/2016 14:56, "Alan DeKok" wrote: >On Oct 6, 2016, at 6:00 AM, t.petch wrote: >> Alan is right to pick up on the style - philosophical - and the >> security - lack of. >>=20 >> But do we want to change it all at this time? > > Please show where I'm trying to change the protocol. > >> This is an Informational document describing the state of play as of >> some time past, perhaps not as far back as 1997 but not for 2016. It >> would require many changes to make it a 2016 Standards Track document >> but that is not what I see us doing except that is how I take Alan's >> comments. > > Then you're not reading my comments. > > I would like to implement historical TACACS+. I have *NO IDEA* what to >do for huge swaths of the protocol. > > I would like to deploy historical TACACS+. I have *NO IDEA* what the >security implications are of using it. > >> The analogy I have in mind is when SSL v3 was published, long after it >> had been superseded by anyone who took security seriously, but was >> needed as an RFC to refer to, although it would not pass muster because >> the security thereof was too weak. It would not have met the standards >> of the day but was published despite that. > > I'm not asking that the protocol be *fixed* in this document. I'm >asking that it be *documented*. That shouldn't be hard to understand. >I've been saying it for about a year now, for anyone who bothers to read >my messages. > > I'll note that RFC 6101 is "Category: Historic", and has substantial >text about the security (or lack thereof) of the protocol. It has >substantial text about how the historical protocol works. I'm suggesting >we do the same here. > > I'm suggesting the the TACACS+ protocol be documented as designed, in >sufficient detail that someone can read the document and create an >inter-operable implementation. I'm suggesting that the TACACS+ >protocols security (or lack thereof) be documented. > > Which is (so far as I'm aware) still IETF practice for informational >specifications. > > If the goal for the document is something else, fine. Update the >document to say that. Something like: > > "This document attempts to specify the historical TACACS+ protocol. >However, there are many portions of the protocol which are >under-specified or unspecified. We cannot second-guess twenty years of >practice here. As a result, this specification is incomplete, >under-specified, insecure, and should not be used by anyone to implement >anything. Please wait for the Standards track document to get the actual >TACACS+ specification that people can implement". > > If the document can be updated with such text, I'll withdraw all of my >review comments. But I predict that the document won't pass security >area review. And they'll make all of the same comments as I've made >here, with a recommendation that the document not be published until it's >fixed. > > Alan DeKok. > From nobody Thu Oct 6 09:21:46 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280A1129667 for ; Thu, 6 Oct 2016 09:21:45 -0700 (PDT) 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=btconnect.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 I6UIWZSl4NsK for ; Thu, 6 Oct 2016 09:21:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0110.outbound.protection.outlook.com [104.47.2.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5A9129555 for ; Thu, 6 Oct 2016 09:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0KK22BG5Id1FFtcnudqWWMGrW+ajDoTbSYwZGC0V74E=; b=OFB5Org6itY3m+/yYk/PtAS9AbmBdq5Y3pTaULBE4a6W1+HlAbhrHdgv90mlfD5d4NgHhpsCbaa1N1cpFOw7WfPj2+9oUjisNdfVhe8ZLZTd3ziEtExQ3AiO6ARIIGKbU9Q0efuSNG22/CPP9oi9hrecOxv21Y03bUO99L1I+Aw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.159.102.255) by DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Thu, 6 Oct 2016 16:21:37 +0000 Message-ID: <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> From: t.petch To: Alan DeKok References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> Date: Thu, 6 Oct 2016 17:19:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.159.102.255] X-ClientProxiedBy: AM4PR0902CA0023.eurprd09.prod.outlook.com (10.171.89.33) To DB6PR0701MB2999.eurprd07.prod.outlook.com (10.168.84.137) X-MS-Office365-Filtering-Correlation-Id: c5110605-2b56-4f83-afc3-08d3ee04d916 X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 2:lKMezH0f+79XfpqbbwJMiWPkbN4lbQhEdfygojmEU9fLRzOWyyhDobm3RsFi0PpEJKmoG/GZX9CWQFocKj6zPL3TcmnDa/k2+4vUgCLYA/6pz0i6f61WVwnv6tBxbF3fZqH6peVxwTV1yJXiIIapnQ+YtQWkJUN1uubZVXPoghSuOa/q8WhYxnnkMPhenOlejokm8VmIQ+Qa9UhRc5CqwQ==; 3:6FxoDV+mugSiY2Q6K8B9K81OO0xw41mYI3lMAXtr6WOLIIDHwkTwLDRD2nJXkVRu0e7R2SQKLjvdJiYuPYo6f25SJ6PRpB756MWYvjOt1xPNgkIpRziTUEfazOKeH5WV5wj+cK5eqCUREXYywxYYew== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 25:ItEGcZriak33KuDuOg/tNLp1T/ZeS0wc6DkjD8C+52paK9rx8kOtxO5JkayOFpSV1sakIpzfCZ5sEFVjeHQveNvZMLCUhZ8oWVqqswx5pB4sN3kcKIMZhDiBe3ersbpncqPrzmmocrGw76ZRiRPweuXpdParUcZTYXYzu+ztYJQiNCKan+7SGcUQrvlAs6XFiIgiLekPz4oNdjDuIaa0L+69MfvSHMo6/O4arzWOeprcCilctN0ULugIMfWeAB71VYhGrO0vTtDtziqquEj+5kIabdn8lgFJb+0KjoWz3T1ZFN11NXcnYJD+wyFpI9mPawRAahssOq2s6NwawGBTOUljAXbsUKd6VJ3/aQdfYfVHug5PW3zmw1DX4TPihnboDr87gthssstmFOZeGind3zTlVzGree2REtD5ILV9E5ZQGerJCuOOb4R1Wx2OY7FDqTyfsRkIc9VA/D4T2mwi4dZZNWnYIezlbP3s96cXdz2D6WZRhJ3L9XpR/I0N8CAXdN+2X2yqMaBSg1+wJfQEVpFwjRT6YCE45tV5GmEwg3dXxNUcYDLByVxc0J5glsQP8XeOcs1AYgwBrHopFtCAJkFXlmbjsWgh7p/LHFVlOffehwne+wSCaKicLX3H1/E7LW/OiK3iUuW8aHxBh9AnxAPO00r9veGlM0Fi9TI4P2/7FrSxX97vEetndWk+aPOY+vy8Ng2uAaZMZSp6/K9I6iZkeGXvlZjY/1QuDREoaOmaZx51+ozPPqU9Dh0gb5ny X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 31:R3BKeK4eL1w4Ev1YMGesNmJe8kWHAPL6gPpDWfBmdxX0fUTHeH8e7gyu3TEwF5LOSaxh51N+fXyPrsU+7usTi0idzA5dGXLZ/pfT2NUbljrUfP3I4kTNZK4RMGnH9NNBiKw+y6x5dZBPumzlpoJcGFm0zjEHdiq7hcrqhdff0LE3BRxNcNleqgZJOoi8hskQ8czgN8Vup7d1DH2ecEoIOStiplygBjkpko+q4nXj7pwwsSaUe3J+OzDM2SLuz5jS; 4:a4IxnLlzmLrdroDUPkpkR4RPORt//fkCfI18XzZ0JGKWfHB+45IMT05xkAdfFyIZFUTvLSnRoktASpZeHf8rqq/G7CsWZ4CxDR8hmR3eDGVR3CCPYs3cUCiJW+Zj/y5/fm5+ZOGrw9MdNJVoUzx3r00zrAb0RZoxpAkdR05Drq9izBR0GV5dKhNH3S929IA6A8fPB4Hks/JGl3T4Z0iPN0C7Pfw/IZRSImLtD9FmslxdYXrzFImljNyTuq33GPI+v5mqlav8+p1f/oQkTcQ3udLvqIeRwbBgqAKrwp4xzuR53/CILnQ03OEcIqe08G+OQo+toWB6C7wK0krYgX7UvC+lzPiVyHhpHK2NzlzqxsO4RlL3Z40EWFjRXYwLclPCiYtZrc1g1e6SJ3EsJeEmCJiw+stPfieSwnC2Ai/rKFJUad95XM4nJ58l8EegPm+6E6ODgdW7atNf70jOfGsZ7l4cpOPhDjuZ288X74+0DfE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Forefront-PRVS: 00872B689F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(199003)(24454002)(377454003)(13464003)(50226002)(6666003)(105586002)(8676002)(81156014)(81166006)(14496001)(66066001)(68736007)(42186005)(9686002)(61296003)(101416001)(33646002)(47776003)(110136003)(5660300001)(97736004)(62236002)(44716002)(23756003)(44736004)(81686999)(6116002)(230700001)(6916009)(50986999)(76176999)(7846002)(7736002)(19580395003)(19580405001)(3846002)(586003)(305945005)(81816999)(1456003)(86362001)(4720700003)(77096005)(92566002)(106356001)(2906002)(93886004)(116806002)(4326007)(50466002)(84392002)(1556002)(189998001)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2999; 23:KHa1nW3MqLczFIdzMHTtayzuwUZsJDPNE0RHV?= =?iso-8859-1?Q?RTlBbsuuUFTHb6OAI6qA6xUmYeOSpfMcRHp3xRvh7SiNuUPa1PsPQpDI65?= =?iso-8859-1?Q?4ShbwUfp6CvjAie2UzBth0kevnhZec95hCExOh/xgx9MK4Ky4PG/e7BgWx?= =?iso-8859-1?Q?ptjqVAwEPGjse1wmV2z8Sb12qpfMFbhUQgyrm3PimzpgmIuk5E4bw7amkO?= =?iso-8859-1?Q?oUa1t2g5R8LAFogwNr0n5p8g7jXSxmTA7Uu00Z5B1rFbsDC2A0KmiKDqX7?= =?iso-8859-1?Q?at+bg6DyLRo2ZXJXr75nXe4Mau0vQ4d6eZx+7UZNCcaN/XOeSvXUIApnid?= =?iso-8859-1?Q?3ZghKH83w0zcKKWH6VCCyw9MVEXmFMB6w6t62oz+evKJulRJ6PIrgOK4S+?= =?iso-8859-1?Q?XmCx5oEsbYFjsiZJ8KM5bKRfaesgM12PypBW7RSTtClerStEhHsTMYQ6j1?= =?iso-8859-1?Q?gsuOKr1Dd6B3FWBYWNr7ZzLmUQnYOG9uA9eKOUbfALbmH7YR0ea35+7NiM?= =?iso-8859-1?Q?M07cObV4tlQngB93m8UGraiK2W0Uw4aq9orBYLzAupBUVzbyYhArSt53sh?= =?iso-8859-1?Q?kTi5amQlqI3MavFw93UvbcUGaA+WbBDo0pApzBaqPCTTqJNmR1rRCYh7Iy?= =?iso-8859-1?Q?ucFWI8MA+HqRPrklgnaujbHC+noGHK3C6DEj+LOIjmMZcIT6jjmcdrIhsh?= =?iso-8859-1?Q?qvVc7aZ7i3So+7OA5PtAXBnZWW2rrvS4qGYrUEFTJKljKQHig9KMrTt1xl?= =?iso-8859-1?Q?+5zyFP4NP3uHEEOS4A2V8N3o6tbwuqdwvABMHu2Lisfyd6wcdhmK5RQfbz?= =?iso-8859-1?Q?gQDHJ8stR9h6eXJqg797x7jbwFooskGhZBhnNhwFrpC1EWFPqfR+u4eOOZ?= =?iso-8859-1?Q?hwDwJvQKQUDIb9AUmcjJx4rFjWZD6N2pnF8MalI6YRD3JaJYDMupt/+DqM?= =?iso-8859-1?Q?VCOGd06hwEeA507y5ylwHDaHp8QPLj+GPyeAmKnRJH/iv/MUtuvHKJw5t0?= =?iso-8859-1?Q?z1btD0OfXAZfNjKKF0wmY0XG0RzvYVZRYV8MQS02AD/IAW+eJIknvaUXwG?= =?iso-8859-1?Q?BQ7UjWU3iN/R+v6X4+aXBO247FtNGd/ewN9ZZCqfvae7w8ze+4x0Wt2Wtl?= =?iso-8859-1?Q?tgZrjIsPdBj0Qjuazclc5XhrXYct/vp87KEwKISXsLIdFnEKCr0BX4lEaQ?= =?iso-8859-1?Q?aD3F0cyN3B5ekTJKFtg0f58myQmkQ7nwjIMoqIFKT3xoGXMTfvAkxRAKMe?= =?iso-8859-1?Q?w0kEUdVbL+9QCKYcksbMAyuhMd8Dn9Rrz7UOHXeMUY14/G1X8vSDh5B+ky?= =?iso-8859-1?Q?1U2MuKxJm+VJSd3s7LkF+s4UT09nGOFzoC11pccZmgKIU+tWkZG1gzjd+9?= =?iso-8859-1?Q?du1qfduDXmUOdWS3O8a8Ei1SWVCcZ5wvUdziaLsasl4L9HvTyAfQO2kdXH?= =?iso-8859-1?Q?s2zJPIIlOOCGJ9qtImJFWQ41WpQYNL6JOpW4jcOeX3o/cja2ORWgIFHBnc?= =?iso-8859-1?Q?aArWrsldNkG11N2yNEd+tg8ZCbSKAUgxHb3QTlEnKvn?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:HjplPtnaYGo8Mdl7HKcK3T6CacLEGKNiDRa1LE3yOrvmpt/7NEmcdX9D1UZY+QUijimD4p1YxVQnsdZkIedv/c3Ru7psMmQl/bfG/DFyh/QA3MthZcwQNh17n011kpnn+8lw6K8N9w23H8ing59hht4kvJjbKCr0NkXdqr4HJFSCizaK5w7JDfZlN0Hg26rBu5q4M1lSG2upIoX9o8JYUTGAVPvuXKCjeUUCQoi4ibhiTUFehTXjekX2qF77/hzFhtIQWoQ/8WnCr0qD5rwGPcGZFCxSCPf22Q0joZp06/5al/VesL2NS65Ah63y/yoW; 5:pJ7bFdfT3Lle+/pGEE9kedMgZcxi+DRgpmAoBIO7vfj4t47Eb3PKJrwUryh55fg/wRVzWc0oPQfs4LKcj0DhJoebZ4Y+ScjS/6Q2tDN8Y6b8TiVALfvl/OinLKbSw+3mjQLEMSzoLoo3L1wOsDVU9RuVTBgkGX+Dw2osYDr1q1Q=; 24:+7a47wQqT1rtY3iqoJeJyoRBjxI9GzlzwMyphTQ8tVI/Q4Cyse+pn0mzdTv2QZNpCzIZyedTxVHUwlHPJ4u0TEjtYeB3l944HVLW0Ea4+G4=; 7:TzNreb5kn1c8UE55TL4eEodllOwwQ0cguOrjsM+Rm095E68MaL4lCC2YsiTerIxPH61D5poncxEAO84lRzGD+pKUlRsp9fpZnKKJlrNKu49vHhPnBwWOs6KXpu92Fh4CQgoR17BcxTnMoZuGxJTJ4xnymoVLjL3A+TXEFa9Uwa1kprZwwgrJV7DXU4qlmj+MsTmCISSAr3ZoPWaOWR97LUB4Yowp7twxcvgvkjTed7IhGCEN3g6/dLN6Mdxa4mayzBVQPXf9NhAvfx8yZLWzL44Fv0UyxbUixeQJEYYJnHPRTh3QFGD9H46W2XhcEeiPAvEsZpN2bzIsu8qKG4jFEA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2016 16:21:37.3810 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 16:21:45 -0000 ----- Original Message ----- From: "Alan DeKok" Sent: Thursday, October 06, 2016 2:56 PM On Oct 6, 2016, at 6:00 AM, t.petch wrote: > Alan is right to pick up on the style - philosophical - and the > security - lack of. > > But do we want to change it all at this time? Please show where I'm trying to change the protocol. Alan You are not, and I did not mean to imply that you were. I mean that your changes seem to me reflect a different approach, a different style which I do not see as that of the authors. I see the existing style as unusual, but not wrong, and am content to leave it as is for an Informational RFC which documents what is, or perhaps what has been. You used the word 'philosophical' and I agreed. So I would keep changes to the minimum, omissions or contradictions and those required by the publication process (such as splitting References into Informative and Normative). It is, after all, WGLC. On Security, I would invite the chairs to ask for an early review by the Security Directorate, explaining the context of this document, asking them how much more is needed and how it should be expressed. It might not be very much although my experience is that I never know in advance what they are going to come up with. Tom Petch > This is an Informational document describing the state of play as of > some time past, perhaps not as far back as 1997 but not for 2016. It > would require many changes to make it a 2016 Standards Track document > but that is not what I see us doing except that is how I take Alan's > comments. Then you're not reading my comments. I would like to implement historical TACACS+. I have *NO IDEA* what to do for huge swaths of the protocol. I would like to deploy historical TACACS+. I have *NO IDEA* what the security implications are of using it. > The analogy I have in mind is when SSL v3 was published, long after it > had been superseded by anyone who took security seriously, but was > needed as an RFC to refer to, although it would not pass muster because > the security thereof was too weak. It would not have met the standards > of the day but was published despite that. I'm not asking that the protocol be *fixed* in this document. I'm asking that it be *documented*. That shouldn't be hard to understand. I've been saying it for about a year now, for anyone who bothers to read my messages. I'll note that RFC 6101 is "Category: Historic", and has substantial text about the security (or lack thereof) of the protocol. It has substantial text about how the historical protocol works. I'm suggesting we do the same here. I'm suggesting the the TACACS+ protocol be documented as designed, in sufficient detail that someone can read the document and create an inter-operable implementation. I'm suggesting that the TACACS+ protocols security (or lack thereof) be documented. Which is (so far as I'm aware) still IETF practice for informational specifications. If the goal for the document is something else, fine. Update the document to say that. Something like: "This document attempts to specify the historical TACACS+ protocol. However, there are many portions of the protocol which are under-specified or unspecified. We cannot second-guess twenty years of practice here. As a result, this specification is incomplete, under-specified, insecure, and should not be used by anyone to implement anything. Please wait for the Standards track document to get the actual TACACS+ specification that people can implement". If the document can be updated with such text, I'll withdraw all of my review comments. But I predict that the document won't pass security area review. And they'll make all of the same comments as I've made here, with a recommendation that the document not be published until it's fixed. Alan DeKok. From nobody Thu Oct 6 09:35:36 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069DD1296A8 for ; Thu, 6 Oct 2016 09:35:35 -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, 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 hNjVj0M2bHGc for ; Thu, 6 Oct 2016 09:35:33 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E9A0912971F for ; Thu, 6 Oct 2016 09:35:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 29E671305; Thu, 6 Oct 2016 16:35:32 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUtZTIcxJVNt; Thu, 6 Oct 2016 16:35:32 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 70257C14; Thu, 6 Oct 2016 16:35:31 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=iso-8859-1 From: Alan DeKok X-Priority: 3 In-Reply-To: <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> Date: Thu, 6 Oct 2016 12:35:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 16:35:35 -0000 On Oct 6, 2016, at 12:19 PM, t.petch wrote: > You are not, and I did not mean to imply that you were. I mean that > your changes seem to me reflect a different approach, a different = style > which I do not see as that of the authors. I see the existing style = as > unusual, but not wrong, and am content to leave it as is for an > Informational RFC which documents what is, or perhaps what has been. = You > used the word 'philosophical' and I agreed. I see the existing draft as not documenting the protocol. That's my = main concern. > So I would keep changes to the minimum, omissions or contradictions = and > those required by the publication process (such as splitting = References > into Informative and Normative). It is, after all, WGLC. This doesn't address my concerns. Again, as an implementor, I have *no idea* what to do for huge swathes = of the protocol. On top of that, the current draft is silent on serious security = topics. e.g. Length of CHAP challenges is implied from the context. OK, = that's fine, but what are the *limits* on CHAP challenge lengths? A: none. CHAP challenges can be omitted entirely! > On Security, I would invite the chairs to ask for an early review by = the > Security Directorate, explaining the context of this document, asking > them how much more is needed and how it should be expressed. It might > not be very much although my experience is that I never know in = advance > what they are going to come up with. I've been a member of SAAG for a while now, and have done reviews, and = read many more. My prediction is that the current document will give = SAAG a heart attack, and they will refuse publication. There is a huge push to get the draft published. That's fine. What's = *not* fine is that it seems to me at least... that many people simply = don't care what's in the document. They don't care if the protocol is = badly specified. Or if it's insecure. In fact, these "features" could = be beneficial. Because it means that everyone can claim compliance. = And no one has to re-examine their implementation. That may sound harsh, but I just don't see any other explanation. If = we are going to document the protocol, then let's document the protocol. = If we're going to agree that we don't need to document the protocol = then put a huge disclaimer at the top of the draft saying so. Giving lip service to "document the protocol", while opposing attempts = to do so is unproductive. Alan DeKok. From nobody Thu Oct 6 10:34:55 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4141E129650 for ; Thu, 6 Oct 2016 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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=-2.996, 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 sGkTiTg2hSS7 for ; Thu, 6 Oct 2016 10:34:48 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FCE12967B for ; Thu, 6 Oct 2016 10:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4047; q=dns/txt; s=iport; t=1475775288; x=1476984888; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zp6KFOUsXm30lYJSYku7of2VY8x/l/f7xCvqrnQRI3A=; b=EG7It/9ozpFJH8zM99TCEmFnBgyojA65kbEynq4btvkJd2H/I6nA3yr5 X4iU2+m1T7UEuSUWCDqroM+8lug7ugIUfZWPG2K7wzpuMtKKk19lxdCGn O7aZHz5rmhRm+oAMt2ebuSV8wwrpEsR1yVrUp5akeF2BO0ettZq42WmXz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAQDhivZX/5NdJa1WBhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM9AQEBAQEegVMHjSuXAJIdgg+CC4YgAoF0OBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?iAQEEeRACAQgYLjIlAgQBDQWITr8CAQEBAQEBAQEBAQEBAQEBAQEBAR+LEYQ5h?= =?us-ascii?q?VAdAQSUJYVaAY96gW6IHoVojHeDfgEeNkuCaxyBU3KHQIEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,454,1473120000"; d="scan'208";a="331957032" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2016 17:34:47 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u96HYlVO028916 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Oct 2016 17:34:47 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Oct 2016 12:34:47 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Oct 2016 12:34:47 -0500 From: "Douglas Gash (dcmgash)" To: Alan DeKok , "t.petch" Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. Thread-Index: AQHSHbl9KZdR5oDUSkK9CBlvcR3x3qCaX9MAgABN84CAAMn/zYAALDV5gAB0/IA= Date: Thu, 6 Oct 2016 17:34:47 +0000 Message-ID: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> In-Reply-To: <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.93] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg-chairs@tools.ietf.org" , Andrej Ota , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" , Thorsten Dahm , "opsawg@ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 17:34:54 -0000 Hi Alan, Regarding the security concern, the approach we have with the current document is: 1) A statement that the protocol does not provide security in a modern environment.=20 2) The two common approaches to support T+ so that it may be used. 3) An indication that a version with built-in security is to follow, which will not require the mitigations in 2) (actually I suspect it may precede the info document ;-)) We need to make sure there is no ambiguity for 1) for any security review. No soft-peddalling. T+ provides the function, not the security. So=8A An approach we could employ is to enumerate all the ways in which 1) is true, including an analysis of each of the other components of the rest of the protocol, and their contribution to 1). My question would be: would this dissection of vulnerabilities and exploration of the attack vectors would help anyone from a security perspective, when we have established that the approaches 2) are required? I suspect that we=B9d probably miss some, and that may give implementors more comfort than is afforded by the clear and simple statement. Therefore, for security review, I=B9d suggest we keep the statement simple, as defined above. However, if this statement is not clear enough/correct in the document, then certainly, it should be clarified. Best Regards, Doug. On 06/10/2016 17:35, "Alan DeKok" wrote: >On Oct 6, 2016, at 12:19 PM, t.petch wrote: >> You are not, and I did not mean to imply that you were. I mean that >> your changes seem to me reflect a different approach, a different style >> which I do not see as that of the authors. I see the existing style as >> unusual, but not wrong, and am content to leave it as is for an >> Informational RFC which documents what is, or perhaps what has been. You >> used the word 'philosophical' and I agreed. > > I see the existing draft as not documenting the protocol. That's my >main concern. > >> So I would keep changes to the minimum, omissions or contradictions and >> those required by the publication process (such as splitting References >> into Informative and Normative). It is, after all, WGLC. > > This doesn't address my concerns. > > Again, as an implementor, I have *no idea* what to do for huge swathes >of the protocol. > > On top of that, the current draft is silent on serious security topics. > > e.g. Length of CHAP challenges is implied from the context. OK, that's >fine, but what are the *limits* on CHAP challenge lengths? > > A: none. CHAP challenges can be omitted entirely! > >> On Security, I would invite the chairs to ask for an early review by the >> Security Directorate, explaining the context of this document, asking >> them how much more is needed and how it should be expressed. It might >> not be very much although my experience is that I never know in advance >> what they are going to come up with. > > I've been a member of SAAG for a while now, and have done reviews, and >read many more. My prediction is that the current document will give >SAAG a heart attack, and they will refuse publication. > > There is a huge push to get the draft published. That's fine. What's >*not* fine is that it seems to me at least... that many people simply >don't care what's in the document. They don't care if the protocol is >badly specified. Or if it's insecure. In fact, these "features" could >be beneficial. Because it means that everyone can claim compliance. And >no one has to re-examine their implementation. > > That may sound harsh, but I just don't see any other explanation. If >we are going to document the protocol, then let's document the protocol. >If we're going to agree that we don't need to document the protocol then >put a huge disclaimer at the top of the draft saying so. > > Giving lip service to "document the protocol", while opposing attempts >to do so is unproductive. > > Alan DeKok. > From nobody Thu Oct 6 11:00:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F0012973D for ; Thu, 6 Oct 2016 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.193 X-Spam-Level: X-Spam-Status: No, score=-7.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, UNPARSEABLE_RELAY=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 8r587hmszGvF for ; Thu, 6 Oct 2016 11:00:24 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D744A12967C for ; Thu, 6 Oct 2016 11:00:23 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u96HtpNp033941; Thu, 6 Oct 2016 13:55:57 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Douglas Gash (dcmgash)" , Alan DeKok , "t.petch" Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. Thread-Index: AQHSHbl7hTNUTbboskaNjFefNq8+s6CaTxAAgABN8oCAAJkY1IAAhHQA///lekiAAEbgAIAAEJCA///EBQA= Date: Thu, 6 Oct 2016 18:00:07 +0000 Message-ID: <9AF97FE8-6D33-4445-B011-FB86FEF9F63C@ll.mit.edu> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.1.160916 x-originating-ip: [172.25.177.81] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3558607206_402865024" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060313 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:00:28 -0000 --B_3558607206_402865024 Content-type: multipart/alternative; boundary="B_3558607206_2049622239" --B_3558607206_2049622239 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable A protocol description needs to include: (a) what threats/attacks become po= ssible as a result of its introduction, (b) how the protocol defends against= [at least some of] them, (c) how the remaining attacks can be mitigated, (d= ) what are the remaining risks. =20 Yes, dissection of vulnerabilities and exploration of the attack vectors wo= uld help, especially if you provide ways to defend/mitigate. If you just say= =E2=80=9Cwhen you deploy X, anybody would be able to do Y and totally screw you u= p=E2=80=9D, somehow I doubt that such a protocol would be warmly welcomed. If you = don=E2=80=99t say anything =E2=80=93 it simply shows that you did not think of the secur= ity angle, and therefore the protocol is not ready even for the draft public= ation. =20 Why do you think anyone at SAAG would agree/permit to =E2=80=9Cbless=E2=80=9D/publish a= protocol that =E2=80=9Cdoes not provide security in a modern Environment=E2=80=9D? I=E2=80=99= d think that everybody realized by now that in today=E2=80=99s environment a proto= col that =E2=80=9Cprovides the function, not the security=E2=80=9D has no right to live,= and ideally should be stamped out =E2=80=93 but in any case not rewarded by recei= ving a =E2=80=9Cstandard=E2=80=9D status. =20 So hold the publication until your (3) comes along. In the meanwhile, enjoy= the vulnerabilities of your deployed implementations. --=20 Regards, Uri Blumenthal =20 On 10/6/16, 13:34 , "OPSAWG on behalf of Douglas Gash (dcmgash)" wrote: =20 Hi Alan, =20 Regarding the security concern, the approach we have with the current document is: =20 1) A statement that the protocol does not provide security in a modern environment.=20 2) The two common approaches to support T+ so that it may be used. 3) An indication that a version with built-in security is to follow, which will not require the mitigations in 2) (actually I suspect it may precede the info document ;-)) =20 We need to make sure there is no ambiguity for 1) for any security review. No soft-peddalling. T+ provides the function, not the security. =20 =20 =20 So=C5=A0 An approach we could employ is to enumerate all the ways in which 1) is true, including an analysis of each of the other components of the rest of the protocol, and their contribution to 1). =20 My question would be: would this dissection of vulnerabilities and exploration of the attack vectors would help anyone from a security perspective, when we have established that the approaches 2) are required? =20 I suspect that we=C2=B9d probably miss some, and that may give implementors more comfort than is afforded by the clear and simple statement. =20 Therefore, for security review, I=C2=B9d suggest we keep the statement simple, as defined above. However, if this statement is not clear enough/correct in the document, then certainly, it should be clarified. =20 Best Regards, =20 Doug. =20 On 06/10/2016 17:35, "Alan DeKok" wrote: =20 On Oct 6, 2016, at 12:19 PM, t.petch wrote: You are not, and I did not mean to imply that you were. I mean that your changes seem to me reflect a different approach, a different style which I do not see as that of the authors. I see the existing style as unusual, but not wrong, and am content to leave it as is for an Informational RFC which documents what is, or perhaps what has been. You used the word 'philosophical' and I agreed. =20 I see the existing draft as not documenting the protocol. That's my main concern. =20 So I would keep changes to the minimum, omissions or contradictions and those required by the publication process (such as splitting References into Informative and Normative). It is, after all, WGLC. =20 This doesn't address my concerns. =20 Again, as an implementor, I have *no idea* what to do for huge swathes of the protocol. =20 On top of that, the current draft is silent on serious security topics. =20 e.g. Length of CHAP challenges is implied from the context. OK, that's fine, but what are the *limits* on CHAP challenge lengths? =20 A: none. CHAP challenges can be omitted entirely! =20 On Security, I would invite the chairs to ask for an early review by the Security Directorate, explaining the context of this document, asking them how much more is needed and how it should be expressed. It might not be very much although my experience is that I never know in advance what they are going to come up with. =20 I've been a member of SAAG for a while now, and have done reviews, and read many more. My prediction is that the current document will give SAAG a heart attack, and they will refuse publication. =20 There is a huge push to get the draft published. That's fine. What's *not* fine is that it seems to me at least... that many people simply don't care what's in the document. They don't care if the protocol is badly specified. Or if it's insecure. In fact, these "features" could be beneficial. Because it means that everyone can claim compliance. And no one has to re-examine their implementation. =20 That may sound harsh, but I just don't see any other explanation. If we are going to document the protocol, then let's document the protocol. If we're going to agree that we don't need to document the protocol then put a huge disclaimer at the top of the draft saying so. =20 Giving lip service to "document the protocol", while opposing attempts to do so is unproductive. =20 Alan DeKok. =20 =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =20 =20 --B_3558607206_2049622239 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

A protocol description needs to include: (a) what= threats/attacks become possible as a result of its introduction, (b) how th= e protocol defends against [at least some of] them, (c) how the remaining at= tacks can be mitigated, (d) what are the remaining risks.<= /p>

 

Yes, dissection of vulnerabilitie= s and exploration of the attack vectors would help, especially if you provid= e ways to defend/mitigate. If you just say “when you deploy X, anybody= would be able to do Y and totally screw you up”, somehow I doubt that= such a protocol would be warmly welcomed. If you don’t say anything &= #8211; it simply shows that you did not think of the security angle, and the= refore the protocol is not ready even for the draft publication.<= /span>

 

Why do you think anyone at SAAG would agree/permit to “bless”/publish a pro= tocol that “does not provide security in a modern Environment”? I’d think th= at everybody realized by now that in today’s environment a protocol th= at “provides the function, not the security” has no right to live, and idea= lly should be stamped out – but in any case not rewarded by receiving = a “standard” status.

 

So hold the publication until your (3) comes along. In the= meanwhile, enjoy the vulnerabilities of your deployed implementations.

-- 

Regards,

Uri Blumenthal

 

On 10/6/16, 13:34 , "OPSAWG on behalf of Do= uglas Gash (dcmgash)" <opsa= wg-bounces@ietf.org on behalf of dcmg= ash@cisco.com> wrote:

 

Hi Alan,

 

Regarding the security concern, the approach we have with the current=

document is:

<= div>

 

1) A statement that= the protocol does not provide security in a modern

environment.

2) The t= wo common approaches to support T+ so that it may be used.=

3) An indication that a version with built-in security= is to follow, which

will not require= the mitigations in 2) (actually I suspect it may precede<= /p>

the info document ;-))

=

 

We need to make sure th= ere is no ambiguity for 1) for any security review.

No soft-peddalling. T+ provides the function, not the securit= y.

 

=

 

 <= /span>

So=C5=A0 An approach we could employ is to enumerate= all the ways in which 1)

is true, in= cluding an analysis of each of the other components of the rest

of the protocol, and their contribution to 1).

 

=

My question would be: would this dissection of vulnerabilities and

exploration of the attack vectors would= help anyone from a security

perspect= ive, when we have established that the approaches 2) are required?

 

= I suspect that we=C2=B9d probably miss some, and that may give implementors=

more comfort than is afforded by the clea= r and simple statement.

<= span style=3D'font-size:11.0pt;font-family:Consolas;color:black'> 

Therefore, for security review, I=C2=B9d sugges= t we keep the statement simple,

as de= fined above. However, if this statement is not clear enough/correct

in the document, then certainly, it should be= clarified.

 <= /p>

Best Regards,

 

Doug.

 

On 06/10/2016 17:= 35, "Alan DeKok" <al= and@deployingradius.com> wrote:

 

On Oct 6, 2016= , at 12:19 PM, t.petch <ietfc@btconn= ect.com> wrote:

= You are not, and I did not mean to imply that you were.  I mean th= at

your changes seem to me reflect a = different approach, a different style

which I do not see as that of the authors.  I see the existing st= yle as

unusual, but not wrong, and am= content to leave it as is for an

Inf= ormational RFC which documents what is, or perhaps what has been. You

used the word 'philosophical' and I agreed.=

 

  I see the existing draft as not documenti= ng the protocol.  That's my

main concern.

 

So I would keep changes to the minimum= , omissions or contradictions and

tho= se required  by the publication process (such as splitting Referen= ces

into Informative and Normative).&= nbsp; It is, after all, WGLC.

<= div>

 

  This do= esn't address my concerns.

 = ;

  Again, as an implementor, I = have *no idea* what to do for huge swathes

<= p class=3DMsoNormal>of the protocol.

 

  On top of that, the current draf= t is silent on serious security topics.

 

  e.g. Length of = CHAP challenges is implied from the context.  OK, that's

fine, but what are the *limits* on CHAP challe= nge lengths?

 =

A: none.  CHAP challenges can be omitted ent= irely!

 

On Security, I would invite the chairs to ask = for an early review by the

Security D= irectorate, explaining the context of this document, asking

them how much more is needed and how it should be exp= ressed.  It might

not be ve= ry much although my experience is that I never know in advance

what they are going to come up with.

 

  I've been a member of SAAG for a while now, and have do= ne reviews, and

read many more. =  My prediction is that the current document will give=

SAAG a heart attack, and they will refuse publication.=

 

  There is a huge push to get the draft published. =  That's fine.  What's

= *not* fine is that it seems to me at least... that many people simply

don't care what's in the document. &nb= sp;They don't care if the protocol is

badly specified.  Or if it's insecure.  In fact, these = "features" could

be benefic= ial.  Because it means that everyone can claim compliance. &n= bsp;And

no one has to re-examine thei= r implementation.

 

  That may sound harsh, but I just don'= t see any other explanation.  If

<= p class=3DMsoNormal>we are going to document the protocol, then let's document the protoco= l.

If we're going to agree that we do= n't need to document the protocol then

put a huge disclaimer at the top of the draft saying so.=

 

 &n= bsp;Giving lip service to "document the protocol", while opposing = attempts

to do so is unproductive.

 

=

  Alan DeKok.

&= nbsp;

 

_______________________________________________<= /o:p>

--B_3558607206_2049622239-- --B_3558607206_402865024 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUZwYJKoZIhvcNAQcCoIIUWDCCFFQCAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM7 SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQxMgQw72bIlIOySvb+zQ3s 8QPwuNJsfcGVEwB6Mfs1Lr1PVAuwJBNVPlPv3b0MlFpBYE6XMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MTAwNjE4MDAwNlowDQYJKoZIhvcNAQEBBQAE ggEAk2tOQkSCM4vLfAN6kdstYtY5w/Eno10bG3qXSKATByN9cZhs0FITfh2CZCyRpjqDiUAt 99Tc8/M1D6jZ0Db2uL8gr1jg0Zh1wYq36vmesX8wPwbQC4XIcpGGta/N0Z1QrjHkr2JTM84D 1UV8K2ulA3RLZe88TV/llBbL8X9mEn2cErgswX7oE643jlJr9/R1o/s8FzZnYSUb0rv2Ural IUDMJOjgCzSB05A8RSInkHeyEbB2WbZT7e9lUhT0RF5/2FOPFb/0YfA9v0JPfgKe0gG2Pwfq ZBPfO7zImpc69wGQZvsPwSu3/qSdZkL7dH0+KDAtMK4AE4bwuhiEDk4R2w== --B_3558607206_402865024-- From nobody Thu Oct 6 11:12:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D970129748 for ; Thu, 6 Oct 2016 11:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.516 X-Spam-Level: X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 lY4dzw35Xqmu for ; Thu, 6 Oct 2016 11:11:57 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7425C129745 for ; Thu, 6 Oct 2016 11:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43801; q=dns/txt; s=iport; t=1475777517; x=1476987117; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zKquBQ1Nc750djENncIi9dse7lJf2p7SSAaxOZinVAo=; b=WFnPYw8SFXbTi0HkQ/yVMFnW8LrnQqzV8YYGJyFlrvFjofSFULgFivLo 49ooc8D6YxI7akHIIMpeAxyM2+zggC9WAliua122P5pddxLsJ4jn7y8gq yI41YB9gDdOZpdmkNFb2obXWqYEY07WNjOGZW/JvGMYBu5ejpOBe/Pr75 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQBOk/ZX/5pdJa1WBg4LAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDBzYBAQEBAR5XfAeNK5cAlCyCCAMbAQqFMEoCHIFYOBQBAgE?= =?us-ascii?q?BAQEBAQFeJ4RhAQEBBAEBASBLCxACAQgRAwECIQEGAwICAiULFAkIAgQBDQWIT?= =?us-ascii?q?g6yI4xsAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWKDIEFhDklCYJkgj4dBZQlhVo?= =?us-ascii?q?Bj3qBbogehWiMd4N+AR42S4JrHIEYO3KGEQaBKYEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,454,1473120000"; d="scan'208,217";a="332687075" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2016 18:11:56 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u96IBuoc013881 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Oct 2016 18:11:56 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Oct 2016 13:11:55 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Oct 2016 13:11:55 -0500 From: "Douglas Gash (dcmgash)" To: "Blumenthal, Uri - 0553 - MITLL" , Alan DeKok , "t.petch" Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. Thread-Index: AQHSHbl9KZdR5oDUSkK9CBlvcR3x3qCaX9MAgABN84CAAMn/zYAALDV5gAB0/ID///ZagIAAFAqA Date: Thu, 6 Oct 2016 18:11:55 +0000 Message-ID: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> <9AF97FE8-6D33-4445-B011-FB86FEF9F63C@ll.mit.edu> In-Reply-To: <9AF97FE8-6D33-4445-B011-FB86FEF9F63C@ll.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.93] Content-Type: multipart/alternative; boundary="_000_D41C51CD195431dcmgashciscocom_" MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:11:59 -0000 --_000_D41C51CD195431dcmgashciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLCB0byBwcm92aWRlIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wgd2l0aCB0 aGUgc2VjdXJpdHkgd2FzIHRoZSBvcmlnaW5hbCBwbGFuLiBJbiBmYWN0LCB0aGF0IHdhcyBob3cg dGhpcyBwcm9jZXNzIHN0YXJ0ZWQuDQoNClJldmVydGluZyB0byB0aGF0IHBsYW4sIG9yIGEgbW9k aWZpZWQgZm9yIG9mIHRoYXQgcGxhbiwgd291bGQgYWx3YXlzIGJlIGFuIG9wdGlvbiwgaWYgcHJl ZmVycmVkIGJ5IHRoZSBncm91cC4NCg0KRnJvbTogIkJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBN SVRMTCIgPHVyaUBsbC5taXQuZWR1PG1haWx0bzp1cmlAbGwubWl0LmVkdT4+DQpEYXRlOiBUaHVy c2RheSwgNiBPY3RvYmVyIDIwMTYgMTk6MDANClRvOiBEb3VnbGFzIEdhc2ggPGRjbWdhc2hAY2lz Y28uY29tPG1haWx0bzpkY21nYXNoQGNpc2NvLmNvbT4+LCBBbGFuIERlS29rIDxhbGFuZEBkZXBs b3lpbmdyYWRpdXMuY29tPG1haWx0bzphbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPj4sICJ0LnBl dGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+DQpD YzogImRyYWZ0LWlldGYtb3BzYXdnLXRhY2Fjcy0wNUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1vcHNhd2ctdGFjYWNzLTA1QHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtb3Bz YXdnLXRhY2Fjcy0wNUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vcHNhd2ctdGFj YWNzLTA1QHRvb2xzLmlldGYub3JnPj4sICJvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0Bp ZXRmLm9yZz4iIDxPcHNBV0dAaWV0Zi5vcmc8bWFpbHRvOk9wc0FXR0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW09QU0FXR10gU3RhcnQgb2YgV0dMQyBmb3IgVEFDQUNTKyBkb2N1bWVudC4NCg0K QSBwcm90b2NvbCBkZXNjcmlwdGlvbiBuZWVkcyB0byBpbmNsdWRlOiAoYSkgd2hhdCB0aHJlYXRz L2F0dGFja3MgYmVjb21lIHBvc3NpYmxlIGFzIGEgcmVzdWx0IG9mIGl0cyBpbnRyb2R1Y3Rpb24s IChiKSBob3cgdGhlIHByb3RvY29sIGRlZmVuZHMgYWdhaW5zdCBbYXQgbGVhc3Qgc29tZSBvZl0g dGhlbSwgKGMpIGhvdyB0aGUgcmVtYWluaW5nIGF0dGFja3MgY2FuIGJlIG1pdGlnYXRlZCwgKGQp IHdoYXQgYXJlIHRoZSByZW1haW5pbmcgcmlza3MuDQoNClllcywgZGlzc2VjdGlvbiBvZiB2dWxu ZXJhYmlsaXRpZXMgYW5kIGV4cGxvcmF0aW9uIG9mIHRoZSBhdHRhY2sgdmVjdG9ycyB3b3VsZCBo ZWxwLCBlc3BlY2lhbGx5IGlmIHlvdSBwcm92aWRlIHdheXMgdG8gZGVmZW5kL21pdGlnYXRlLiBJ ZiB5b3UganVzdCBzYXkg4oCcd2hlbiB5b3UgZGVwbG95IFgsIGFueWJvZHkgd291bGQgYmUgYWJs ZSB0byBkbyBZIGFuZCB0b3RhbGx5IHNjcmV3IHlvdSB1cOKAnSwgc29tZWhvdyBJIGRvdWJ0IHRo YXQgc3VjaCBhIHByb3RvY29sIHdvdWxkIGJlIHdhcm1seSB3ZWxjb21lZC4gSWYgeW91IGRvbuKA mXQgc2F5IGFueXRoaW5nIOKAkyBpdCBzaW1wbHkgc2hvd3MgdGhhdCB5b3UgZGlkIG5vdCB0aGlu ayBvZiB0aGUgc2VjdXJpdHkgYW5nbGUsIGFuZCB0aGVyZWZvcmUgdGhlIHByb3RvY29sIGlzIG5v dCByZWFkeSBldmVuIGZvciB0aGUgZHJhZnQgcHVibGljYXRpb24uDQoNCldoeSBkbyB5b3UgdGhp bmsgYW55b25lIGF0IFNBQUcgd291bGQgYWdyZWUvcGVybWl0IHRvIOKAnGJsZXNz4oCdL3B1Ymxp c2ggYSBwcm90b2NvbCB0aGF0IOKAnGRvZXMgbm90IHByb3ZpZGUgc2VjdXJpdHkgaW4gYSBtb2Rl cm4gRW52aXJvbm1lbnTigJ0/IEnigJlkIHRoaW5rIHRoYXQgZXZlcnlib2R5IHJlYWxpemVkIGJ5 IG5vdyB0aGF0IGluIHRvZGF54oCZcyBlbnZpcm9ubWVudCBhIHByb3RvY29sIHRoYXQg4oCccHJv dmlkZXMgdGhlIGZ1bmN0aW9uLCBub3QgdGhlIHNlY3VyaXR54oCdIGhhcyBubyByaWdodCB0byBs aXZlLCBhbmQgaWRlYWxseSBzaG91bGQgYmUgc3RhbXBlZCBvdXQg4oCTIGJ1dCBpbiBhbnkgY2Fz ZSBub3QgcmV3YXJkZWQgYnkgcmVjZWl2aW5nIGEg4oCcc3RhbmRhcmTigJ0gc3RhdHVzLg0KDQpT byBob2xkIHRoZSBwdWJsaWNhdGlvbiB1bnRpbCB5b3VyICgzKSBjb21lcyBhbG9uZy4gSW4gdGhl IG1lYW53aGlsZSwgZW5qb3kgdGhlIHZ1bG5lcmFiaWxpdGllcyBvZiB5b3VyIGRlcGxveWVkIGlt cGxlbWVudGF0aW9ucy4NCi0tDQpSZWdhcmRzLA0KVXJpIEJsdW1lbnRoYWwNCg0KT24gMTAvNi8x NiwgMTM6MzQgLCAiT1BTQVdHIG9uIGJlaGFsZiBvZiBEb3VnbGFzIEdhc2ggKGRjbWdhc2gpIiA8 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgZGNtZ2FzaEBjaXNjby5jb208bWFpbHRvOmRjbWdhc2hAY2lzY28uY29tPj4g d3JvdGU6DQoNCkhpIEFsYW4sDQoNClJlZ2FyZGluZyB0aGUgc2VjdXJpdHkgY29uY2VybiwgdGhl IGFwcHJvYWNoIHdlIGhhdmUgd2l0aCB0aGUgY3VycmVudA0KZG9jdW1lbnQgaXM6DQoNCjEpIEEg c3RhdGVtZW50IHRoYXQgdGhlIHByb3RvY29sIGRvZXMgbm90IHByb3ZpZGUgc2VjdXJpdHkgaW4g YSBtb2Rlcm4NCmVudmlyb25tZW50Lg0KMikgVGhlIHR3byBjb21tb24gYXBwcm9hY2hlcyB0byBz dXBwb3J0IFQrIHNvIHRoYXQgaXQgbWF5IGJlIHVzZWQuDQozKSBBbiBpbmRpY2F0aW9uIHRoYXQg YSB2ZXJzaW9uIHdpdGggYnVpbHQtaW4gc2VjdXJpdHkgaXMgdG8gZm9sbG93LCB3aGljaA0Kd2ls bCBub3QgcmVxdWlyZSB0aGUgbWl0aWdhdGlvbnMgaW4gMikgKGFjdHVhbGx5IEkgc3VzcGVjdCBp dCBtYXkgcHJlY2VkZQ0KdGhlIGluZm8gZG9jdW1lbnQgOy0pKQ0KDQpXZSBuZWVkIHRvIG1ha2Ug c3VyZSB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgZm9yIDEpIGZvciBhbnkgc2VjdXJpdHkgcmV2aWV3 Lg0KTm8gc29mdC1wZWRkYWxsaW5nLiBUKyBwcm92aWRlcyB0aGUgZnVuY3Rpb24sIG5vdCB0aGUg c2VjdXJpdHkuDQoNCg0KDQpTb8WgIEFuIGFwcHJvYWNoIHdlIGNvdWxkIGVtcGxveSBpcyB0byBl bnVtZXJhdGUgYWxsIHRoZSB3YXlzIGluIHdoaWNoIDEpDQppcyB0cnVlLCBpbmNsdWRpbmcgYW4g YW5hbHlzaXMgb2YgZWFjaCBvZiB0aGUgb3RoZXIgY29tcG9uZW50cyBvZiB0aGUgcmVzdA0Kb2Yg dGhlIHByb3RvY29sLCBhbmQgdGhlaXIgY29udHJpYnV0aW9uIHRvIDEpLg0KDQpNeSBxdWVzdGlv biB3b3VsZCBiZTogd291bGQgdGhpcyBkaXNzZWN0aW9uIG9mIHZ1bG5lcmFiaWxpdGllcyBhbmQN CmV4cGxvcmF0aW9uIG9mIHRoZSBhdHRhY2sgdmVjdG9ycyB3b3VsZCBoZWxwIGFueW9uZSBmcm9t IGEgc2VjdXJpdHkNCnBlcnNwZWN0aXZlLCB3aGVuIHdlIGhhdmUgZXN0YWJsaXNoZWQgdGhhdCB0 aGUgYXBwcm9hY2hlcyAyKSBhcmUgcmVxdWlyZWQ/DQoNCkkgc3VzcGVjdCB0aGF0IHdlwrlkIHBy b2JhYmx5IG1pc3Mgc29tZSwgYW5kIHRoYXQgbWF5IGdpdmUgaW1wbGVtZW50b3JzDQptb3JlIGNv bWZvcnQgdGhhbiBpcyBhZmZvcmRlZCBieSB0aGUgY2xlYXIgYW5kIHNpbXBsZSBzdGF0ZW1lbnQu DQoNClRoZXJlZm9yZSwgZm9yIHNlY3VyaXR5IHJldmlldywgScK5ZCBzdWdnZXN0IHdlIGtlZXAg dGhlIHN0YXRlbWVudCBzaW1wbGUsDQphcyBkZWZpbmVkIGFib3ZlLiBIb3dldmVyLCBpZiB0aGlz IHN0YXRlbWVudCBpcyBub3QgY2xlYXIgZW5vdWdoL2NvcnJlY3QNCmluIHRoZSBkb2N1bWVudCwg dGhlbiBjZXJ0YWlubHksIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQuDQoNCkJlc3QgUmVnYXJkcywN Cg0KRG91Zy4NCg0KT24gMDYvMTAvMjAxNiAxNzozNSwgIkFsYW4gRGVLb2siIDxhbGFuZEBkZXBs b3lpbmdyYWRpdXMuY29tPG1haWx0bzphbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPj4gd3JvdGU6 DQoNCk9uIE9jdCA2LCAyMDE2LCBhdCAxMjoxOSBQTSwgdC5wZXRjaCA8aWV0ZmNAYnRjb25uZWN0 LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+IHdyb3RlOg0KWW91IGFyZSBub3QsIGFu ZCBJIGRpZCBub3QgbWVhbiB0byBpbXBseSB0aGF0IHlvdSB3ZXJlLiAgSSBtZWFuIHRoYXQNCnlv dXIgY2hhbmdlcyBzZWVtIHRvIG1lIHJlZmxlY3QgYSBkaWZmZXJlbnQgYXBwcm9hY2gsIGEgZGlm ZmVyZW50IHN0eWxlDQp3aGljaCBJIGRvIG5vdCBzZWUgYXMgdGhhdCBvZiB0aGUgYXV0aG9ycy4g IEkgc2VlIHRoZSBleGlzdGluZyBzdHlsZSBhcw0KdW51c3VhbCwgYnV0IG5vdCB3cm9uZywgYW5k IGFtIGNvbnRlbnQgdG8gbGVhdmUgaXQgYXMgaXMgZm9yIGFuDQpJbmZvcm1hdGlvbmFsIFJGQyB3 aGljaCBkb2N1bWVudHMgd2hhdCBpcywgb3IgcGVyaGFwcyB3aGF0IGhhcyBiZWVuLiBZb3UNCnVz ZWQgdGhlIHdvcmQgJ3BoaWxvc29waGljYWwnIGFuZCBJIGFncmVlZC4NCg0KICBJIHNlZSB0aGUg ZXhpc3RpbmcgZHJhZnQgYXMgbm90IGRvY3VtZW50aW5nIHRoZSBwcm90b2NvbC4gIFRoYXQncyBt eQ0KbWFpbiBjb25jZXJuLg0KDQpTbyBJIHdvdWxkIGtlZXAgY2hhbmdlcyB0byB0aGUgbWluaW11 bSwgb21pc3Npb25zIG9yIGNvbnRyYWRpY3Rpb25zIGFuZA0KdGhvc2UgcmVxdWlyZWQgIGJ5IHRo ZSBwdWJsaWNhdGlvbiBwcm9jZXNzIChzdWNoIGFzIHNwbGl0dGluZyBSZWZlcmVuY2VzDQppbnRv IEluZm9ybWF0aXZlIGFuZCBOb3JtYXRpdmUpLiAgSXQgaXMsIGFmdGVyIGFsbCwgV0dMQy4NCg0K ICBUaGlzIGRvZXNuJ3QgYWRkcmVzcyBteSBjb25jZXJucy4NCg0KICBBZ2FpbiwgYXMgYW4gaW1w bGVtZW50b3IsIEkgaGF2ZSAqbm8gaWRlYSogd2hhdCB0byBkbyBmb3IgaHVnZSBzd2F0aGVzDQpv ZiB0aGUgcHJvdG9jb2wuDQoNCiAgT24gdG9wIG9mIHRoYXQsIHRoZSBjdXJyZW50IGRyYWZ0IGlz IHNpbGVudCBvbiBzZXJpb3VzIHNlY3VyaXR5IHRvcGljcy4NCg0KICBlLmcuIExlbmd0aCBvZiBD SEFQIGNoYWxsZW5nZXMgaXMgaW1wbGllZCBmcm9tIHRoZSBjb250ZXh0LiAgT0ssIHRoYXQncw0K ZmluZSwgYnV0IHdoYXQgYXJlIHRoZSAqbGltaXRzKiBvbiBDSEFQIGNoYWxsZW5nZSBsZW5ndGhz Pw0KDQpBOiBub25lLiAgQ0hBUCBjaGFsbGVuZ2VzIGNhbiBiZSBvbWl0dGVkIGVudGlyZWx5IQ0K DQpPbiBTZWN1cml0eSwgSSB3b3VsZCBpbnZpdGUgdGhlIGNoYWlycyB0byBhc2sgZm9yIGFuIGVh cmx5IHJldmlldyBieSB0aGUNClNlY3VyaXR5IERpcmVjdG9yYXRlLCBleHBsYWluaW5nIHRoZSBj b250ZXh0IG9mIHRoaXMgZG9jdW1lbnQsIGFza2luZw0KdGhlbSBob3cgbXVjaCBtb3JlIGlzIG5l ZWRlZCBhbmQgaG93IGl0IHNob3VsZCBiZSBleHByZXNzZWQuICBJdCBtaWdodA0Kbm90IGJlIHZl cnkgbXVjaCBhbHRob3VnaCBteSBleHBlcmllbmNlIGlzIHRoYXQgSSBuZXZlciBrbm93IGluIGFk dmFuY2UNCndoYXQgdGhleSBhcmUgZ29pbmcgdG8gY29tZSB1cCB3aXRoLg0KDQogIEkndmUgYmVl biBhIG1lbWJlciBvZiBTQUFHIGZvciBhIHdoaWxlIG5vdywgYW5kIGhhdmUgZG9uZSByZXZpZXdz LCBhbmQNCnJlYWQgbWFueSBtb3JlLiAgTXkgcHJlZGljdGlvbiBpcyB0aGF0IHRoZSBjdXJyZW50 IGRvY3VtZW50IHdpbGwgZ2l2ZQ0KU0FBRyBhIGhlYXJ0IGF0dGFjaywgYW5kIHRoZXkgd2lsbCBy ZWZ1c2UgcHVibGljYXRpb24uDQoNCiAgVGhlcmUgaXMgYSBodWdlIHB1c2ggdG8gZ2V0IHRoZSBk cmFmdCBwdWJsaXNoZWQuICBUaGF0J3MgZmluZS4gIFdoYXQncw0KKm5vdCogZmluZSBpcyB0aGF0 IGl0IHNlZW1zIHRvIG1lIGF0IGxlYXN0Li4uIHRoYXQgbWFueSBwZW9wbGUgc2ltcGx5DQpkb24n dCBjYXJlIHdoYXQncyBpbiB0aGUgZG9jdW1lbnQuICBUaGV5IGRvbid0IGNhcmUgaWYgdGhlIHBy b3RvY29sIGlzDQpiYWRseSBzcGVjaWZpZWQuICBPciBpZiBpdCdzIGluc2VjdXJlLiAgSW4gZmFj dCwgdGhlc2UgImZlYXR1cmVzIiBjb3VsZA0KYmUgYmVuZWZpY2lhbC4gIEJlY2F1c2UgaXQgbWVh bnMgdGhhdCBldmVyeW9uZSBjYW4gY2xhaW0gY29tcGxpYW5jZS4gIEFuZA0Kbm8gb25lIGhhcyB0 byByZS1leGFtaW5lIHRoZWlyIGltcGxlbWVudGF0aW9uLg0KDQogIFRoYXQgbWF5IHNvdW5kIGhh cnNoLCBidXQgSSBqdXN0IGRvbid0IHNlZSBhbnkgb3RoZXIgZXhwbGFuYXRpb24uICBJZg0Kd2Ug YXJlIGdvaW5nIHRvIGRvY3VtZW50IHRoZSBwcm90b2NvbCwgdGhlbiBsZXQncyBkb2N1bWVudCB0 aGUgcHJvdG9jb2wuDQpJZiB3ZSdyZSBnb2luZyB0byBhZ3JlZSB0aGF0IHdlIGRvbid0IG5lZWQg dG8gZG9jdW1lbnQgdGhlIHByb3RvY29sIHRoZW4NCnB1dCBhIGh1Z2UgZGlzY2xhaW1lciBhdCB0 aGUgdG9wIG9mIHRoZSBkcmFmdCBzYXlpbmcgc28uDQoNCiAgR2l2aW5nIGxpcCBzZXJ2aWNlIHRv ICJkb2N1bWVudCB0aGUgcHJvdG9jb2wiLCB3aGlsZSBvcHBvc2luZyBhdHRlbXB0cw0KdG8gZG8g c28gaXMgdW5wcm9kdWN0aXZlLg0KDQogIEFsYW4gRGVLb2suDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9Q U0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg0KDQo= --_000_D41C51CD195431dcmgashciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2600EB3B084E6548BE7D554B3994DC80@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BZ3JlZWQsIHRv IHByb3ZpZGUgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBwcm90b2NvbCB3aXRoIHRoZSBzZWN1cml0 eSB3YXMgdGhlIG9yaWdpbmFsIHBsYW4uIEluIGZhY3QsIHRoYXQgd2FzIGhvdyB0aGlzIHByb2Nl c3Mgc3RhcnRlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJldmVydGluZyB0byB0 aGF0IHBsYW4sIG9yIGEgbW9kaWZpZWQgZm9yIG9mIHRoYXQgcGxhbiwgd291bGQgYWx3YXlzIGJl IGFuIG9wdGlvbiwgaWYgcHJlZmVycmVkIGJ5IHRoZSBncm91cC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+JnF1b3Q7Qmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86dXJpQGxsLm1pdC5lZHUiPnVyaUBsbC5taXQuZWR1PC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJz ZGF5LCA2IE9jdG9iZXIgMjAxNiAxOTowMDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5UbzogPC9zcGFuPkRvdWdsYXMgR2FzaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRjbWdhc2hA Y2lzY28uY29tIj5kY21nYXNoQGNpc2NvLmNvbTwvYT4mZ3Q7LCBBbGFuIERlS29rICZsdDs8YSBo cmVmPSJtYWlsdG86YWxhbmRAZGVwbG95aW5ncmFkaXVzLmNvbSI+YWxhbmRAZGVwbG95aW5ncmFk aXVzLmNvbTwvYT4mZ3Q7LCAmcXVvdDt0LnBldGNoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZmNAYnRjb25uZWN0LmNvbSI+aWV0ZmNAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtb3BzYXdnLXRhY2Fjcy0wNUB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0 Zi1vcHNhd2ctdGFjYWNzLTA1QHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtb3BzYXdnLXRhY2Fjcy0wNUB0b29scy5pZXRmLm9yZyI+ZHJhZnQt aWV0Zi1vcHNhd2ctdGFjYWNzLTA1QHRvb2xzLmlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk9wc0FXR0BpZXRmLm9yZyI+T3BzQVdHQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJl OiBbT1BTQVdHXSBTdGFydCBvZiBXR0xDIGZvciBUQUNBQ1MmIzQzOyBkb2N1bWVudC48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+ DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9IktleXdvcmRzIiBj b250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29y ZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9u cyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpBcmlhbDsNCglwYW5vc2UtMToyIDExIDYg NCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgi Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNb25hY287DQoJcGFub3NlLTE6MiAwIDUg MCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5 bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCgltc28tbGlnYXR1cmVzOnN0YW5kYXJkY29udGV4 dHVhbDsNCgltc28tc3R5bGlzdGljLXNldDowOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8ZGl2IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+QSBwcm90b2NvbCBkZXNjcmlwdGlvbiBuZWVk cyB0byBpbmNsdWRlOiAoYSkgd2hhdCB0aHJlYXRzL2F0dGFja3MgYmVjb21lIHBvc3NpYmxlIGFz IGEgcmVzdWx0IG9mIGl0cyBpbnRyb2R1Y3Rpb24sIChiKSBob3cgdGhlIHByb3RvY29sIGRlZmVu ZHMgYWdhaW5zdCBbYXQgbGVhc3Qgc29tZSBvZl0gdGhlbSwNCiAoYykgaG93IHRoZSByZW1haW5p bmcgYXR0YWNrcyBjYW4gYmUgbWl0aWdhdGVkLCAoZCkgd2hhdCBhcmUgdGhlIHJlbWFpbmluZyBy aXNrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Z ZXMsIGRpc3NlY3Rpb24gb2YgdnVsbmVyYWJpbGl0aWVzIGFuZCBleHBsb3JhdGlvbiBvZiB0aGUg YXR0YWNrIHZlY3RvcnMgd291bGQgaGVscCwgZXNwZWNpYWxseSBpZiB5b3UgcHJvdmlkZSB3YXlz IHRvIGRlZmVuZC9taXRpZ2F0ZS4gSWYgeW91IGp1c3Qgc2F5IOKAnHdoZW4geW91IGRlcGxveSBY LCBhbnlib2R5DQogd291bGQgYmUgYWJsZSB0byBkbyBZIGFuZCB0b3RhbGx5IHNjcmV3IHlvdSB1 cOKAnSwgc29tZWhvdyBJIGRvdWJ0IHRoYXQgc3VjaCBhIHByb3RvY29sIHdvdWxkIGJlIHdhcm1s eSB3ZWxjb21lZC4gSWYgeW91IGRvbuKAmXQgc2F5IGFueXRoaW5nIOKAkyBpdCBzaW1wbHkgc2hv d3MgdGhhdCB5b3UgZGlkIG5vdCB0aGluayBvZiB0aGUgc2VjdXJpdHkgYW5nbGUsIGFuZCB0aGVy ZWZvcmUgdGhlIHByb3RvY29sIGlzIG5vdCByZWFkeSBldmVuIGZvciB0aGUgZHJhZnQNCiBwdWJs aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr Ij5XaHkgZG8geW91IHRoaW5rDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tbGlnYXR1cmVzOnN0YW5kYXJkY29udGV4dHVhbCI+YW55 b25lIGF0IFNBQUcgd291bGQgYWdyZWUvcGVybWl0IHRvIOKAnGJsZXNz4oCdL3B1Ymxpc2ggYSBw cm90b2NvbCB0aGF0IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpNb25hY287Y29sb3I6YmxhY2siPmRvZXMgbm90IHByb3ZpZGUgc2VjdXJpdHkgaW4N CiBhIG1vZGVybiBFbnZpcm9ubWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+4oCdPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPj8gSeKA mWQgdGhpbmsgdGhhdCBldmVyeWJvZHkgcmVhbGl6ZWQgYnkgbm93IHRoYXQgaW4gdG9kYXnigJlz IGVudmlyb25tZW50IGEgcHJvdG9jb2wgdGhhdCDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPnByb3ZpZGVzDQog dGhlIGZ1bmN0aW9uLCBub3QgdGhlIHNlY3VyaXR5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPuKAnSBoYXMgbm8gcmln aHQgdG8gbGl2ZSwgYW5kIGlkZWFsbHkgc2hvdWxkIGJlIHN0YW1wZWQgb3V0IOKAkyBidXQgaW4g YW55IGNhc2Ugbm90IHJld2FyZGVkIGJ5IHJlY2VpdmluZyBhIOKAnHN0YW5kYXJk4oCdIHN0YXR1 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5TbyBo b2xkIHRoZSBwdWJsaWNhdGlvbiB1bnRpbCB5b3VyICgzKSBjb21lcyBhbG9uZy4gSW4gdGhlIG1l YW53aGlsZSwgZW5qb3kgdGhlIHZ1bG5lcmFiaWxpdGllcyBvZiB5b3VyIGRlcGxveWVkIGltcGxl bWVudGF0aW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaTttc28tbGlnYXR1cmVzOnN0YW5kYXJkY29udGV4dHVhbCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4tLSZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPlVyaSBCbHVtZW50 aGFsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmk7bXNvLWxpZ2F0dXJlczpzdGFuZGFyZGNvbnRleHR1YWwiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7bXNvLWxpZ2F0dXJlczpzdGFuZGFyZGNvbnRleHR1YWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7 bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk9uIDEwLzYvMTYsIDEzOjM0ICwgJnF1b3Q7 T1BTQVdHIG9uIGJlaGFsZiBvZiBEb3VnbGFzIEdhc2ggKGRjbWdhc2gpJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPm9wc2F3Zy1ib3VuY2VzQGlldGYu b3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpkY21nYXNoQGNpc2NvLmNvbSI+ ZGNtZ2FzaEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPkhpIEFsYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5SZWdhcmRpbmcgdGhl IHNlY3VyaXR5IGNvbmNlcm4sIHRoZSBhcHByb2FjaCB3ZSBoYXZlIHdpdGggdGhlIGN1cnJlbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+ZG9jdW1lbnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4xKSBBIHN0YXRl bWVudCB0aGF0IHRoZSBwcm90b2NvbCBkb2VzIG5vdCBwcm92aWRlIHNlY3VyaXR5IGluIGEgbW9k ZXJuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPmVudmlyb25tZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjIpIFRoZSB0d28gY29tbW9uIGFw cHJvYWNoZXMgdG8gc3VwcG9ydCBUJiM0Mzsgc28gdGhhdCBpdCBtYXkgYmUgdXNlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+MykgQW4gaW5kaWNhdGlvbiB0aGF0IGEgdmVyc2lvbiB3aXRoIGJ1aWx0LWluIHNlY3VyaXR5 IGlzIHRvIGZvbGxvdywgd2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+d2lsbCBub3QgcmVxdWlyZSB0aGUgbWl0aWdh dGlvbnMgaW4gMikgKGFjdHVhbGx5IEkgc3VzcGVjdCBpdCBtYXkgcHJlY2VkZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj50 aGUgaW5mbyBkb2N1bWVudCA7LSkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5XZSBuZWVkIHRv IG1ha2Ugc3VyZSB0aGVyZSBpcyBubyBhbWJpZ3VpdHkgZm9yIDEpIGZvciBhbnkgc2VjdXJpdHkg cmV2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrIj5ObyBzb2Z0LXBlZGRhbGxpbmcuIFQmIzQzOyBwcm92aWRlcyB0aGUg ZnVuY3Rpb24sIG5vdCB0aGUgc2VjdXJpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlNvxaAgQW4gYXBwcm9hY2ggd2UgY291bGQgZW1w bG95IGlzIHRvIGVudW1lcmF0ZSBhbGwgdGhlIHdheXMgaW4gd2hpY2ggMSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+aXMg dHJ1ZSwgaW5jbHVkaW5nIGFuIGFuYWx5c2lzIG9mIGVhY2ggb2YgdGhlIG90aGVyIGNvbXBvbmVu dHMgb2YgdGhlIHJlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+b2YgdGhlIHByb3RvY29sLCBhbmQgdGhlaXIgY29udHJp YnV0aW9uIHRvIDEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+TXkgcXVlc3Rpb24gd291bGQg YmU6IHdvdWxkIHRoaXMgZGlzc2VjdGlvbiBvZiB2dWxuZXJhYmlsaXRpZXMgYW5kPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si PmV4cGxvcmF0aW9uIG9mIHRoZSBhdHRhY2sgdmVjdG9ycyB3b3VsZCBoZWxwIGFueW9uZSBmcm9t IGEgc2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+cGVyc3BlY3RpdmUsIHdoZW4gd2UgaGF2ZSBlc3RhYmxpc2hl ZCB0aGF0IHRoZSBhcHByb2FjaGVzIDIpIGFyZSByZXF1aXJlZD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPkkgc3VzcGVjdCB0aGF0IHdlwrlkIHByb2JhYmx5IG1pc3Mgc29tZSwgYW5kIHRoYXQg bWF5IGdpdmUgaW1wbGVtZW50b3JzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPm1vcmUgY29tZm9ydCB0aGFuIGlzIGFmZm9y ZGVkIGJ5IHRoZSBjbGVhciBhbmQgc2ltcGxlIHN0YXRlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPlRoZXJlZm9yZSwgZm9yIHNlY3VyaXR5IHJldmlldywgScK5ZCBzdWdnZXN0IHdlIGtl ZXAgdGhlIHN0YXRlbWVudCBzaW1wbGUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmFzIGRlZmluZWQgYWJvdmUuIEhvd2V2 ZXIsIGlmIHRoaXMgc3RhdGVtZW50IGlzIG5vdCBjbGVhciBlbm91Z2gvY29ycmVjdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij5pbiB0aGUgZG9jdW1lbnQsIHRoZW4gY2VydGFpbmx5LCBpdCBzaG91bGQgYmUgY2xhcmlmaWVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+RG91Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk9uIDA2LzEwLzIwMTYgMTc6 MzUsICZxdW90O0FsYW4gRGVLb2smcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbGFuZEBkZXBs b3lpbmdyYWRpdXMuY29tIj5hbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBp biIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5PbiBPY3QgNiwgMjAxNiwgYXQgMTI6MTkgUE0sIHQucGV0 Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIj5pZXRmY0BidGNvbm5l Y3QuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmln aHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPllvdSBhcmUgbm90LCBhbmQgSSBkaWQgbm90IG1l YW4gdG8gaW1wbHkgdGhhdCB5b3Ugd2VyZS4mbmJzcDsmbmJzcDtJIG1lYW4gdGhhdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij55b3VyIGNoYW5nZXMgc2VlbSB0byBtZSByZWZsZWN0IGEgZGlmZmVyZW50IGFwcHJvYWNoLCBh IGRpZmZlcmVudCBzdHlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj53aGljaCBJIGRvIG5vdCBzZWUgYXMgdGhhdCBvZiB0 aGUgYXV0aG9ycy4mbmJzcDsmbmJzcDtJIHNlZSB0aGUgZXhpc3Rpbmcgc3R5bGUgYXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+dW51c3VhbCwgYnV0IG5vdCB3cm9uZywgYW5kIGFtIGNvbnRlbnQgdG8gbGVhdmUgaXQgYXMg aXMgZm9yIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPkluZm9ybWF0aW9uYWwgUkZDIHdoaWNoIGRvY3VtZW50cyB3aGF0 IGlzLCBvciBwZXJoYXBzIHdoYXQgaGFzIGJlZW4uIFlvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj51c2VkIHRoZSB3b3Jk ICdwaGlsb3NvcGhpY2FsJyBhbmQgSSBhZ3JlZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtJIHNlZSB0aGUgZXhpc3RpbmcgZHJhZnQgYXMgbm90 IGRvY3VtZW50aW5nIHRoZSBwcm90b2NvbC4mbmJzcDsmbmJzcDtUaGF0J3MgbXk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ bWFpbiBjb25jZXJuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVD NERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+U28gSSB3b3VsZCBrZWVwIGNoYW5n ZXMgdG8gdGhlIG1pbmltdW0sIG9taXNzaW9ucyBvciBjb250cmFkaWN0aW9ucyBhbmQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+dGhvc2UgcmVxdWlyZWQmbmJzcDsmbmJzcDtieSB0aGUgcHVibGljYXRpb24gcHJvY2VzcyAo c3VjaCBhcyBzcGxpdHRpbmcgUmVmZXJlbmNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5pbnRvIEluZm9ybWF0aXZlIGFu ZCBOb3JtYXRpdmUpLiZuYnNwOyZuYnNwO0l0IGlzLCBhZnRlciBhbGwsIFdHTEMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtUaGlzIGRvZXNuJ3Qg YWRkcmVzcyBteSBjb25jZXJucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw O0FnYWluLCBhcyBhbiBpbXBsZW1lbnRvciwgSSBoYXZlICpubyBpZGVhKiB3aGF0IHRvIGRvIGZv ciBodWdlIHN3YXRoZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+b2YgdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7T24gdG9wIG9mIHRoYXQsIHRoZSBjdXJyZW50IGRyYWZ0IGlz IHNpbGVudCBvbiBzZXJpb3VzIHNlY3VyaXR5IHRvcGljcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwO2UuZy4gTGVuZ3RoIG9mIENIQVAgY2hhbGxlbmdlcyBpcyBpbXBsaWVk IGZyb20gdGhlIGNvbnRleHQuJm5ic3A7Jm5ic3A7T0ssIHRoYXQnczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5maW5lLCBi dXQgd2hhdCBhcmUgdGhlICpsaW1pdHMqIG9uIENIQVAgY2hhbGxlbmdlIGxlbmd0aHM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5BOiBub25lLiZuYnNwOyZuYnNwO0NIQVAgY2hhbGxlbmdlcyBj YW4gYmUgb21pdHRlZCBlbnRpcmVseSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk9uIFNlY3VyaXR5 LCBJIHdvdWxkIGludml0ZSB0aGUgY2hhaXJzIHRvIGFzayBmb3IgYW4gZWFybHkgcmV2aWV3IGJ5 IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj5TZWN1cml0eSBEaXJlY3RvcmF0ZSwgZXhwbGFpbmluZyB0aGUgY29udGV4 dCBvZiB0aGlzIGRvY3VtZW50LCBhc2tpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+dGhlbSBob3cgbXVjaCBtb3JlIGlz IG5lZWRlZCBhbmQgaG93IGl0IHNob3VsZCBiZSBleHByZXNzZWQuJm5ic3A7Jm5ic3A7SXQgbWln aHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+bm90IGJlIHZlcnkgbXVjaCBhbHRob3VnaCBteSBleHBlcmllbmNlIGlzIHRo YXQgSSBuZXZlciBrbm93IGluIGFkdmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+d2hhdCB0aGV5IGFyZSBnb2luZyB0 byBjb21lIHVwIHdpdGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDtJJ3ZlIGJlZW4gYSBtZW1iZXIgb2YgU0FBRyBmb3IgYSB3aGlsZSBub3csIGFu ZCBoYXZlIGRvbmUgcmV2aWV3cywgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPnJlYWQgbWFueSBtb3JlLiZuYnNwOyZu YnNwO015IHByZWRpY3Rpb24gaXMgdGhhdCB0aGUgY3VycmVudCBkb2N1bWVudCB3aWxsIGdpdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+U0FBRyBhIGhlYXJ0IGF0dGFjaywgYW5kIHRoZXkgd2lsbCByZWZ1c2UgcHVibGlj YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtUaGVyZSBpcyBhIGh1 Z2UgcHVzaCB0byBnZXQgdGhlIGRyYWZ0IHB1Ymxpc2hlZC4mbmJzcDsmbmJzcDtUaGF0J3MgZmlu ZS4mbmJzcDsmbmJzcDtXaGF0J3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+Km5vdCogZmluZSBpcyB0aGF0IGl0IHNlZW1z IHRvIG1lIGF0IGxlYXN0Li4uIHRoYXQgbWFueSBwZW9wbGUgc2ltcGx5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmRvbid0 IGNhcmUgd2hhdCdzIGluIHRoZSBkb2N1bWVudC4mbmJzcDsmbmJzcDtUaGV5IGRvbid0IGNhcmUg aWYgdGhlIHByb3RvY29sIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmJhZGx5IHNwZWNpZmllZC4mbmJzcDsmbmJzcDtP ciBpZiBpdCdzIGluc2VjdXJlLiZuYnNwOyZuYnNwO0luIGZhY3QsIHRoZXNlICZxdW90O2ZlYXR1 cmVzJnF1b3Q7IGNvdWxkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmJlIGJlbmVmaWNpYWwuJm5ic3A7Jm5ic3A7QmVjYXVz ZSBpdCBtZWFucyB0aGF0IGV2ZXJ5b25lIGNhbiBjbGFpbSBjb21wbGlhbmNlLiZuYnNwOyZuYnNw O0FuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj5ubyBvbmUgaGFzIHRvIHJlLWV4YW1pbmUgdGhlaXIgaW1wbGVtZW50YXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtUaGF0IG1heSBzb3VuZCBo YXJzaCwgYnV0IEkganVzdCBkb24ndCBzZWUgYW55IG90aGVyIGV4cGxhbmF0aW9uLiZuYnNwOyZu YnNwO0lmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPndlIGFyZSBnb2luZyB0byBkb2N1bWVudCB0aGUgcHJvdG9jb2wsIHRo ZW4gbGV0J3MgZG9jdW1lbnQgdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5JZiB3ZSdyZSBnb2luZyB0 byBhZ3JlZSB0aGF0IHdlIGRvbid0IG5lZWQgdG8gZG9jdW1lbnQgdGhlIHByb3RvY29sIHRoZW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+cHV0IGEgaHVnZSBkaXNjbGFpbWVyIGF0IHRoZSB0b3Agb2YgdGhlIGRyYWZ0IHNh eWluZyBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO0dpdmluZyBsaXAg c2VydmljZSB0byAmcXVvdDtkb2N1bWVudCB0aGUgcHJvdG9jb2wmcXVvdDssIHdoaWxlIG9wcG9z aW5nIGF0dGVtcHRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6YmxhY2siPnRvIGRvIHNvIGlzIHVucHJvZHVjdGl2ZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwO0FsYW4gRGVLb2suPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+T1BTQVdHIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86T1BTQVdHQGlldGYub3JnIj5PUFNBV0dAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb3BzYXdnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3 ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D41C51CD195431dcmgashciscocom_-- From nobody Thu Oct 6 11:51:27 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3C1293E9 for ; Thu, 6 Oct 2016 11:51:26 -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, 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 WJQtV2Q_9dbT for ; Thu, 6 Oct 2016 11:51:24 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A82A41293D8 for ; Thu, 6 Oct 2016 11:51:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id F18B71F3B; Thu, 6 Oct 2016 18:51:23 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqiRjKe0ux77; Thu, 6 Oct 2016 18:51:23 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id CFB8D11B8; Thu, 6 Oct 2016 18:51:22 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 6 Oct 2016 14:51:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD4416D-361C-492C-9B7D-FBA85A3BACD5@deployingradius.com> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> <0124D7D3-98BA-4175-AE57-39C03349009C@deployingradius.com> To: "Douglas Gash (dcmgash)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg-chairs@tools.ietf.org" , Andrej Ota , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" , Thorsten Dahm , "opsawg@ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:51:26 -0000 On Oct 6, 2016, at 1:34 PM, Douglas Gash (dcmgash) = wrote: > Regarding the security concern, the approach we have with the current > document is: >=20 > 1) A statement that the protocol does not provide security in a modern > environment.=20 I'm happy with that. > 2) The two common approaches to support T+ so that it may be used. OK... > 3) An indication that a version with built-in security is to follow, = which > will not require the mitigations in 2) (actually I suspect it may = precede > the info document ;-)) Except that the current document doesn't even document CHAP securely. RFC 1994 (published in 1996) says: =20 Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness. Tho I'll also note that RFC 1994 also doesn't specify a minimum length = for the challenge. That is, the document doesn't even meet the security requirements in = place in 1994. > We need to make sure there is no ambiguity for 1) for any security = review. > No soft-peddalling. T+ provides the function, not the security. I'm fine with that. I want to document historical TACACS+. This means the document needs = to answer the following questions: a) can people implement it? b) can people gain the maximum amount of security available in the = historical protocol? c) can people be aware of the security concerns and trade-offs with = using the historical protocol? The push-back so far shows that the answers are: a) no b) no c) no I suggest these are the wrong answers. *All* of them are the wrong = answers. > My question would be: would this dissection of vulnerabilities and > exploration of the attack vectors would help anyone from a security > perspective, when we have established that the approaches 2) are = required? Yes. See any of the RADIUS RFCs in the last 5 years. The SAAG = reviews require discussion not only of the issues with the new = standards, but also of the problems with the historical protocol. > I suspect that we=B9d probably miss some, and that may give = implementors > more comfort than is afforded by the clear and simple statement. The argument that we can't be perfect isn't a reason to give up = entirely. If the statement is anything other than "no one should use this = protocol for anything", we might as well *try* to document security = issues. > Therefore, for security review, I=B9d suggest we keep the statement = simple, > as defined above. However, if this statement is not clear = enough/correct > in the document, then certainly, it should be clarified. Then the introduction and/or abstract should say: "This document attempts to specify the historical TACACS+ protocol. = However, there are many portions of the protocol which are = under-specified or unspecified. We cannot second-guess twenty years of = practice here. As a result, this specification is incomplete, = under-specified, insecure, and should not be used by anyone to implement = anything. Please wait for the Standards track document to get the = actual TACACS+ specification that people can implement". It shouldn't be a contentious issue. Either document the protocol, or = admit we're not going to document the protocol. Alan DeKok. From nobody Thu Oct 6 13:10:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0895A1296C8 for ; Thu, 6 Oct 2016 13:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 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=-2.996, 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 uQpnDTaGxH1o for ; Thu, 6 Oct 2016 13:10:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B47129408 for ; Thu, 6 Oct 2016 13:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5900; q=dns/txt; s=iport; t=1475784644; x=1476994244; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8c7I6Q5LAh62oxQXn59Swz3hNyOfkkKvHYKgMa+MC+s=; b=k4aPYA5AHGIwzbh9SYrwN0B++XRneDrDu0NB9RmgqxigcMEOgs/byug6 Y51McpnpQsxym1oquU/kMysawcZvAil02IHKvMobLIu/d3toBZZNhXX9I m5D57MWMCwXM8R3em5q/O4C8+LNuKvnCFZyafshXV7qHcTWaAWvE5XHC6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AQCCrvZX/4ENJK1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgz0BAQEBAR6BUweNK6kdgg+CC4YgHoFYOBQBAgEBAQEBAQFeJ4RiAgQ0OAo?= =?us-ascii?q?DEgEIHCgEMCcEDgWITpUVnSkGjHABAQEBAQEBAQIBAQEBAQEBIYEBihCEXoJng?= =?us-ascii?q?kQdBZQlhVoBj3qBboRniR+Md4N+AR42GjGEWnKGYoEAAQEB?= X-IronPort-AV: E=Sophos;i="5.31,454,1473120000"; d="scan'208";a="157229947" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2016 20:10:43 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u96KAhlv019750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Oct 2016 20:10:43 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Oct 2016 15:10:43 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 6 Oct 2016 15:10:43 -0500 From: "Douglas Gash (dcmgash)" To: Alan DeKok Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. - Security element (or not) Thread-Index: AQHSIA23Qk1eACCHMECzU4HZfySLXg== Date: Thu, 6 Oct 2016 20:10:42 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.93] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "opsawg-chairs@tools.ietf.org" , Andrej Ota , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" , Thorsten Dahm , "opsawg@ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. - Security element (or not) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:10:46 -0000 SGksDQoNClJlZ2FyZGluZyB5b3VyIGEpIGIpIGMpIGVsZW1lbnRzLCB3ZSBhcmUgaGFwcHkgdG8g d29yayB0aHJvdWdoIHRoZSBpc3N1ZXMNCmluIGEgZGlmZmVyZW50IHRocmVhZCwgYW5kIHdpbGwg d2FpdCB5b3VyIGZpbmFsIGluc3RhbG1lbnQuIFRoaXMgc3BlY2lmaWMNCnF1ZXN0aW9uL3RocmVh ZCByZWdhcmRlZCBzZWN1cml0eSwgaGVuY2UgdGhlIGhhbmR5IGNoYW5nZSBvZiBzdWJqZWN0Lg0K DQpUaGUgcmVhc29uIEkgd291bGQgZ28gYWxvbmcgdGhlIGxpbmVzIG9mIHlvdXIgcHJvcG9zYWwg YXQgdGhlIGVuZCAoYnV0DQp3aXRoIGEgbGl0dGxlIG1vZGlmaWNhdGlvbikgcmF0aGVyIHRoYW4g YW5hbHlzaW5nIHNlY3VyaXR5IG9mIGVhY2ggcGFydCwNCmlzIGJlY2F1c2Ugc3VjaCBhbiBpbmNs dXNpdmUgc3RhdGVtZW50IGNvdmVycyB0aGUgc2l0dWF0aW9uIGNvbXBsZXRlbHksDQphbmQgbm8g b25lIHdpbGwgYmUgdW5kZXIgYW55IGlsbHVzaW9ucy4NCg0KVGhhbmtzLA0KDQpSZWdhcmRzLA0K DQpEb3VnLg0KDQpPbiAwNi8xMC8yMDE2IDE5OjUxLCAiQWxhbiBEZUtvayIgPGFsYW5kQGRlcGxv eWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KDQo+T24gT2N0IDYsIDIwMTYsIGF0IDE6MzQgUE0sIERv dWdsYXMgR2FzaCAoZGNtZ2FzaCkgPGRjbWdhc2hAY2lzY28uY29tPg0KPndyb3RlOg0KPj4gUmVn YXJkaW5nIHRoZSBzZWN1cml0eSBjb25jZXJuLCB0aGUgYXBwcm9hY2ggd2UgaGF2ZSB3aXRoIHRo ZSBjdXJyZW50DQo+PiBkb2N1bWVudCBpczoNCj4+IA0KPj4gMSkgQSBzdGF0ZW1lbnQgdGhhdCB0 aGUgcHJvdG9jb2wgZG9lcyBub3QgcHJvdmlkZSBzZWN1cml0eSBpbiBhIG1vZGVybg0KPj4gZW52 aXJvbm1lbnQuIA0KPg0KPiAgSSdtIGhhcHB5IHdpdGggdGhhdC4NCj4NCj4+IDIpIFRoZSB0d28g Y29tbW9uIGFwcHJvYWNoZXMgdG8gc3VwcG9ydCBUKyBzbyB0aGF0IGl0IG1heSBiZSB1c2VkLg0K Pg0KPiAgT0suLi4NCj4NCj4+IDMpIEFuIGluZGljYXRpb24gdGhhdCBhIHZlcnNpb24gd2l0aCBi dWlsdC1pbiBzZWN1cml0eSBpcyB0byBmb2xsb3csDQo+PndoaWNoDQo+PiB3aWxsIG5vdCByZXF1 aXJlIHRoZSBtaXRpZ2F0aW9ucyBpbiAyKSAoYWN0dWFsbHkgSSBzdXNwZWN0IGl0IG1heQ0KPj5w cmVjZWRlDQo+PiB0aGUgaW5mbyBkb2N1bWVudCA7LSkpDQo+DQo+ICBFeGNlcHQgdGhhdCB0aGUg Y3VycmVudCBkb2N1bWVudCBkb2Vzbid0IGV2ZW4gZG9jdW1lbnQgQ0hBUCBzZWN1cmVseS4NCj4N Cj4gIFJGQyAxOTk0IChwdWJsaXNoZWQgaW4gMTk5Nikgc2F5czoNCj4gDQo+ICAgRWFjaCBjaGFs bGVuZ2UgdmFsdWUgU0hPVUxEIGJlIHVuaXF1ZSwgc2luY2UgcmVwZXRpdGlvbiBvZiBhDQo+ICAg Y2hhbGxlbmdlIHZhbHVlIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIHNhbWUgc2VjcmV0IHdvdWxk IHBlcm1pdCBhbg0KPiAgIGF0dGFja2VyIHRvIHJlcGx5IHdpdGggYSBwcmV2aW91c2x5IGludGVy Y2VwdGVkIHJlc3BvbnNlLiAgU2luY2UgaXQNCj4gICBpcyBleHBlY3RlZCB0aGF0IHRoZSBzYW1l IHNlY3JldCBNQVkgYmUgdXNlZCB0byBhdXRoZW50aWNhdGUgd2l0aA0KPiAgIHNlcnZlcnMgaW4g ZGlzcGFyYXRlIGdlb2dyYXBoaWMgcmVnaW9ucywgdGhlIGNoYWxsZW5nZSBTSE9VTEQgZXhoaWJp dA0KPiAgIGdsb2JhbCBhbmQgdGVtcG9yYWwgdW5pcXVlbmVzcy4NCj4NCj4gIFRobyBJJ2xsIGFs c28gbm90ZSB0aGF0IFJGQyAxOTk0IGFsc28gZG9lc24ndCBzcGVjaWZ5IGEgbWluaW11bSBsZW5n dGgNCj5mb3IgdGhlIGNoYWxsZW5nZS4NCj4NCj4gIFRoYXQgaXMsIHRoZSBkb2N1bWVudCBkb2Vz bid0IGV2ZW4gbWVldCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGluDQo+cGxhY2UgaW4gMTk5 NC4NCj4NCj4+IFdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoZXJlIGlzIG5vIGFtYmlndWl0eSBmb3Ig MSkgZm9yIGFueSBzZWN1cml0eQ0KPj5yZXZpZXcuDQo+PiBObyBzb2Z0LXBlZGRhbGxpbmcuIFQr IHByb3ZpZGVzIHRoZSBmdW5jdGlvbiwgbm90IHRoZSBzZWN1cml0eS4NCj4NCj4gIEknbSBmaW5l IHdpdGggdGhhdC4NCj4NCj4gIEkgd2FudCB0byBkb2N1bWVudCBoaXN0b3JpY2FsIFRBQ0FDUysu ICBUaGlzIG1lYW5zIHRoZSBkb2N1bWVudCBuZWVkcw0KPnRvIGFuc3dlciB0aGUgZm9sbG93aW5n IHF1ZXN0aW9uczoNCj4NCj5hKSBjYW4gcGVvcGxlIGltcGxlbWVudCBpdD8NCj4NCj5iKSBjYW4g cGVvcGxlIGdhaW4gdGhlIG1heGltdW0gYW1vdW50IG9mIHNlY3VyaXR5IGF2YWlsYWJsZSBpbiB0 aGUNCj5oaXN0b3JpY2FsIHByb3RvY29sPw0KPg0KPmMpIGNhbiBwZW9wbGUgYmUgYXdhcmUgb2Yg dGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFuZCB0cmFkZS1vZmZzIHdpdGggdXNpbmcNCj50aGUgaGlz dG9yaWNhbCBwcm90b2NvbD8NCj4NCj4gIFRoZSBwdXNoLWJhY2sgc28gZmFyIHNob3dzIHRoYXQg dGhlIGFuc3dlcnMgYXJlOg0KPg0KPmEpIG5vDQo+DQo+Yikgbm8NCj4NCj5jKSBubw0KPg0KPiAg SSBzdWdnZXN0IHRoZXNlIGFyZSB0aGUgd3JvbmcgYW5zd2Vycy4gICpBbGwqIG9mIHRoZW0gYXJl IHRoZSB3cm9uZw0KPmFuc3dlcnMuDQo+DQo+PiBNeSBxdWVzdGlvbiB3b3VsZCBiZTogd291bGQg dGhpcyBkaXNzZWN0aW9uIG9mIHZ1bG5lcmFiaWxpdGllcyBhbmQNCj4+IGV4cGxvcmF0aW9uIG9m IHRoZSBhdHRhY2sgdmVjdG9ycyB3b3VsZCBoZWxwIGFueW9uZSBmcm9tIGEgc2VjdXJpdHkNCj4+ IHBlcnNwZWN0aXZlLCB3aGVuIHdlIGhhdmUgZXN0YWJsaXNoZWQgdGhhdCB0aGUgYXBwcm9hY2hl cyAyKSBhcmUNCj4+cmVxdWlyZWQ/DQo+DQo+ICBZZXMuICBTZWUgYW55IG9mIHRoZSBSQURJVVMg UkZDcyBpbiB0aGUgbGFzdCA1IHllYXJzLiAgVGhlIFNBQUcgcmV2aWV3cw0KPnJlcXVpcmUgZGlz Y3Vzc2lvbiBub3Qgb25seSBvZiB0aGUgaXNzdWVzIHdpdGggdGhlIG5ldyBzdGFuZGFyZHMsIGJ1 dA0KPmFsc28gb2YgdGhlIHByb2JsZW1zIHdpdGggdGhlIGhpc3RvcmljYWwgcHJvdG9jb2wuDQo+ DQo+PiBJIHN1c3BlY3QgdGhhdCB3Zan2ZCBwcm9iYWJseSBtaXNzIHNvbWUsIGFuZCB0aGF0IG1h eSBnaXZlIGltcGxlbWVudG9ycw0KPj4gbW9yZSBjb21mb3J0IHRoYW4gaXMgYWZmb3JkZWQgYnkg dGhlIGNsZWFyIGFuZCBzaW1wbGUgc3RhdGVtZW50Lg0KPg0KPiAgVGhlIGFyZ3VtZW50IHRoYXQg d2UgY2FuJ3QgYmUgcGVyZmVjdCBpc24ndCBhIHJlYXNvbiB0byBnaXZlIHVwDQo+ZW50aXJlbHku DQo+DQo+ICBJZiB0aGUgc3RhdGVtZW50IGlzIGFueXRoaW5nIG90aGVyIHRoYW4gIm5vIG9uZSBz aG91bGQgdXNlIHRoaXMNCj5wcm90b2NvbCBmb3IgYW55dGhpbmciLCB3ZSBtaWdodCBhcyB3ZWxs ICp0cnkqIHRvIGRvY3VtZW50IHNlY3VyaXR5DQo+aXNzdWVzLg0KPg0KPj4gVGhlcmVmb3JlLCBm b3Igc2VjdXJpdHkgcmV2aWV3LCBJqfZkIHN1Z2dlc3Qgd2Uga2VlcCB0aGUgc3RhdGVtZW50DQo+ PnNpbXBsZSwNCj4+IGFzIGRlZmluZWQgYWJvdmUuIEhvd2V2ZXIsIGlmIHRoaXMgc3RhdGVtZW50 IGlzIG5vdCBjbGVhciBlbm91Z2gvY29ycmVjdA0KPj4gaW4gdGhlIGRvY3VtZW50LCB0aGVuIGNl cnRhaW5seSwgaXQgc2hvdWxkIGJlIGNsYXJpZmllZC4NCj4NCj4gIFRoZW4gdGhlIGludHJvZHVj dGlvbiBhbmQvb3IgYWJzdHJhY3Qgc2hvdWxkIHNheToNCj4NCj4gIlRoaXMgZG9jdW1lbnQgYXR0 ZW1wdHMgdG8gc3BlY2lmeSB0aGUgaGlzdG9yaWNhbCBUQUNBQ1MrIHByb3RvY29sLg0KPkhvd2V2 ZXIsIHRoZXJlIGFyZSBtYW55IHBvcnRpb25zIG9mIHRoZSBwcm90b2NvbCB3aGljaCBhcmUNCj51 bmRlci1zcGVjaWZpZWQgb3IgdW5zcGVjaWZpZWQuICBXZSBjYW5ub3Qgc2Vjb25kLWd1ZXNzIHR3 ZW50eSB5ZWFycyBvZg0KPnByYWN0aWNlIGhlcmUuICBBcyBhIHJlc3VsdCwgdGhpcyBzcGVjaWZp Y2F0aW9uIGlzIGluY29tcGxldGUsDQo+dW5kZXItc3BlY2lmaWVkLCBpbnNlY3VyZSwgYW5kIHNo b3VsZCBub3QgYmUgdXNlZCBieSBhbnlvbmUgdG8gaW1wbGVtZW50DQo+YW55dGhpbmcuICBQbGVh c2Ugd2FpdCBmb3IgdGhlIFN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCB0byBnZXQgdGhlIGFjdHVh bA0KPlRBQ0FDUysgc3BlY2lmaWNhdGlvbiB0aGF0IHBlb3BsZSBjYW4gaW1wbGVtZW50Ii4NCj4N Cj4gIEl0IHNob3VsZG4ndCBiZSBhIGNvbnRlbnRpb3VzIGlzc3VlLiAgRWl0aGVyIGRvY3VtZW50 IHRoZSBwcm90b2NvbCwgb3INCj5hZG1pdCB3ZSdyZSBub3QgZ29pbmcgdG8gZG9jdW1lbnQgdGhl IHByb3RvY29sLg0KPg0KPiAgQWxhbiBEZUtvay4NCj4NCg0K From nobody Thu Oct 6 13:17:08 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B894B129430 for ; Thu, 6 Oct 2016 13:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.193 X-Spam-Level: X-Spam-Status: No, score=-7.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, UNPARSEABLE_RELAY=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 NOeh4282hDWm for ; Thu, 6 Oct 2016 13:17:03 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id F330A1293DF for ; Thu, 6 Oct 2016 13:17:02 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u96KCk61021324; Thu, 6 Oct 2016 16:12:46 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Douglas Gash (dcmgash)" , Alan DeKok Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. - Security element (or not) Thread-Index: AQHSIA23Qk1eACCHMECzU4HZfySLXqCb3RGA Date: Thu, 6 Oct 2016 20:16:58 +0000 Message-ID: <9AFE3EB4-C59A-4FF2-A88D-11D7938534FF@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.1.160916 x-originating-ip: [172.25.177.81] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3558615417_323441911" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060350 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. - Security element (or not) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:17:07 -0000 --B_3558615417_323441911 Content-type: multipart/alternative; boundary="B_3558615417_386779009" --B_3558615417_386779009 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable One comment: stating that (for example) =E2=80=9Cthis protocol has no security=E2=80=9D= leave no illusions (covers the situation completely), but convinces securit= y practitioners that its advancement should be blocked/vetoed (=E2=80=9Cdiscuss=E2=80=9D= in IETF lingo J) until the =E2=80=9Cno security=E2=80=9D situation changes. --=20 Regards, Uri Blumenthal =20 On 10/6/16, 16:10 , "OPSAWG on behalf of Douglas Gash (dcmgash)" wrote: =20 Hi, =20 Regarding your a) b) c) elements, we are happy to work through the issues in a different thread, and will wait your final instalment. This specific question/thread regarded security, hence the handy change of subject. =20 The reason I would go along the lines of your proposal at the end (but with a little modification) rather than analysing security of each part, is because such an inclusive statement covers the situation completely, and no one will be under any illusions. =20 Thanks, =20 Regards, =20 Doug. =20 On 06/10/2016 19:51, "Alan DeKok" wrote: =20 On Oct 6, 2016, at 1:34 PM, Douglas Gash (dcmgash) wrote: Regarding the security concern, the approach we have with the current document is: 1) A statement that the protocol does not provide security in a modern environment.=20 =20 I'm happy with that. =20 2) The two common approaches to support T+ so that it may be used. =20 OK... =20 3) An indication that a version with built-in security is to follow, which will not require the mitigations in 2) (actually I suspect it may precede the info document ;-)) =20 Except that the current document doesn't even document CHAP securely. =20 RFC 1994 (published in 1996) says: Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness. =20 Tho I'll also note that RFC 1994 also doesn't specify a minimum length for the challenge. =20 That is, the document doesn't even meet the security requirements in place in 1994. =20 We need to make sure there is no ambiguity for 1) for any security review. No soft-peddalling. T+ provides the function, not the security. =20 I'm fine with that. =20 I want to document historical TACACS+. This means the document needs to answer the following questions: =20 a) can people implement it? =20 b) can people gain the maximum amount of security available in the historical protocol? =20 c) can people be aware of the security concerns and trade-offs with using the historical protocol? =20 The push-back so far shows that the answers are: =20 a) no =20 b) no =20 c) no =20 I suggest these are the wrong answers. *All* of them are the wrong answers. =20 My question would be: would this dissection of vulnerabilities and exploration of the attack vectors would help anyone from a security perspective, when we have established that the approaches 2) are required? =20 Yes. See any of the RADIUS RFCs in the last 5 years. The SAAG reviews require discussion not only of the issues with the new standards, but also of the problems with the historical protocol. =20 I suspect that we=C2=B9d probably miss some, and that may give implementors more comfort than is afforded by the clear and simple statement. =20 The argument that we can't be perfect isn't a reason to give up entirely. =20 If the statement is anything other than "no one should use this protocol for anything", we might as well *try* to document security issues. =20 Therefore, for security review, I=C2=B9d suggest we keep the statement simple, as defined above. However, if this statement is not clear enough/correct in the document, then certainly, it should be clarified. =20 Then the introduction and/or abstract should say: =20 "This document attempts to specify the historical TACACS+ protocol. However, there are many portions of the protocol which are under-specified or unspecified. We cannot second-guess twenty years of practice here. As a result, this specification is incomplete, under-specified, insecure, and should not be used by anyone to implement anything. Please wait for the Standards track document to get the actual TACACS+ specification that people can implement". =20 It shouldn't be a contentious issue. Either document the protocol, or admit we're not going to document the protocol. =20 Alan DeKok. =20 =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =20 --B_3558615417_386779009 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

One comment: stating that (f= or example) “this protocol has no security” leave no illusions (= covers the situation completely), but convinces security practitioners that = its advancement should be blocked/vetoed (“discuss” in IETF ling= o J) until the “no security” sit= uation changes.

-- 

Regards,

Uri Blumenthal

 

On 10/6/16, 16:10 , "OPSAWG on behalf = of Douglas Gash (dcmgash)" <opsawg-bounces@ietf.org on behalf of dcmgash@cisco.com> wrote:

 

Hi,

 

Regarding your a) b) c) elements, we are happy to work through the issues<= o:p>

in a different thread, and will wait = your final instalment. This specific

= question/thread regarded security, hence the handy change of subject.

 

The reason I would go along the lines of your proposal at the end (but

with a little modification) rather than= analysing security of each part,

is = because such an inclusive statement covers the situation completely,

and no one will be under any illusions.=

 

Thanks,

 =

Regards,

&= nbsp;

Doug.

 

On 06/10/2016 19:51, = "Alan DeKok" <aland@= deployingradius.com> wrote:

 

On Oct 6, 2016, at= 1:34 PM, Douglas Gash (dcmgash) <dcmg= ash@cisco.com>

wrote:

Regarding the security concern,= the approach we have with the current

document is:

1) A statement that th= e protocol does not provide security in a modern

=

environment.

 

  I'm happy with t= hat.

 

2) The two common approaches to support T+ so th= at it may be used.

=  

  OK...=

 

<= p class=3DMsoNormal>3) An indication that a version with built-in security is to follow,

which

=

will not require the mitigations in 2) (actually I suspect it may

precede

=

the info document ;-))

<= p class=3DMsoNormal> 

  Except that = the current document doesn't even document CHAP securely.<= /p>

 

 &nb= sp;RFC 1994 (published in 1996) says:

   Each challenge value SHOULD be unique, since repetition of a

   challenge value in conjun= ction with the same secret would permit an

<= p class=3DMsoNormal>   attacker to reply with a previously intercepted response.=   Since it

   is = expected that the same secret MAY be used to authenticate with

   servers in disparate geographic regio= ns, the challenge SHOULD exhibit

&nbs= p;  global and temporal uniqueness.

 

  Tho I'll also = note that RFC 1994 also doesn't specify a minimum length

for the challenge.

 

  That is, the doc= ument doesn't even meet the security requirements in

place in 1994.

&= nbsp;

We need to make sure t= here is no ambiguity for 1) for any security

review.

No soft-peddalling. T= + provides the function, not the security.

 

  = ;I'm fine with that.

 

  I want to document historical TACA= CS+.  This means the document needs

to answer the following questions:

=

 

a) can people implement= it?

 

b) can people gain the maximum amount of security available in= the

historical protocol?<= /span>

 

c)= can people be aware of the security concerns and trade-offs with using=

the historical protocol?

 

 &= nbsp;The push-back so far shows that the answers are:

<= /div>

 

<= span style=3D'font-size:11.0pt;font-family:Consolas;color:black'>a) no

 

b) no

 

<= /div>

c) no

 

  I suggest these are the wrong an= swers.  *All* of them are the wrong

answers.

 

My question would be: would this di= ssection of vulnerabilities and

explo= ration of the attack vectors would help anyone from a security

perspective, when we have established that the app= roaches 2) are

required?

 

  Yes.  See any of the RADIUS RFCs in the last= 5 years.  The SAAG reviews

require discussion not only of the issues with the new standards, but<= /o:p>

also of the problems with the historical p= rotocol.

 

=

I suspect that we=C2=B9d probably miss some, and= that may give implementors

more comf= ort than is afforded by the clear and simple statement.

 

  The argument that we can't be perfect isn't a reason to give u= p

entirely.

 

  If t= he statement is anything other than "no one should use this<= /span>

protocol for anything", we might as well *t= ry* to document security

= issues.=

 

Therefore, for security review, I=C2=B9d suggest we keep the = statement

simple,

as defined above. However, if this statement is not clea= r enough/correct

in the document, the= n certainly, it should be clarified.

 

  Then = the introduction and/or abstract should say:

 

"This document at= tempts to specify the historical TACACS+ protocol.

However, there are many portions of the protocol which are

under-specified or unspecified. &nb= sp;We cannot second-guess twenty years of

practice here.  As a result, this specification is incomplete= ,

under-specified, insecure, and shou= ld not be used by anyone to implement

anything.  Please wait for the Standards track document to get th= e actual

TACACS+ specification that p= eople can implement".

 = ;

  It shouldn't be a contentiou= s issue.  Either document the protocol, or

admit we're not going to document the protocol.

 

&nb= sp; Alan DeKok.

 

 

_______________________________________________

OPSAWG mailing list

--B_3558615417_386779009-- --B_3558615417_323441911 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUZwYJKoZIhvcNAQcCoIIUWDCCFFQCAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCjM7 SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQxMgQwS/wXusY/UzasGPVP kw/8WLUTrbFyj63GLNcjjT9c4IHNtcQPNYSnawTW5ILkyC2WMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MTAwNjIwMTY1N1owDQYJKoZIhvcNAQEBBQAE ggEAStzqLNLDsTQvX+BlNozhg3v18N7USSw5yh6cy7k8RfQgh5YUW0MZLM7bg6wSKR7Q5f4W wNaY2jL5njdEh0FsEAEntS8pSpsa4LgXycyS6p23E0SHfJod64NGASJ83eHEO0x2P05M6EU4 w7V5csxyUoS+YllGx3xQ4yy1lv2zliUNdpuq6ABb/wZppshYL3k6sigSngWaRA3Q8jJmnUS2 CQ4fd0pT9ZAZwr03JDfMkAmbjyYJC97F1Vrmp+yy4SuxJ+Pu1wFzTiAl3Ksa168I+IOBgTh+ ZZt7RINt6C5A/i4Frlb4vWRtm2ggDG5nrGE6FqD4Wlf4fuEZRhF2xEatcQ== --B_3558615417_323441911-- From nobody Thu Oct 6 22:51:03 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0A7129447 for ; Thu, 6 Oct 2016 22:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA-Xco6U2Qki for ; Thu, 6 Oct 2016 22:50:59 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ACEF127078 for ; Thu, 6 Oct 2016 22:50:59 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id o68so34760164qkf.3 for ; Thu, 06 Oct 2016 22:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8QSW0B8C47nVzxDL2B7UuO19mdZxUjiY1BAZFncpKCo=; b=hXm11QJet2TL+LQRqGk2PQjwl+vSZW8u+c27pkEwqUm1LYTGoTH58M23XBwoLzjZGR heceJBeCoRPRF4SD6NQi+6mqjYHqnVF6tCFQXYxBzArnqghZWxDzLn7m1PkvjnEZnxdI fgBqbt/Wau4oE9qaKgCV+3KKAQ8f9HJq9sqAb6Nwz4XIzWn9hN+jIEQdiL613LEvIVyx 4jxlaSU2hRBAJHfD9O2oPnbUKw3OcdTYsPhMlA8AYw0nl2KEsCx+U2JXlJHNkSKQVjUO xWdfc7ldTFITmv/e9PbDxQwp0MDboCPQ8ad4NIMNoHI9nFKGuqbylm8KdqLH2mE/pOo3 /jOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8QSW0B8C47nVzxDL2B7UuO19mdZxUjiY1BAZFncpKCo=; b=N2QDojDur5h8Z6HTkcAQ/6pz6cB50XX0kme5AoYinuGtj20J8oChphgk+HoL23B9RQ VqN08aWxn0QfpySdvc7UMy7cXSQg8twQrvsczpjcTxniJwnrdQppOH01uiy8aunGvFg7 4jiKMOneRDQEh/+c/UCL18pXEZiyOyQ9Raz2WruiCST+9onfsvd7xTAAmRU80QuiR8Sa CO8cvwrd8iEcpnUsp3Fke1oDtpBw2Y6+V74KdATAIPBhrfNErYiDvURs4nfnkGZvU8g5 j1MIGAQmw51p5jWI1iTo3pZC1BYqKMxfAWANJVWB/5y517WQF7KwBVZHaQJ/xkoOo7ZN KXhg== X-Gm-Message-State: AA6/9RmnwQHKwdH5/E8635kS0VKd30n5ClNmMue20wosJViQoiV9f47z6kM5yY5QqQA3MnI3+LBagw4ONt5iHg== X-Received: by 10.55.135.1 with SMTP id j1mr3865588qkd.46.1475819458386; Thu, 06 Oct 2016 22:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.21.228 with HTTP; Thu, 6 Oct 2016 22:50:57 -0700 (PDT) In-Reply-To: <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> <2769B0A9-00DE-41F8-9971-9C0AABDC8109@deployingradius.com> <003101d21fed$6978cb80$4001a8c0@gateway.2wire.net> From: Dan Romascanu Date: Fri, 7 Oct 2016 08:50:57 +0300 Message-ID: To: "t.petch" Content-Type: multipart/alternative; boundary=94eb2c073c1091feef053e3ffea4 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 05:51:03 -0000 --94eb2c073c1091feef053e3ffea4 Content-Type: text/plain; charset=UTF-8 FWIW - I agree with much of Alan's observation and with his approach here. Documenting an existing protocol does not mean changing it. Asking for changes in the content of the document (including more details about implementation of parts of the protocols, and security implications of deploying this technology in today's Internet) does not mean changing the protocol. These are legitimate comments and IMO necessary changes to ask at WGLC phase. Keeping 'changes to the minimum, omissions or contradictions and those required by the publication process' is not a WGLC goal. Regards, Dan On Thu, Oct 6, 2016 at 7:19 PM, t.petch wrote: > ----- Original Message ----- > From: "Alan DeKok" > Sent: Thursday, October 06, 2016 2:56 PM > > > On Oct 6, 2016, at 6:00 AM, t.petch wrote: > > Alan is right to pick up on the style - philosophical - and the > > security - lack of. > > > > But do we want to change it all at this time? > > Please show where I'm trying to change the protocol. > > > > Alan > > You are not, and I did not mean to imply that you were. I mean that > your changes seem to me reflect a different approach, a different style > which I do not see as that of the authors. I see the existing style as > unusual, but not wrong, and am content to leave it as is for an > Informational RFC which documents what is, or perhaps what has been. You > used the word 'philosophical' and I agreed. > > So I would keep changes to the minimum, omissions or contradictions and > those required by the publication process (such as splitting References > into Informative and Normative). It is, after all, WGLC. > > On Security, I would invite the chairs to ask for an early review by the > Security Directorate, explaining the context of this document, asking > them how much more is needed and how it should be expressed. It might > not be very much although my experience is that I never know in advance > what they are going to come up with. > > Tom Petch > > > This is an Informational document describing the state of play as of > > some time past, perhaps not as far back as 1997 but not for 2016. It > > would require many changes to make it a 2016 Standards Track document > > but that is not what I see us doing except that is how I take Alan's > > comments. > > Then you're not reading my comments. > > I would like to implement historical TACACS+. I have *NO IDEA* what > to do for huge swaths of the protocol. > > I would like to deploy historical TACACS+. I have *NO IDEA* what the > security implications are of using it. > > > The analogy I have in mind is when SSL v3 was published, long after it > > had been superseded by anyone who took security seriously, but was > > needed as an RFC to refer to, although it would not pass muster > because > > the security thereof was too weak. It would not have met the > standards > > of the day but was published despite that. > > I'm not asking that the protocol be *fixed* in this document. I'm > asking that it be *documented*. That shouldn't be hard to understand. > I've been saying it for about a year now, for anyone who bothers to read > my messages. > > I'll note that RFC 6101 is "Category: Historic", and has substantial > text about the security (or lack thereof) of the protocol. It has > substantial text about how the historical protocol works. I'm suggesting > we do the same here. > > I'm suggesting the the TACACS+ protocol be documented as designed, in > sufficient detail that someone can read the document and create an > inter-operable implementation. I'm suggesting that the TACACS+ > protocols security (or lack thereof) be documented. > > Which is (so far as I'm aware) still IETF practice for informational > specifications. > > If the goal for the document is something else, fine. Update the > document to say that. Something like: > > "This document attempts to specify the historical TACACS+ protocol. > However, there are many portions of the protocol which are > under-specified or unspecified. We cannot second-guess twenty years of > practice here. As a result, this specification is incomplete, > under-specified, insecure, and should not be used by anyone to implement > anything. Please wait for the Standards track document to get the > actual TACACS+ specification that people can implement". > > If the document can be updated with such text, I'll withdraw all of my > review comments. But I predict that the document won't pass security > area review. And they'll make all of the same comments as I've made > here, with a recommendation that the document not be published until > it's fixed. > > Alan DeKok. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --94eb2c073c1091feef053e3ffea4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW - I agree with much of Alan's observati= on and with his approach here. Documenting an existing protocol does not me= an changing it. Asking for changes in the content of the document (includin= g more details about implementation of parts of the protocols, and security= implications of deploying this technology in today's Internet) does no= t mean changing the protocol. These are legitimate comments and IMO necessa= ry changes to ask at WGLC phase. Keeping 'changes to the minimum, omiss= ions or contradictions and those required=C2=A0 by the publication process&= #39; is not a WGLC goal.

Regards,

Dan

On Thu, Oct 6, 2016 at 7= :19 PM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Alan DeKok" <aland@deployingradius.com>
Sent: Thursday, October 06, 2016 2:56 PM


On Oct 6, 2016, at 6:00 AM, t.petch <ietfc@btconnect.com> wrote:
> Alan is right to pick up on the style - philosophical - and the
> security - lack of.
>
> But do we want to change it all at this time?

=C2=A0 Please show where I'm trying to change the protocol.

<tp>

Alan

You are not, and I did not mean to imply that you were.=C2=A0 I mean that your changes seem to me reflect a different approach, a different style
which I do not see as that of the authors.=C2=A0 I see the existing style a= s
unusual, but not wrong, and am content to leave it as is for an
Informational RFC which documents what is, or perhaps what has been. You used the word 'philosophical' and I agreed.

So I would keep changes to the minimum, omissions or contradictions and
those required=C2=A0 by the publication process (such as splitting Referenc= es
into Informative and Normative).=C2=A0 It is, after all, WGLC.

On Security, I would invite the chairs to ask for an early review by the Security Directorate, explaining the context of this document, asking
them how much more is needed and how it should be expressed.=C2=A0 It might=
not be very much although my experience is that I never know in advance
what they are going to come up with.

Tom Petch

> This is an Informational document describing the state of play as of > some time past, perhaps not as far back as 1997 but not for 2016.=C2= =A0 It
> would require many changes to make it a 2016 Standards Track document<= br> > but that is not what I see us doing except that is how I take Alan'= ;s
> comments.

=C2=A0 Then you're not reading my comments.

=C2=A0 I would like to implement historical TACACS+.=C2=A0 I have *NO IDEA*= what
to do for huge swaths of the protocol.

=C2=A0 I would like to deploy historical TACACS+. I have *NO IDEA* what the=
security implications are of using it.

> The analogy I have in mind is when SSL v3 was published, long after it=
> had been superseded by anyone who took security seriously, but was
> needed as an RFC to refer to, although it would not pass muster
because
> the security thereof was too weak.=C2=A0 It would not have met the
standards
> of the day but was published=C2=A0 despite that.

=C2=A0 I'm not asking that the protocol be *fixed* in this document.=C2= =A0 I'm
asking that it be *documented*.=C2=A0 That shouldn't be hard to underst= and.
I've been saying it for about a year now, for anyone who bothers to rea= d
my messages.

=C2=A0 I'll note that RFC 6101 is "Category: Historic", and h= as substantial
text about the security (or lack thereof) of the protocol.=C2=A0 It has
substantial text about how the historical protocol works. I'm suggestin= g
we do the same here.

=C2=A0 I'm suggesting the the TACACS+ protocol be documented as designe= d, in
sufficient detail that someone can read the document and create an
inter-operable implementation.=C2=A0 I'm suggesting that the=C2=A0 TACA= CS+
protocols security (or lack thereof) be documented.

=C2=A0 Which is (so far as I'm aware) still IETF practice for informati= onal
specifications.

=C2=A0 If the goal for the document is something else, fine.=C2=A0 Update t= he
document to say that.=C2=A0 =C2=A0Something like:

=C2=A0 "This document attempts to specify the historical TACACS+ proto= col.
However, there are many portions of the protocol which are
under-specified or unspecified.=C2=A0 We cannot second-guess twenty years o= f
practice here.=C2=A0 As a result, this specification is incomplete,
under-specified, insecure, and should not be used by anyone to implement anything.=C2=A0 Please wait for the Standards track document to get the
actual TACACS+ specification that people can implement".

=C2=A0 If the document can be updated with such text, I'll withdraw all= of my
review comments.=C2=A0 But I predict that the document won't pass secur= ity
area review.=C2=A0 And they'll make all of the same comments as I'v= e made
here, with a recommendation that the document not be published until
it's fixed.

=C2=A0 Alan DeKok.

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

--94eb2c073c1091feef053e3ffea4-- From nobody Fri Oct 7 17:53:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BF612955B for ; Fri, 7 Oct 2016 17:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.897 X-Spam-Level: X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.996, 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 Vjdp6dkZlcNC for ; Fri, 7 Oct 2016 17:53:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 02D6D12950B for ; Fri, 7 Oct 2016 17:53:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bsfsp-0003W8-H0; Sat, 08 Oct 2016 00:52:59 +0000 Date: Sat, 08 Oct 2016 09:52:56 +0900 Message-ID: From: Randy Bush To: t.petch In-Reply-To: <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <025401d21fb8$71906e20$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 00:53:08 -0000 > But do we want to change it all at this time? yes. a proper sec cons does not change the protocol but advises as to its use. randy From nobody Sat Oct 8 10:52:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC31295FB for ; Sat, 8 Oct 2016 10:52:45 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 jSMPVv4bME0J for ; Sat, 8 Oct 2016 10:52:37 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9FF1295EB for ; Sat, 8 Oct 2016 10:52:37 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f128so48247781qkb.1 for ; Sat, 08 Oct 2016 10:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7krmwsJKPZwQiyDhSV/pmDDoNZCzzLhpplRxLfjZshI=; b=1NTLIZswV1N4weCAgZkHTgrP5eZe7RyRViespEd9/HRhKYUzs/36st/c5yVdiwu3TW YP/+mGjHTPM7Q8Fnpi8wG/sPMM2HOn4QtTBm8GX6QFjeFJKyspQdm5N+mtHpc1fViAwX 0K9AXw+EoAuvS4uef0LhebjrhOQY+IfPJ6dn7xobpOuAggdIo5yX/MNFC59X3c+rBAPo mlxNehN8WxnHenfXBuO3lX5uzqbYj4PSyKnBjVi4q8QCGQutEHn453erimICXMni1Qgk mNCsmNjpOKbkY2aPMoqJnZDtqhO19JLkKL005W4smD9t7VNMtMUvKnur7PTWEZbeAICA racA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7krmwsJKPZwQiyDhSV/pmDDoNZCzzLhpplRxLfjZshI=; b=TTyYVveJtodA/TCfc2E9lAW8+ReS2YZVq7Adt5muwZN7EkTfNkmYgHe+TNH1c9aVOz D7N01//+N6jLgR3Ba5nnug1mqxlZOMwn22j7mY2MsVO6omDy20Td5fMiBzjN/wx/mYDG GDeLWs0OdpeKIsgT1olGmdEIy/LumasDw90ajKKiAiusQ311cUs/bgB1+HwX5rt5Do2n PCi6P9C959KF3DzQ+6KLSRg2hQcB3nRYq4FLlh+iQDibTNr0V/aaoqwnPECWpQGN+Rdw aVd19WTxesgngo2cttUwSyJ/mssy+q1Y+uohXYU8J/ZQPrj3bVTby6YdtivF/sOtxS+S cOaw== X-Gm-Message-State: AA6/9RkfrClXVDJ+EcIjK5o16MkflLz7y07ZHrVPpm5WJ4fzVAqrCqp5JnEFPlvYv4MNSoPpqm9rmvfKYtPDIoHd X-Received: by 10.233.237.145 with SMTP id c139mr23870876qkg.29.1475949156669; Sat, 08 Oct 2016 10:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Sat, 8 Oct 2016 10:52:06 -0700 (PDT) In-Reply-To: References: <3FCB4CBE-6885-4708-AD21-4D4B2D1AA7EE@juniper.net> <058F02CC-5369-4A4D-96E9-B81FB6407973@juniper.net> <53f367e8-f011-a0e2-d027-8d21476a47dd@cisco.com> <2708A743-B900-41D2-9485-8EF901EBBE3B@juniper.net> From: Warren Kumari Date: Sat, 8 Oct 2016 13:52:06 -0400 Message-ID: To: Zhoutianran Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "opsawg-chairs@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 17:52:46 -0000 Hi all, So, reviving this thread... I think that there is sufficient merit to request early allocations according to RFC7120 criteria. Please note that if we request early allocations, it is good for one year, renewable once. Assuming that the document progresses within that two year timeframe to become and RFC, the IANA will convert the early allocations into a permanent one -- if we don't, it will automatically expire and be marked as such in the registry (or, if the WG decided that they want to abandon this work, we can request that they be released early). While the document is still in flux, the parts around the allocations should be stable. The majority of the requests are for allocations from large (or unlimited) code-spaces, and so it does not seem like there is scarcity. The exception is the DHCPv4 (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameter= s.xhtml#options); the v4 option space is 8bit, and ~68 (or, around a quarter) are unassigned. The IPv6 option space is 16bit (65535 entries) and so close to unlimited. Because I am not at all familiar with the sensitivity / implications of the registrations in the various registries, I'm planning on asking an expert reviewer from each of the below registries to please take an early (before early allocation!) look at the document / relevant parts of the document to confirm that we are doing the right thing, that there isn't a more appropriate sub-registry, etc. "SMI Security for PKIX Certificate Extension" Registry (http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-= 1.3.6.1.5.5.7.1) - "id-pe-mud-uri"; Registration Procedure: Specification Required. The IANA considerations for this say: "The expert is expected to ensure that any new values are strongly related to the work that was done by the PKIX Working Group. That is, additional object identifiers are to be related to X.509 certificates, X.509 attribute certificates, X.509 certificate revocation lists (CRLs), or protocols associated with them. Object identifiers for other purposes should not be assigned in this arc.", so it is unclear if this is the appropriate place for this, but perhaps Russ can suggest a better location / system. Well Known URIs (http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml) - "mud"; Registration Procedure: Expert Review, mnot. MIME Media-type Registration (http://www.iana.org/assignments/media-types/media-types.xhtml) - "application/mud+json"; For allocations under the "Standards Tree requests made through IETF documents will be reviewed and approved by the IESG..." - this sounds like 'IESG Approval', but I'm planning on asking our AD, Ned and / or Murray. Well Known Universal Resource Name (URNs) (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) - "urn:mud" ; Registration Procedure: IETF Consensus. The final issue is the creation of a registry for "IANA Link Layer Discovery Protocol (LLDP) TLV subtype values" - this would create a registry under the IANA OUI, as a "vendor-specific TLV". It appears that there currently is no registry under the IANA vendor specific OUI for LLDP, and this is creates an 8 bit registry. I'm *assuming* that we could have something like 1-253 are useable, and 254 can later be defined to be an "extension", but I'd like to get some additional feedback. https://tools.ietf.org/html/rfc7042 seems to be the closest that I could find..... The "IANA Considerations" section of the document also needs some polishing -- it would be nice if it pointed more definitely at the registry from which it is making requests, if the "{{secon}}" label expanded, and if the formatting of the URN bit were better. So, does anyone object to this plan? If so, please let us know by October 13th If not, the chairs will reach out to our AD / the Designated Experts as described above. On Tue, Aug 30, 2016 at 9:47 PM, Zhoutianran wrote= : > Hi Kent, > > Here are some words copied from RFC 7120. I think they can address your q= uestion. > > Request: > 6. IANA makes an allocation from the appropriate registry, marking > it as "Temporary", valid for a period of one year from the date > of allocation. The date of first allocation and the date of > expiry are also recorded in the registry and made visible to the > public. > > Follow up: > If the document progresses to the point at which IANA normally makes > code point allocations, it is the responsibility of the authors and > the WG chairs to remind IANA that there were early allocations and of > the code point values allocated in the IANA Considerations section of > the RFC-to-be. Allocation is then just a matter of removing the > "Temporary" tag from the allocation description. > > Expiry: > If an early allocation expires before the document progresses to the poin= t where > IANA normally makes allocations, the authors and WG chairs may repeat > the process described in Section 3.1 to request renewal of the code > points. At most, one renewal request may be made; thus, authors > should choose carefully when the original request is to be made. > > If a follow-up request is not made, or the document fails to progress > to an RFC, the assignment will remain visible in the registry, but > the temporary assignment will be shown to have expired as indicated > by the expiry date. The WG chairs are responsible for informing IANA > that the expired assignments are not required and that the code > points are to be marked "deprecated". > > A deprecated code point is not marked as allocated for use as > described in any document (that is, it is not allocated) and is not > available for allocation in a future document. The WG chairs may > inform IANA that a deprecated code point can be completely > de-allocated (i.e., made available for new allocations) at any time > after it has been deprecated. > > > Regards, > Tianran > >> -----Original Message----- >> From: Kent Watsen [mailto:kwatsen@juniper.net] >> Sent: Tuesday, August 30, 2016 9:56 PM >> To: Warren Kumari; Eliot Lear >> Cc: Zhoutianran; opsawg@ietf.org; opsawg-chairs@ietf.org >> Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment //= RE: >> Adoption poll for draft-lear-ietf-netmod-mud-04 >> >> >> I didn=E2=80=99t know that, thanks for the clarification. I retract my = comment. >> >> But I wonder then, if they are temporary and reclaimed, will Elliot=E2= =80=99s goal >> be achieved? - or is it the case that the temporary assignments can bec= ome >> permanent through the RFC process? - an optimistic long-term allocation? >> >> Thanks, >> Kent >> >> >> On 8/29/16, 4:39 PM, "Warren Kumari" wrote: >> >> ... and just as a reminder to the WG, early allocations are explicit= ly >> temporary, and are marked in the registry as such. >> >> This isn't burning a critical resource forever - the allocations >> spaces are not very rare, and they can be reclaimed if needed... >> >> W >> >> On Thu, Aug 25, 2016 at 4:49 PM, Eliot Lear wrote: >> > Yes, there is. And Early assignment is not an unusual request. S= ee >> RFC >> > 7120. >> > >> > >> > On 8/25/16 10:01 PM, Kent Watsen wrote: >> > >> > >> > >> > I don=E2=80=99t know. It seems that every draft could make simila= r claims, >> and yet >> > having IANA make early assignments all the time wouldn=E2=80=99t b= e good. I >> don=E2=80=99t >> > see why this draft should get a pass. Is there any documentation >> detailing >> > criteria for early assignments? >> > >> > >> > >> > Kent >> > >> > >> > >> > From: Eliot Lear >> > Date: Thursday, August 25, 2016 at 2:36 PM >> > To: Kent Watsen , Zhoutianran >> , >> > Warren Kumari >> > Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" >> > >> > Subject: Re: [OPSAWG] WG consensus call for the IANA early assignm= ent >> //RE: >> > Adoption poll for draft-lear-ietf-netmod-mud-04 >> > >> > >> > >> > Hi Kent, >> > >> > We're doing some open source and would like to make it easier for = those >> who >> > are coding to have to do a little less REcoding. I doubt very muc= h >> we're >> > going to see much change in the content or format the URL or the o= ption. >> > That's what most of the requests are for. Where I expect we will = see >> change >> > is in the content of the YANG file. There we have the option to b= ump >> the >> > version # in the URL if we think there has been any real uptake of >> earlier >> > versions. >> > >> > Fair enough? >> > >> > Eliot >> > >> > >> > >> > On 8/25/16 7:27 PM, Kent Watsen wrote: >> > >> > >> > >> > Why is an early assignment being requested? I think it unusual, >> especially >> > for a draft that was just adopted, and no justification is given f= or >> why >> > it=E2=80=99s needed other than =E2=80=9Cto assist with interoperab= le development=E2=80=9D... >> > >> > >> > >> > Kent >> > >> > >> > >> > From: OPSAWG on behalf of Zhoutianran >> > >> > Date: Tuesday, August 23, 2016 at 5:46 AM >> > To: Eliot Lear , Warren Kumari >> > Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" >> > >> > Subject: [OPSAWG] WG consensus call for the IANA early assignment = //RE: >> > Adoption poll for draft-lear-ietf-netmod-mud-04 >> > >> > >> > >> > Hi All, >> > >> > >> > >> > Since the authors of the draft-ietf-opsawg-mud-00 asked for the ea= rly >> > assignment for various registries from IANA, I would like to ask t= he >> WG >> > consensus. >> > >> > >> > >> > There will be 1 week since today. You can express your support or >> objection. >> > >> > >> > >> > If there is no objection, I would like to request from the WG. >> > >> > >> > >> > The following is a list of IANA considerations copied from the dra= ft. >> > >> > >> > >> > >> > >> > Best, >> > >> > Tianran >> > >> > >> > >> > ------------------------------------- >> > >> > >> > >> > 15. IANA Considerations >> > >> > >> > >> > 15.1. DHCPv4 and DHCPv6 Options >> > >> > >> > >> > IANA is requested to allocated the DHCPv4 and v6 options as spe= cified >> > >> > in Section 9. >> > >> > >> > >> > 15.2. PKIX Extensions >> > >> > >> > >> > The IANA is requested to assign a value for id-pe-mud-uri in th= e >> "SMI >> > >> > Security for PKIX Certificate Extension" Registry. Its use is >> > >> > specified in Section 10. >> > >> > >> > >> > 15.3. Well Known URI Suffix >> > >> > >> > >> > The IANA is requested to register the URL suffix of "mud" as fo= llows: >> > >> > >> > >> > o URI Suffix: "mud" o Specification documents: this document o >> > >> > Related information: n/a >> > >> > >> > >> > 15.4. MIME Media-type Registration for MUD files >> > >> > >> > >> > The following media-type is defined for transfer of MUD file: >> > >> > >> > >> > o Type name: application >> > >> > o Subtype name: mud+json >> > >> > o Required parameters: n/a >> > >> > o Optional parameters: n/a >> > >> > o Encoding considerations: 8bit; application/mud+json values >> > >> > are represented as a JSON object; UTF-8 encoding SHOULD be >> > >> > employed. >> > >> > o Security considerations: See {{secon}} of this document. >> > >> > o Interoperability considerations: n/a >> > >> > o Published specification: this document >> > >> > o Applications that use this media type: MUD controllers as >> > >> > specified by this document. >> > >> > o Fragment identifier considerations: n/a >> > >> > o Additional information: >> > >> > >> > >> > Magic number(s): n/a >> > >> > File extension(s): n/a >> > >> > Macintosh file type code(s): n/a >> > >> > >> > >> > o Person & email address to contact for further information: >> > >> > Eliot Lear , Ralph Droms >> > >> > o Intended usage: COMMON >> > >> > o Restrictions on usage: none >> > >> > >> > >> > o Author: Eliot Lear , Ralph Droms >> >> > >> > o Change controller: IESG >> > >> > o Provisional registration? (standards tree only): No. >> > >> > >> > >> > >> > >> > 15.5. LLDP IANA TLV Subtype Registry >> > >> > >> > >> > IANA is requested to create a new registry for IANA Link Layer >> > >> > Discovery Protocol (LLDP) TLV subtype values. The recommended >> policy >> > >> > for this registry is Expert Review. The maximum number of entr= ies >> in >> > >> > the registry is 256. >> > >> > >> > >> > IANA is required to populate the initial registry with the valu= e: >> > >> > >> > >> > LLDP subtype value =3D 1 >> > >> > >> > >> > Description =3D the Manufacturer Usage Description (MUD) Unifor= m >> > >> > Resource Locator (URL) >> > >> > >> > >> > Reference =3D < this document > >> > >> > >> > >> > >> > >> > >> > >> > From: Eliot Lear [mailto:lear@cisco.com] >> > Sent: Monday, August 22, 2016 7:04 PM >> > To: Warren Kumari >> > Cc: Zhoutianran; opsawg@ietf.org; opsawg-chairs@ietf.org >> > Subject: Re: Adoption poll for draft-lear-ietf-netmod-mud-04 >> > >> > >> > >> > Hi Warren, Tianran, and all, >> > >> > >> > >> > On 8/17/16 4:17 PM, Warren Kumari wrote: >> > >> > >> > >> > >> > Second, and hopefully not that more of a controversy, I would like >> to >> > request early IANA assignments to assist with interoperable >> > development. These would be listed in the IANA considerations sec= tion >> > of the current draft. If we need a WG draft to make this happen, = that's >> > fine with me, but we should do a quick rev after the assignments. >> > >> > >> > >> > I believe that this *can* be accomplished without it being a WG do= c, >> but it >> > is better / cleaner / easier if we make it a WG doc and then ask f= or >> early >> > assistant. We are fine with lots of revisions / it being submitted >> and then >> > quickly revised. >> > >> > >> > Just following up on this point: we'd like to request early assign= ment >> from >> > IANA for the various registries. Does that go through the chairs = or >> the >> > authors at this point? >> > >> > Thanks, >> > >> > Eliot >> > >> > >> > >> > >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressi= ng >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sat Oct 8 20:36:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEFB129420; Sat, 8 Oct 2016 20:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 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=-2.996, 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 x5ocZn04AWI1; Sat, 8 Oct 2016 20:35:59 -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 1B5AD12940C; Sat, 8 Oct 2016 20:35:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSP98978; Sun, 09 Oct 2016 03:35:55 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 9 Oct 2016 04:35:54 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.186]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Sun, 9 Oct 2016 11:35:47 +0800 From: "Chenrui (Richard)" To: "opsawg@ietf.org" , "denghui02@hotmail.com" Thread-Topic: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AdIh3jIy6eBygY9/T163FpIY0l9gig== Date: Sun, 9 Oct 2016 03:35:46 +0000 Message-ID: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.55.144] Content-Type: multipart/alternative; boundary="_000_0D5441A3DF1544449089458210966F29788EFCD9SZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57F9BB1C.003D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: abb7fb1649a33c1782336b110eceb1b6 Archived-At: Cc: "opsawg-chairs@ietf.org" Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 03:36:02 -0000 --_000_0D5441A3DF1544449089458210966F29788EFCD9SZXEMA501MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSHVpIGFuZCBhbGwsDQoNCldoZW4gSSB3ZW50IHRocm91Z2ggdGhlIGRvY3VtZW50cyBvZiBJ RVRGIzk2LEkgbm90aWNlZCB0aGF0IHRoaXMgZHJhZnQgaGFzIHJhaXNlZCBhIGludGVyZXN0aW5n IHJlcXVpcmVtZW50IGluIENoaW5hIE1vYmlsZSBvZiBFMkUgZGVwbG95bWVudCBpbnRlcmZhY2Ug dG8gYSBtdWx0aXBsZSBWUE5zIGNvbXBvc2VkIGluZnJhc3RydWN0dXJlLCBzdWNoIGFzIEwyK0wz IG5ldHdvcmsuIFNvIHRoZSBpbnRlcmZhY2UgY291bGQgbWFrZSB0aGUgc2VydmljZSBmdWxmaWxs bWVudCBhbmQgbWFuYWdlbWVudCBtb3JlIGVhc3kuDQpJcyBteSB1bmRlcnN0YW5kaW5nIHJpZ2h0 Pw0KDQpJIGRvIGJlbGlldmUgdGhpcyBpbnRlcmZhY2UgYW5kIGl0cyBtb2RlbCBhcmUgaW5kZWVk IGhlbHBmdWwgZm9yIG9wZXJhdG9ycyB0byBzaW1wbGlmeSBvcGVyYXRpb25zIGFuZCBtYW5hZ2Vt ZW50Lg0KQW5kIEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9ucyBuZWVkIHRvIGJlIGRpc2N1c3Nl ZCBhbmQgYWxpZ25lZCB3aXRoIHlvdSBhbmQgZXhwZXJ0cyBpbiBlbWFpbCB0aHJlYWQuDQoNCjEu V2hpbGUgcmVmZXJyaW5nIHRvIGFub3RoZXIgZHJhZnQgYXQgc2FtZSBtZWV0aW5nIDw8c2Vydmlj ZSBtb2RlbCBleHBsYWluZWQ+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC13dS1v cHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDMudHh0KSwNCkkgYmVsaWV2ZSB0aGUgYWJv dmUgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNlIHNob3VsZCBiZSBwb3NpdGlvbiBiZXR3ZWVuIHNl cnZpY2Ugb3JjaGVzdHJhdGlvbiBhbmQgIG5ldHdvcmsgb3JjaGVzdHJhdGlvbihGaWd1cmUgMyku DQpUaGF0IG1lYW4gaXShr3MgYSBpbnRlcm5hbCBpbnRlcmZhY2UgaW4gb25lIG9wZXJhdG9yIGFu ZCBpdCBhY3RzIG5vdCBvbmx5IHRvIGltcGxlbWVudCB0aGUgY3VzdG9tZXIgZmFjaW5nIG1vZGVs IChpLmUuIEwzU00pLGJ1dCBhbHNvIHRvIG1haW50YWluLCBtb25pdG9yIGFuZCBkaWFnbm9zZSB0 aGUgZW5kIHRvIGVuZCBQRS1iYXNlZCBWUE4gc2VydmljZXMgY3Jvc3NpbmcgbXVsdGlwbGUgdGVj aG5vbG9naWVzIGRlcGxveWVkIG5ldHdvcmsuDQpJcyBpdCByaWdodD8gYW5kIHNob3VsZCB0aGlz IGludGVyZmFjZSBuZWVkIHRvIHN1cHBvcnQgVlBOIHNlcnZpY2Ugd2hpY2ggbWF5YmUgY3Jvc3Mg bXVsdGlwbGUgb3BlcmF0b3JzPw0KDQoyLkFjdHVhbGx5IEmhr20gbmV3IGd1eSBpbiBJRVRGLCBz byBJoa9tIG5vdCBzdXJlIGlmIHRoZXJlIGFyZSBleGlzdGluZyB3b3JrcyBpbiBJRVRGIHdoaWNo IGNvdWxkIGluc3RydWN0IG9yIG1vZGVsaW5nIHRoZSBpbnRlcmZhY2UvRTJFLXZpZXcgdG8gbWFu YWdlIGEgbXVsdGlwbGUgdGVjaG5vbG9naWVzIGNvbXBvc2VkIG5ldHdvcmssIHdoaWNoIEkgYmVs aWV2ZSB2ZXJ5IGNvbW1vbiBpbiBvcGVyYXRvcqGvcyBkZXBsb3ltZW50IHdoaWxlIHN0aWxsIG5l ZWQgdG8gcHJvdmlkZSBzaW1wbGUgRTJFIHNlcnZpY2UgZXhwZXJpZW5jZSB0byB0aGVpciBjdXN0 b21lcnMuIE1heWJlIHdlIGNhbiBpbXByb3ZlIHNvbWV0aGluZyBoZXJlLiBTbyBpZiBleHBlcnRz IGhlcmUgaGF2ZSBtb3JlIGJhY2tncm91bmQsIHBsZWFzZSBoZWxwIG1lLiBUaGFua3MuDQoNCjMu QXMgSSB1bmRlcnN0YW5kIHRoaXMgaW50ZXJmYWNlL21vZGVsIHNob3VsZCBiZSBpbnRlcm5hbCBp biBvcGVyYXRvcnMsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhlcmUgYW55IG90aGVyIG9wZXJhdG9y cyBhcmUgaW50ZXJlc3RlZCBpdCBhbmQgbmVlZCBhIElFVEYgUkZDPw0KDQpUaGFua3MuDQoNClJl Z2FyZHMsDQpSaWNoYXJkIENoZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KtdjWt6O6 ye7b2srQwfq42sf42+DM77uqzqq7+bXYINPKseCjujUxODEyOQ0KSHVhd2VpIFRlY2hub2xvZ2ll cyBDby4sIEx0ZC4NCkJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwg UC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2rei y824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7K vcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+ 1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8 /sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRl ZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBh Ym92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55 IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRp c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSBy ZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkN CnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg== --_000_0D5441A3DF1544449089458210966F29788EFCD9SZXEMA501MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hui and all,

 

When I went through the documents of IETF#96,I= noticed that this draft has raised a interesting requirement in China Mobi= le of E2E deployment interface to a multiple VPNs composed infrastructure, such as L2+L3 network. So the interface could= make the service fulfillment and management more easy.

Is my understanding right?

 

I do believe this interface and its model are = indeed helpful for operators to simplify operations and management.

And I still have some questions need to be dis= cussed and aligned with you and experts in email thread.<= /p>

 

1.While referring to another draft at same mee= ting <<service model explained>> (<= /span>https://tools.ietf.org/id/draft-wu-opsawg-service-model-explain= ed-03.txt),

I believe the above E2E deployment interface s= hould be position between service orchestration and  network orchestra= tion(Figure 3).

That mean it=A1=AFs a internal interface in on= e operator and it acts not only to implement the customer facing model (i.e= . L3SM),but also to maintain, monitor and diagnose the end to end PE-based VPN services crossing multiple technologies deployed n= etwork.

Is it right? and should this interface need to= support VPN service which maybe cross multiple operators?

 

2.Actually I=A1=AFm new guy in IETF, so I=A1= =AFm not sure if there are existing works in IETF which could instruct or m= odeling the interface/E2E-view to manage a multiple technologies composed network, which I believe very common in operator=A1=AFs deploymen= t while still need to provide simple E2E service experience to their custom= ers. Maybe we can improve something here. So if experts here have more back= ground, please help me. Thanks.

 

3.As I understand this interface/model should = be internal in operators, so I=A1=AFm not sure if there any other operators= are interested it and need a IETF RFC?

 

Thanks.

 

Regards,

Richard Chen<= /o:p>

 


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8= =DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com =

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA= =AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6= =CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5= =C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!<= /o:p>

 

--_000_0D5441A3DF1544449089458210966F29788EFCD9SZXEMA501MBXchi_-- From nobody Mon Oct 10 08:15:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D56129462; Mon, 10 Oct 2016 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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=-2.996, 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 UbYehTGfbt2X; Mon, 10 Oct 2016 08:15:13 -0700 (PDT) Received: from BAY004-OMC4S23.hotmail.com (bay004-omc4s23.hotmail.com [65.54.190.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC8312940F; Mon, 10 Oct 2016 08:15:13 -0700 (PDT) Received: from BAY181-W79 ([65.54.190.201]) by BAY004-OMC4S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 10 Oct 2016 08:15:13 -0700 X-TMN: [8EQDPQlqorWwcIPOLogJsXKelSaPGF7d] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2d956c6d-7c8e-4a38-904f-dd9a28e761ba_" From: Hui Deng To: Chenrui Richard , "opsawg@ietf.org" Date: Mon, 10 Oct 2016 23:15:12 +0800 Importance: Normal In-Reply-To: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Oct 2016 15:15:13.0217 (UTC) FILETIME=[193B7310:01D22309] Archived-At: Cc: "opsawg-chairs@ietf.org" Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:15:20 -0000 --_2d956c6d-7c8e-4a38-904f-dd9a28e761ba_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpIaSBSaWNoYXJkLA0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLCBJIHJlY2FsbGVk IHRoYXQgb3RoZXIgdHdvIG9wZXJhdG9ycyBkdXJpbmcgbGFzdCB0aW1lIGYyZiBtZWV0aW5nIGhh ZCBtYWRlIHNvbWUgY29tbWVudHMgYWJvdXQgZmVkZXJhdGlvbiBpc3N1ZSwgaG9wZSB0aGV5IGNh biBlbGFib3JhdGUgbW9yZSBkZXRhaWwgY29tbWVudHMgaGVyZSBhcyB3ZWxsLCBpbmxpbmUgd2l0 aCA9PT4NCkZyb206IGNoZW5ydWlAaHVhd2VpLmNvbQ0KVG86IG9wc2F3Z0BpZXRmLm9yZzsgZGVu Z2h1aTAyQGhvdG1haWwuY29tDQpDQzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVu dHMtMDEudHh0DQpEYXRlOiBTdW4sIDkgT2N0IDIwMTYgMDM6MzU6NDYgKzAwMDANCg0KCgoKCgoK CgpIaSBIdWkgYW5kIGFsbCwKIApXaGVuIEkgd2VudCB0aHJvdWdoIHRoZSBkb2N1bWVudHMgb2Yg SUVURiM5NixJIG5vdGljZWQgdGhhdCB0aGlzIGRyYWZ0IGhhcyByYWlzZWQgYSBpbnRlcmVzdGlu ZyByZXF1aXJlbWVudCBpbiBDaGluYSBNb2JpbGUgb2YgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNl IHRvIGEgbXVsdGlwbGUgVlBOcwogY29tcG9zZWQgaW5mcmFzdHJ1Y3R1cmUsIHN1Y2ggYXMgTDIr TDMgbmV0d29yay4gU28gdGhlIGludGVyZmFjZSBjb3VsZCBtYWtlIHRoZSBzZXJ2aWNlIGZ1bGZp bGxtZW50IGFuZCBtYW5hZ2VtZW50IG1vcmUgZWFzeS4KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdo dD8KID09PiBZZXMsIGN1cnJlbnQgZXhpc3RpbmcgTDNTTSBhcmUgbW9zdGx5IHRhbGtpbmcgYWJv dXQgY3VzdG9tZXIgZmFjaW5nIHNlcnZpY2UgbW9kZWwudGhpcyByZXF1aXJlbWVudCBleHBlY3Rz IHRvIGhlbHAgb3BlcmF0b3JzIHdpdGggbGFyZ2Ugc2NhbGUgdG8gbWFuZ2UgdGhlIHVuZGVybGF5 IG5ldHdvcmsgd2l0aCBhIGdsb2JhbCB2aWV3LiAgKGhlcmUgY291bGQgYmUgYSBtdWx0aXBsZSBv cGVyYXRvcnMsIHRoYXQgaXMgcmVsYXRlZCB0byBmZWRlcmF0aW9uKSBhbiBlbnRlcnByaXNlIGN1 c3RvbWVyIG1heSBzaW1wbHkgcmVxdWVzdCBhIEwzIFZQTiBzZXJ2aWNlLCBidXQgb3BlcmF0b3Ig aGFzIHRvIHByb3Zpc2lvbiBhbmQgbWFuZ2UgdGhlIGVuZCB0byBlbmQgdW5kZXJsYXkgbmV0d29y ayBjb25zdHJ1Y3RlZCB3aXRoIG11bHRpcGxlIEFTZXMgYW5kIHRlY2huaXF1ZXMsIGFuZCBmdXJ0 aGVyIGFzc3VyZSB0aGUgc2VydmljZS4gdGhpcyBpcyB0aGUga2V5IGlzc3VlIGZvciB0b2RheSdz IG9wZXJhdG9ycy4NCgpJIGRvIGJlbGlldmUgdGhpcyBpbnRlcmZhY2UgYW5kIGl0cyBtb2RlbCBh cmUgaW5kZWVkIGhlbHBmdWwgZm9yIG9wZXJhdG9ycyB0byBzaW1wbGlmeSBvcGVyYXRpb25zIGFu ZCBtYW5hZ2VtZW50LgpBbmQgSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zIG5lZWQgdG8gYmUg ZGlzY3Vzc2VkIGFuZCBhbGlnbmVkIHdpdGggeW91IGFuZCBleHBlcnRzIGluIGVtYWlsIHRocmVh ZC4KIAoxLldoaWxlIHJlZmVycmluZyB0byBhbm90aGVyIGRyYWZ0IGF0IHNhbWUgbWVldGluZyA8 PHNlcnZpY2UgbW9kZWwgZXhwbGFpbmVkPj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAzLnR4dCksCkkgYmVsaWV2ZSB0 aGUgYWJvdmUgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNlIHNob3VsZCBiZSBwb3NpdGlvbiBiZXR3 ZWVuIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiBhbmQgIG5ldHdvcmsgb3JjaGVzdHJhdGlvbihGaWd1 cmUgMykuClRoYXQgbWVhbiBpdKGvcyBhIGludGVybmFsIGludGVyZmFjZSBpbiBvbmUgb3BlcmF0 b3IgYW5kIGl0IGFjdHMgbm90IG9ubHkgdG8gaW1wbGVtZW50IHRoZSBjdXN0b21lciBmYWNpbmcg bW9kZWwgKGkuZS4gTDNTTSksYnV0IGFsc28gdG8gbWFpbnRhaW4sIG1vbml0b3IgYW5kIGRpYWdu b3NlIHRoZQogZW5kIHRvIGVuZCBQRS1iYXNlZCBWUE4gc2VydmljZXMgY3Jvc3NpbmcgbXVsdGlw bGUgdGVjaG5vbG9naWVzIGRlcGxveWVkIG5ldHdvcmsuCklzIGl0IHJpZ2h0PyBhbmQgc2hvdWxk IHRoaXMgaW50ZXJmYWNlIG5lZWQgdG8gc3VwcG9ydCBWUE4gc2VydmljZSB3aGljaCBtYXliZSBj cm9zcyBtdWx0aXBsZSBvcGVyYXRvcnM/Cj09PiBnb29kIHBvaW50LCB0aGUgZnV0dXJlIGluIHRo ZSBsaW5rIGlzIHF1aXRlIGhlbHBmdWwsIHRoaXMgc2hvdWxkIGJlIHVwZGF0ZWQgaW4gbmV4dCBy ZXZpc2lvbi4NCj09PiBmb3IgeW91ciBxdWVzdGlvbnMgYWJvdXQgbXVsdGlwbGUgb3BlcmF0b3Jz LCB0aGlzIGlzIGV4YWN0bHkgdGhlIGlzc3VlIHJhaXNlZCBkdXJpbmcgdGhlIG1lZXRpbmcsIG9w ZXJhdG9yIGFyZSBpbnRlcmNvbm5lY3RlZCBlYWNoIG90aGVyIHRocm91Z2ggZmVkZXJhdGlvbiwg dGhlIGVuZCB0byBlbmQgc2VydmljZSBtYXkgZ28gYWNyb3NzIG11bHRpcGxlIG9wZXJhdG9ycycg YWNjZXNzIGFuZCBjb3JlIG5ldHdvcmsuIHRoYXQgaXMgdGhlIHJlYXNvbiB3aHkgd2UgZGVmaW5l IFZQTiBzZWdtZW50IHdpdGhpbiB0aGUgY29tcG9zZWQgVlBOLiB0aGlzIGhhc24ndCBiZWVuIGNv bnNpZGVyIGluIHRoZSBkb2N1bWVudCBiZWZvcmUsIGJ1dCB0aGUgZmxleGliaWxpdHkgb2YgY29t cG9zZWQgVlBOIGZyYW1ld29yayBzaG91bGQgYmUgaW5jbHVkZWQuIAoyLkFjdHVhbGx5IEmhr20g bmV3IGd1eSBpbiBJRVRGLCBzbyBJoa9tIG5vdCBzdXJlIGlmIHRoZXJlIGFyZSBleGlzdGluZyB3 b3JrcyBpbiBJRVRGIHdoaWNoIGNvdWxkIGluc3RydWN0IG9yIG1vZGVsaW5nIHRoZSBpbnRlcmZh Y2UvRTJFLXZpZXcgdG8gbWFuYWdlIGEgbXVsdGlwbGUgdGVjaG5vbG9naWVzCiBjb21wb3NlZCBu ZXR3b3JrLCB3aGljaCBJIGJlbGlldmUgdmVyeSBjb21tb24gaW4gb3BlcmF0b3Khr3MgZGVwbG95 bWVudCB3aGlsZSBzdGlsbCBuZWVkIHRvIHByb3ZpZGUgc2ltcGxlIEUyRSBzZXJ2aWNlIGV4cGVy aWVuY2UgdG8gdGhlaXIgY3VzdG9tZXJzLiBNYXliZSB3ZSBjYW4gaW1wcm92ZSBzb21ldGhpbmcg aGVyZS4gU28gaWYgZXhwZXJ0cyBoZXJlIGhhdmUgbW9yZSBiYWNrZ3JvdW5kLCBwbGVhc2UgaGVs cCBtZS4gVGhhbmtzLgogPT0+IGFsdGhvdWdoIGl0IGlzIGltcG9ydGFudCwgYnV0IEkgZGlkbid0 IHNlZSBhbnkgZTJlIGVmZm9ydCBvbiB0aGUgbmV0d29yayB5ZXQuIHRoZXJlIGlzIGEgcmVsYXRl ZCB3b3JrIGluIEwzU00gaW4gY3VzdG9tZXIgc2VydmljZSBsZXZlbCBhbmQgc29tZSBkZWRpY2F0 ZWQgVlBOIG1vZGVscyBpbiBCRVNTLiB0aGF0J3Mgd2h5IEkgcmFpc2UgdGhpcyB0b3BpYy4gZGVm aW5pdGVseSB3ZWxjb21lIGFueSBlZmZvcnQgdG8gam9pbiB0aGUgZm9sbG93aW5nIGRhdGEgbW9k ZWwgZGVzaWduIGlmIHlvdSByZWFsbHkgaGF2ZSBhIHN0cm9uZyBiYWNrZ3JvdW5kIG9uIGl0Lg0K CjMuQXMgSSB1bmRlcnN0YW5kIHRoaXMgaW50ZXJmYWNlL21vZGVsIHNob3VsZCBiZSBpbnRlcm5h bCBpbiBvcGVyYXRvcnMsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhlcmUgYW55IG90aGVyIG9wZXJh dG9ycyBhcmUgaW50ZXJlc3RlZCBpdCBhbmQgbmVlZCBhIElFVEYgUkZDPwogPT0+IEkgZGlkIGhl YXIgdHdvIGJpZyBvcGVyYXRvcnMgc2hvd2VkIHRoZSBpbnRlcmVzdCBpbiB0aGlzIHRvcGljLCBo b3BlIHRoZXkgY2FuIGpvaW4gYXMgd2VsbCBpbiBvdXIgbmV4dCByZXZpc2lvbi4gdGhpcyBtYXkg cmVsYXRlZCB0byBuZXR3b3JrIG9yY2hlc3RyYXRvciwgT1NTL0JTUyBhbmQgZXZlbiBhbmFseXRp Y3Mgc3lzdGVtIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIGEgc3RhbmRhcmQgbW9kZWwgd2lsbCBk ZWZpbml0ZWx5ICBoZXAgdGhlIGRpdmVyc2l0eSBpbiBvbmUgb3BlcmF0b3IncyBwcm9kdWN0aW9u IGVudmlyb25tZW50Lg0KQmVzdCByZWdhcmRzLA0KREVORyBIdWkKVGhhbmtzLgogClJlZ2FyZHMs ClJpY2hhcmQgQ2hlbgogCgoKCg0KCruqzqq8vMr109DP3rmry74gSHVhd2VpIFRlY2hub2xvZ2ll cyBDby4sIEx0ZC4NCgq12Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgKINPKseCjujUxODEy OQ0KCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQoKQmFudGlhbiwgTG9uZ2dhbmcgRGlz dHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCgpodHRwOi8vd3d3Lmh1YXdlaS5jb20g CgoKCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D 5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQoK1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508Oj qLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCgq1 xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Ki yb6z/bG+08q8/qOhDQoKVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gKDQoKaXMgaW50ZW5kZWQg b25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJv dmUuIEFueSB1c2Ugb2YgdGhlCg0KCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55 IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwKDQoK ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90 aGVyIHRoYW4gdGhlIGludGVuZGVkIA0KCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5 b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGJ5Cg0KCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhCiAKIAkJIAkg ICAJCSAg --_2d956c6d-7c8e-4a38-904f-dd9a28e761ba_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+PGJyPkhpIFJpY2hhcmQsPGRpdj48YnI+PC9kaXY+PGRp dj5UaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMsIEkgcmVjYWxsZWQgdGhhdCBvdGhlciB0 d28gb3BlcmF0b3JzIGR1cmluZyBsYXN0IHRpbWUgZjJmIG1lZXRpbmcgaGFkIG1hZGUgc29tZSBj b21tZW50cyBhYm91dCBmZWRlcmF0aW9uIGlzc3VlLCBob3BlIHRoZXkgY2FuIGVsYWJvcmF0ZSBt b3JlIGRldGFpbCBjb21tZW50cyBoZXJlIGFzIHdlbGwsIGlubGluZSB3aXRoID09Jmd0Ozxicj48 ZGl2PjxociBpZD0ic3RvcFNwZWxsaW5nIj5Gcm9tOiBjaGVucnVpQGh1YXdlaS5jb208YnI+VG86 IG9wc2F3Z0BpZXRmLm9yZzsgZGVuZ2h1aTAyQGhvdG1haWwuY29tPGJyPkNDOiBvcHNhd2ctY2hh aXJzQGlldGYub3JnPGJyPlN1YmplY3Q6IFJlOiBbT1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1j b21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dDxicj5EYXRlOiBTdW4sIDkgT2N0IDIw MTYgMDM6MzU6NDYgKzAwMDA8YnI+PGJyPgoKCgo8c3R5bGU+PCEtLQouRXh0ZXJuYWxDbGFzcyBw LmVjeE1zb05vcm1hbCwgLkV4dGVybmFsQ2xhc3MgbGkuZWN4TXNvTm9ybWFsLCAuRXh0ZXJuYWxD bGFzcyBkaXYuZWN4TXNvTm9ybWFsIHsKdGV4dC1hbGlnbjpqdXN0aWZ5Owp0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoOwpmb250LXNpemU6MTAuNXB0Owpmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOwp9CgouRXh0ZXJuYWxDbGFzcyBhOmxpbmssIC5FeHRlcm5hbENsYXNzIHNw YW4uZWN4TXNvSHlwZXJsaW5rIHsKY29sb3I6Ymx1ZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsKfQoKLkV4dGVybmFsQ2xhc3Mgc3Bhbi5lY3hNc29IeXBlcmxpbmtGb2xsb3dlZCB7CmNvbG9y OnB1cnBsZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKLkV4dGVybmFsQ2xhc3Mgc3Bh bi5lY3hFbWFpbFN0eWxlMTcgewpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwpj b2xvcjp3aW5kb3d0ZXh0Owp9CgouRXh0ZXJuYWxDbGFzcyAuZWN4TXNvQ2hwRGVmYXVsdCB7Cn0K Ci5FeHRlcm5hbENsYXNzIGRpdi5lY3hXb3JkU2VjdGlvbjEgewp9CgotLT48L3N0eWxlPgoKCjxk aXYgY2xhc3M9ImVjeFdvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RDsiPkhpIEh1aSBhbmQgYWxsLDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNz PSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPldoZW4gSSB3ZW50IHRocm91Z2gg dGhlIGRvY3VtZW50cyBvZiBJRVRGIzk2LEkgbm90aWNlZCB0aGF0IHRoaXMgZHJhZnQgaGFzIHJh aXNlZCBhIGludGVyZXN0aW5nIHJlcXVpcmVtZW50IGluIENoaW5hIE1vYmlsZSBvZiBFMkUgZGVw bG95bWVudCBpbnRlcmZhY2UgdG8gYSBtdWx0aXBsZSBWUE5zCiBjb21wb3NlZCBpbmZyYXN0cnVj dHVyZSwgc3VjaCBhcyBMMitMMyBuZXR3b3JrLiBTbyB0aGUgaW50ZXJmYWNlIGNvdWxkIG1ha2Ug dGhlIHNlcnZpY2UgZnVsZmlsbG1lbnQgYW5kIG1hbmFnZW1lbnQgbW9yZSBlYXN5Ljwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPklzIG15IHVu ZGVyc3RhbmRpbmcgcmlnaHQ/PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEOyI+Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iZWN4TXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij49PSZndDsgWWVzLCBjdXJyZW50IGV4aXN0aW5nIEwzU00g YXJlIG1vc3RseSB0YWxraW5nIGFib3V0IGN1c3RvbWVyIGZhY2luZyBzZXJ2aWNlIG1vZGVsLjwv c3Bhbj48L3A+PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+dGhp cyByZXF1aXJlbWVudCBleHBlY3RzIHRvIGhlbHAgb3BlcmF0b3JzIHdpdGggbGFyZ2Ugc2NhbGUg dG8gbWFuZ2UgdGhlIHVuZGVybGF5IG5ldHdvcmsgd2l0aCBhIGdsb2JhbCB2aWV3LiAmbmJzcDso aGVyZSBjb3VsZCBiZSBhIG11bHRpcGxlIG9wZXJhdG9ycywgdGhhdCBpcyByZWxhdGVkIHRvIGZl ZGVyYXRpb24pIGFuIGVudGVycHJpc2UgY3VzdG9tZXIgbWF5IHNpbXBseSByZXF1ZXN0IGEgTDMg VlBOIHNlcnZpY2UsIGJ1dCBvcGVyYXRvciBoYXMgdG8gcHJvdmlzaW9uIGFuZCBtYW5nZSB0aGUg ZW5kIHRvIGVuZCB1bmRlcmxheSBuZXR3b3JrIGNvbnN0cnVjdGVkIHdpdGggbXVsdGlwbGUgQVNl cyBhbmQgdGVjaG5pcXVlcywgYW5kIGZ1cnRoZXIgYXNzdXJlIHRoZSBzZXJ2aWNlLiB0aGlzIGlz IHRoZSBrZXkgaXNzdWUgZm9yIHRvZGF5J3Mgb3BlcmF0b3JzLjwvc3Bhbj48L3A+PHAgY2xhc3M9 ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+PGJyPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPkkgZG8gYmVsaWV2ZSB0aGlz IGludGVyZmFjZSBhbmQgaXRzIG1vZGVsIGFyZSBpbmRlZWQgaGVscGZ1bCBmb3Igb3BlcmF0b3Jz IHRvIHNpbXBsaWZ5IG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQuPC9zcGFuPjwvcD4KPHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+QW5kIEkgc3RpbGwgaGF2ZSBz b21lIHF1ZXN0aW9ucyBuZWVkIHRvIGJlIGRpc2N1c3NlZCBhbmQgYWxpZ25lZCB3aXRoIHlvdSBh bmQgZXhwZXJ0cyBpbiBlbWFpbCB0aHJlYWQuPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+Jm5ic3A7PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVj eE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+MS5XaGlsZSByZWZlcnJpbmcgdG8gYW5v dGhlciBkcmFmdCBhdCBzYW1lIG1lZXRpbmcgJmx0OyZsdDtzZXJ2aWNlIG1vZGVsIGV4cGxhaW5l ZCZndDsmZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gKDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNl LW1vZGVsLWV4cGxhaW5lZC0wMy50eHQpLDwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPkkgYmVsaWV2ZSB0aGUgYWJvdmUgRTJFIGRlcGxveW1l bnQgaW50ZXJmYWNlIHNob3VsZCBiZSBwb3NpdGlvbiBiZXR3ZWVuIHNlcnZpY2Ugb3JjaGVzdHJh dGlvbiBhbmQgJm5ic3A7bmV0d29yayBvcmNoZXN0cmF0aW9uKEZpZ3VyZSAzKS48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij5UaGF0IG1lYW4g aXShr3MgYSBpbnRlcm5hbCBpbnRlcmZhY2UgaW4gb25lIG9wZXJhdG9yIGFuZCBpdCBhY3RzIG5v dCBvbmx5IHRvIGltcGxlbWVudCB0aGUgY3VzdG9tZXIgZmFjaW5nIG1vZGVsIChpLmUuIEwzU00p LGJ1dCBhbHNvIHRvIG1haW50YWluLCBtb25pdG9yIGFuZCBkaWFnbm9zZSB0aGUKIGVuZCB0byBl bmQgUEUtYmFzZWQgVlBOIHNlcnZpY2VzIGNyb3NzaW5nIG11bHRpcGxlIHRlY2hub2xvZ2llcyBk ZXBsb3llZCBuZXR3b3JrLjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RDsiPklzIGl0IHJpZ2h0PyBhbmQgc2hvdWxkIHRoaXMgaW50ZXJmYWNlIG5l ZWQgdG8gc3VwcG9ydCBWUE4gc2VydmljZSB3aGljaCBtYXliZSBjcm9zcyBtdWx0aXBsZSBvcGVy YXRvcnM/PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEOyI+PT0mZ3Q7IGdvb2QgcG9pbnQsIHRoZSBmdXR1cmUgaW4gdGhlIGxpbmsgaXMgcXVpdGUg aGVscGZ1bCwgdGhpcyBzaG91bGQgYmUgdXBkYXRlZCBpbiBuZXh0IHJldmlzaW9uLjwvc3Bhbj48 L3A+PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+PGJyPjwvc3Bh bj48L3A+PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+PT0mZ3Q7 IGZvciB5b3VyIHF1ZXN0aW9ucyBhYm91dCBtdWx0aXBsZSBvcGVyYXRvcnMsIHRoaXMgaXMgZXhh Y3RseSB0aGUgaXNzdWUgcmFpc2VkIGR1cmluZyB0aGUgbWVldGluZywgb3BlcmF0b3IgYXJlIGlu dGVyY29ubmVjdGVkIGVhY2ggb3RoZXIgdGhyb3VnaCBmZWRlcmF0aW9uLCB0aGUgZW5kIHRvIGVu ZCBzZXJ2aWNlIG1heSBnbyBhY3Jvc3MgbXVsdGlwbGUgb3BlcmF0b3JzJyBhY2Nlc3MgYW5kIGNv cmUgbmV0d29yay4gdGhhdCBpcyB0aGUgcmVhc29uIHdoeSB3ZSBkZWZpbmUgVlBOIHNlZ21lbnQg d2l0aGluIHRoZSBjb21wb3NlZCBWUE4uIHRoaXMgaGFzbid0IGJlZW4gY29uc2lkZXIgaW4gdGhl IGRvY3VtZW50IGJlZm9yZSwgYnV0IHRoZSBmbGV4aWJpbGl0eSBvZiBjb21wb3NlZCBWUE4gZnJh bWV3b3JrIHNob3VsZCBiZSBpbmNsdWRlZC48L3NwYW4+PC9wPjxwIGNsYXNzPSJlY3hNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPjIuQWN0dWFsbHkgSaGvbSBuZXcgZ3V5IGlu IElFVEYsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhlcmUgYXJlIGV4aXN0aW5nIHdvcmtzIGluIElF VEYgd2hpY2ggY291bGQgaW5zdHJ1Y3Qgb3IgbW9kZWxpbmcgdGhlIGludGVyZmFjZS9FMkUtdmll dyB0byBtYW5hZ2UgYSBtdWx0aXBsZSB0ZWNobm9sb2dpZXMKIGNvbXBvc2VkIG5ldHdvcmssIHdo aWNoIEkgYmVsaWV2ZSB2ZXJ5IGNvbW1vbiBpbiBvcGVyYXRvcqGvcyBkZXBsb3ltZW50IHdoaWxl IHN0aWxsIG5lZWQgdG8gcHJvdmlkZSBzaW1wbGUgRTJFIHNlcnZpY2UgZXhwZXJpZW5jZSB0byB0 aGVpciBjdXN0b21lcnMuIE1heWJlIHdlIGNhbiBpbXByb3ZlIHNvbWV0aGluZyBoZXJlLiBTbyBp ZiBleHBlcnRzIGhlcmUgaGF2ZSBtb3JlIGJhY2tncm91bmQsIHBsZWFzZSBoZWxwIG1lLiBUaGFu a3MuPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE OyI+Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7Ij49PSZndDsgYWx0aG91Z2ggaXQgaXMgaW1wb3J0YW50LCBidXQgSSBkaWRuJ3Qgc2Vl IGFueSBlMmUgZWZmb3J0IG9uIHRoZSBuZXR3b3JrIHlldC4gdGhlcmUgaXMgYSByZWxhdGVkIHdv cmsgaW4gTDNTTSBpbiBjdXN0b21lciBzZXJ2aWNlIGxldmVsIGFuZCBzb21lIGRlZGljYXRlZCBW UE4gbW9kZWxzIGluIEJFU1MuIHRoYXQncyB3aHkgSSByYWlzZSB0aGlzIHRvcGljLiBkZWZpbml0 ZWx5IHdlbGNvbWUgYW55IGVmZm9ydCB0byBqb2luIHRoZSBmb2xsb3dpbmcgZGF0YSBtb2RlbCBk ZXNpZ24gaWYgeW91IHJlYWxseSBoYXZlIGEgc3Ryb25nIGJhY2tncm91bmQgb24gaXQuPC9zcGFu PjwvcD48cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij48YnI+PC9z cGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+My5B cyBJIHVuZGVyc3RhbmQgdGhpcyBpbnRlcmZhY2UvbW9kZWwgc2hvdWxkIGJlIGludGVybmFsIGlu IG9wZXJhdG9ycywgc28gSaGvbSBub3Qgc3VyZSBpZiB0aGVyZSBhbnkgb3RoZXIgb3BlcmF0b3Jz IGFyZSBpbnRlcmVzdGVkIGl0IGFuZCBuZWVkIGEgSUVURiBSRkM/PC9zcGFuPjwvcD4KPHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+Jm5ic3A7PC9zcGFuPjwvcD48 cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij49PSZndDsgSSBkaWQg aGVhciB0d28gYmlnIG9wZXJhdG9ycyBzaG93ZWQgdGhlIGludGVyZXN0IGluIHRoaXMgdG9waWMs IGhvcGUgdGhleSBjYW4gam9pbiBhcyB3ZWxsIGluIG91ciBuZXh0IHJldmlzaW9uLiB0aGlzIG1h eSByZWxhdGVkIHRvIG5ldHdvcmsgb3JjaGVzdHJhdG9yLCBPU1MvQlNTIGFuZCBldmVuIGFuYWx5 dGljcyBzeXN0ZW0gZnJvbSBkaWZmZXJlbnQgdmVuZG9ycy4gYSBzdGFuZGFyZCBtb2RlbCB3aWxs IGRlZmluaXRlbHkgJm5ic3A7aGVwIHRoZSBkaXZlcnNpdHkgaW4gb25lIG9wZXJhdG9yJ3MgcHJv ZHVjdGlvbiBlbnZpcm9ubWVudC48L3NwYW4+PC9wPjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RDsiPjxicj48L3NwYW4+PC9wPjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RDsiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PC9wPjxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPjxicj48L3NwYW4+PC9wPjxwIGNsYXNz PSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPkRFTkcgSHVpPC9zcGFuPjwvcD4K PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+VGhhbmtzLjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPiZuYnNw Ozwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsi PlJlZ2FyZHMsPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEOyI+UmljaGFyZCBDaGVuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu PjwvcD4KPGRpdiBjbGFzcz0iZWN4TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXI7Ij48c3BhbiBsYW5nPSJFTi1VUyI+CjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+Cjwvc3Bhbj48L2Rpdj4KPHAgY2xhc3M9ImVjeE1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OruqzsTPuLraO2NvbG9yOmJsYWNrOyI+u6rOqry8yvXT0M/euavL vjxzcGFuIGxhbmc9IkVOLVVTIj4gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC48YnI+Cjwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6u6rO xM+4uto7Y29sb3I6YmxhY2s7Ij612Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgKINPKseCj ujxzcGFuIGxhbmc9IkVOLVVTIj41MTgxMjk8YnI+Ckh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBM dGQuPGJyPgpCYW50aWFuLCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5D aGluYTxicj4KaHR0cDovL3d3dy5odWF3ZWkuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+IDwvc3Bhbj48L3A+CjxkaXYgY2xhc3M9ImVjeE1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyOyI+PHNwYW4gbGFuZz0iRU4tVVMiPgo8aHIgc2l6 ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPgo8L3NwYW4+PC9kaXY+CjxwIGNsYXNz PSJlY3hNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 u6rOxM+4uto7Y29sb3I6Z3JheTsiPrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXP oqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4KPC9zcGFuPta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e 09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQPHNwYW4gbGFuZz0iRU4t VVMiPjxicj4KPC9zcGFuPrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C7 8tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6E8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPgo8L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Z3Jh eTsiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwg aW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoCjxicj4KaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1 c2Ugb2YgdGhlCjxicj4KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChp bmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbAo8YnI+CmRpc2Ns b3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCA8YnI+CnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5 Cjxicj4KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPgo8L2Rpdj48L2Rpdj48L2Rpdj4gCQkgCSAg IAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_2d956c6d-7c8e-4a38-904f-dd9a28e761ba_-- From nobody Mon Oct 10 19:27:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D832129620; Mon, 10 Oct 2016 19:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 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=-2.996, 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 oli2GmW-msvy; Mon, 10 Oct 2016 19:27:25 -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 1D0BF1297BE; Mon, 10 Oct 2016 19:27:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXT13107; Tue, 11 Oct 2016 02:27:22 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 11 Oct 2016 03:27:20 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.186]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Tue, 11 Oct 2016 10:27:15 +0800 From: "Chenrui (Richard)" To: Hui Deng , "opsawg@ietf.org" Thread-Topic: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSIwkiYJG+K9TIm0S25A/jquZ476Cig+4g Date: Tue, 11 Oct 2016 02:27:14 +0000 Message-ID: <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.55.144] Content-Type: multipart/alternative; boundary="_000_0D5441A3DF1544449089458210966F29788F021FSZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57FC4E0A.00AB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b8896c36031f7e90b1d4aa14c499c68a Archived-At: Cc: "opsawg-chairs@ietf.org" Subject: [OPSAWG] =?gb2312?b?tPC4tDogIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2Vk?= =?gb2312?b?LXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 02:27:27 -0000 --_000_0D5441A3DF1544449089458210966F29788F021FSZXEMA501MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSHVpLA0KDQpUaGFua3MgZm9yIHRoZXNlIGNsYXJpZmljYXRpb25zLiBNYXliZSB3ZSBjYW4g dGFsayBhYm91dCBpdCBtb3JlIGluIG5leHQgbWVldGluZyBhbmQgd2UgY2FuIHByb3ZpZGUgYSBp bml0aWFsIHNvbHV0aW9uIGFyb3VuZCB0aGVzZSBpc3N1ZXMuDQoNCkJUVywgaWYgd2UgdGFsa2lu ZyBhYm91dCBmZWRlcmF0aW9uIHVzZWQgaW4gbXVsdGlwbGUgb3BlcmF0b3JzIHNjZW5hcmlvcywg SSBzdWdnZXN0IHRoYXQgdGhlcmUgc2hvdWxkIGJlIGVhc3Qtd2VzdCBpbnRlcmZhY2UgYmV0d2Vl biBwZWVyIG9yY2hlc3RyYXRpb24gc3lzdGVtIGluIHRoZXNlIG9wZXJhdG9ycy4gVGhhdCBlYXNl LXdlc3QgaW50ZXJmYWNlIGlzIGRpZmZlcmVudCB3aXRoIGludGVybmFsIEUyRSBzZXJ2aWNlIGFj dGl2YXRpb24gaW50ZXJmYWNlIGZvciBzb21lIHNwZWNpYWwgcmVxdWlyZW1lbnQgYmV0d2VlbiBv cGVyYXRvcnMsIHN1Y2ggYXMgc2VjdXJpdHksIHJlc291cmNlIHZpc3VhbGl6YXRpb24sZXRjLg0K DQpUaGFua3MsDQpSaWNoYXJkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Cruqzqq8vMr109DP3rmry74gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCrXY1rejusnu 29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHgo7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMg Q28uLCBMdGQuDQpCYW50aWFuLCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAu Ui5DaGluYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvN uPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3K udPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQ DQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7I y7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4g Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQg b25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJv dmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3 YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIg dGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVj ZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpw aG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQq3orz+yMs6IEh1aSBE ZW5nIFttYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTbE6jEw1MIx MMjVIDIzOjE1DQrK1bz+yMs6IENoZW5ydWkgKFJpY2hhcmQpOyBvcHNhd2dAaWV0Zi5vcmcNCrOt y806IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbT1BTQVdHXSBkcmFmdC1kZW5n LW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KDQoNCkhpIFJpY2hh cmQsDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciBjb21tZW50cywgSSByZWNhbGxlZCB0aGF0IG90 aGVyIHR3byBvcGVyYXRvcnMgZHVyaW5nIGxhc3QgdGltZSBmMmYgbWVldGluZyBoYWQgbWFkZSBz b21lIGNvbW1lbnRzIGFib3V0IGZlZGVyYXRpb24gaXNzdWUsIGhvcGUgdGhleSBjYW4gZWxhYm9y YXRlIG1vcmUgZGV0YWlsIGNvbW1lbnRzIGhlcmUgYXMgd2VsbCwgaW5saW5lIHdpdGggPT0+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogY2hlbnJ1aUBodWF3ZWkuY29t PG1haWx0bzpjaGVucnVpQGh1YXdlaS5jb20+DQpUbzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpv cHNhd2dAaWV0Zi5vcmc+OyBkZW5naHVpMDJAaG90bWFpbC5jb208bWFpbHRvOmRlbmdodWkwMkBo b3RtYWlsLmNvbT4NCkNDOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hh aXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNv bXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0DQpEYXRlOiBTdW4sIDkgT2N0IDIwMTYg MDM6MzU6NDYgKzAwMDANCkhpIEh1aSBhbmQgYWxsLA0KDQpXaGVuIEkgd2VudCB0aHJvdWdoIHRo ZSBkb2N1bWVudHMgb2YgSUVURiM5NixJIG5vdGljZWQgdGhhdCB0aGlzIGRyYWZ0IGhhcyByYWlz ZWQgYSBpbnRlcmVzdGluZyByZXF1aXJlbWVudCBpbiBDaGluYSBNb2JpbGUgb2YgRTJFIGRlcGxv eW1lbnQgaW50ZXJmYWNlIHRvIGEgbXVsdGlwbGUgVlBOcyBjb21wb3NlZCBpbmZyYXN0cnVjdHVy ZSwgc3VjaCBhcyBMMitMMyBuZXR3b3JrLiBTbyB0aGUgaW50ZXJmYWNlIGNvdWxkIG1ha2UgdGhl IHNlcnZpY2UgZnVsZmlsbG1lbnQgYW5kIG1hbmFnZW1lbnQgbW9yZSBlYXN5Lg0KSXMgbXkgdW5k ZXJzdGFuZGluZyByaWdodD8NCg0KPT0+IFllcywgY3VycmVudCBleGlzdGluZyBMM1NNIGFyZSBt b3N0bHkgdGFsa2luZyBhYm91dCBjdXN0b21lciBmYWNpbmcgc2VydmljZSBtb2RlbC4NCnRoaXMg cmVxdWlyZW1lbnQgZXhwZWN0cyB0byBoZWxwIG9wZXJhdG9ycyB3aXRoIGxhcmdlIHNjYWxlIHRv IG1hbmdlIHRoZSB1bmRlcmxheSBuZXR3b3JrIHdpdGggYSBnbG9iYWwgdmlldy4gIChoZXJlIGNv dWxkIGJlIGEgbXVsdGlwbGUgb3BlcmF0b3JzLCB0aGF0IGlzIHJlbGF0ZWQgdG8gZmVkZXJhdGlv bikgYW4gZW50ZXJwcmlzZSBjdXN0b21lciBtYXkgc2ltcGx5IHJlcXVlc3QgYSBMMyBWUE4gc2Vy dmljZSwgYnV0IG9wZXJhdG9yIGhhcyB0byBwcm92aXNpb24gYW5kIG1hbmdlIHRoZSBlbmQgdG8g ZW5kIHVuZGVybGF5IG5ldHdvcmsgY29uc3RydWN0ZWQgd2l0aCBtdWx0aXBsZSBBU2VzIGFuZCB0 ZWNobmlxdWVzLCBhbmQgZnVydGhlciBhc3N1cmUgdGhlIHNlcnZpY2UuIHRoaXMgaXMgdGhlIGtl eSBpc3N1ZSBmb3IgdG9kYXkncyBvcGVyYXRvcnMuDQoNCkkgZG8gYmVsaWV2ZSB0aGlzIGludGVy ZmFjZSBhbmQgaXRzIG1vZGVsIGFyZSBpbmRlZWQgaGVscGZ1bCBmb3Igb3BlcmF0b3JzIHRvIHNp bXBsaWZ5IG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQuDQpBbmQgSSBzdGlsbCBoYXZlIHNvbWUg cXVlc3Rpb25zIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGFuZCBhbGlnbmVkIHdpdGggeW91IGFuZCBl eHBlcnRzIGluIGVtYWlsIHRocmVhZC4NCg0KMS5XaGlsZSByZWZlcnJpbmcgdG8gYW5vdGhlciBk cmFmdCBhdCBzYW1lIG1lZXRpbmcgPDxzZXJ2aWNlIG1vZGVsIGV4cGxhaW5lZD4+IChodHRwczov L3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5l ZC0wMy50eHQpLA0KSSBiZWxpZXZlIHRoZSBhYm92ZSBFMkUgZGVwbG95bWVudCBpbnRlcmZhY2Ug c2hvdWxkIGJlIHBvc2l0aW9uIGJldHdlZW4gc2VydmljZSBvcmNoZXN0cmF0aW9uIGFuZCAgbmV0 d29yayBvcmNoZXN0cmF0aW9uKEZpZ3VyZSAzKS4NClRoYXQgbWVhbiBpdKGvcyBhIGludGVybmFs IGludGVyZmFjZSBpbiBvbmUgb3BlcmF0b3IgYW5kIGl0IGFjdHMgbm90IG9ubHkgdG8gaW1wbGVt ZW50IHRoZSBjdXN0b21lciBmYWNpbmcgbW9kZWwgKGkuZS4gTDNTTSksYnV0IGFsc28gdG8gbWFp bnRhaW4sIG1vbml0b3IgYW5kIGRpYWdub3NlIHRoZSBlbmQgdG8gZW5kIFBFLWJhc2VkIFZQTiBz ZXJ2aWNlcyBjcm9zc2luZyBtdWx0aXBsZSB0ZWNobm9sb2dpZXMgZGVwbG95ZWQgbmV0d29yay4N CklzIGl0IHJpZ2h0PyBhbmQgc2hvdWxkIHRoaXMgaW50ZXJmYWNlIG5lZWQgdG8gc3VwcG9ydCBW UE4gc2VydmljZSB3aGljaCBtYXliZSBjcm9zcyBtdWx0aXBsZSBvcGVyYXRvcnM/DQo9PT4gZ29v ZCBwb2ludCwgdGhlIGZ1dHVyZSBpbiB0aGUgbGluayBpcyBxdWl0ZSBoZWxwZnVsLCB0aGlzIHNo b3VsZCBiZSB1cGRhdGVkIGluIG5leHQgcmV2aXNpb24uDQoNCj09PiBmb3IgeW91ciBxdWVzdGlv bnMgYWJvdXQgbXVsdGlwbGUgb3BlcmF0b3JzLCB0aGlzIGlzIGV4YWN0bHkgdGhlIGlzc3VlIHJh aXNlZCBkdXJpbmcgdGhlIG1lZXRpbmcsIG9wZXJhdG9yIGFyZSBpbnRlcmNvbm5lY3RlZCBlYWNo IG90aGVyIHRocm91Z2ggZmVkZXJhdGlvbiwgdGhlIGVuZCB0byBlbmQgc2VydmljZSBtYXkgZ28g YWNyb3NzIG11bHRpcGxlIG9wZXJhdG9ycycgYWNjZXNzIGFuZCBjb3JlIG5ldHdvcmsuIHRoYXQg aXMgdGhlIHJlYXNvbiB3aHkgd2UgZGVmaW5lIFZQTiBzZWdtZW50IHdpdGhpbiB0aGUgY29tcG9z ZWQgVlBOLiB0aGlzIGhhc24ndCBiZWVuIGNvbnNpZGVyIGluIHRoZSBkb2N1bWVudCBiZWZvcmUs IGJ1dCB0aGUgZmxleGliaWxpdHkgb2YgY29tcG9zZWQgVlBOIGZyYW1ld29yayBzaG91bGQgYmUg aW5jbHVkZWQuDQoNCjIuQWN0dWFsbHkgSaGvbSBuZXcgZ3V5IGluIElFVEYsIHNvIEmhr20gbm90 IHN1cmUgaWYgdGhlcmUgYXJlIGV4aXN0aW5nIHdvcmtzIGluIElFVEYgd2hpY2ggY291bGQgaW5z dHJ1Y3Qgb3IgbW9kZWxpbmcgdGhlIGludGVyZmFjZS9FMkUtdmlldyB0byBtYW5hZ2UgYSBtdWx0 aXBsZSB0ZWNobm9sb2dpZXMgY29tcG9zZWQgbmV0d29yaywgd2hpY2ggSSBiZWxpZXZlIHZlcnkg Y29tbW9uIGluIG9wZXJhdG9yoa9zIGRlcGxveW1lbnQgd2hpbGUgc3RpbGwgbmVlZCB0byBwcm92 aWRlIHNpbXBsZSBFMkUgc2VydmljZSBleHBlcmllbmNlIHRvIHRoZWlyIGN1c3RvbWVycy4gTWF5 YmUgd2UgY2FuIGltcHJvdmUgc29tZXRoaW5nIGhlcmUuIFNvIGlmIGV4cGVydHMgaGVyZSBoYXZl IG1vcmUgYmFja2dyb3VuZCwgcGxlYXNlIGhlbHAgbWUuIFRoYW5rcy4NCg0KPT0+IGFsdGhvdWdo IGl0IGlzIGltcG9ydGFudCwgYnV0IEkgZGlkbid0IHNlZSBhbnkgZTJlIGVmZm9ydCBvbiB0aGUg bmV0d29yayB5ZXQuIHRoZXJlIGlzIGEgcmVsYXRlZCB3b3JrIGluIEwzU00gaW4gY3VzdG9tZXIg c2VydmljZSBsZXZlbCBhbmQgc29tZSBkZWRpY2F0ZWQgVlBOIG1vZGVscyBpbiBCRVNTLiB0aGF0 J3Mgd2h5IEkgcmFpc2UgdGhpcyB0b3BpYy4gZGVmaW5pdGVseSB3ZWxjb21lIGFueSBlZmZvcnQg dG8gam9pbiB0aGUgZm9sbG93aW5nIGRhdGEgbW9kZWwgZGVzaWduIGlmIHlvdSByZWFsbHkgaGF2 ZSBhIHN0cm9uZyBiYWNrZ3JvdW5kIG9uIGl0Lg0KDQozLkFzIEkgdW5kZXJzdGFuZCB0aGlzIGlu dGVyZmFjZS9tb2RlbCBzaG91bGQgYmUgaW50ZXJuYWwgaW4gb3BlcmF0b3JzLCBzbyBJoa9tIG5v dCBzdXJlIGlmIHRoZXJlIGFueSBvdGhlciBvcGVyYXRvcnMgYXJlIGludGVyZXN0ZWQgaXQgYW5k IG5lZWQgYSBJRVRGIFJGQz8NCg0KPT0+IEkgZGlkIGhlYXIgdHdvIGJpZyBvcGVyYXRvcnMgc2hv d2VkIHRoZSBpbnRlcmVzdCBpbiB0aGlzIHRvcGljLCBob3BlIHRoZXkgY2FuIGpvaW4gYXMgd2Vs bCBpbiBvdXIgbmV4dCByZXZpc2lvbi4gdGhpcyBtYXkgcmVsYXRlZCB0byBuZXR3b3JrIG9yY2hl c3RyYXRvciwgT1NTL0JTUyBhbmQgZXZlbiBhbmFseXRpY3Mgc3lzdGVtIGZyb20gZGlmZmVyZW50 IHZlbmRvcnMuIGEgc3RhbmRhcmQgbW9kZWwgd2lsbCBkZWZpbml0ZWx5ICBoZXAgdGhlIGRpdmVy c2l0eSBpbiBvbmUgb3BlcmF0b3IncyBwcm9kdWN0aW9uIGVudmlyb25tZW50Lg0KDQpCZXN0IHJl Z2FyZHMsDQoNCkRFTkcgSHVpDQpUaGFua3MuDQoNClJlZ2FyZHMsDQpSaWNoYXJkIENoZW4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXY INPKseCjujUxODEyOQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4sIExv bmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1 YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28 /rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjL u/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+7 8rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHL sb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMg ZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9y IGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90 IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwg b3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVj aXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg== --_000_0D5441A3DF1544449089458210966F29788F021FSZXEMA501MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hui,

 = ;

Thanks for= these clarifications. Maybe we can talk about it more in next meeting and = we can provide a initial solution around these issues.

 = ;

BTW, if we= talking about federation used in multiple operators scenarios, I suggest tha= t there should be east-west interface between peer orchestration system in = these operators. That ease-west interface is different with internal E2E service activation interface for some special requiremen= t between operators, such as security, resource visualization,etc.

 

Thanks,

Richard

 = ;


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8= =DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 = ;

=B7=A2=BC=FE=C8= =CB: Hui Deng [mailto:denghui02@hotmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C210=C8=D5 = 23:15
=CA=D5=BC=FE=C8=CB: Chenrui (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 


Hi Richard,

 

Thanks a lot for your comments, I recalle= d that other two operators during last time f2f meeting had made some comme= nts about federation issue, hope they can elaborate more detail comments here as well, inline with =3D=3D>

From: chenrui@huawei.com
To: opsawg@ietf.org; denghui02@hotmail.com
CC: opsawg-chairs@ietf.org Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=
Date: Sun, 9 Oct 2016 03:35:46 +0000

Hi Hui and all,

 

When I went through the documents of IETF#96,I= noticed that this draft has raised a interesting requirement in China Mobi= le of E2E deployment interface to a multiple VPNs composed infrastructure, such as L2+L3 network. So the interface could= make the service fulfillment and management more easy.

Is my understanding right?

 

=3D=3D> Yes, current existing L3SM are most= ly talking about customer facing service model.

this requirement expects to help operators wit= h large scale to mange the underlay network with a global view.  (here= could be a multiple operators, that is related to federation) an enterprise customer may simply request a L3 VPN service, but operator h= as to provision and mange the end to end underlay network constructed with = multiple ASes and techniques, and further assure the service. this is the k= ey issue for today's operators.

 

I do believe this interface and its model are = indeed helpful for operators to simplify operations and management.<= span lang=3D"EN-US" style=3D"font-family:"Calibri","sans-ser= if"">

And I still have some questions need to be dis= cussed and aligned with you and experts in email thread.

 

1.While referring to another draft at same mee= ting <<service model explained>> (https://tools.ietf.org/id/draft-wu-opsawg-service-model-explain= ed-03.txt),

I believe the above E2E deployment interface s= hould be position between service orchestration and  network orchestra= tion(Figure 3).

That mean it=A1=AFs a internal interface in on= e operator and it acts not only to implement the customer facing model (i.e= . L3SM),but also to maintain, monitor and diagnose the end to end PE-based VPN services crossing multiple technologies deployed n= etwork.

Is it right? and should this interface need to= support VPN service which maybe cross multiple operators?

=3D=3D> good point, the future in the link = is quite helpful, this should be updated in next revision.

 

=3D=3D> for your questions about multiple o= perators, this is exactly the issue raised during the meeting, operator are= interconnected each other through federation, the end to end service may go across multiple operators' access and core network. = that is the reason why we define VPN segment within the composed VPN. this = hasn't been consider in the document before, but the flexibility of compose= d VPN framework should be included.

 

2.Actually I=A1=AFm new guy in IETF, so I=A1= =AFm not sure if there are existing works in IETF which could instruct or m= odeling the interface/E2E-view to manage a multiple technologies composed network, which I believe very common in operator=A1=AFs deploymen= t while still need to provide simple E2E service experience to their custom= ers. Maybe we can improve something here. So if experts here have more back= ground, please help me. Thanks.

 

=3D=3D> although it is important, but I did= n't see any e2e effort on the network yet. there is a related work in L3SM = in customer service level and some dedicated VPN models in BESS. that's why I raise this topic. definitely welcome any effort to j= oin the following data model design if you really have a strong background = on it.

 

3.As I understand this interface/model should = be internal in operators, so I=A1=AFm not sure if there any other operators= are interested it and need a IETF RFC?=

 

=3D=3D> I did hear two big operators showed= the interest in this topic, hope they can join as well in our next revisio= n. this may related to network orchestrator, OSS/BSS and even analytics system from different vendors. a standard model will defini= tely  hep the diversity in one operator's production environment.

 

Best regards,

 

DENG Hui

Thanks.

 

Regards,

Richard Chen

 


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF= =BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA= =AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6= =CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5= =C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_0D5441A3DF1544449089458210966F29788F021FSZXEMA501MBXchi_-- From nobody Tue Oct 11 07:02:56 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC4612954D for ; Tue, 11 Oct 2016 07:02:55 -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, 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 zBzlWmWiN36i for ; Tue, 11 Oct 2016 07:02:53 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FA12954B for ; Tue, 11 Oct 2016 07:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 630D31759; Tue, 11 Oct 2016 14:02:52 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqSTOUPsHKpm; Tue, 11 Oct 2016 14:02:52 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 4F74931F; Tue, 11 Oct 2016 14:02:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 11 Oct 2016 10:02:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <638AC1BA-02A7-4346-8DC0-B7E762DA334D@deployingradius.com> References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 14:02:56 -0000 Continuing with 4.4.3 While the order of hosts in this packet indicates a preference, but the client is not obliged to use that ordering. * the use of "obliged" is unusual here. Perhaps "the order used by the = client is implementation specific, and does not have to follow the order = sent by the server" If the status equals TAC_PLUS_AUTHEN_STATUS_RESTART, then the authentication sequence is restarted with a new START packet from the client. ... * nit: it may be good to say that the next session does not have to use = the current TCP connection * "restart" may also be ambiguous. Does the session ID change for the = next session? It may be good to say instead "If the status equals = TAC_PLUS_AUTHEN_STATUS_RESTART, then the client re-authenticates with a = new session, beginning with a new START packet" ... This REPLY packet indicates that the current authen_type value (as specified in the START packet) is not acceptable for this session, but that others may be. * Which others "may" be acceptable? And why "acceptable for this = session"? is the client free to re-try the same authentication type in = a different session? i.e. what does the client *do*? * perhaps say "the REPLY indicates a negative acknowledgement that the = current authen_type is not accepted by the server. The client SHOULD = start a new session with a different authen_type" If a client chooses not to accept the TAC_PLUS_AUTHEN_STATUS_RESTART packet, then it is TREATED as if the status was TAC_PLUS_AUTHEN_STATUS_FAIL. * why uppercase "TREATED" ? * why "chooses not to accept" ? again, prescriptive is better than = philosophical * Perhaps "If the client does not start a new session after receiving a = TAC_PLUS_AUTHEN_STATUS_RESTART, it MUST behave as if it received a = TAC_PLUS_AUTHEN_STATUS_FAIL." 5. Authorization ... The authorization REQUEST message contains a fixed set of fields that indicate how the user was authenticated or processed * nit: remove "or processed" * from a security point of view, it's unusual for a client to indicate = to a server how a user was authenticated. This allows the client to = claim authentication when none existed. ... This field matches the port field in the authentication section (Section 4) above * what is meant by "matches"? Perhaps "The definition of this field is = the same as in Section 4". Or does the field in the authorization = session have to contain the same data as the similar field from the = authentication session? * similar comments apply for other uses of "matches" It is not legal for an attribute name to contain either of the separators. It is legal for attribute values to contain the separators. * what are the legal characters for an attribute name? The previous = paragraph says US-ASCII. So is "($#@!" a legal attribute name? * a reference to Section 7 would be useful here. Optional arguments are ones that may be disregarded by either client or server. Mandatory arguments require that the receiving side understands the attribute and will act on it. If the client receives a mandatory argument that it cannot oblige or does not understand, it MUST consider the authorization to have failed. * "oblige" is an unusual word to use here. Perhaps "If the client = receives a mandatory argument it cannot implement, it MUST consider the = authorization to have failed" 5.2 The Authorization RESPONSE Packet Body ... server_msg, server_msg_len This is an US-ASCII string that may be presented to the user. The decision to present this message is client specific. * nit: perhaps "This field is a message from the server to the client. = The client MAY display it to the user" * saying "decision is client specific" is a long way of saying "the = client MAY do it", but doesn't always have to ... The attribute-value pair that describes the authorization to be performed. (see below),=20 * That's not clear to me. Perhaps "if present, the list of additional = authorizations permitted the user" If the status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the appropriate action is to deny the user action. * again, a bit more philosophical than prescriptive. Perhaps "If the = status equals TAC_PLUS_AUTHOR_STATUS_FAIL, then the requested action = MUST be denied" If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the arguments specified in the request are authorized and the arguments in the response are to be used IN ADDITION to those arguments. * uppercase "IN ADDITION" is unusual. Perhaps: If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_ADD, then the arguments specified in the request are authorized and the client MUST also enforce the authorization attribute-value pairs (if any) in the = response. * similar comments apply here: If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the arguments in the request are to be completely replaced by the arguments in the response. * perhaps If the status equals TAC_PLUS_AUTHOR_STATUS_PASS_REPL then the client MUST use the authorization attribute-value pairs (if any) in = the response, instead of any authorization attribute-value pairs from the request. ... If the intended action is to approve the authorization with no modifications, then the status is set to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt is set to 0. * should be prescriptive. Perhaps: Servers can signal to client that the authorization is approved with = no modifications by setting the status to TAC_PLUS_AUTHOR_STATUS_PASS_ADD and the arg_cnt is set to 0. ... A status of TAC_PLUS_AUTHOR_STATUS_ERROR indicates an error occurred on the server. * what does the client do then? Perhaps "the client MAY show an error = to the user (how???), and MUST treat the response as = TAC_PLUS_AUTHOR_STATUS_FAIL" * Also, the last sentence of the subsequent paragraph also talks about = ERROR, and seems misplaced. 6.1. The Account REQUEST Packet Body TACACS+ accounting is very similar to authorization. The packet format is also similar.=20 * nit: that seems redundant. All of the packets use a common format. ... There is a fixed portion and an extensible portion. The extensible portion uses all the same attribute-value pairs that authorization uses, and adds several more. * except that the authorization section didn't list any attribute-value = pairs. So it's hard to say that those (non-existent) pairs are re-used = here All other fields are defined in the authorization and authentication sections above and have the same semantics. * Can an accounting packet indicate an authen_type and authen_service? = If so, what does that mean? 6.2. The Accounting REPLY Packet Body The response to an accounting message is used to indicate that the accounting function on the server has completed. * what does that mean? Do servers always implement "functions"? As = background, RFC 2866 (RADIUS accounting) says: ... Upon receipt of an Accounting-Request, the server MUST transmit an Accounting-Response reply if it successfully records the accounting packet, and MUST NOT transmit any reply if it fails to record the accounting packet. ... * perhaps similar text could be used here. ... The server will reply with success only when the record has been committed to the required level of security, * what is a "required level of security"? Is that indicated in the = packet? Elsewhere? * my recommendation is just to delete that... ... relieving the burden on the client from ensuring any better form of accounting is required. * I find that statement awkward. Perhaps re-using / re-phrasing text = from RFC 2866 would be good here. 6.2. The Accounting REPLY Packet Body * there's more duplication definition of fields here. It may be useful = to just say "server_msg has the same meaning and behaviour as defined in = Section 4.2" ... The server MUST terminate the session after sending a REPLY. * this is the only reference to a session being terminated in the = document. What does it mean? Perhaps that the next REQUEST packet has = to have a different session ID? If so, it would be good to say that in = the REQUEST section. The TAC_PLUS_ACCT_FLAG_START flag indicates that this is a start accounting message. Start messages will only be sent once when a task is started. The TAC_PLUS_ACCT_FLAG_STOP indicates that this is a stop record and that the task has terminated. The TAC_PLUS_ACCT_FLAG_WATCHDOG flag means that this is an update record. Update records are sent at the client's discretion when the task is still running. * what's a "task" ? This is the first reference in the document to a = "task". Perhaps more explanation here as to the expected use-case The START and STOP flags are mutually exclusive. When the WATCHDOG flag is set along with the START flag, it indicates that the update record is a duplicate of the original START record.=20 * why would an update duplicate the original START record? This seems = redundant. ... If the START flag is not set, then this indicates a minimal record indicating only that task is still running. * nit: perhaps delete "a minimal record indicating only". * Some more questions... * does the client retry an accounting packet if it doesn't get a = response from the server? * how often do the updates get sent? Saying "implementation defined" is = OK, but some recommendations would be good. i.e. not more than 100x per = second, and not less than 1 day apart (as extreme examples) * I have similar questions about the TCP connection. What happens if a = client can't connect to a server? How often should it retry? Should it = treat "unable to connect" as "authentication / authorization fail"? = Should the user be forbidden *all* access if the client cannot connect = to the server? Should the user be given minimal access in order to be = able to diagnose server connection problems? 7. Attribute-Value Pairs It is recommended that hosts be specified as a numeric address so as to avoid any ambiguities. * Is this IPv6 safe? I suspect not... but it should be stated Absolute times are specified in seconds since the epoch, 12:00am Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is specified. * nit: perhaps "a decimal number representing seconds since..." except = what about time zones? * how is a time zone specified? what format is the time? Examples = would help here. * nit: the section defines numbers, booleans, hosts, and time. But no = "text" type. RADIUS is just in the process of fixing this (20+ years = later...), which is why I noticed * adding a data type to each attribute definition would be useful * also, it would be good to say which attributes are mandatory, and = which are optional Attributes may be submitted with no value, in which case they consist of the name and the mandatory or optional separator. * this sounds like the separator is optional. Perhaps "... consist of = the name and separator only" 7.1. Authorization Attributes ... a protocol that is a subset of a service. An example would be any PPP NCP.=20 * nit: expand acronyms on first use. What's a "PPP NCP" ? cmd a shell (exec) command. This indicates the command name for a shell command that is to be run. This attribute MUST be specified if service equals "shell". If no value is present then the shell itself is being referred to. * perhaps a bit more explanation of the use-case here. What is a "shell" = in reference to an administrative management protocol? routing A boolean. ... * note that "routing" is defined to be a boolean, but the other = attributes don't have data types defined. I *think* "cmd" is a textual = attribute, but it's not defined that way timeout an absolute timer for the connection (in minutes). A value of zero indicates no timeout. * probably "numeric" data type? autocmd an auto-command to run. Used only when service=3Dshell and cmd=3DNULL * it's confusing to have an explicit NULL in "cmd". Perhaps quotes = would clarify it here. e.g. n auto-command to run. Used only when the packet contains = attribute-values of "service=3Dshell" and "cmd=3D" noescape Boolean. ... * nit: consistent terminology. "Boolean" ? or "A boolean ..." ?? callback-dialstring Indicates that callback is to be done. Value is NULL, or a dialstring. A NULL value indicates that the service MAY choose to get the dialstring through other means. * nit: explicit NULL is confusing. Perhaps "value is a dial string, or = when omitted, indicates that the server may choose to get the value via = other means" * nit: what's a "dialstring" ? * what's a callback? How does that work? 7.2. Accounting Attributes ... The following new attributes are defined for TACACS+ accounting only. When these attribute-value pairs are included in the argument list, they will precede any attribute-value pairs that are defined in the authorization section (Section 5) above. * "will" precede? Perhaps "MUST precede" task_id Start and stop records for the same event MUST have matching task_id attribute values. The client must not reuse a specific task_id in a start record until it has sent a stop record for that task_id. * how big is the task_id? Since values can be omitted, is it OK to have = a zero-length task_id? or 1 octet? * are there recommendations for the content of task_id? e.g. = incrementing numbers, strings, etc. * is task_id mandatory to occur in accounting packets? start_time The time the action started (). * nit: what are the brackets for? stop_time The time the action stopped (in seconds since the epoch.) * which attributes are allowed in which packets? I presume it's not = recommended to have a START which contains "stop_time" elapsed_time The elapsed time in seconds for the action. Useful when the device does not keep real time. * I'd recommend removing that last sentence. it also indicates that the = device may not have accurate time, notwithstanding the definition of = "absolute times" at the start of Section 7. bytes_in The number of input bytes transferred by this action * input to where? This was poorly specified in RADIUS, and some = implementations got it wrong... * this number might be large. Should implementations allow 16 bit = numbers? 32-bit? 64-bit? What are the expected / recommended limits? * i.e. implementations MUST be able to parse numbers up to 2^32, and = SHOULD be able to parse numbers up to 2^64 status The numeric status value associated with the action. This is a signed four (4) byte word in network byte order. 0 is defined as success. Negative numbers indicate errors. Positive numbers indicate non-error failures. The exact status values may be defined by the client. * This is the first (and only) time that a field is defined as = non-ASCII. That's very off. * nit: values "may" be defined by the client? Perhaps just saying = "values are implementation specific" would be better From nobody Tue Oct 11 09:27:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BC129645; Tue, 11 Oct 2016 09:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 kWczIK0aR9Ah; Tue, 11 Oct 2016 09:27:50 -0700 (PDT) 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 15768129643; Tue, 11 Oct 2016 09:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7429; q=dns/txt; s=iport; t=1476203269; x=1477412869; h=from:subject:to:cc:message-id:date:mime-version; bh=QJNKZ1eU+w5vWh3IcL3dSn+slABg2HkDZR8wIhRw9S0=; b=WEOSqw6zBQcN4EWMfwTo1fnIwAJ2p8O+bXbO2oDa4CAWfQ0sf5jxP7ID FCfQeFcBitS3DCD5odTOK5cVqHhH3QxmmrD1A1lTfde2+LL9ENmYIhX5N 6PpD3GWzcrA6OKnK56XWGghxJJcatXnMT9Wisj6I0nqv4bRML6fl4oD9e 4=; X-IronPort-AV: E=Sophos;i="5.31,329,1473120000"; d="scan'208,217";a="646300406" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2016 16:27:47 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9BGRkPj003567; Tue, 11 Oct 2016 16:27:46 GMT From: Benoit Claise To: "opsawg@ietf.org" Message-ID: <6516fa03-8075-1401-933f-dda07c507db1@cisco.com> Date: Tue, 11 Oct 2016 18:27:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------709E24ED4FD48B19F4652F44" Archived-At: Cc: Sebastien Marchal , draft-xie-ps-centralized-address-management@ietf.org, draft-sun-i2apm-address-pool-management-arch@ietf.org, draft-sun-i2apm-address-pool-management-yang@ietf.org Subject: [OPSAWG] IPPROV BoF was declined X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:27:52 -0000 This is a multi-part message in MIME format. --------------709E24ED4FD48B19F4652F44 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let me inform you that the IPPROV BoF was declined by the IESG/IAB. Even if the IETF discussion started three IETF meetings ago (draft-sun-i2apm-address-pool-management-arch and draft-sun-i2apm-address-pool-management-yang were presented at IETF 94 in OPSAWG), this BoF request came as a surprise, on the last day just before the BoF submission deadline. As such, it didn't generate much (visible) discussion among the community. draft-sun-i2apm-address-pool-management-yang is about a YANG model for IPv4 management. Coming from an operator, it was specifically welcome, and OPSAWG seems like the perfect WG. This document describes an mechanism for a standard, programmatic interface for address pool management. With the remaining IPv4 address becoming more and more scattered, it is complicated to manually configure the address pools on lots of Broadband Network Gateways(BNGs) for operators. By introducing SDN/NFV in BNG, the address pools can be allocatedin a centralized way. It will not only simplify the address management for operators, but also improve the utilization efficiency of the address pool. One issue is that IPAM use cases involve many different NMS/OSS different systems: IPAM, DHCP, DNS, Orchestrator, CMTS, Router, Firewall. All these different key players need to agree on these protocol exchanges/APIs/data models. Btw, I consider YANG models as APIs, as the APIs can be deduced from the models. While we understand that any operators have this issue today and would like to have a simplified solution for address pool management, do we have all the key players from the NMS/OSS ecosystems involved, and a willingness to implement what would become a standard? On top of that, some integration happens today, as those independent different systems have some embedded automation and event mechanisms. Today, the controller/orchestrator will take whatever is APIs are available. Granted, the integration is certainly clean and standardized, but aren't we risking to be late if a standard is approved in 1.5 years? Or maybe this effort should be supported in opensource, with de facto solutions? Looking at the scope, it seems that it extended along the time: From IPv4 address management to IPv6 (well, obviously, we have the same issues with IPv6) to bandwidth and services management, along with some "possible protocol work", as mentioned in the BoF description. A well defined scope is a plus for a BoF request. This BoF would be have benefited from some more preparation and preliminary discussions with the community and the ADs. The connection with ANIMA, as discovered on the mailing list, is certainly a prove of that. Finally, not having a BoF is certainly not a reason for the community to stop organizing itself. Regards, Benoit --------------709E24ED4FD48B19F4652F44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Let me inform you that the IPPROV BoF was declined by the IESG/IAB.

Even if the IETF discussion started three IETF meetings ago (draft-sun-i2apm-address-pool-management-arch and draft-sun-i2apm-address-pool-management-yang were presented at IETF 94 in OPSAWG), this BoF request came as a surprise, on the last day just before the BoF submission deadline. As such, it didn't generate much (visible) discussion among the community.

draft-sun-i2apm-address-pool-management-yang is about a YANG model for IPv4 management. Coming from an operator, it was specifically welcome, and OPSAWG seems like the perfect WG. 
   This document describes an mechanism for a standard, programmatic
   interface for address pool management.  With the remaining IPv4
   address becoming more and more scattered, it is complicated to
   manually configure the address pools on lots of Broadband Network
   Gateways(BNGs) for operators.  By introducing SDN/NFV in BNG, the
   address pools can be allocated in a centralized way.  It will not
   only simplify the address management for operators, but also improve
   the utilization efficiency of the address pool.
One issue is that IPAM use cases involve many different NMS/OSS different systems: IPAM, DHCP, DNS, Orchestrator, CMTS, Router, Firewall. All these different key players need to agree on these protocol exchanges/APIs/data models. Btw, I consider YANG models as APIs, as the APIs can be deduced from the models.
While we understand that any operators have this issue today and would like to have a simplified solution for address pool management, do we have all the key players from the NMS/OSS ecosystems involved, and a willingness to implement what would become a standard?

On top of that, some integration happens today, as those independent different systems have some embedded automation and event mechanisms. Today, the controller/orchestrator will take whatever is APIs are available. Granted, the integration is certainly clean and standardized, but aren't we risking to be late if a standard is approved in 1.5 years? Or maybe this effort should be supported in opensource, with de facto solutions?

Looking at the scope, it seems that it extended along the time: From IPv4 address management to IPv6 (well, obviously, we have the same issues with IPv6) to bandwidth and services management, along with some "possible protocol work", as mentioned in the BoF description.
A well defined scope is a plus for a BoF request.

This BoF would be have benefited from some more preparation and preliminary discussions with the community and the ADs.
The connection with ANIMA, as discovered on the mailing list, is certainly a prove of that.

Finally, not having a BoF is certainly not a reason for the community to stop organizing itself.

Regards, Benoit


--------------709E24ED4FD48B19F4652F44-- From nobody Wed Oct 12 08:07:44 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85294129553 for ; Wed, 12 Oct 2016 08:07: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, 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 IqZyUuzfQ28n for ; Wed, 12 Oct 2016 08:07:41 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 99EAC126B6D for ; Wed, 12 Oct 2016 08:07:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 0282C1F6F; Wed, 12 Oct 2016 15:07:41 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aefiBuOxtECV; Wed, 12 Oct 2016 15:07:40 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 5830F47A; Wed, 12 Oct 2016 15:07:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <638AC1BA-02A7-4346-8DC0-B7E762DA334D@deployingradius.com> Date: Wed, 12 Oct 2016 11:07:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <638AC1BA-02A7-4346-8DC0-B7E762DA334D@deployingradius.com> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 15:07:43 -0000 Continuing with Section 8 ... Privilege Levels are ordered values from 0 to 15 with each level representing a privilege level that is a superset of the next lower value.=20 * nit: perhaps this could be "each level is defined to be a superset of = the next lower value", instead of "representing". If a client uses a different privilege level scheme, then it must map the privilege level to scheme above. * editorial :"... to A scheme..." * and how is mapping done? It might be better to just omit that = sentence. Privilege Levels are applied in two ways in the TACACS+ protocol: * nit: perhaps "used" instead of "applied" - As an argument in authorization EXEC phase (when service=3Dshell and cmd=3DNULL), where it is primarily used to set the initial privilege level for the EXEC session. * how does that work? And what does it mean to set an initial privilege = level? - In the packet headers for Authentication, Authorization and Accounting. The privilege level in the header is primarily significant in the Authentication phase for enable authentication where a different privilege level is required. * again, how does that work? Additional text would be useful. e.g. In typical use-cases, an administrator can perform a series of commands = at a low privilege level. When additional privileges are required, the = administrator can authenticate at the desired level, perform a series of = commands, and the drop privilege level to the lower one. This = methodology minimizes possible errors by using high privilege levels = only when necessary, and using low privilege levels for most commands. * expanding on the use-case and work flow would be of great benefit. The use of Privilege levels to determine session-based access to commands and resources is not mandatory for clients, but it is in common use so SHOULD be supported by servers. * and clients, presumably? Perhaps instead, say: It is RECOMMENDED that clients and servers use Privilege levels to = signal and control session-based access. It is RECOMMENDED that clients permit users to change their Privilege levels, so as to ensure that commands = are executed with the minimum Privilege level required. 9. TACACS+ Security Considerations * there is a lot which can be said here. My proposal here is a = substantial amount of text. I'll include it in another message= From nobody Wed Oct 12 08:27:53 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D112954E; Wed, 12 Oct 2016 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.665 X-Spam-Level: X-Spam-Status: No, score=-4.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 jnATgE65GzP4; Wed, 12 Oct 2016 08:27:48 -0700 (PDT) Received: from BAY004-OMC4S12.hotmail.com (bay004-omc4s12.hotmail.com [65.54.190.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142AD129472; Wed, 12 Oct 2016 08:27:48 -0700 (PDT) Received: from BAY181-W40 ([65.54.190.199]) by BAY004-OMC4S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 12 Oct 2016 08:27:48 -0700 X-TMN: [2xzctKj1SedvgjLJhO6n0lUv3B1HcK3S] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_00648d0f-6eba-4a14-ac9d-5059dfb176c1_" From: Hui Deng To: Chenrui Richard , "opsawg@ietf.org" Date: Wed, 12 Oct 2016 23:27:47 +0800 Importance: Normal In-Reply-To: <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2016 15:27:48.0032 (UTC) FILETIME=[2FF69400:01D2249D] Archived-At: Cc: "opsawg-chairs@ietf.org" Subject: Re: [OPSAWG] =?gb2312?b?tPC4tDogIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2Vk?= =?gb2312?b?LXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 15:27:52 -0000 --_00648d0f-6eba-4a14-ac9d-5059dfb176c1_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCkkgYWdyZWUgd2l0aCB5b3VyIHBvaW50LCBpbiBvcmRlciB0byBtZWV0IHRo b3NlIG9wZXJhdG9ycyBleHBlY3RhdGlvbiwgdGhlIGRyYWZ0IG1heSBuZWVkIHRvIGJlIHVwZGF0 ZWQgYW5kIHJlZmxlY3QgdGhhdCBhcmNoaXRlY3R1cmUuDQpSZWdhcmRpbmcgdG8gc29sdXRpb24s IHRoYXQgd2lsbCBiZSBncmVhdCwgdGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiB0 byBJRVRGIGlmIHRoZXJlIGlzIGFueSBwcm9vZiBvZiBjb25jZXB0IHRvIHRoaXMuDQp0aGFua3Mg YSBsb3QgZm9yIHlvdXIgc3VnZ2VzdGlvbg0KQmVzdCByZWdhcmRzLA0KREVORyBIdWkNCg0KRnJv bTogY2hlbnJ1aUBodWF3ZWkuY29tDQpUbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tOyBvcHNhd2dA aWV0Zi5vcmcNCkNDOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiC08Li0OiBbT1BT QVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4 dA0KRGF0ZTogVHVlLCAxMSBPY3QgMjAxNiAwMjoyNzoxNCArMDAwMA0KDQoKCgoKCgoKCkhpIEh1 aSwKIApUaGFua3MgZm9yIHRoZXNlIGNsYXJpZmljYXRpb25zLiBNYXliZSB3ZSBjYW4gdGFsayBh Ym91dCBpdCBtb3JlIGluIG5leHQgbWVldGluZyBhbmQgd2UgY2FuIHByb3ZpZGUgYSBpbml0aWFs IHNvbHV0aW9uIGFyb3VuZCB0aGVzZSBpc3N1ZXMuCiAKQlRXLCBpZiB3ZSB0YWxraW5nIGFib3V0 CmZlZGVyYXRpb24gdXNlZCBpbiBtdWx0aXBsZSBvcGVyYXRvcnMgc2NlbmFyaW9zLCBJIHN1Z2dl c3QgdGhhdCB0aGVyZSBzaG91bGQgYmUgZWFzdC13ZXN0IGludGVyZmFjZSBiZXR3ZWVuIHBlZXIg b3JjaGVzdHJhdGlvbiBzeXN0ZW0gaW4gdGhlc2Ugb3BlcmF0b3JzLiBUaGF0IGVhc2Utd2VzdCBp bnRlcmZhY2UgaXMgZGlmZmVyZW50CiB3aXRoIGludGVybmFsIEUyRSBzZXJ2aWNlIGFjdGl2YXRp b24gaW50ZXJmYWNlIGZvciBzb21lIHNwZWNpYWwgcmVxdWlyZW1lbnQgYmV0d2VlbiBvcGVyYXRv cnMsIHN1Y2ggYXMgc2VjdXJpdHksIHJlc291cmNlIHZpc3VhbGl6YXRpb24sZXRjLgogClRoYW5r cywKUmljaGFyZAogCgoKCgoNCgq7qs6qvLzK9dPQz965q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMg Q28uLCBMdGQuDQoKtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXYCiDTyrHgo7o1MTgxMjkN CgpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KCkJhbnRpYW4sIExvbmdnYW5nIERpc3Ry aWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQoKaHR0cDovL3d3dy5odWF3ZWkuY29tCgoK CgqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a1 2Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0KCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw /MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQoKtcTQ xc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+ s/2xvtPKvP6joQ0KClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoCg0KCmlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl LiBBbnkgdXNlIG9mIHRoZQoNCgppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3 YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsCg0KCmRp c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZCANCgpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91 IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBi eQoNCgpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQoKIAoKCgq3orz+ yMs6IEh1aSBEZW5nIFttYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tXQoNCgq3osvNyrG85Dog MjAxNsTqMTDUwjEwyNUgMjM6MTUNCgrK1bz+yMs6IENoZW5ydWkgKFJpY2hhcmQpOyBvcHNhd2dA aWV0Zi5vcmcNCgqzrcvNOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnDQoK1vfM4jogUkU6IFtPUFNB V0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0 CgoKIAoKDQoKSGkgUmljaGFyZCwKCiAKCgpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMs IEkgcmVjYWxsZWQgdGhhdCBvdGhlciB0d28gb3BlcmF0b3JzIGR1cmluZyBsYXN0IHRpbWUgZjJm IG1lZXRpbmcgaGFkIG1hZGUgc29tZSBjb21tZW50cyBhYm91dCBmZWRlcmF0aW9uIGlzc3VlLCBo b3BlIHRoZXkgY2FuIGVsYWJvcmF0ZSBtb3JlIGRldGFpbAogY29tbWVudHMgaGVyZSBhcyB3ZWxs LCBpbmxpbmUgd2l0aCA9PT4KCgoKCkZyb206CmNoZW5ydWlAaHVhd2VpLmNvbQ0KClRvOiBvcHNh d2dAaWV0Zi5vcmc7IApkZW5naHVpMDJAaG90bWFpbC5jb20NCgpDQzogb3BzYXdnLWNoYWlyc0Bp ZXRmLm9yZw0KClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3Nl ZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KCkRhdGU6IFN1biwgOSBPY3QgMjAxNiAwMzoz NTo0NiArMDAwMAoKSGkgSHVpIGFuZCBhbGwsCiAKV2hlbiBJIHdlbnQgdGhyb3VnaCB0aGUgZG9j dW1lbnRzIG9mIElFVEYjOTYsSSBub3RpY2VkIHRoYXQgdGhpcyBkcmFmdCBoYXMgcmFpc2VkIGEg aW50ZXJlc3RpbmcgcmVxdWlyZW1lbnQgaW4gQ2hpbmEgTW9iaWxlIG9mIEUyRSBkZXBsb3ltZW50 IGludGVyZmFjZSB0byBhIG11bHRpcGxlIFZQTnMKIGNvbXBvc2VkIGluZnJhc3RydWN0dXJlLCBz dWNoIGFzIEwyK0wzIG5ldHdvcmsuIFNvIHRoZSBpbnRlcmZhY2UgY291bGQgbWFrZSB0aGUgc2Vy dmljZSBmdWxmaWxsbWVudCBhbmQgbWFuYWdlbWVudCBtb3JlIGVhc3kuCklzIG15IHVuZGVyc3Rh bmRpbmcgcmlnaHQ/CiAKPT0+IFllcywgY3VycmVudCBleGlzdGluZyBMM1NNIGFyZSBtb3N0bHkg dGFsa2luZyBhYm91dCBjdXN0b21lciBmYWNpbmcgc2VydmljZSBtb2RlbC4KdGhpcyByZXF1aXJl bWVudCBleHBlY3RzIHRvIGhlbHAgb3BlcmF0b3JzIHdpdGggbGFyZ2Ugc2NhbGUgdG8gbWFuZ2Ug dGhlIHVuZGVybGF5IG5ldHdvcmsgd2l0aCBhIGdsb2JhbCB2aWV3LiAgKGhlcmUgY291bGQgYmUg YSBtdWx0aXBsZSBvcGVyYXRvcnMsIHRoYXQgaXMgcmVsYXRlZCB0byBmZWRlcmF0aW9uKQogYW4g ZW50ZXJwcmlzZSBjdXN0b21lciBtYXkgc2ltcGx5IHJlcXVlc3QgYSBMMyBWUE4gc2VydmljZSwg YnV0IG9wZXJhdG9yIGhhcyB0byBwcm92aXNpb24gYW5kIG1hbmdlIHRoZSBlbmQgdG8gZW5kIHVu ZGVybGF5IG5ldHdvcmsgY29uc3RydWN0ZWQgd2l0aCBtdWx0aXBsZSBBU2VzIGFuZCB0ZWNobmlx dWVzLCBhbmQgZnVydGhlciBhc3N1cmUgdGhlIHNlcnZpY2UuIHRoaXMgaXMgdGhlIGtleSBpc3N1 ZSBmb3IgdG9kYXkncyBvcGVyYXRvcnMuCiAKSSBkbyBiZWxpZXZlIHRoaXMgaW50ZXJmYWNlIGFu ZCBpdHMgbW9kZWwgYXJlIGluZGVlZCBoZWxwZnVsIGZvciBvcGVyYXRvcnMgdG8gc2ltcGxpZnkg b3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudC4KQW5kIEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9u cyBuZWVkIHRvIGJlIGRpc2N1c3NlZCBhbmQgYWxpZ25lZCB3aXRoIHlvdSBhbmQgZXhwZXJ0cyBp biBlbWFpbCB0aHJlYWQuCiAKMS5XaGlsZSByZWZlcnJpbmcgdG8gYW5vdGhlciBkcmFmdCBhdCBz YW1lIG1lZXRpbmcgPDxzZXJ2aWNlIG1vZGVsIGV4cGxhaW5lZD4+IChodHRwczovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMy50eHQp LApJIGJlbGlldmUgdGhlIGFib3ZlIEUyRSBkZXBsb3ltZW50IGludGVyZmFjZSBzaG91bGQgYmUg cG9zaXRpb24gYmV0d2VlbiBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gYW5kICBuZXR3b3JrIG9yY2hl c3RyYXRpb24oRmlndXJlIDMpLgpUaGF0IG1lYW4gaXShr3MgYSBpbnRlcm5hbCBpbnRlcmZhY2Ug aW4gb25lIG9wZXJhdG9yIGFuZCBpdCBhY3RzIG5vdCBvbmx5IHRvIGltcGxlbWVudCB0aGUgY3Vz dG9tZXIgZmFjaW5nIG1vZGVsIChpLmUuIEwzU00pLGJ1dCBhbHNvIHRvIG1haW50YWluLCBtb25p dG9yIGFuZCBkaWFnbm9zZSB0aGUKIGVuZCB0byBlbmQgUEUtYmFzZWQgVlBOIHNlcnZpY2VzIGNy b3NzaW5nIG11bHRpcGxlIHRlY2hub2xvZ2llcyBkZXBsb3llZCBuZXR3b3JrLgpJcyBpdCByaWdo dD8gYW5kIHNob3VsZCB0aGlzIGludGVyZmFjZSBuZWVkIHRvIHN1cHBvcnQgVlBOIHNlcnZpY2Ug d2hpY2ggbWF5YmUgY3Jvc3MgbXVsdGlwbGUgb3BlcmF0b3JzPwo9PT4gZ29vZCBwb2ludCwgdGhl IGZ1dHVyZSBpbiB0aGUgbGluayBpcyBxdWl0ZSBoZWxwZnVsLCB0aGlzIHNob3VsZCBiZSB1cGRh dGVkIGluIG5leHQgcmV2aXNpb24uCiAKPT0+IGZvciB5b3VyIHF1ZXN0aW9ucyBhYm91dCBtdWx0 aXBsZSBvcGVyYXRvcnMsIHRoaXMgaXMgZXhhY3RseSB0aGUgaXNzdWUgcmFpc2VkIGR1cmluZyB0 aGUgbWVldGluZywgb3BlcmF0b3IgYXJlIGludGVyY29ubmVjdGVkIGVhY2ggb3RoZXIgdGhyb3Vn aCBmZWRlcmF0aW9uLCB0aGUgZW5kCiB0byBlbmQgc2VydmljZSBtYXkgZ28gYWNyb3NzIG11bHRp cGxlIG9wZXJhdG9ycycgYWNjZXNzIGFuZCBjb3JlIG5ldHdvcmsuIHRoYXQgaXMgdGhlIHJlYXNv biB3aHkgd2UgZGVmaW5lIFZQTiBzZWdtZW50IHdpdGhpbiB0aGUgY29tcG9zZWQgVlBOLiB0aGlz IGhhc24ndCBiZWVuIGNvbnNpZGVyIGluIHRoZSBkb2N1bWVudCBiZWZvcmUsIGJ1dCB0aGUgZmxl eGliaWxpdHkgb2YgY29tcG9zZWQgVlBOIGZyYW1ld29yayBzaG91bGQgYmUgaW5jbHVkZWQuCiAK Mi5BY3R1YWxseSBJoa9tIG5ldyBndXkgaW4gSUVURiwgc28gSaGvbSBub3Qgc3VyZSBpZiB0aGVy ZSBhcmUgZXhpc3Rpbmcgd29ya3MgaW4gSUVURiB3aGljaCBjb3VsZCBpbnN0cnVjdCBvciBtb2Rl bGluZyB0aGUgaW50ZXJmYWNlL0UyRS12aWV3IHRvIG1hbmFnZSBhIG11bHRpcGxlIHRlY2hub2xv Z2llcwogY29tcG9zZWQgbmV0d29yaywgd2hpY2ggSSBiZWxpZXZlIHZlcnkgY29tbW9uIGluIG9w ZXJhdG9yoa9zIGRlcGxveW1lbnQgd2hpbGUgc3RpbGwgbmVlZCB0byBwcm92aWRlIHNpbXBsZSBF MkUgc2VydmljZSBleHBlcmllbmNlIHRvIHRoZWlyIGN1c3RvbWVycy4gTWF5YmUgd2UgY2FuIGlt cHJvdmUgc29tZXRoaW5nIGhlcmUuIFNvIGlmIGV4cGVydHMgaGVyZSBoYXZlIG1vcmUgYmFja2dy b3VuZCwgcGxlYXNlIGhlbHAgbWUuIFRoYW5rcy4KIAo9PT4gYWx0aG91Z2ggaXQgaXMgaW1wb3J0 YW50LCBidXQgSSBkaWRuJ3Qgc2VlIGFueSBlMmUgZWZmb3J0IG9uIHRoZSBuZXR3b3JrIHlldC4g dGhlcmUgaXMgYSByZWxhdGVkIHdvcmsgaW4gTDNTTSBpbiBjdXN0b21lciBzZXJ2aWNlIGxldmVs IGFuZCBzb21lIGRlZGljYXRlZCBWUE4gbW9kZWxzCiBpbiBCRVNTLiB0aGF0J3Mgd2h5IEkgcmFp c2UgdGhpcyB0b3BpYy4gZGVmaW5pdGVseSB3ZWxjb21lIGFueSBlZmZvcnQgdG8gam9pbiB0aGUg Zm9sbG93aW5nIGRhdGEgbW9kZWwgZGVzaWduIGlmIHlvdSByZWFsbHkgaGF2ZSBhIHN0cm9uZyBi YWNrZ3JvdW5kIG9uIGl0LgogCjMuQXMgSSB1bmRlcnN0YW5kIHRoaXMgaW50ZXJmYWNlL21vZGVs IHNob3VsZCBiZSBpbnRlcm5hbCBpbiBvcGVyYXRvcnMsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhl cmUgYW55IG90aGVyIG9wZXJhdG9ycyBhcmUgaW50ZXJlc3RlZCBpdCBhbmQgbmVlZCBhIElFVEYg UkZDPwogCj09PiBJIGRpZCBoZWFyIHR3byBiaWcgb3BlcmF0b3JzIHNob3dlZCB0aGUgaW50ZXJl c3QgaW4gdGhpcyB0b3BpYywgaG9wZSB0aGV5IGNhbiBqb2luIGFzIHdlbGwgaW4gb3VyIG5leHQg cmV2aXNpb24uIHRoaXMgbWF5IHJlbGF0ZWQgdG8gbmV0d29yayBvcmNoZXN0cmF0b3IsIE9TUy9C U1MgYW5kCiBldmVuIGFuYWx5dGljcyBzeXN0ZW0gZnJvbSBkaWZmZXJlbnQgdmVuZG9ycy4gYSBz dGFuZGFyZCBtb2RlbCB3aWxsIGRlZmluaXRlbHkgIGhlcCB0aGUgZGl2ZXJzaXR5IGluIG9uZSBv cGVyYXRvcidzIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQuCiAKQmVzdCByZWdhcmRzLAogCkRFTkcg SHVpClRoYW5rcy4KIApSZWdhcmRzLApSaWNoYXJkIENoZW4KIAoKCgoNCgq7qs6qvLzK9dPQz965 q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQoKtdjWt6O6ye7b2srQwfq42sf42+DM 77uqzqq7+bXYINPKseCjujUxODEyOQ0KCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQoK QmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCgpo dHRwOi8vd3d3Lmh1YXdlaS5jb20KCgoKCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc 0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQoK1rnIzrrO xuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sah orvyyaK3oqOpsb7Tyrz+1tANCgq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS1 57uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQoKVGhpcyBlLW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwg d2hpY2gKDQoKaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2Ug YWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlCg0KCmluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8s IHRvdGFsIG9yIHBhcnRpYWwKDQoKZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1p bmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIA0KCnJlY2lwaWVudChz KSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5Cg0KCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgaXQhCiAKCgoKCgogCQkgCSAgIAkJICA= --_00648d0f-6eba-4a14-ac9d-5059dfb176c1_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGkgUmljaGFyZCw8ZGl2Pjxicj48L2Rpdj48ZGl2Pkkg YWdyZWUgd2l0aCB5b3VyIHBvaW50LCBpbiBvcmRlciB0byBtZWV0IHRob3NlIG9wZXJhdG9ycyBl eHBlY3RhdGlvbiwgdGhlIGRyYWZ0IG1heSBuZWVkIHRvIGJlIHVwZGF0ZWQgYW5kIHJlZmxlY3Qg dGhhdCBhcmNoaXRlY3R1cmUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5SZWdhcmRpbmcgdG8g c29sdXRpb24sIHRoYXQgd2lsbCBiZSBncmVhdCwgdGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbnRy aWJ1dGlvbiB0byBJRVRGIGlmIHRoZXJlIGlzIGFueSBwcm9vZiBvZiBjb25jZXB0IHRvIHRoaXMu PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj50aGFua3MgYSBsb3QgZm9yIHlvdXIgc3VnZ2VzdGlv bjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+REVORyBIdWk8YnI+PGJyPjxkaXY+PGhyIGlkPSJzdG9wU3BlbGxpbmciPkZyb206 IGNoZW5ydWlAaHVhd2VpLmNvbTxicj5UbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tOyBvcHNhd2dA aWV0Zi5vcmc8YnI+Q0M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8YnI+U3ViamVjdDogtPC4tDog W09QU0FXR10gZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0w MS50eHQ8YnI+RGF0ZTogVHVlLCAxMSBPY3QgMjAxNiAwMjoyNzoxNCArMDAwMDxicj48YnI+CgoK CjxzdHlsZT48IS0tCi5FeHRlcm5hbENsYXNzIHAuZWN4TXNvTm9ybWFsLCAuRXh0ZXJuYWxDbGFz cyBsaS5lY3hNc29Ob3JtYWwsIC5FeHRlcm5hbENsYXNzIGRpdi5lY3hNc29Ob3JtYWwgewpmb250 LXNpemU6MTIuMHB0Owpmb250LWZhbWlseTrLzszlOwp9CgouRXh0ZXJuYWxDbGFzcyBhOmxpbmss IC5FeHRlcm5hbENsYXNzIHNwYW4uZWN4TXNvSHlwZXJsaW5rIHsKY29sb3I6Ymx1ZTsKdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsKfQoKLkV4dGVybmFsQ2xhc3Mgc3Bhbi5lY3hNc29IeXBlcmxp bmtGb2xsb3dlZCB7CmNvbG9yOnB1cnBsZTsKdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsKfQoK LkV4dGVybmFsQ2xhc3MgcCB7CmZvbnQtc2l6ZToxMi4wcHQ7CmZvbnQtZmFtaWx5OsvOzOU7Cn0K Ci5FeHRlcm5hbENsYXNzIHAuZWN4TXNvQWNldGF0ZSwgLkV4dGVybmFsQ2xhc3MgbGkuZWN4TXNv QWNldGF0ZSwgLkV4dGVybmFsQ2xhc3MgZGl2LmVjeE1zb0FjZXRhdGUgewpmb250LXNpemU6OS4w cHQ7CmZvbnQtZmFtaWx5OsvOzOU7Cn0KCi5FeHRlcm5hbENsYXNzIHAuZWN4bXNvbm9ybWFsLCAu RXh0ZXJuYWxDbGFzcyBsaS5lY3htc29ub3JtYWwsIC5FeHRlcm5hbENsYXNzIGRpdi5lY3htc29u b3JtYWwgewpmb250LXNpemU6MTIuMHB0Owpmb250LWZhbWlseTrLzszlOwp9CgouRXh0ZXJuYWxD bGFzcyBzcGFuLmVjeG1zb2h5cGVybGluayB7Cn0KCi5FeHRlcm5hbENsYXNzIHNwYW4uZWN4bXNv aHlwZXJsaW5rZm9sbG93ZWQgewp9CgouRXh0ZXJuYWxDbGFzcyBzcGFuLmVjeGVtYWlsc3R5bGUx NyB7Cn0KCi5FeHRlcm5hbENsYXNzIHAuZWN4bXNvbm9ybWFsMSwgLkV4dGVybmFsQ2xhc3MgbGku ZWN4bXNvbm9ybWFsMSwgLkV4dGVybmFsQ2xhc3MgZGl2LmVjeG1zb25vcm1hbDEgewp0ZXh0LWFs aWduOmp1c3RpZnk7CnRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7CmZvbnQtc2l6ZToxMC41 cHQ7CmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cn0KCi5FeHRlcm5hbENsYXNz IHNwYW4uZWN4bXNvaHlwZXJsaW5rMSB7CmNvbG9yOmJsdWU7CnRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7Cn0KCi5FeHRlcm5hbENsYXNzIHNwYW4uZWN4bXNvaHlwZXJsaW5rZm9sbG93ZWQxIHsK Y29sb3I6cHVycGxlOwp0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOwp9CgouRXh0ZXJuYWxDbGFz cyBzcGFuLmVjeGVtYWlsc3R5bGUxNzEgewpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOwpjb2xvcjp3aW5kb3d0ZXh0Owp9CgouRXh0ZXJuYWxDbGFzcyBzcGFuLmVjeENoYXIgewpm b250LWZhbWlseTrLzszlOwp9CgouRXh0ZXJuYWxDbGFzcyBzcGFuLmVjeEVtYWlsU3R5bGUyOCB7 CmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7CmNvbG9yOiMxRjQ5N0Q7Cn0KCi5F eHRlcm5hbENsYXNzIC5lY3hNc29DaHBEZWZhdWx0IHsKZm9udC1zaXplOjEwLjBwdDsKfQoKLkV4 dGVybmFsQ2xhc3MgZGl2LmVjeFdvcmRTZWN0aW9uMSB7Cn0KCi0tPjwvc3R5bGU+CgoKPGRpdiBj bGFzcz0iZWN4V29yZFNlY3Rpb24xIj4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEOyI+SGkgSHVpLDwv c3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNs YXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDsiPlRoYW5rcyBmb3IgdGhlc2UgY2xhcmlmaWNhdGlvbnMuIE1heWJl IHdlIGNhbiB0YWxrIGFib3V0IGl0IG1vcmUgaW4gbmV4dCBtZWV0aW5nIGFuZCB3ZSBjYW4gcHJv dmlkZSBhIGluaXRpYWwgc29sdXRpb24gYXJvdW5kIHRoZXNlIGlzc3Vlcy48L3NwYW4+PC9wPgo8 cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7Ij5CVFcsIGlmIHdlIHRhbGtpbmcgYWJvdXQKPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RDsiPmZlZGVyYXRpb24gdXNlZCBpbiBtdWx0aXBsZSBvcGVyYXRvcnMgc2NlbmFyaW9zLCBJIHN1 Z2dlc3QgdGhhdCB0aGVyZSBzaG91bGQgYmUgZWFzdC13ZXN0IGludGVyZmFjZSBiZXR3ZWVuIHBl ZXIgb3JjaGVzdHJhdGlvbiBzeXN0ZW0gaW4gdGhlc2Ugb3BlcmF0b3JzLiBUaGF0IGVhc2Utd2Vz dCBpbnRlcmZhY2UgaXMgZGlmZmVyZW50CiB3aXRoIGludGVybmFsIEUyRSBzZXJ2aWNlIGFjdGl2 YXRpb24gaW50ZXJmYWNlIGZvciBzb21lIHNwZWNpYWwgcmVxdWlyZW1lbnQgYmV0d2VlbiBvcGVy YXRvcnMsIHN1Y2ggYXMgc2VjdXJpdHksIHJlc291cmNlIHZpc3VhbGl6YXRpb24sZXRjLjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPiZuYnNw Ozwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPlRoYW5rcyw8L3NwYW4+PC9wPgo8 cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij5SaWNoYXJkPC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEOyI+Jm5ic3A7PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBjbGFzcz0iZWN4TXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij4KPGhyIHNpemU9IjIi IHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4KPC9zcGFuPjwvZGl2Pgo8cCBjbGFzcz0iZWN4 TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGg7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7Ij48YnI+Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTq7qs7Ez7i62jtjb2xvcjpibGFjazsiPruqzqq8vMr109DP3rmry748c3BhbiBsYW5n PSJFTi1VUyI+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuPGJyPgo8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OruqzsTPuLraO2NvbG9y OmJsYWNrOyI+tdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXYCiDTyrHgo7o8c3BhbiBsYW5n PSJFTi1VUyI+NTE4MTI5PGJyPgpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4KQmFu dGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmE8YnI+Cmh0 dHA6Ly93d3cuaHVhd2VpLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEOyI+Cjwvc3Bhbj48L3A+CjxkaXYgY2xhc3M9 ImVjeE1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyOyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEOyI+ CjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+Cjwvc3Bhbj48L2Rpdj4K PHAgY2xhc3M9ImVjeE1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1 c3RpZnk6aW50ZXItaWRlb2dyYXBoOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTq7qs7Ez7i62jtjb2xvcjpncmF5OyI+sb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761 xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfs8c3Bh biBsYW5nPSJFTi1VUyI+PGJyPgo8L3NwYW4+1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8 wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+1tA8c3BhbiBs YW5nPSJFTi1VUyI+PGJyPgo8L3NwYW4+tcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrB ory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joTxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+Cjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpncmF5OyI+VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gKPGJyPgppcyBpbnRlbmRlZCBv bmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92 ZS4gQW55IHVzZSBvZiB0aGUKPGJyPgppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFu eSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsCjxi cj4KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25z IG90aGVyIHRoYW4gdGhlIGludGVuZGVkIDxicj4KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkKPGJyPgpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0ITwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7Ij48L3NwYW4+PC9wPgo8L2Rpdj4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEOyI+Jm5ic3A7PC9z cGFuPjwvcD4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0OyI+CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtOyI+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0OyI+t6K8/sjLPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Ij4gSHVpIERlbmcgW21h aWx0bzpkZW5naHVpMDJAaG90bWFpbC5jb21dCjxicj4KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0OyI+t6LLzcqxvOQ8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsiPiAyMDE2 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyI+xOo8c3BhbiBsYW5nPSJFTi1V UyI+MTA8L3NwYW4+1MI8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+yNU8c3BhbiBsYW5nPSJF Ti1VUyI+IDIzOjE1PGJyPgo8L3NwYW4+PGI+ytW8/sjLPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQ2hlbnJ1aSAoUmljaGFyZCk7IG9wc2F3Z0BpZXRm Lm9yZzxicj4KPC9zcGFuPjxiPrOty808c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPGJyPgo8L3NwYW4+PGI+1vfM 4jxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJFOiBb T1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAx LnR4dDwvc3Bhbj48L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJlY3hNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjxicj4KSGkgUmljaGFyZCw8 L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciBj b21tZW50cywgSSByZWNhbGxlZCB0aGF0IG90aGVyIHR3byBvcGVyYXRvcnMgZHVyaW5nIGxhc3Qg dGltZSBmMmYgbWVldGluZyBoYWQgbWFkZSBzb21lIGNvbW1lbnRzIGFib3V0IGZlZGVyYXRpb24g aXNzdWUsIGhvcGUgdGhleSBjYW4gZWxhYm9yYXRlIG1vcmUgZGV0YWlsCiBjb21tZW50cyBoZXJl IGFzIHdlbGwsIGlubGluZSB3aXRoID09Jmd0Ozwvc3Bhbj48L3A+CjxkaXY+CjxkaXYgY2xhc3M9 ImVjeE1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyOyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4KPGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGln bj0iY2VudGVyIiBpZD0iZWN4c3RvcFNwZWxsaW5nIj4KPC9zcGFuPjwvZGl2Pgo8cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPkZyb206Cjxh IGhyZWY9Im1haWx0bzpjaGVucnVpQGh1YXdlaS5jb20iPmNoZW5ydWlAaHVhd2VpLmNvbTwvYT48 YnI+ClRvOiA8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIj5vcHNhd2dAaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tIj4KZGVuZ2h1aTAyQGhv dG1haWwuY29tPC9hPjxicj4KQ0M6IDxhIGhyZWY9Im1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYu b3JnIj5vcHNhd2ctY2hhaXJzQGlldGYub3JnPC9hPjxicj4KU3ViamVjdDogUmU6IFtPUFNBV0dd IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0PGJy PgpEYXRlOiBTdW4sIDkgT2N0IDIwMTYgMDM6MzU6NDYgKzAwMDA8L3NwYW4+PC9wPgo8ZGl2Pgo8 cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij5IaSBIdWkgYW5kIGFs bCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7Ij5XaGVuIEkgd2VudCB0aHJvdWdoIHRoZSBkb2N1bWVudHMgb2YgSUVU RiM5NixJIG5vdGljZWQgdGhhdCB0aGlzIGRyYWZ0IGhhcyByYWlzZWQgYSBpbnRlcmVzdGluZyBy ZXF1aXJlbWVudCBpbiBDaGluYSBNb2JpbGUgb2YgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNlIHRv IGEgbXVsdGlwbGUgVlBOcwogY29tcG9zZWQgaW5mcmFzdHJ1Y3R1cmUsIHN1Y2ggYXMgTDIrTDMg bmV0d29yay4gU28gdGhlIGludGVyZmFjZSBjb3VsZCBtYWtlIHRoZSBzZXJ2aWNlIGZ1bGZpbGxt ZW50IGFuZCBtYW5hZ2VtZW50IG1vcmUgZWFzeS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7Ij5JcyBteSB1bmRlcnN0YW5kaW5nIHJpZ2h0Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsiPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPj09Jmd0OyBZZXMs IGN1cnJlbnQgZXhpc3RpbmcgTDNTTSBhcmUgbW9zdGx5IHRhbGtpbmcgYWJvdXQgY3VzdG9tZXIg ZmFjaW5nIHNlcnZpY2UgbW9kZWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PC9z cGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+dGhp cyByZXF1aXJlbWVudCBleHBlY3RzIHRvIGhlbHAgb3BlcmF0b3JzIHdpdGggbGFyZ2Ugc2NhbGUg dG8gbWFuZ2UgdGhlIHVuZGVybGF5IG5ldHdvcmsgd2l0aCBhIGdsb2JhbCB2aWV3LiAmbmJzcDso aGVyZSBjb3VsZCBiZSBhIG11bHRpcGxlIG9wZXJhdG9ycywgdGhhdCBpcyByZWxhdGVkIHRvIGZl ZGVyYXRpb24pCiBhbiBlbnRlcnByaXNlIGN1c3RvbWVyIG1heSBzaW1wbHkgcmVxdWVzdCBhIEwz IFZQTiBzZXJ2aWNlLCBidXQgb3BlcmF0b3IgaGFzIHRvIHByb3Zpc2lvbiBhbmQgbWFuZ2UgdGhl IGVuZCB0byBlbmQgdW5kZXJsYXkgbmV0d29yayBjb25zdHJ1Y3RlZCB3aXRoIG11bHRpcGxlIEFT ZXMgYW5kIHRlY2huaXF1ZXMsIGFuZCBmdXJ0aGVyIGFzc3VyZSB0aGUgc2VydmljZS4gdGhpcyBp cyB0aGUga2V5IGlzc3VlIGZvciB0b2RheSdzIG9wZXJhdG9ycy48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPkkgZG8gYmVsaWV2ZSB0aGlzIGludGVyZmFjZSBhbmQg aXRzIG1vZGVsIGFyZSBpbmRlZWQgaGVscGZ1bCBmb3Igb3BlcmF0b3JzIHRvIHNpbXBsaWZ5IG9w ZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+ QW5kIEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9ucyBuZWVkIHRvIGJlIGRpc2N1c3NlZCBhbmQg YWxpZ25lZCB3aXRoIHlvdSBhbmQgZXhwZXJ0cyBpbiBlbWFpbCB0aHJlYWQuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE OyI+MS5XaGlsZSByZWZlcnJpbmcgdG8gYW5vdGhlciBkcmFmdCBhdCBzYW1lIG1lZXRpbmcgJmx0 OyZsdDtzZXJ2aWNlIG1vZGVsIGV4cGxhaW5lZCZndDsmZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7OyI+ICg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEOyI+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWlu ZWQtMDMudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFm dC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDMudHh0PC9hPiksPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEOyI+SSBiZWxpZXZlIHRoZSBhYm92ZSBFMkUgZGVwbG95bWVu dCBpbnRlcmZhY2Ugc2hvdWxkIGJlIHBvc2l0aW9uIGJldHdlZW4gc2VydmljZSBvcmNoZXN0cmF0 aW9uIGFuZCAmbmJzcDtuZXR3b3JrIG9yY2hlc3RyYXRpb24oRmlndXJlIDMpLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RDsiPlRoYXQgbWVhbiBpdKGvcyBhIGludGVybmFsIGludGVyZmFj ZSBpbiBvbmUgb3BlcmF0b3IgYW5kIGl0IGFjdHMgbm90IG9ubHkgdG8gaW1wbGVtZW50IHRoZSBj dXN0b21lciBmYWNpbmcgbW9kZWwgKGkuZS4gTDNTTSksYnV0IGFsc28gdG8gbWFpbnRhaW4sIG1v bml0b3IgYW5kIGRpYWdub3NlIHRoZQogZW5kIHRvIGVuZCBQRS1iYXNlZCBWUE4gc2VydmljZXMg Y3Jvc3NpbmcgbXVsdGlwbGUgdGVjaG5vbG9naWVzIGRlcGxveWVkIG5ldHdvcmsuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMUY0OTdEOyI+SXMgaXQgcmlnaHQ/IGFuZCBzaG91bGQgdGhpcyBpbnRl cmZhY2UgbmVlZCB0byBzdXBwb3J0IFZQTiBzZXJ2aWNlIHdoaWNoIG1heWJlIGNyb3NzIG11bHRp cGxlIG9wZXJhdG9ycz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij49PSZndDsgZ29v ZCBwb2ludCwgdGhlIGZ1dHVyZSBpbiB0aGUgbGluayBpcyBxdWl0ZSBoZWxwZnVsLCB0aGlzIHNo b3VsZCBiZSB1cGRhdGVkIGluIG5leHQgcmV2aXNpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij49PSZndDsgZm9yIHlvdXIgcXVlc3Rpb25zIGFib3V0IG11bHRp cGxlIG9wZXJhdG9ycywgdGhpcyBpcyBleGFjdGx5IHRoZSBpc3N1ZSByYWlzZWQgZHVyaW5nIHRo ZSBtZWV0aW5nLCBvcGVyYXRvciBhcmUgaW50ZXJjb25uZWN0ZWQgZWFjaCBvdGhlciB0aHJvdWdo IGZlZGVyYXRpb24sIHRoZSBlbmQKIHRvIGVuZCBzZXJ2aWNlIG1heSBnbyBhY3Jvc3MgbXVsdGlw bGUgb3BlcmF0b3JzJyBhY2Nlc3MgYW5kIGNvcmUgbmV0d29yay4gdGhhdCBpcyB0aGUgcmVhc29u IHdoeSB3ZSBkZWZpbmUgVlBOIHNlZ21lbnQgd2l0aGluIHRoZSBjb21wb3NlZCBWUE4uIHRoaXMg aGFzbid0IGJlZW4gY29uc2lkZXIgaW4gdGhlIGRvY3VtZW50IGJlZm9yZSwgYnV0IHRoZSBmbGV4 aWJpbGl0eSBvZiBjb21wb3NlZCBWUE4gZnJhbWV3b3JrIHNob3VsZCBiZSBpbmNsdWRlZC48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7Ij4yLkFjdHVhbGx5IEmhr20gbmV3IGd1eSBpbiBJRVRGLCBzbyBJoa9tIG5vdCBz dXJlIGlmIHRoZXJlIGFyZSBleGlzdGluZyB3b3JrcyBpbiBJRVRGIHdoaWNoIGNvdWxkIGluc3Ry dWN0IG9yIG1vZGVsaW5nIHRoZSBpbnRlcmZhY2UvRTJFLXZpZXcgdG8gbWFuYWdlIGEgbXVsdGlw bGUgdGVjaG5vbG9naWVzCiBjb21wb3NlZCBuZXR3b3JrLCB3aGljaCBJIGJlbGlldmUgdmVyeSBj b21tb24gaW4gb3BlcmF0b3Khr3MgZGVwbG95bWVudCB3aGlsZSBzdGlsbCBuZWVkIHRvIHByb3Zp ZGUgc2ltcGxlIEUyRSBzZXJ2aWNlIGV4cGVyaWVuY2UgdG8gdGhlaXIgY3VzdG9tZXJzLiBNYXli ZSB3ZSBjYW4gaW1wcm92ZSBzb21ldGhpbmcgaGVyZS4gU28gaWYgZXhwZXJ0cyBoZXJlIGhhdmUg bW9yZSBiYWNrZ3JvdW5kLCBwbGVhc2UgaGVscCBtZS4gVGhhbmtzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsiPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPj09 Jmd0OyBhbHRob3VnaCBpdCBpcyBpbXBvcnRhbnQsIGJ1dCBJIGRpZG4ndCBzZWUgYW55IGUyZSBl ZmZvcnQgb24gdGhlIG5ldHdvcmsgeWV0LiB0aGVyZSBpcyBhIHJlbGF0ZWQgd29yayBpbiBMM1NN IGluIGN1c3RvbWVyIHNlcnZpY2UgbGV2ZWwgYW5kIHNvbWUgZGVkaWNhdGVkIFZQTiBtb2RlbHMK IGluIEJFU1MuIHRoYXQncyB3aHkgSSByYWlzZSB0aGlzIHRvcGljLiBkZWZpbml0ZWx5IHdlbGNv bWUgYW55IGVmZm9ydCB0byBqb2luIHRoZSBmb2xsb3dpbmcgZGF0YSBtb2RlbCBkZXNpZ24gaWYg eW91IHJlYWxseSBoYXZlIGEgc3Ryb25nIGJhY2tncm91bmQgb24gaXQuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij4zLkFzIEkgdW5kZXJzdGFuZCB0aGlzIGludGVy ZmFjZS9tb2RlbCBzaG91bGQgYmUgaW50ZXJuYWwgaW4gb3BlcmF0b3JzLCBzbyBJoa9tIG5vdCBz dXJlIGlmIHRoZXJlIGFueSBvdGhlciBvcGVyYXRvcnMgYXJlIGludGVyZXN0ZWQgaXQgYW5kIG5l ZWQgYSBJRVRGIFJGQz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9w Pgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij49PSZndDsgSSBkaWQgaGVhciB0d28gYmlnIG9w ZXJhdG9ycyBzaG93ZWQgdGhlIGludGVyZXN0IGluIHRoaXMgdG9waWMsIGhvcGUgdGhleSBjYW4g am9pbiBhcyB3ZWxsIGluIG91ciBuZXh0IHJldmlzaW9uLiB0aGlzIG1heSByZWxhdGVkIHRvIG5l dHdvcmsgb3JjaGVzdHJhdG9yLCBPU1MvQlNTIGFuZAogZXZlbiBhbmFseXRpY3Mgc3lzdGVtIGZy b20gZGlmZmVyZW50IHZlbmRvcnMuIGEgc3RhbmRhcmQgbW9kZWwgd2lsbCBkZWZpbml0ZWx5ICZu YnNwO2hlcCB0aGUgZGl2ZXJzaXR5IGluIG9uZSBvcGVyYXRvcidzIHByb2R1Y3Rpb24gZW52aXJv bm1lbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+ PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij5CZXN0IHJl Z2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+ PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij5ERU5HIEh1 aTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPlRoYW5rcy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Ij48L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48 L3NwYW4+PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7Ij5S ZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJlY3hNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RDsiPlJpY2hhcmQgQ2hlbjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJlY3hNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PC9zcGFuPjwvcD4KPGRpdiBj bGFzcz0iZWN4TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXI7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPgo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPgo8L3NwYW4+PC9kaXY+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PGJyPgo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6u6rOxM+4uto7Y29sb3I6YmxhY2s7Ij67qs6qvLzK9dPQz965 q8u+PHNwYW4gbGFuZz0iRU4tVVMiPiBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4K PC9zcGFuPrXY1rejusnu29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHgo7o8c3BhbiBsYW5nPSJF Ti1VUyI+NTE4MTI5PGJyPgpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4KQmFudGlh biwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmE8YnI+CjxhIGhy ZWY9Imh0dHA6Ly93d3cuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaHVh d2VpLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Cjwvc3Bh bj48L3A+CjxkaXYgY2xhc3M9ImVjeE1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRl eHQtYWxpZ246Y2VudGVyOyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4KPGhyIHNpemU9IjIi IHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4KPC9zcGFuPjwvZGl2Pgo8cCBjbGFzcz0iZWN4 TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OruqzsTP uLraO2NvbG9yOmdyYXk7Ij6xvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32 z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+zxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+Cjwvc3Bhbj7WucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuy v7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0DxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+Cjwvc3Bhbj61xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+ zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhPHNwYW4gbGFuZz0iRU4tVVMiPjxicj4KPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmdyYXk7Ij5U aGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaAo8YnI+CmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBw ZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9m IHRoZQo8YnI+CmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVk aW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwKPGJyPgpkaXNjbG9zdXJl LCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgPGJyPgpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp dmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQo8YnI+ CnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyI+PC9zcGFuPjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8L2Rpdj4KPC9kaXY+Cjwv ZGl2Pgo8L2Rpdj4KPC9kaXY+CjwvZGl2PjwvZGl2PjwvZGl2PiAJCSAJICAgCQkgIDwvZGl2Pjwv Ym9keT4NCjwvaHRtbD4= --_00648d0f-6eba-4a14-ac9d-5059dfb176c1_-- From nobody Wed Oct 12 14:35:57 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DCE129673 for ; Wed, 12 Oct 2016 14:35:56 -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, 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 wKTU2WZw1MX1 for ; Wed, 12 Oct 2016 14:35:53 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2A8129498 for ; Wed, 12 Oct 2016 14:35:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5E0581F6F; Wed, 12 Oct 2016 21:35:52 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbEnYtSiJqjJ; Wed, 12 Oct 2016 21:35:52 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 90D09A6D; Wed, 12 Oct 2016 21:35:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Wed, 12 Oct 2016 17:35:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <638AC1BA-02A7-4346-8DC0-B7E762DA334D@deployingradius.com> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "opsawg@ietf.org" , draft-ietf-opsawg-tacacs-05@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 21:35:56 -0000 My $0.02 on the contents of the Security Considerations section. I'm = sure I've missed things. Please also comment if the suggestions here are wrong or unworkable. ---- 9. Security Considerations The protocol described in this document has been in widespread use since specified in "The Draft" (1998). However it does not meet modern security standards, and faces vulnerabilities with privacy and authenticity. This section describes issues with the TACACS+ specification, then the protocol, deployments, followed by recommendations for implementations. Because of the security issues with TACACS+, the authors intend to follow up this document with an enhanced specification of the protocol employing modern security mechanisms. 9.1 Security of The Draft Specification TACACS+ was originally specified in "The Draft" (1998). However, this draft is incomplete, and leaves key points unspecified. As a result, software authors have had to make implementation choices about what should, or should not, be done in certain situations. These implementation choices are somewhat constrained by ad hoc interoperability tests. That is, all TACACS+ clients and servers interoperate, so there is a rough consensus on how the protocol works. While the authors have made every effort to maintain compatibility, there is no guarantee, however, that this specification matches the behavior of current or historical implementations. We believe that any incompatibilites are due to modern security requirements. We therefore suggest that implementors should read this document, and verify that their implementations follow the security practices recommended here. 9.2 Security of The Protocol The major security issue with the TACACS+ protocol is the ad hoc "encryption" defined in Section 3.6. This "encryption" is more properly called "obfuscation", and has had no security analysis. That is, the security or insecurity of the protocol is entirely unknown. Attacks on cryptographic hashes are well known and are getting better with time, as discussed in [RFC4270]. The security of the TACACS+ protocol is dependent on MD5 [RFC1321], which has security issues as discussed in [RFC6151]. It is not known if the issues described in [RFC6151] apply to TACACS+. <> The choice of encrypting the body but not the packet header is unusual. The lack of security on the packet header means that an attacker can modify the header without detection. For example, a "session_id" can be replaced by an alternate one, which could allow an unprivileged administrator to "steal" the authorization from a session for a privileged administrator. An attacker could also update the "flags" field to indicate that one or the other end of a connection requires TAC_PLUS_UNENCRYPTED_FLAG, which could remove what little security is available. What little security that exists is dependent on implementations limiting access to known clients, and on the strenght of the secret key. Attacks who can guess the key or break the obfuscastion method can gain unrestricted and undetected access to all TACACS+ traffic. This access permits the attacker to execute any command on any system, leaving the attacker in complete control of the network. The negative side effects of such a successful attack cannot be overstated. 9.2.1 Security of Authentication Sessions There are a number of security issues with authentication sessions. As the sessions enable the exchange of clear-text passwords, an attacker capable of observing the unencrypted traffic or breakign the encrypted traffic, can gain complete network access. Similarly, MSCHAPv1 and MS-CHAPv2 offer little additional security, while ARAP is insecure and MUST NOT be used. As of the publication of this document, there has been no similar attacks on the CHAP protocol. Section 4.4.3 permits the redirection of a session to another server via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this process, the secret key for a new server can be sent to the client. This public exchange of secret keys means that once one session is broken, it may be possible to leverage that attack to attacking connections to other servers. Section 9.4, below, has recommendations for securing this portion of the protocol. 9.2.2 Security of Authorization Sessions The primary issue with authorization sessions is that unauthenticated authorization is allowed. Almost as bad, authorization is permitted where authentication was done by a third party, such as with TAC_PLUS_AUTHEN_METH_KRB5. This third party authentication is based entirely on the client claiming that the user has been authenticated, and the server trusting that request. This practice is entirely insecure. There is also no way to cryptographically tie an authorization session to a particular authentication session. That is, when the client indicates "authen_method" in the packet header, the authentication and authorization sessions are tied together implicitly by the contents of the other fields, such as "use", "port", "rem_addr", etc. <> The specification allows for the exchange of attribute-value pairs. While a few such attributes are defined here, the protocol is extensible, and vendors can define their own attributes. There is no registry for such attributes, and in the absence of a published specification, no way for a client or server to know the meaning of a new attribute. As a result, vendors SHOULD NOT define new attribute-value pairs, unless such pairs are used only to communicate between client and server implementations both written by the same vendor. The "cmd" and "cmd-arg" attributes define shell commands and arguments, but does not specify what these are. The specific commands, therefore, are undefined. 9.2.3 Security of Accounting Sessions The security considerations for accounting sessions are largely the same as for authorization sessions. This section describes additional issues specific to accounting sessions. There is no way in TACACS+ to signal that accounting is required. There is no way for a server to signal a client how often accounting is required. The accounting packets are received solely at the clients discretion. Adding such functionality would assist with auditing of user actions. The "task_id" field is defined only for accounting packets, and not for authentication or authorization packets. As such, it is difficult to correlate accounting data with a previous authentication or authorization request. <> 9.4 Security of Deployments Due to the above concerns with the protocol, it is critical that it be deployed in a secure manner. Systems using TACACS+ MUST be configured so that TACACS+ traffic is secured. Any user or service who is not interacting with the TACACS+ protocol MUST NOT be able to observe TACACS+ traffic, even when TACACS+ "encryption" is used. When used inside of enterprises, TACACS+ traffic MUST be sent over management networks. When used on the wider internet, TACACS+ traffic MUST be secured via a modern security protocol such as TLS or IPSec. As this specification describes the historic protocol, recommendations on TLS and IPSec parameters are outside of the scope of this document. 9.4 Recommendations for Implementations The following recommendations are for clients and servers which implement the TACACS+ protocol. These recommendations describe end user interaction or user interface design. While not part of the protocol itself, good designs can prevent insecure configurations. Clients and servers MUST default to rejecting all connections which have the TAC_PLUS_UNENCRYPTED_FLAG set. Clients and servers MAY permit such connections when a debugging or test flag is set. Clients and servers MUST NOT run with this flag set in normal environments. Similarly, the default for both clients and servers MUST be to require a secret key when configuring a new server or client. The secret key MUST NOT be empty, and SHOULD be at least eight (8) characters in length. Clients and servers SHOULD permit the user of keys unique to each server or client which they are connecting to. They SHOULD warn the administrator if a secret key is re-used. Documentation for implementations SHOULD recommend the use of strong secret keys. Servers should maintain list of known clients, and reject connections which originate from other systems. Servers SHOULD NOT permit the configuration of wildcard clients. e.g. clients which map to a network range. Where a client or server detects that the secret key is incorrect, it SHOULD terminate the underlying TCP connection, and log a message to the system administrator. There is no good reason to keep a connection open when the systems are unable to communicate in a meaningful fashion. Implementions MUST default to using TAC_PLUS_AUTHEN_TYPE_CHAP for authentication. We recognize, however, that this authentication method is incompatible with many password storage systems. As a result, other authentication methods are still in the protocol, and can be used so long as administrators recognize the security issues with their use. Clients MUST default to treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as if TAC_PLUS_AUTHEN_STATUS_FAIL had been received instead. Clients SHOULD allow administrators to explicitly enable the TAC_PLUS_AUTHEN_STATUS_FOLLOW functionality. When the functionality is enabled, clients SHOULD permit administrators to specify ranges of addresses, and/or sets of hosts, along with corresponding secret keys, for which redirection will be permitted. Clients SHOULD ignore redirects to hosts which are outside of the pre-configured range or list. Clients SHOULD ignore any key provided via TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a preconfigured key for that host. For authorization, servers SHOULD default to requiring TAC_PLUS_AUTHEN_METH_TACACSPLUS. Servers SHOULD track authentication sessions via methods "to be described" in Section 5.1. Where a server receives an unknown attribute-value pair, it SHOULD reply with TAC_PLUS_AUTHOR_STATUS_FAIL. Where a server receives an unrecognized values in authorization attributes such as "cmd", "cmd-arg", "acl", etc., the server SHOULD reply with TAC_PLUS_AUTHOR_STATUS_FAIL. When a client receives an unknown authorization attribute, it SHOULD behave as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. From nobody Thu Oct 13 12:14:56 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB0D12960C; Thu, 13 Oct 2016 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 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=-2.996, 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 9Ku5VWBiBJeJ; Thu, 13 Oct 2016 12:14:50 -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 99135129461; Thu, 13 Oct 2016 12:14:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTD20678; Thu, 13 Oct 2016 19:14:46 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Oct 2016 20:14:45 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 13 Oct 2016 12:14:34 -0700 From: Lucy yong To: Hui Deng , "Chenrui (Richard)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSJJ18MZ4lC1eKjUqffVl88R3hraCmrozA Date: Thu, 13 Oct 2016 19:14:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.253] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572E0E5Edfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.57FFDD27.0046, 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: 1f18fdd46ef98e65785a68e7870b2b79 Archived-At: Cc: "opsawg-chairs@ietf.org" Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 19:14:54 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D572E0E5Edfweml501mbb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSHVpIGFuZCBSdWksDQoNClRoZSBkcmFmdCBpbnRyb2R1Y3Rpb24gc3RhcnRzIHRoYXQgSVNQ cyBoYXZlIGludGVyZXN0IG9uIHByb3ZpZGluZyBQcm92aWRlciBFZGdlIChQRSkgYmFzZWQgdmly dHVhbCBwcml2YXRlIG5ldHdvcmsgKFZQTikgc2VydmljZSBhbmQgbmFtZXMgaXQgYXMgY29tcG9z ZWQgVlBOIHNlcnZpY2UgYW5kIGludGVuZHMgdG8gc3BlY2lmeSB0aGUgc2VydmljZSBtb2RlbCBy ZXF1aXJlbWVudHMgZm9yIHRoZSBjb21wb3NlZCBWUE4uIFRoZW4gaXQgc3RhdGVzIHRoYXQgdGhp cyBzZXJ2aWNlIG1vZGVsIGlzIGZyb20gb3BlcmF0b3IgcGVyc3BlY3RpdmUuDQoNCk15IGNvbW1l bnRzIGFuZCBzdWdnZXN0aW9uczoNCg0KDQqhpCAgICAgICAgIElzIHRoaXMgYSBicmFuZCBuZXcg VlBOIHNlcnZpY2Ugb2ZmZXJlZCBieSBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVycyBvciBhIHVz ZSBjYXNlIGZvciBleGlzdGluZyBWUE4gc2VydmljZXMgc3BlY2lmaWVkIGluIFtSRkM0MzY0XSBb UkZDNjc0Ml1bUkZDNzQzMl0/IElmIHRoaXMgaXMgYSBuZXcgc2VydmljZSwgcGxlYXNlIG1ha2Ug dGhhdCB2ZXJ5IGNsZWFyIGluIHRoZSBiZWdpbm5pbmcgYW5kIGRlc2NyaWJlIHdoYXQgaXMgdGhl IG5ldyBzZXJ2aWNlLCBzZXJ2aWNlIGFyY2hpdGVjdHVyZSwgYW5kIGFyY2hpdGVjdHVyZSBjb21w b25lbnRzLiBJZiB0aGlzIGlzIGEgdXNlIGNhc2UgZm9yIGV4aXN0aW5nIFZQTiBzZXJ2aWNlczsg cGxlYXNlIGRvIG5vdCBjYWxsIGl0IGNvbXBvc2VkIFZQTiBzZXJ2aWNlIChtYWtlIGEgbG90IG9m IGNvbmZ1c2lvbnMuKQ0KDQqhpCAgICAgICAgIEFzc3VtZSB0aGlzIGlzIGZvciBleGlzdGluZyBW UE5zIGFuZCBkcmFmdCB3YW50cyB0byBzcGVjaWZ5IHRoZSBvcGVyYXRvciB2aWV3IG9mIGUtMi1l IFZQTnMgdGhhdCBtYXkgYWNyb3NzIG11bHRpcGxlIG9wZXJhdG9yIGRvbWFpbnMuIFN1Z2dlc3Rz IHRvIHN0YXJ0IHdpdGggZXhpc3RpbmcgVlBOIHNlcnZpY2UgYXJjaGl0ZWN0dXJlIHZpZXcgYW5k IGNvbXBvbmVudHM6IENFLCBQRSwgcHJvdmlkZXIgYmFja2JvbmUgbmV0d29ya3MsIEFDIGV0Yy4g YW5kIGV4cGxhaW4gaG93IG9wZXJhdG9yIG1heSB1c2UgbXVsdGlwbGUgbmV0d29yayBkb21haW5z IHRvIGFjaGlldmUgaXQuIEZvciBleGFtcGxlcywgUEVzIHRoYXQgY3VzdG9tZXIgc2l0ZXMgYXR0 YWNoIHRvIG1heSBleGlzdCBpbiBkaWZmZXJlbnQgQVNlczsgIHRoZSBBQyBiZXR3ZWVuIENFLVBF IG1heSBiZSBhY3Jvc3MgYW4gYWNjZXNzIG5ldHdvcmssIGV0Yy4NCg0KoaQgICAgICAgICBFeGlz dGluZyBWUE4gc2VydmljZSBhY3Jvc3MgbXVsdGlwbGUgbmV0d29ya3MgYXJlIG5vdCBuZXcgYW5k IGN1cnJlbnQgc29sdXRpb25zIHN1cHBvcnQgdGhhdC4NCg0KoaQgICAgICAgICBUZXh0IKGwUHJv dmlkZXIgRWRnZSAoUEUgYmFzZWQgdmlydHVhbCBwcml2YXRlIG5ldHdvcmsgKFZQTiBzZXJ2aWNl cywgaW4gd2hpY2ggdGhlIHR1bm5lbCBlbmRwb2ludHMgYXJlIHRoZSBQRSBkZXZpY2VzobEgaXMg dmVyeSBjb25mdXNlLiBXaWxsIHRoZSB0dW5uZWwgaXMgYmV0d2VlbiBQRS1QRSBvciBQRS1DRT8g V2lsbCB0aGlzIHR1bm5lbCBpcyBkaWZmZXJlbnQgZnJvbSBjdXJyZW50IHR1bm5lbCB0ZWNobmlx dWVzIGluIFtSRkM0MzY0XSBbUkZDNjc0Ml1bUkZDNzQzMl0/DQoNCqGkICAgICAgICAgRXhpc3Rp bmcgVlBOIHNlcnZpY2UgUEUgYW5kIENFIGhhdmUgaXRzIHJvbGUuIFRleHQ6IKGwQ0UgZGV2aWNl IGRvIG5vdCBuZWVkIHRvIGhhdmUgYW55IHNwZWNpYWwgVlBOIGNhcGFiaWxpdHmhsSBpcyBjb25m dXNlZCB0b28uDQoNCqGkICAgICAgICAgV2hlbiBhbiBvcGVyYXRvciBnZXRzIGN1c3RvbWVyIFZQ TiBzZXJ2aWNlIHJlcXVlc3QgdGhhdCBpcyBhbiBlMmUgc2VydmljZSBkZXNjcmlwdGlvbiAoZHJh ZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwpLCBoZSB3aWxsIGRlc2lnbiBpbmRpdmlk dWFsIHNlZ21lbnRzIChDRS1QRSBhbmQgUEUtUEUpIHRvIG1lZXQgdGhlIHJlcXVlc3QuIFRoZSBy ZXN1bHQgbWF5IG1lYW4gdGhhdCB0aGUgVlBOIGlzIGltcGxlbWVudGVkIGFjcm9zcyBzZXZlcmFs IGRvbWFpbnMuDQoNCqGkICAgICAgICAgV2hhdCB2YWx1ZXMgdGhhdCBhIGZsYXQgb3BlcmF0b3Ig VlBOIHNlcnZpY2UgbW9kZWwgcHJvdmlkZXM/ICB0d28gc2VnbWVudCBWUE5zIG1heSBub3QgZXZl biBhdCB0aGUgc2FtZSBsYXllcnMuIElmIG9uZSBzZWdtZW50IFZQTiBqdXN0IHByb3ZpZGVzIGEg dHJhbnNpdCBsaW5rIG9yIGFjY2VzcyBsaW5rIHRvIHRoZSBWUE4gc2VydmljZSwgZG8gb3BlcmF0 b3IgbmVlZCBhIGhpZXJhcmNoaWNhbCBvcGVyYXRvciBWUE4gc2VydmljZSBtb2RlbCBvciBhIGZs YXQgb25lPw0KDQqhpCAgICAgICAgICBmaWd1cmUgaW4gcGFnZSA1IHZlcnkgY29uZnVzaW9uLiBJ ZiB0aGlzIGlzIGZvciBleGlzdGluZyBWUE4gc2VydmljZSwgcGxlYXNlIHJlcGxhY2UgobBDb21w b3NlZCBWUE6hsSB3aXRoIKGwTDNWUE6hsSAob3IgobBMMlZQTqGxKSwgYW5kIHJlcGxhY2UgQVAg d2l0aCBBQy4NCg0KoaQgICAgICAgICBJZiB0aGlzIGlzIGEgbmV3IFZQTiBzZXJ2aWNlLCBwbGVh c2UgZGVmaW5lIHdoYXQgaXMgdGhlIGNvbXBvc2VkIFZQTiBzZXJ2aWNlIGFuZCB0aGUgYXJjaGl0 ZWN0dXJlLiBUaGVuIGNsYXJpZnkgaWYgY3VycmVudCBJRVRGIGhhcyBzb2x1dGlvbnMgZm9yIHRo aXMgc2VydmljZS4NCg0KUmVnYXJkcywNCkx1Y3kNCg0KDQoNCkZyb206IE9QU0FXRyBbbWFpbHRv Om9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHVpIERlbmcNClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAxMiwgMjAxNiAxMDoyOCBBTQ0KVG86IENoZW5ydWkgKFJpY2hhcmQp OyBvcHNhd2dAaWV0Zi5vcmcNCkNjOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW09QU0FXR10gPz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJl bWVudHMtMDEudHh0DQoNCkhpIFJpY2hhcmQsDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHBvaW50LCBp biBvcmRlciB0byBtZWV0IHRob3NlIG9wZXJhdG9ycyBleHBlY3RhdGlvbiwgdGhlIGRyYWZ0IG1h eSBuZWVkIHRvIGJlIHVwZGF0ZWQgYW5kIHJlZmxlY3QgdGhhdCBhcmNoaXRlY3R1cmUuDQoNClJl Z2FyZGluZyB0byBzb2x1dGlvbiwgdGhhdCB3aWxsIGJlIGdyZWF0LCB0aGFua3MgYSBsb3QgZm9y IHlvdXIgY29udHJpYnV0aW9uIHRvIElFVEYgaWYgdGhlcmUgaXMgYW55IHByb29mIG9mIGNvbmNl cHQgdG8gdGhpcy4NCg0KdGhhbmtzIGEgbG90IGZvciB5b3VyIHN1Z2dlc3Rpb24NCg0KQmVzdCBy ZWdhcmRzLA0KDQpERU5HIEh1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IGNoZW5ydWlAaHVhd2VpLmNvbTxtYWlsdG86Y2hlbnJ1aUBodWF3ZWkuY29tPg0KVG86IGRl bmdodWkwMkBob3RtYWlsLmNvbTxtYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tPjsgb3BzYXdn QGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpDQzogb3BzYXdnLWNoYWlyc0BpZXRm Lm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtPUFNB V0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0 DQpEYXRlOiBUdWUsIDExIE9jdCAyMDE2IDAyOjI3OjE0ICswMDAwDQpIaSBIdWksDQoNClRoYW5r cyBmb3IgdGhlc2UgY2xhcmlmaWNhdGlvbnMuIE1heWJlIHdlIGNhbiB0YWxrIGFib3V0IGl0IG1v cmUgaW4gbmV4dCBtZWV0aW5nIGFuZCB3ZSBjYW4gcHJvdmlkZSBhIGluaXRpYWwgc29sdXRpb24g YXJvdW5kIHRoZXNlIGlzc3Vlcy4NCg0KQlRXLCBpZiB3ZSB0YWxraW5nIGFib3V0IGZlZGVyYXRp b24gdXNlZCBpbiBtdWx0aXBsZSBvcGVyYXRvcnMgc2NlbmFyaW9zLCBJIHN1Z2dlc3QgdGhhdCB0 aGVyZSBzaG91bGQgYmUgZWFzdC13ZXN0IGludGVyZmFjZSBiZXR3ZWVuIHBlZXIgb3JjaGVzdHJh dGlvbiBzeXN0ZW0gaW4gdGhlc2Ugb3BlcmF0b3JzLiBUaGF0IGVhc2Utd2VzdCBpbnRlcmZhY2Ug aXMgZGlmZmVyZW50IHdpdGggaW50ZXJuYWwgRTJFIHNlcnZpY2UgYWN0aXZhdGlvbiBpbnRlcmZh Y2UgZm9yIHNvbWUgc3BlY2lhbCByZXF1aXJlbWVudCBiZXR3ZWVuIG9wZXJhdG9ycywgc3VjaCBh cyBzZWN1cml0eSwgcmVzb3VyY2UgdmlzdWFsaXphdGlvbixldGMuDQoNClRoYW5rcywNClJpY2hh cmQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavL viBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uq zqq7+bXYINPKseCjujUxODEyOQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRp YW4sIExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8v d3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQqxvtPKvP68 sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2 tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T 2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6 tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6EN ClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0 aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBi dXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVj dGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRl ZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGlt bWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCreivP7IyzogSHVpIERlbmcgW21haWx0bzpkZW5n aHVpMDJAaG90bWFpbC5jb21dDQq3osvNyrG85DogMjAxNsTqMTDUwjEwyNUgMjM6MTUNCsrVvP7I yzogQ2hlbnJ1aSAoUmljaGFyZCk7IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYu b3JnPg0Ks63LzTogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0Bp ZXRmLm9yZz4NCtb3zOI6IFJFOiBbT1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12 cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KDQoNCkhpIFJpY2hhcmQsDQoNClRoYW5rcyBhIGxv dCBmb3IgeW91ciBjb21tZW50cywgSSByZWNhbGxlZCB0aGF0IG90aGVyIHR3byBvcGVyYXRvcnMg ZHVyaW5nIGxhc3QgdGltZSBmMmYgbWVldGluZyBoYWQgbWFkZSBzb21lIGNvbW1lbnRzIGFib3V0 IGZlZGVyYXRpb24gaXNzdWUsIGhvcGUgdGhleSBjYW4gZWxhYm9yYXRlIG1vcmUgZGV0YWlsIGNv bW1lbnRzIGhlcmUgYXMgd2VsbCwgaW5saW5lIHdpdGggPT0+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogY2hlbnJ1aUBodWF3ZWkuY29tPG1haWx0bzpjaGVucnVpQGh1 YXdlaS5jb20+DQpUbzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBk ZW5naHVpMDJAaG90bWFpbC5jb208bWFpbHRvOmRlbmdodWkwMkBob3RtYWlsLmNvbT4NCkNDOiBv cHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1 aXJlbWVudHMtMDEudHh0DQpEYXRlOiBTdW4sIDkgT2N0IDIwMTYgMDM6MzU6NDYgKzAwMDANCkhp IEh1aSBhbmQgYWxsLA0KDQpXaGVuIEkgd2VudCB0aHJvdWdoIHRoZSBkb2N1bWVudHMgb2YgSUVU RiM5NixJIG5vdGljZWQgdGhhdCB0aGlzIGRyYWZ0IGhhcyByYWlzZWQgYSBpbnRlcmVzdGluZyBy ZXF1aXJlbWVudCBpbiBDaGluYSBNb2JpbGUgb2YgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNlIHRv IGEgbXVsdGlwbGUgVlBOcyBjb21wb3NlZCBpbmZyYXN0cnVjdHVyZSwgc3VjaCBhcyBMMitMMyBu ZXR3b3JrLiBTbyB0aGUgaW50ZXJmYWNlIGNvdWxkIG1ha2UgdGhlIHNlcnZpY2UgZnVsZmlsbG1l bnQgYW5kIG1hbmFnZW1lbnQgbW9yZSBlYXN5Lg0KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodD8N Cg0KPT0+IFllcywgY3VycmVudCBleGlzdGluZyBMM1NNIGFyZSBtb3N0bHkgdGFsa2luZyBhYm91 dCBjdXN0b21lciBmYWNpbmcgc2VydmljZSBtb2RlbC4NCnRoaXMgcmVxdWlyZW1lbnQgZXhwZWN0 cyB0byBoZWxwIG9wZXJhdG9ycyB3aXRoIGxhcmdlIHNjYWxlIHRvIG1hbmdlIHRoZSB1bmRlcmxh eSBuZXR3b3JrIHdpdGggYSBnbG9iYWwgdmlldy4gIChoZXJlIGNvdWxkIGJlIGEgbXVsdGlwbGUg b3BlcmF0b3JzLCB0aGF0IGlzIHJlbGF0ZWQgdG8gZmVkZXJhdGlvbikgYW4gZW50ZXJwcmlzZSBj dXN0b21lciBtYXkgc2ltcGx5IHJlcXVlc3QgYSBMMyBWUE4gc2VydmljZSwgYnV0IG9wZXJhdG9y IGhhcyB0byBwcm92aXNpb24gYW5kIG1hbmdlIHRoZSBlbmQgdG8gZW5kIHVuZGVybGF5IG5ldHdv cmsgY29uc3RydWN0ZWQgd2l0aCBtdWx0aXBsZSBBU2VzIGFuZCB0ZWNobmlxdWVzLCBhbmQgZnVy dGhlciBhc3N1cmUgdGhlIHNlcnZpY2UuIHRoaXMgaXMgdGhlIGtleSBpc3N1ZSBmb3IgdG9kYXkn cyBvcGVyYXRvcnMuDQoNCkkgZG8gYmVsaWV2ZSB0aGlzIGludGVyZmFjZSBhbmQgaXRzIG1vZGVs IGFyZSBpbmRlZWQgaGVscGZ1bCBmb3Igb3BlcmF0b3JzIHRvIHNpbXBsaWZ5IG9wZXJhdGlvbnMg YW5kIG1hbmFnZW1lbnQuDQpBbmQgSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zIG5lZWQgdG8g YmUgZGlzY3Vzc2VkIGFuZCBhbGlnbmVkIHdpdGggeW91IGFuZCBleHBlcnRzIGluIGVtYWlsIHRo cmVhZC4NCg0KMS5XaGlsZSByZWZlcnJpbmcgdG8gYW5vdGhlciBkcmFmdCBhdCBzYW1lIG1lZXRp bmcgPDxzZXJ2aWNlIG1vZGVsIGV4cGxhaW5lZD4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMy50eHQpLA0KSSBiZWxp ZXZlIHRoZSBhYm92ZSBFMkUgZGVwbG95bWVudCBpbnRlcmZhY2Ugc2hvdWxkIGJlIHBvc2l0aW9u IGJldHdlZW4gc2VydmljZSBvcmNoZXN0cmF0aW9uIGFuZCAgbmV0d29yayBvcmNoZXN0cmF0aW9u KEZpZ3VyZSAzKS4NClRoYXQgbWVhbiBpdKGvcyBhIGludGVybmFsIGludGVyZmFjZSBpbiBvbmUg b3BlcmF0b3IgYW5kIGl0IGFjdHMgbm90IG9ubHkgdG8gaW1wbGVtZW50IHRoZSBjdXN0b21lciBm YWNpbmcgbW9kZWwgKGkuZS4gTDNTTSksYnV0IGFsc28gdG8gbWFpbnRhaW4sIG1vbml0b3IgYW5k IGRpYWdub3NlIHRoZSBlbmQgdG8gZW5kIFBFLWJhc2VkIFZQTiBzZXJ2aWNlcyBjcm9zc2luZyBt dWx0aXBsZSB0ZWNobm9sb2dpZXMgZGVwbG95ZWQgbmV0d29yay4NCklzIGl0IHJpZ2h0PyBhbmQg c2hvdWxkIHRoaXMgaW50ZXJmYWNlIG5lZWQgdG8gc3VwcG9ydCBWUE4gc2VydmljZSB3aGljaCBt YXliZSBjcm9zcyBtdWx0aXBsZSBvcGVyYXRvcnM/DQo9PT4gZ29vZCBwb2ludCwgdGhlIGZ1dHVy ZSBpbiB0aGUgbGluayBpcyBxdWl0ZSBoZWxwZnVsLCB0aGlzIHNob3VsZCBiZSB1cGRhdGVkIGlu IG5leHQgcmV2aXNpb24uDQoNCj09PiBmb3IgeW91ciBxdWVzdGlvbnMgYWJvdXQgbXVsdGlwbGUg b3BlcmF0b3JzLCB0aGlzIGlzIGV4YWN0bHkgdGhlIGlzc3VlIHJhaXNlZCBkdXJpbmcgdGhlIG1l ZXRpbmcsIG9wZXJhdG9yIGFyZSBpbnRlcmNvbm5lY3RlZCBlYWNoIG90aGVyIHRocm91Z2ggZmVk ZXJhdGlvbiwgdGhlIGVuZCB0byBlbmQgc2VydmljZSBtYXkgZ28gYWNyb3NzIG11bHRpcGxlIG9w ZXJhdG9ycycgYWNjZXNzIGFuZCBjb3JlIG5ldHdvcmsuIHRoYXQgaXMgdGhlIHJlYXNvbiB3aHkg d2UgZGVmaW5lIFZQTiBzZWdtZW50IHdpdGhpbiB0aGUgY29tcG9zZWQgVlBOLiB0aGlzIGhhc24n dCBiZWVuIGNvbnNpZGVyIGluIHRoZSBkb2N1bWVudCBiZWZvcmUsIGJ1dCB0aGUgZmxleGliaWxp dHkgb2YgY29tcG9zZWQgVlBOIGZyYW1ld29yayBzaG91bGQgYmUgaW5jbHVkZWQuDQoNCjIuQWN0 dWFsbHkgSaGvbSBuZXcgZ3V5IGluIElFVEYsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhlcmUgYXJl IGV4aXN0aW5nIHdvcmtzIGluIElFVEYgd2hpY2ggY291bGQgaW5zdHJ1Y3Qgb3IgbW9kZWxpbmcg dGhlIGludGVyZmFjZS9FMkUtdmlldyB0byBtYW5hZ2UgYSBtdWx0aXBsZSB0ZWNobm9sb2dpZXMg Y29tcG9zZWQgbmV0d29yaywgd2hpY2ggSSBiZWxpZXZlIHZlcnkgY29tbW9uIGluIG9wZXJhdG9y oa9zIGRlcGxveW1lbnQgd2hpbGUgc3RpbGwgbmVlZCB0byBwcm92aWRlIHNpbXBsZSBFMkUgc2Vy dmljZSBleHBlcmllbmNlIHRvIHRoZWlyIGN1c3RvbWVycy4gTWF5YmUgd2UgY2FuIGltcHJvdmUg c29tZXRoaW5nIGhlcmUuIFNvIGlmIGV4cGVydHMgaGVyZSBoYXZlIG1vcmUgYmFja2dyb3VuZCwg cGxlYXNlIGhlbHAgbWUuIFRoYW5rcy4NCg0KPT0+IGFsdGhvdWdoIGl0IGlzIGltcG9ydGFudCwg YnV0IEkgZGlkbid0IHNlZSBhbnkgZTJlIGVmZm9ydCBvbiB0aGUgbmV0d29yayB5ZXQuIHRoZXJl IGlzIGEgcmVsYXRlZCB3b3JrIGluIEwzU00gaW4gY3VzdG9tZXIgc2VydmljZSBsZXZlbCBhbmQg c29tZSBkZWRpY2F0ZWQgVlBOIG1vZGVscyBpbiBCRVNTLiB0aGF0J3Mgd2h5IEkgcmFpc2UgdGhp cyB0b3BpYy4gZGVmaW5pdGVseSB3ZWxjb21lIGFueSBlZmZvcnQgdG8gam9pbiB0aGUgZm9sbG93 aW5nIGRhdGEgbW9kZWwgZGVzaWduIGlmIHlvdSByZWFsbHkgaGF2ZSBhIHN0cm9uZyBiYWNrZ3Jv dW5kIG9uIGl0Lg0KDQozLkFzIEkgdW5kZXJzdGFuZCB0aGlzIGludGVyZmFjZS9tb2RlbCBzaG91 bGQgYmUgaW50ZXJuYWwgaW4gb3BlcmF0b3JzLCBzbyBJoa9tIG5vdCBzdXJlIGlmIHRoZXJlIGFu eSBvdGhlciBvcGVyYXRvcnMgYXJlIGludGVyZXN0ZWQgaXQgYW5kIG5lZWQgYSBJRVRGIFJGQz8N Cg0KPT0+IEkgZGlkIGhlYXIgdHdvIGJpZyBvcGVyYXRvcnMgc2hvd2VkIHRoZSBpbnRlcmVzdCBp biB0aGlzIHRvcGljLCBob3BlIHRoZXkgY2FuIGpvaW4gYXMgd2VsbCBpbiBvdXIgbmV4dCByZXZp c2lvbi4gdGhpcyBtYXkgcmVsYXRlZCB0byBuZXR3b3JrIG9yY2hlc3RyYXRvciwgT1NTL0JTUyBh bmQgZXZlbiBhbmFseXRpY3Mgc3lzdGVtIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIGEgc3RhbmRh cmQgbW9kZWwgd2lsbCBkZWZpbml0ZWx5ICBoZXAgdGhlIGRpdmVyc2l0eSBpbiBvbmUgb3BlcmF0 b3IncyBwcm9kdWN0aW9uIGVudmlyb25tZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRFTkcgSHVp DQpUaGFua3MuDQoNClJlZ2FyZHMsDQpSaWNoYXJkIENoZW4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENv LiwgTHRkLg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXYINPKseCjujUxODEyOQ0KSHVh d2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0LFNo ZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD 3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrO xuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sah orvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXn u7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0 YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdo aWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRy ZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFs IG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikg YnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hp Yml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQh DQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D572E0E5Edfweml501mbb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hui and Rui,

 

The draft introduction= starts that ISPs have interest on providing Provider Edge (PE) based virtu= al private network (VPN) service and names it as composed VPN service and intends to specify the service model requirements for the = composed VPN. Then it states that this service model is from operator persp= ective.

 

My comments and sugges= tions:

 

=A1=A4      &= nbsp;  Is this a bran= d new VPN service offered by Internet Service Providers or a use case for e= xisting VPN services specified in [RFC4364] [RFC6742][RFC7432]? If this is a new service, please make that very clear in the beginning and= describe what is the new service, service architecture, and architecture c= omponents. If this is a use case for existing VPN services; please do not c= all it composed VPN service (make a lot of confusions.)

=A1=A4      &= nbsp;  Assume this is= for existing VPNs and draft wants to specify the operator view of e-2-e VP= Ns that may across multiple operator domains. Suggests to start with existing VPN service architecture view and components: CE, P= E, provider backbone networks, AC etc. and explain how operator may use mul= tiple network domains to achieve it. For examples, PEs that customer sites = attach to may exist in different ASes;  the AC between CE-PE may be across an access network, etc.

=A1=A4      &= nbsp;  Existing VPN s= ervice across multiple networks are not new and current solutions support t= hat.

=A1=A4      &= nbsp;  Text =A1=B0Pro= vider Edge (PE based virtual private network (VPN services, in which the tu= nnel endpoints are the PE devices=A1=B1 is very confuse. Will the tunnel is between PE-PE or PE-CE? Will this tunnel is different from curre= nt tunnel techniques in [RFC4364] [RFC6742][RFC7432]?=

=A1=A4      &= nbsp;  Existing VPN s= ervice PE and CE have its role. Text: =A1=B0CE device do not need to have a= ny special VPN capability=A1=B1 is confused too.

=A1=A4      &= nbsp;  When an operat= or gets customer VPN service request that is an e2e service description (dr= aft-ietf-l3sm-l3vpn-service-model), he will design individual segments (CE-PE and PE-PE) to meet the request. The result may mean that t= he VPN is implemented across several domains.   

=A1=A4      &= nbsp;  What values th= at a flat operator VPN service model provides?  two segment VPNs may n= ot even at the same layers. If one segment VPN just provides a transit link or access link to the VPN service, do operator need a hiera= rchical operator VPN service model or a flat one?

=A1=A4      &= nbsp;   figure i= n page 5 very confusion. If this is for existing VPN service, please replac= e =A1=B0Composed VPN=A1=B1 with =A1=B0L3VPN=A1=B1 (or =A1=B0L2VPN=A1=B1), a= nd replace AP with AC.

=A1=A4      &= nbsp;  If this is a n= ew VPN service, please define what is the composed VPN service and the arch= itecture. Then clarify if current IETF has solutions for this service.

 

Regards,

Lucy

 

 

 

From: OPSAWG [= mailto:opsawg-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Wednesday, October 12, 2016 10:28 AM
To: Chenrui (Richard); opsawg@ietf.org
Cc: opsawg-chairs@ietf.org
Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Richard,

 

I agree with your point, in order to meet those operator= s expectation, the draft may need to be updated and reflect that architectu= re.

 

Regarding to solution, that will be great, thanks a lot = for your contribution to IETF if there is any proof of concept to this.

 

thanks a lot for your suggestion

 

Best regards,

 

DENG Hui

From: chenrui@huawei.com
To: denghui02@hotmail.com; opsawg@ietf.org
CC: opsawg-chairs@ietf.org Subject: =B4=F0=B8=B4: [OPSAWG] draft-deng-o= psawg-composed-vpn-sm-requirements-01.txt
Date: Tue, 11 Oct 2016 02:27:14 +0000

Hi Hui,

 

Thanks for these clarific= ations. Maybe we can talk about it more in next meeting and we can provide = a initial solution around these issues.

 

BTW, if we talking about fe= deration used in multiple operators scenarios, I suggest that there should = be east-west interface between peer orchestration system in these operators= . That ease-west interface is different with internal E2E service activation interface for some special requirement bet= ween operators, such as security, resource visualization,etc.=

 

Thanks,

Richard

 


=BB=AA= =CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
=B5=D8= =D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB= =F9=B5=D8 =D3=CA= =B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3= =CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4= =B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3= =E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3= =BD=FB
=D6=B9=C8= =CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8= =B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0= =B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE= =D6=D0
=B5=C4=D0= =C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC= =C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC= =FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

= =B7=A2=BC=FE=C8=CB: Hui = Deng [mailto:denghui02@hotmail.com= ]
=B7=A2=CB=CD=CA= =B1=BC=E4: 2016=C4=EA10<= /span>=D4=C210=C8=D5= 23:15
=CA=D5=BC=FE=C8= =CB: Chenrui (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG] draft-deng-ops= awg-composed-vpn-sm-requirements-01.txt

 


Hi Richard,

 

Thanks a lot for your comments, I recalled that other tw= o operators during last time f2f meeting had made some comments about feder= ation issue, hope they can elaborate more detail comments here as well, inline with =3D=3D>

From: chenrui@huawei.com
To: opsawg@ietf.org; denghui02@hotmail.com
CC: opsawg-chairs@ietf.org Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=
Date: Sun, 9 Oct 2016 03:35:46 +0000

Hi Hui and all,

 

When I went through the documents of IETF#96,I noticed that t= his draft has raised a interesting requirement in China Mobile of E2E deplo= yment interface to a multiple VPNs composed infrastructure, such as L2+L3 network. So the interface could make the service fulfill= ment and management more easy.

Is my understanding right?

 

=3D=3D> Yes, current existing L3SM are mostly talking abou= t customer facing service model.

this requirement expects to help operators with large scale t= o mange the underlay network with a global view.  (here could be a mul= tiple operators, that is related to federation) an enterprise customer may simply request a L3 VPN service, but operator has = to provision and mange the end to end underlay network constructed with mul= tiple ASes and techniques, and further assure the service. this is the key = issue for today's operators.

 

I do believe this interface and its model are indeed helpful = for operators to simplify operations and management.

And I still have some questions need to be discussed and alig= ned with you and experts in email thread.

 

1.While referring to another draft at same meeting <<se= rvice model explained>> (https://tools.i= etf.org/id/draft-wu-opsawg-service-model-explained-03.txt),

I believe the above E2E deployment interface should be positi= on between service orchestration and  network orchestration(Figure 3).=

That mean it=A1=AFs a internal interface in one operator and = it acts not only to implement the customer facing model (i.e. L3SM),but als= o to maintain, monitor and diagnose the end to end PE-based VPN services crossing multiple technologies deployed network.<= o:p>

Is it right? and should this interface need to support VPN se= rvice which maybe cross multiple operators?

=3D=3D> good point, the future in the link is quite helpfu= l, this should be updated in next revision.

 

=3D=3D> for your questions about multiple operators, this = is exactly the issue raised during the meeting, operator are interconnected= each other through federation, the end to end service may go across multiple operators' access and core network. that is the rea= son why we define VPN segment within the composed VPN. this hasn't been con= sider in the document before, but the flexibility of composed VPN framework= should be included.

 

2.Actually I=A1=AFm new guy in IETF, so I=A1=AFm not sure if = there are existing works in IETF which could instruct or modeling the inter= face/E2E-view to manage a multiple technologies composed network, which I believe very common in operator=A1=AFs deployment while s= till need to provide simple E2E service experience to their customers. Mayb= e we can improve something here. So if experts here have more background, p= lease help me. Thanks.

 

=3D=3D> although it is important, but I didn't see any e2e= effort on the network yet. there is a related work in L3SM in customer ser= vice level and some dedicated VPN models in BESS. that's why I raise this topic. definitely welcome any effort to join the followin= g data model design if you really have a strong background on it.

 

3.As I understand this interface/model should be internal in = operators, so I=A1=AFm not sure if there any other operators are interested= it and need a IETF RFC?

 

=3D=3D> I did hear two big operators showed the interest i= n this topic, hope they can join as well in our next revision. this may rel= ated to network orchestrator, OSS/BSS and even analytics system from different vendors. a standard model will definitely  hep = the diversity in one operator's production environment.

 

Best regards,

 

DENG Hui

Thanks.

 

Regards,

Richard Chen

 


=BB=AA= =CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
=B5=D8= =D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB= =F9=B5=D8 =D3=CA= =B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9= =AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD= =B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8= =BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8= =CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8= =B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0= =B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE= =D6=D0
=B5=C4=D0= =C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC= =C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC= =FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_2691CE0099834E4A9C5044EEC662BB9D572E0E5Edfweml501mbb_-- From nobody Fri Oct 14 00:45:34 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372A12940C; Fri, 14 Oct 2016 00:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 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=-2.996, 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 QIhb-TkS2oFf; Fri, 14 Oct 2016 00:45:29 -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 0CF631293D6; Fri, 14 Oct 2016 00:45:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYE74168; Fri, 14 Oct 2016 07:45:23 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 14 Oct 2016 08:45:20 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.186]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Fri, 14 Oct 2016 15:45:06 +0800 From: "Chenrui (Richard)" To: Lucy yong , Hui Deng Thread-Topic: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSJYYRaoB4EZHCnEeWdW72DK055qCnh9aA Date: Fri, 14 Oct 2016 07:45:07 +0000 Message-ID: <0D5441A3DF1544449089458210966F29788F0C95@SZXEMA501-MBX.china.huawei.com> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.55.144] Content-Type: multipart/alternative; boundary="_000_0D5441A3DF1544449089458210966F29788F0C95SZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58008D14.0119, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 57f803c5fee4d688e030cda7050f5bd3 Archived-At: Cc: Songxiaolin , "opsawg@ietf.org" , "opsawg-chairs@ietf.org" , zhangliya Subject: [OPSAWG] =?gb2312?b?tPC4tDogID8/OiAgZHJhZnQtZGVuZy1vcHNhd2ctY29t?= =?gb2312?b?cG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQ=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 07:45:33 -0000 --_000_0D5441A3DF1544449089458210966F29788F0C95SZXEMA501MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTHVjeSwNCg0KVmVyeSBnb29kIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gSSBiZWxpZXZl IEkgY2FuIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50IGZyb20gQ2hpbmEgTW9iaWxlIGJ1dCBJ IGhhdmVuoa90IHJlYWNoZWQgYXMgZGVlcCB1bmRlcnN0YW5kaW5nIGFzIHlvdS4NCkkgdW5kZXJz dGFuZCBpdKGvcyBpbmRlZWQgbm9uZSBidXNpbmVzcyB3aXRoIGEgbmV3IFZQTiBzZXJ2aWNlLiBJ dKGvcyBqdXN0IGhvdyBvcGVyYXRvciBjb3VsZCBzcGVjaWZ5IHRoZSBlbmQtMi1lbmQgZGVwbG95 bWVudCB2aWV3IG9mIGV4aXN0aW5nIEwyL0wzVlBOIHNlcnZpY2UgY3Jvc3NpbmcgbXVsdGlwbGUg b3BlcmF0b3IgZG9tYWlucy4NClRoYXQgY2FuIHNpbXBsaWZ5IHRoZSBzZXJ2aWNlIGFjdGl2YXRp b24gb3IgZGVwbG95bWVudCBwcm9ncmVzcyB0byBzb21lIGV4dGVudCBkdWUgdG8gb3JjaGVzdHJh dGlvbiBjYXBhYmlsaXR5LiBSaWdodD8NClNvIEkgYmVsaWV2ZSBpdCAsdGhvdWdoIG5vdCAgc3Vy ZSBpZiBpdKGvcyBjb21tb24gbmVlZHMgIGZyb20gb3BlcmF0b3JzLiAgSaGvbSAgbG9va2luZyBm b3IgbW9yZSBjb21tZW50cy4NCg0KUGxlYXNlIEh1aSBjb3JyZWN0IG1lIGlmIEmhr20gbWlzdGFr ZW4gdGhlIGludGVudCBmcm9tIHlvdSBkcmFmdC4NCg0KQlRXLGluIHlvdXIgc2VudGVuY2Ugb2Yg IKGwZG8gb3BlcmF0b3IgbmVlZCBhIGhpZXJhcmNoaWNhbCBvcGVyYXRvciBWUE4gc2VydmljZSBt b2RlbCBvciBhIGZsYXQgb25lP6GxIC5Joa9tIG5vdCBzdXJlIHRoZSBtZWFuaW5nIG9mIKGwIGhp ZXJhcmNoaWNhbKGxIG9yIKGwZmxhdKGxLCBhcmUgdGhleSB0aGUgc2FtZSBzb2x1dGlvbnMgZm9y IHRoaXMgcmVxdWlyZW1lbnQgb3IgZGlmZmVyZW50IHNvbHV0aW9ucz8gQXJlIHRoZXkgZXhpc3Rp bmcgd29yayBpbiBJRVRGIGZvciB0aGlzIHJlcXVpcmVtZW50Pw0KDQpUaGFua3MuDQpSaWNoYXJk DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCruqzqq8vMr109DP3rmry74g SHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCrXY1rejusnu29rK0MH6uNrH+NvgzO+7qs6q u/m12CDTyrHgo7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW50aWFu LCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KaHR0cDovL3d3 dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+vLDG 5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXE uPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rI q7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTt ytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpU aGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNv biBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhl DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rp b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQN CnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQq3orz+yMs6IEx1Y3kgeW9uZw0Kt6LLzcqxvOQ6IDIw MTbE6jEw1MIxNMjVIDM6MTUNCsrVvP7IyzogSHVpIERlbmc7IENoZW5ydWkgKFJpY2hhcmQpOyBv cHNhd2dAaWV0Zi5vcmcNCrOty806IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6IFJFOiBb T1BTQVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50 cy0wMS50eHQNCg0KSGkgSHVpIGFuZCBSdWksDQoNClRoZSBkcmFmdCBpbnRyb2R1Y3Rpb24gc3Rh cnRzIHRoYXQgSVNQcyBoYXZlIGludGVyZXN0IG9uIHByb3ZpZGluZyBQcm92aWRlciBFZGdlIChQ RSkgYmFzZWQgdmlydHVhbCBwcml2YXRlIG5ldHdvcmsgKFZQTikgc2VydmljZSBhbmQgbmFtZXMg aXQgYXMgY29tcG9zZWQgVlBOIHNlcnZpY2UgYW5kIGludGVuZHMgdG8gc3BlY2lmeSB0aGUgc2Vy dmljZSBtb2RlbCByZXF1aXJlbWVudHMgZm9yIHRoZSBjb21wb3NlZCBWUE4uIFRoZW4gaXQgc3Rh dGVzIHRoYXQgdGhpcyBzZXJ2aWNlIG1vZGVsIGlzIGZyb20gb3BlcmF0b3IgcGVyc3BlY3RpdmUu DQoNCk15IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9uczoNCg0KDQqhpCAgICAgICAgSXMgdGhpcyBh IGJyYW5kIG5ldyBWUE4gc2VydmljZSBvZmZlcmVkIGJ5IEludGVybmV0IFNlcnZpY2UgUHJvdmlk ZXJzIG9yIGEgdXNlIGNhc2UgZm9yIGV4aXN0aW5nIFZQTiBzZXJ2aWNlcyBzcGVjaWZpZWQgaW4g W1JGQzQzNjRdIFtSRkM2NzQyXVtSRkM3NDMyXT8gSWYgdGhpcyBpcyBhIG5ldyBzZXJ2aWNlLCBw bGVhc2UgbWFrZSB0aGF0IHZlcnkgY2xlYXIgaW4gdGhlIGJlZ2lubmluZyBhbmQgZGVzY3JpYmUg d2hhdCBpcyB0aGUgbmV3IHNlcnZpY2UsIHNlcnZpY2UgYXJjaGl0ZWN0dXJlLCBhbmQgYXJjaGl0 ZWN0dXJlIGNvbXBvbmVudHMuIElmIHRoaXMgaXMgYSB1c2UgY2FzZSBmb3IgZXhpc3RpbmcgVlBO IHNlcnZpY2VzOyBwbGVhc2UgZG8gbm90IGNhbGwgaXQgY29tcG9zZWQgVlBOIHNlcnZpY2UgKG1h a2UgYSBsb3Qgb2YgY29uZnVzaW9ucy4pDQoNCqGkICAgICAgICBBc3N1bWUgdGhpcyBpcyBmb3Ig ZXhpc3RpbmcgVlBOcyBhbmQgZHJhZnQgd2FudHMgdG8gc3BlY2lmeSB0aGUgb3BlcmF0b3Igdmll dyBvZiBlLTItZSBWUE5zIHRoYXQgbWF5IGFjcm9zcyBtdWx0aXBsZSBvcGVyYXRvciBkb21haW5z LiBTdWdnZXN0cyB0byBzdGFydCB3aXRoIGV4aXN0aW5nIFZQTiBzZXJ2aWNlIGFyY2hpdGVjdHVy ZSB2aWV3IGFuZCBjb21wb25lbnRzOiBDRSwgUEUsIHByb3ZpZGVyIGJhY2tib25lIG5ldHdvcmtz LCBBQyBldGMuIGFuZCBleHBsYWluIGhvdyBvcGVyYXRvciBtYXkgdXNlIG11bHRpcGxlIG5ldHdv cmsgZG9tYWlucyB0byBhY2hpZXZlIGl0LiBGb3IgZXhhbXBsZXMsIFBFcyB0aGF0IGN1c3RvbWVy IHNpdGVzIGF0dGFjaCB0byBtYXkgZXhpc3QgaW4gZGlmZmVyZW50IEFTZXM7ICB0aGUgQUMgYmV0 d2VlbiBDRS1QRSBtYXkgYmUgYWNyb3NzIGFuIGFjY2VzcyBuZXR3b3JrLCBldGMuDQoNCqGkICAg ICAgICBFeGlzdGluZyBWUE4gc2VydmljZSBhY3Jvc3MgbXVsdGlwbGUgbmV0d29ya3MgYXJlIG5v dCBuZXcgYW5kIGN1cnJlbnQgc29sdXRpb25zIHN1cHBvcnQgdGhhdC4NCg0KoaQgICAgICAgIFRl eHQgobBQcm92aWRlciBFZGdlIChQRSBiYXNlZCB2aXJ0dWFsIHByaXZhdGUgbmV0d29yayAoVlBO IHNlcnZpY2VzLCBpbiB3aGljaCB0aGUgdHVubmVsIGVuZHBvaW50cyBhcmUgdGhlIFBFIGRldmlj ZXOhsSBpcyB2ZXJ5IGNvbmZ1c2UuIFdpbGwgdGhlIHR1bm5lbCBpcyBiZXR3ZWVuIFBFLVBFIG9y IFBFLUNFPyBXaWxsIHRoaXMgdHVubmVsIGlzIGRpZmZlcmVudCBmcm9tIGN1cnJlbnQgdHVubmVs IHRlY2huaXF1ZXMgaW4gW1JGQzQzNjRdIFtSRkM2NzQyXVtSRkM3NDMyXT8NCg0KoaQgICAgICAg IEV4aXN0aW5nIFZQTiBzZXJ2aWNlIFBFIGFuZCBDRSBoYXZlIGl0cyByb2xlLiBUZXh0OiChsENF IGRldmljZSBkbyBub3QgbmVlZCB0byBoYXZlIGFueSBzcGVjaWFsIFZQTiBjYXBhYmlsaXR5obEg aXMgY29uZnVzZWQgdG9vLg0KDQqhpCAgICAgICAgV2hlbiBhbiBvcGVyYXRvciBnZXRzIGN1c3Rv bWVyIFZQTiBzZXJ2aWNlIHJlcXVlc3QgdGhhdCBpcyBhbiBlMmUgc2VydmljZSBkZXNjcmlwdGlv biAoZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwpLCBoZSB3aWxsIGRlc2lnbiBp bmRpdmlkdWFsIHNlZ21lbnRzIChDRS1QRSBhbmQgUEUtUEUpIHRvIG1lZXQgdGhlIHJlcXVlc3Qu IFRoZSByZXN1bHQgbWF5IG1lYW4gdGhhdCB0aGUgVlBOIGlzIGltcGxlbWVudGVkIGFjcm9zcyBz ZXZlcmFsIGRvbWFpbnMuDQoNCqGkICAgICAgICBXaGF0IHZhbHVlcyB0aGF0IGEgZmxhdCBvcGVy YXRvciBWUE4gc2VydmljZSBtb2RlbCBwcm92aWRlcz8gIHR3byBzZWdtZW50IFZQTnMgbWF5IG5v dCBldmVuIGF0IHRoZSBzYW1lIGxheWVycy4gSWYgb25lIHNlZ21lbnQgVlBOIGp1c3QgcHJvdmlk ZXMgYSB0cmFuc2l0IGxpbmsgb3IgYWNjZXNzIGxpbmsgdG8gdGhlIFZQTiBzZXJ2aWNlLCBkbyBv cGVyYXRvciBuZWVkIGEgaGllcmFyY2hpY2FsIG9wZXJhdG9yIFZQTiBzZXJ2aWNlIG1vZGVsIG9y IGEgZmxhdCBvbmU/DQoNCqGkICAgICAgICAgZmlndXJlIGluIHBhZ2UgNSB2ZXJ5IGNvbmZ1c2lv bi4gSWYgdGhpcyBpcyBmb3IgZXhpc3RpbmcgVlBOIHNlcnZpY2UsIHBsZWFzZSByZXBsYWNlIKGw Q29tcG9zZWQgVlBOobEgd2l0aCChsEwzVlBOobEgKG9yIKGwTDJWUE6hsSksIGFuZCByZXBsYWNl IEFQIHdpdGggQUMuDQoNCqGkICAgICAgICBJZiB0aGlzIGlzIGEgbmV3IFZQTiBzZXJ2aWNlLCBw bGVhc2UgZGVmaW5lIHdoYXQgaXMgdGhlIGNvbXBvc2VkIFZQTiBzZXJ2aWNlIGFuZCB0aGUgYXJj aGl0ZWN0dXJlLiBUaGVuIGNsYXJpZnkgaWYgY3VycmVudCBJRVRGIGhhcyBzb2x1dGlvbnMgZm9y IHRoaXMgc2VydmljZS4NCg0KUmVnYXJkcywNCkx1Y3kNCg0KDQoNCkZyb206IE9QU0FXRyBbbWFp bHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHVpIERlbmcNClNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAxMiwgMjAxNiAxMDoyOCBBTQ0KVG86IENoZW5ydWkgKFJpY2hh cmQpOyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCkNjOiBvcHNhd2ct Y2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtPUFNBV0ddID8/OiBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWly ZW1lbnRzLTAxLnR4dA0KDQpIaSBSaWNoYXJkLA0KDQpJIGFncmVlIHdpdGggeW91ciBwb2ludCwg aW4gb3JkZXIgdG8gbWVldCB0aG9zZSBvcGVyYXRvcnMgZXhwZWN0YXRpb24sIHRoZSBkcmFmdCBt YXkgbmVlZCB0byBiZSB1cGRhdGVkIGFuZCByZWZsZWN0IHRoYXQgYXJjaGl0ZWN0dXJlLg0KDQpS ZWdhcmRpbmcgdG8gc29sdXRpb24sIHRoYXQgd2lsbCBiZSBncmVhdCwgdGhhbmtzIGEgbG90IGZv ciB5b3VyIGNvbnRyaWJ1dGlvbiB0byBJRVRGIGlmIHRoZXJlIGlzIGFueSBwcm9vZiBvZiBjb25j ZXB0IHRvIHRoaXMuDQoNCnRoYW5rcyBhIGxvdCBmb3IgeW91ciBzdWdnZXN0aW9uDQoNCkJlc3Qg cmVnYXJkcywNCg0KREVORyBIdWkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBjaGVucnVpQGh1YXdlaS5jb208bWFpbHRvOmNoZW5ydWlAaHVhd2VpLmNvbT4NClRvOiBk ZW5naHVpMDJAaG90bWFpbC5jb208bWFpbHRvOmRlbmdodWkwMkBob3RtYWlsLmNvbT47IG9wc2F3 Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KQ0M6IG9wc2F3Zy1jaGFpcnNAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiC08Li0OiBbT1BT QVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4 dA0KRGF0ZTogVHVlLCAxMSBPY3QgMjAxNiAwMjoyNzoxNCArMDAwMA0KSGkgSHVpLA0KDQpUaGFu a3MgZm9yIHRoZXNlIGNsYXJpZmljYXRpb25zLiBNYXliZSB3ZSBjYW4gdGFsayBhYm91dCBpdCBt b3JlIGluIG5leHQgbWVldGluZyBhbmQgd2UgY2FuIHByb3ZpZGUgYSBpbml0aWFsIHNvbHV0aW9u IGFyb3VuZCB0aGVzZSBpc3N1ZXMuDQoNCkJUVywgaWYgd2UgdGFsa2luZyBhYm91dCBmZWRlcmF0 aW9uIHVzZWQgaW4gbXVsdGlwbGUgb3BlcmF0b3JzIHNjZW5hcmlvcywgSSBzdWdnZXN0IHRoYXQg dGhlcmUgc2hvdWxkIGJlIGVhc3Qtd2VzdCBpbnRlcmZhY2UgYmV0d2VlbiBwZWVyIG9yY2hlc3Ry YXRpb24gc3lzdGVtIGluIHRoZXNlIG9wZXJhdG9ycy4gVGhhdCBlYXNlLXdlc3QgaW50ZXJmYWNl IGlzIGRpZmZlcmVudCB3aXRoIGludGVybmFsIEUyRSBzZXJ2aWNlIGFjdGl2YXRpb24gaW50ZXJm YWNlIGZvciBzb21lIHNwZWNpYWwgcmVxdWlyZW1lbnQgYmV0d2VlbiBvcGVyYXRvcnMsIHN1Y2gg YXMgc2VjdXJpdHksIHJlc291cmNlIHZpc3VhbGl6YXRpb24sZXRjLg0KDQpUaGFua3MsDQpSaWNo YXJkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCruqzqq8vMr109DP3rmr y74gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCrXY1rejusnu29rK0MH6uNrH+NvgzO+7 qs6qu/m12CDTyrHgo7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW50 aWFuLCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KaHR0cDov L3d3dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+ vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz 9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e 09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE +rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOh DQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBl cnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2Yg dGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywg YnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1 Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBp bW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQq3orz+yMs6IEh1aSBEZW5nIFttYWlsdG86ZGVu Z2h1aTAyQGhvdG1haWwuY29tXQ0Kt6LLzcqxvOQ6IDIwMTbE6jEw1MIxMMjVIDIzOjE1DQrK1bz+ yMs6IENoZW5ydWkgKFJpY2hhcmQpOyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NCrOty806IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNA aWV0Zi5vcmc+DQrW98ziOiBSRTogW09QU0FXR10gZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQt dnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCg0KDQpIaSBSaWNoYXJkLA0KDQpUaGFua3MgYSBs b3QgZm9yIHlvdXIgY29tbWVudHMsIEkgcmVjYWxsZWQgdGhhdCBvdGhlciB0d28gb3BlcmF0b3Jz IGR1cmluZyBsYXN0IHRpbWUgZjJmIG1lZXRpbmcgaGFkIG1hZGUgc29tZSBjb21tZW50cyBhYm91 dCBmZWRlcmF0aW9uIGlzc3VlLCBob3BlIHRoZXkgY2FuIGVsYWJvcmF0ZSBtb3JlIGRldGFpbCBj b21tZW50cyBoZXJlIGFzIHdlbGwsIGlubGluZSB3aXRoID09Pg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IGNoZW5ydWlAaHVhd2VpLmNvbTxtYWlsdG86Y2hlbnJ1aUBo dWF3ZWkuY29tPg0KVG86IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsg ZGVuZ2h1aTAyQGhvdG1haWwuY29tPG1haWx0bzpkZW5naHVpMDJAaG90bWFpbC5jb20+DQpDQzog b3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVx dWlyZW1lbnRzLTAxLnR4dA0KRGF0ZTogU3VuLCA5IE9jdCAyMDE2IDAzOjM1OjQ2ICswMDAwDQpI aSBIdWkgYW5kIGFsbCwNCg0KV2hlbiBJIHdlbnQgdGhyb3VnaCB0aGUgZG9jdW1lbnRzIG9mIElF VEYjOTYsSSBub3RpY2VkIHRoYXQgdGhpcyBkcmFmdCBoYXMgcmFpc2VkIGEgaW50ZXJlc3Rpbmcg cmVxdWlyZW1lbnQgaW4gQ2hpbmEgTW9iaWxlIG9mIEUyRSBkZXBsb3ltZW50IGludGVyZmFjZSB0 byBhIG11bHRpcGxlIFZQTnMgY29tcG9zZWQgaW5mcmFzdHJ1Y3R1cmUsIHN1Y2ggYXMgTDIrTDMg bmV0d29yay4gU28gdGhlIGludGVyZmFjZSBjb3VsZCBtYWtlIHRoZSBzZXJ2aWNlIGZ1bGZpbGxt ZW50IGFuZCBtYW5hZ2VtZW50IG1vcmUgZWFzeS4NCklzIG15IHVuZGVyc3RhbmRpbmcgcmlnaHQ/ DQoNCj09PiBZZXMsIGN1cnJlbnQgZXhpc3RpbmcgTDNTTSBhcmUgbW9zdGx5IHRhbGtpbmcgYWJv dXQgY3VzdG9tZXIgZmFjaW5nIHNlcnZpY2UgbW9kZWwuDQp0aGlzIHJlcXVpcmVtZW50IGV4cGVj dHMgdG8gaGVscCBvcGVyYXRvcnMgd2l0aCBsYXJnZSBzY2FsZSB0byBtYW5nZSB0aGUgdW5kZXJs YXkgbmV0d29yayB3aXRoIGEgZ2xvYmFsIHZpZXcuICAoaGVyZSBjb3VsZCBiZSBhIG11bHRpcGxl IG9wZXJhdG9ycywgdGhhdCBpcyByZWxhdGVkIHRvIGZlZGVyYXRpb24pIGFuIGVudGVycHJpc2Ug Y3VzdG9tZXIgbWF5IHNpbXBseSByZXF1ZXN0IGEgTDMgVlBOIHNlcnZpY2UsIGJ1dCBvcGVyYXRv ciBoYXMgdG8gcHJvdmlzaW9uIGFuZCBtYW5nZSB0aGUgZW5kIHRvIGVuZCB1bmRlcmxheSBuZXR3 b3JrIGNvbnN0cnVjdGVkIHdpdGggbXVsdGlwbGUgQVNlcyBhbmQgdGVjaG5pcXVlcywgYW5kIGZ1 cnRoZXIgYXNzdXJlIHRoZSBzZXJ2aWNlLiB0aGlzIGlzIHRoZSBrZXkgaXNzdWUgZm9yIHRvZGF5 J3Mgb3BlcmF0b3JzLg0KDQpJIGRvIGJlbGlldmUgdGhpcyBpbnRlcmZhY2UgYW5kIGl0cyBtb2Rl bCBhcmUgaW5kZWVkIGhlbHBmdWwgZm9yIG9wZXJhdG9ycyB0byBzaW1wbGlmeSBvcGVyYXRpb25z IGFuZCBtYW5hZ2VtZW50Lg0KQW5kIEkgc3RpbGwgaGF2ZSBzb21lIHF1ZXN0aW9ucyBuZWVkIHRv IGJlIGRpc2N1c3NlZCBhbmQgYWxpZ25lZCB3aXRoIHlvdSBhbmQgZXhwZXJ0cyBpbiBlbWFpbCB0 aHJlYWQuDQoNCjEuV2hpbGUgcmVmZXJyaW5nIHRvIGFub3RoZXIgZHJhZnQgYXQgc2FtZSBtZWV0 aW5nIDw8c2VydmljZSBtb2RlbCBleHBsYWluZWQ+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC13dS1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDMudHh0KSwNCkkgYmVs aWV2ZSB0aGUgYWJvdmUgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNlIHNob3VsZCBiZSBwb3NpdGlv biBiZXR3ZWVuIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiBhbmQgIG5ldHdvcmsgb3JjaGVzdHJhdGlv bihGaWd1cmUgMykuDQpUaGF0IG1lYW4gaXShr3MgYSBpbnRlcm5hbCBpbnRlcmZhY2UgaW4gb25l IG9wZXJhdG9yIGFuZCBpdCBhY3RzIG5vdCBvbmx5IHRvIGltcGxlbWVudCB0aGUgY3VzdG9tZXIg ZmFjaW5nIG1vZGVsIChpLmUuIEwzU00pLGJ1dCBhbHNvIHRvIG1haW50YWluLCBtb25pdG9yIGFu ZCBkaWFnbm9zZSB0aGUgZW5kIHRvIGVuZCBQRS1iYXNlZCBWUE4gc2VydmljZXMgY3Jvc3Npbmcg bXVsdGlwbGUgdGVjaG5vbG9naWVzIGRlcGxveWVkIG5ldHdvcmsuDQpJcyBpdCByaWdodD8gYW5k IHNob3VsZCB0aGlzIGludGVyZmFjZSBuZWVkIHRvIHN1cHBvcnQgVlBOIHNlcnZpY2Ugd2hpY2gg bWF5YmUgY3Jvc3MgbXVsdGlwbGUgb3BlcmF0b3JzPw0KPT0+IGdvb2QgcG9pbnQsIHRoZSBmdXR1 cmUgaW4gdGhlIGxpbmsgaXMgcXVpdGUgaGVscGZ1bCwgdGhpcyBzaG91bGQgYmUgdXBkYXRlZCBp biBuZXh0IHJldmlzaW9uLg0KDQo9PT4gZm9yIHlvdXIgcXVlc3Rpb25zIGFib3V0IG11bHRpcGxl IG9wZXJhdG9ycywgdGhpcyBpcyBleGFjdGx5IHRoZSBpc3N1ZSByYWlzZWQgZHVyaW5nIHRoZSBt ZWV0aW5nLCBvcGVyYXRvciBhcmUgaW50ZXJjb25uZWN0ZWQgZWFjaCBvdGhlciB0aHJvdWdoIGZl ZGVyYXRpb24sIHRoZSBlbmQgdG8gZW5kIHNlcnZpY2UgbWF5IGdvIGFjcm9zcyBtdWx0aXBsZSBv cGVyYXRvcnMnIGFjY2VzcyBhbmQgY29yZSBuZXR3b3JrLiB0aGF0IGlzIHRoZSByZWFzb24gd2h5 IHdlIGRlZmluZSBWUE4gc2VnbWVudCB3aXRoaW4gdGhlIGNvbXBvc2VkIFZQTi4gdGhpcyBoYXNu J3QgYmVlbiBjb25zaWRlciBpbiB0aGUgZG9jdW1lbnQgYmVmb3JlLCBidXQgdGhlIGZsZXhpYmls aXR5IG9mIGNvbXBvc2VkIFZQTiBmcmFtZXdvcmsgc2hvdWxkIGJlIGluY2x1ZGVkLg0KDQoyLkFj dHVhbGx5IEmhr20gbmV3IGd1eSBpbiBJRVRGLCBzbyBJoa9tIG5vdCBzdXJlIGlmIHRoZXJlIGFy ZSBleGlzdGluZyB3b3JrcyBpbiBJRVRGIHdoaWNoIGNvdWxkIGluc3RydWN0IG9yIG1vZGVsaW5n IHRoZSBpbnRlcmZhY2UvRTJFLXZpZXcgdG8gbWFuYWdlIGEgbXVsdGlwbGUgdGVjaG5vbG9naWVz IGNvbXBvc2VkIG5ldHdvcmssIHdoaWNoIEkgYmVsaWV2ZSB2ZXJ5IGNvbW1vbiBpbiBvcGVyYXRv cqGvcyBkZXBsb3ltZW50IHdoaWxlIHN0aWxsIG5lZWQgdG8gcHJvdmlkZSBzaW1wbGUgRTJFIHNl cnZpY2UgZXhwZXJpZW5jZSB0byB0aGVpciBjdXN0b21lcnMuIE1heWJlIHdlIGNhbiBpbXByb3Zl IHNvbWV0aGluZyBoZXJlLiBTbyBpZiBleHBlcnRzIGhlcmUgaGF2ZSBtb3JlIGJhY2tncm91bmQs IHBsZWFzZSBoZWxwIG1lLiBUaGFua3MuDQoNCj09PiBhbHRob3VnaCBpdCBpcyBpbXBvcnRhbnQs IGJ1dCBJIGRpZG4ndCBzZWUgYW55IGUyZSBlZmZvcnQgb24gdGhlIG5ldHdvcmsgeWV0LiB0aGVy ZSBpcyBhIHJlbGF0ZWQgd29yayBpbiBMM1NNIGluIGN1c3RvbWVyIHNlcnZpY2UgbGV2ZWwgYW5k IHNvbWUgZGVkaWNhdGVkIFZQTiBtb2RlbHMgaW4gQkVTUy4gdGhhdCdzIHdoeSBJIHJhaXNlIHRo aXMgdG9waWMuIGRlZmluaXRlbHkgd2VsY29tZSBhbnkgZWZmb3J0IHRvIGpvaW4gdGhlIGZvbGxv d2luZyBkYXRhIG1vZGVsIGRlc2lnbiBpZiB5b3UgcmVhbGx5IGhhdmUgYSBzdHJvbmcgYmFja2dy b3VuZCBvbiBpdC4NCg0KMy5BcyBJIHVuZGVyc3RhbmQgdGhpcyBpbnRlcmZhY2UvbW9kZWwgc2hv dWxkIGJlIGludGVybmFsIGluIG9wZXJhdG9ycywgc28gSaGvbSBub3Qgc3VyZSBpZiB0aGVyZSBh bnkgb3RoZXIgb3BlcmF0b3JzIGFyZSBpbnRlcmVzdGVkIGl0IGFuZCBuZWVkIGEgSUVURiBSRkM/ DQoNCj09PiBJIGRpZCBoZWFyIHR3byBiaWcgb3BlcmF0b3JzIHNob3dlZCB0aGUgaW50ZXJlc3Qg aW4gdGhpcyB0b3BpYywgaG9wZSB0aGV5IGNhbiBqb2luIGFzIHdlbGwgaW4gb3VyIG5leHQgcmV2 aXNpb24uIHRoaXMgbWF5IHJlbGF0ZWQgdG8gbmV0d29yayBvcmNoZXN0cmF0b3IsIE9TUy9CU1Mg YW5kIGV2ZW4gYW5hbHl0aWNzIHN5c3RlbSBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLiBhIHN0YW5k YXJkIG1vZGVsIHdpbGwgZGVmaW5pdGVseSAgaGVwIHRoZSBkaXZlcnNpdHkgaW4gb25lIG9wZXJh dG9yJ3MgcHJvZHVjdGlvbiBlbnZpcm9ubWVudC4NCg0KQmVzdCByZWdhcmRzLA0KDQpERU5HIEh1 aQ0KVGhhbmtzLg0KDQpSZWdhcmRzLA0KUmljaGFyZCBDaGVuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCruqzqq8vMr109DP3rmry74gSHVhd2VpIFRlY2hub2xvZ2llcyBD by4sIEx0ZC4NCrXY1rejusnu29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHgo7o1MTgxMjkNCkh1 YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW50aWFuLCBMb25nZ2FuZyBEaXN0cmljdCxT aGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGj w9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66 zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbG oaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS1 57uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0 dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3 aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRk cmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWlu ZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3Rh bCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24p IGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0 IQ0KDQo= --_000_0D5441A3DF1544449089458210966F29788F0C95SZXEMA501MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Lucy,

 = ;

Very good = comments and suggestions. I believe I can understand the requirement from C= hina Mobile but I haven=A1=AFt reached as deep understanding as you.

I understa= nd it=A1=AFs indeed none business with a new VPN service. It=A1=AFs just ho= w operator could specify the end-2-end deployment view of existing L2/L3VPN service crossing multiple operator domains.

That can s= implify the service activation or deployment progress to some extent due to= orchestration capability. Right?

So I be= lieve it ,though not  sure if it=A1=AFs common needs  from operat= ors.  I=A1=AFm  looking for more comments.

 = ;

Please Hui= correct me if I=A1=AFm mistaken the intent from you draft.

 = ;

BTW,in = your sentence of  =A1=B0do operator need a hierarchical operator VPN s= ervice model or a flat one?=A1=B1 .I=A1=AFm not sure the meaning of =A1=B0 = hierarchical=A1=B1 or =A1=B0flat=A1=B1, are they the same solutions for this requirement or d= ifferent solutions? Are they existing work in IETF for this requirement?

&n= bsp;

Thanks.=

Richard=

 = ;


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8= =DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE= =AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2= =CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB= =F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 = ;

=B7=A2=BC=FE=C8= =CB: Lucy yong
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C214=C8=D5 = 3:15
=CA=D5=BC=FE=C8=CB: Hui Deng; Chenrui (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 

Hi Hui = and Rui,

&n= bsp;

The dra= ft introduction starts that ISPs have interest on providing Provider Edge (= PE) based virtual private network (VPN) service and names it as composed VPN service and intends to specify the service model requir= ements for the composed VPN. Then it states that this service model is from= operator perspective.

&n= bsp;

My comm= ents and suggestions:

&n= bsp;

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Is this a brand new VPN service offered by Internet Service Providers or a= use case for existing VPN services specified in [RFC4364] [RFC6742][RFC7432]? If this is a new service, please make that very clear = in the beginning and describe what is the new service, service architecture= , and architecture components. If this is a use case for existing VPN servi= ces; please do not call it composed VPN service (make a lot of confusions.)

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Assume this is for existing VPNs and draft wants to specify the operator v= iew of e-2-e VPNs that may across multiple operator domains. Suggests to start with existing VPN service architecture view and componen= ts: CE, PE, provider backbone networks, AC etc. and explain how operator ma= y use multiple network domains to achieve it. For examples, PEs that custom= er sites attach to may exist in different ASes;  the AC between CE-PE may be across an access network= , etc.

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Existing VPN service across multiple networks are not new and current solu= tions support that.

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Text =A1=B0Provider Edge (PE based virtual private network (VPN services, = in which the tunnel endpoints are the PE devices=A1=B1 is very confuse. Will the tunnel is between PE-PE or PE-CE? Will this tunnel is different f= rom current tunnel techniques in [RFC4364] [RFC6742][RFC7432]?

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Existing VPN service PE and CE have its role. Text: =A1=B0CE device do not= need to have any special VPN capability=A1=B1 is confused too.<= /span>

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    When an operator gets customer VPN service request that is an e2e service = description (draft-ietf-l3sm-l3vpn-service-model), he will design individual segments (CE-PE and PE-PE) to meet the request. The resu= lt may mean that the VPN is implemented across several domains.   = ;

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    What values that a flat operator VPN service model provides?  two seg= ment VPNs may not even at the same layers. If one segment VPN just provides a transit link or access link to the VPN service, do operato= r need a hierarchical operator VPN service model or a flat one?<= /span>

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;     figure in page 5 very confusion. If this is for existing VPN service= , please replace =A1=B0Composed VPN=A1=B1 with =A1=B0L3VPN=A1=B1 (or =A1=B0= L2VPN=A1=B1), and replace AP with AC.

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    If this is a new VPN service, please define what is the composed VPN servi= ce and the architecture. Then clarify if current IETF has solutions for this service.

&n= bsp;

Regards= ,

Lucy

&n= bsp;

&n= bsp;

&n= bsp;

From: OPSAWG [ma= ilto:opsawg-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Wednesday, October 12, 2016 10:28 AM
To: Chenrui (Richard); opsawg@iet= f.org
Cc: opsawg-chairs@ietf.org=
Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Richard,

 

I agree with your point, in order to meet= those operators expectation, the draft may need to be updated and reflect = that architecture.

 

Regarding to solution, that will be great= , thanks a lot for your contribution to IETF if there is any proof of conce= pt to this.

 

thanks a lot for your suggestion

 

Best regards,

 

DENG Hui

From: chenrui@huawei.com
To: denghui02@hotmail.com; opsawg@ietf.org
CC: opsawg-chairs@ietf.org Subject: =B4=F0=B8=B4: [OPSAWG] draft-deng-opsawg-compose= d-vpn-sm-requirements-01.txt
Date: Tue, 11 Oct 2016 02:27:14 +0000

Hi Hui,

 

Thanks for= these clarifications. Maybe we can talk about it more in next meeting and = we can provide a initial solution around these issues.

 

BTW, if we= talking about federation used in multiple operators scenarios, I suggest tha= t there should be east-west interface between peer orchestration system in = these operators. That ease-west interface is different with internal E2E service activation interface for some special requiremen= t between operators, such as security, resource visualization,etc.

 

Thanks,

Richard

 


=BB=AA=CE=AA=BC=BC=CA= =F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9= =EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0= =C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0= =C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7= =D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4= =CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5= =AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2= =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3= =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

=B7=A2=BC=FE=C8= =CB: Hui Deng [mailto:denghu= i02@hotmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4<= /b>: = 2016=C4=EA10=D4=C210=C8=D5 23:15
=CA=D5=BC=FE=C8=CB= : Chenru= i (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG]= draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 


Hi Richard,

 

Thanks a lot for your comments, I recalle= d that other two operators during last time f2f meeting had made some comme= nts about federation issue, hope they can elaborate more detail comments here as well, inline with =3D=3D>

From: chenrui@huawei.com
To: opsawg@ietf.org; denghui02@hotmail.com
CC: opsawg-chairs@ietf.org Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=
Date: Sun, 9 Oct 2016 03:35:46 +0000

Hi Hui and all,

 

When I went through the documents of IETF#96,I= noticed that this draft has raised a interesting requirement in China Mobi= le of E2E deployment interface to a multiple VPNs composed infrastructure, such as L2+L3 network. So the interface could= make the service fulfillment and management more easy.

Is my understanding right?

 

=3D=3D> Yes, current existing L3SM are most= ly talking about customer facing service model.

this requirement expects to help operators wit= h large scale to mange the underlay network with a global view.  (here= could be a multiple operators, that is related to federation) an enterprise customer may simply request a L3 VPN service, but operator h= as to provision and mange the end to end underlay network constructed with = multiple ASes and techniques, and further assure the service. this is the k= ey issue for today's operators.

 

I do believe this interface and its model are = indeed helpful for operators to simplify operations and management.<= span lang=3D"EN-US" style=3D"font-family:"Calibri","sans-ser= if"">

And I still have some questions need to be dis= cussed and aligned with you and experts in email thread.

 

1.While referring to another draft at same mee= ting <<service model explained>> (https://tools.ietf.org/id/draft-wu-opsawg-ser= vice-model-explained-03.txt),

I believe the above E2E deployment interface s= hould be position between service orchestration and  network orchestra= tion(Figure 3).

That mean it=A1=AFs a internal interface in on= e operator and it acts not only to implement the customer facing model (i.e= . L3SM),but also to maintain, monitor and diagnose the end to end PE-based VPN services crossing multiple technologies deployed n= etwork.

Is it right? and should this interface need to= support VPN service which maybe cross multiple operators?

=3D=3D> good point, the future in the link = is quite helpful, this should be updated in next revision.

 

=3D=3D> for your questions about multiple o= perators, this is exactly the issue raised during the meeting, operator are= interconnected each other through federation, the end to end service may go across multiple operators' access and core network. = that is the reason why we define VPN segment within the composed VPN. this = hasn't been consider in the document before, but the flexibility of compose= d VPN framework should be included.

 

2.Actually I=A1=AFm new guy in IETF, so I=A1= =AFm not sure if there are existing works in IETF which could instruct or m= odeling the interface/E2E-view to manage a multiple technologies composed network, which I believe very common in operator=A1=AFs deploymen= t while still need to provide simple E2E service experience to their custom= ers. Maybe we can improve something here. So if experts here have more back= ground, please help me. Thanks.

 

=3D=3D> although it is important, but I did= n't see any e2e effort on the network yet. there is a related work in L3SM = in customer service level and some dedicated VPN models in BESS. that's why I raise this topic. definitely welcome any effort to j= oin the following data model design if you really have a strong background = on it.

 

3.As I understand this interface/model should = be internal in operators, so I=A1=AFm not sure if there any other operators= are interested it and need a IETF RFC?=

 

=3D=3D> I did hear two big operators showed= the interest in this topic, hope they can join as well in our next revisio= n. this may related to network orchestrator, OSS/BSS and even analytics system from different vendors. a standard model will defini= tely  hep the diversity in one operator's production environment.

 

Best regards,

 

DENG Hui

Thanks.

 

Regards,

Richard Chen

 


=BB=AA=CE=AA=BC=BC=CA= =F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9= =EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3= =CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4= =B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3= =E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3= =BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4= =CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5= =AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2= =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3= =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_0D5441A3DF1544449089458210966F29788F0C95SZXEMA501MBXchi_-- From nobody Fri Oct 14 07:23:42 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155BF129796; Fri, 14 Oct 2016 07:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 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=-2.996, 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 gVEUQGw6G5k4; Fri, 14 Oct 2016 07:23:35 -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 BC42712978D; Fri, 14 Oct 2016 07:23:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTE43166; Fri, 14 Oct 2016 14:23:31 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 14 Oct 2016 15:23:31 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Fri, 14 Oct 2016 07:23:21 -0700 From: Lucy yong To: "Chenrui (Richard)" , Hui Deng Thread-Topic: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSJJ18MZ4lC1eKjUqffVl88R3hraCmrozAgAFbVYD///CXAA== Date: Fri, 14 Oct 2016 14:23:20 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572E1351@dfweml501-mbb> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> <0D5441A3DF1544449089458210966F29788F0C95@SZXEMA501-MBX.china.huawei.com> In-Reply-To: <0D5441A3DF1544449089458210966F29788F0C95@SZXEMA501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.245] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572E1351dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5800EA64.0295, 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: 1f18fdd46ef98e65785a68e7870b2b79 Archived-At: Cc: Songxiaolin , "opsawg@ietf.org" , "opsawg-chairs@ietf.org" , zhangliya Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:23:41 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D572E1351dfweml501mbb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IENoZW5ydWkgKFJpY2hhcmQpDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTQsIDIw MTYgMjo0NSBBTQ0KVG86IEx1Y3kgeW9uZzsgSHVpIERlbmcNCkNjOiBvcHNhd2ctY2hhaXJzQGll dGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IFNvbmd4aWFvbGluOyB6aGFuZ2xpeWENClN1YmplY3Q6 ID8/OiBbT1BTQVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVp cmVtZW50cy0wMS50eHQNCg0KSGkgTHVjeSwNCg0KVmVyeSBnb29kIGNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucy4gSSBiZWxpZXZlIEkgY2FuIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50IGZyb20g Q2hpbmEgTW9iaWxlIGJ1dCBJIGhhdmVuoa90IHJlYWNoZWQgYXMgZGVlcCB1bmRlcnN0YW5kaW5n IGFzIHlvdS4NCkkgdW5kZXJzdGFuZCBpdKGvcyBpbmRlZWQgbm9uZSBidXNpbmVzcyB3aXRoIGEg bmV3IFZQTiBzZXJ2aWNlLiBJdKGvcyBqdXN0IGhvdyBvcGVyYXRvciBjb3VsZCBzcGVjaWZ5IHRo ZSBlbmQtMi1lbmQgZGVwbG95bWVudCB2aWV3IG9mIGV4aXN0aW5nIEwyL0wzVlBOIHNlcnZpY2Ug Y3Jvc3NpbmcgbXVsdGlwbGUgb3BlcmF0b3IgZG9tYWlucy4NCltMdWN5XSBHb29kLiBJIGhvcGUg dGhpcyBpcyB0aGUgY2FzZS4NClRoYXQgY2FuIHNpbXBsaWZ5IHRoZSBzZXJ2aWNlIGFjdGl2YXRp b24gb3IgZGVwbG95bWVudCBwcm9ncmVzcyB0byBzb21lIGV4dGVudCBkdWUgdG8gb3JjaGVzdHJh dGlvbiBjYXBhYmlsaXR5LiBSaWdodD8NClNvIEkgYmVsaWV2ZSBpdCAsdGhvdWdoIG5vdCAgc3Vy ZSBpZiBpdKGvcyBjb21tb24gbmVlZHMgIGZyb20gb3BlcmF0b3JzLiAgSaGvbSAgbG9va2luZyBm b3IgbW9yZSBjb21tZW50cy4NCg0KUGxlYXNlIEh1aSBjb3JyZWN0IG1lIGlmIEmhr20gbWlzdGFr ZW4gdGhlIGludGVudCBmcm9tIHlvdSBkcmFmdC4NCg0KQlRXLGluIHlvdXIgc2VudGVuY2Ugb2Yg IKGwZG8gb3BlcmF0b3IgbmVlZCBhIGhpZXJhcmNoaWNhbCBvcGVyYXRvciBWUE4gc2VydmljZSBt b2RlbCBvciBhIGZsYXQgb25lP6GxIC5Joa9tIG5vdCBzdXJlIHRoZSBtZWFuaW5nIG9mIKGwIGhp ZXJhcmNoaWNhbKGxIG9yIKGwZmxhdKGxLCBhcmUgdGhleSB0aGUgc2FtZSBzb2x1dGlvbnMgZm9y IHRoaXMgcmVxdWlyZW1lbnQgb3IgZGlmZmVyZW50IHNvbHV0aW9ucz8gQXJlIHRoZXkgZXhpc3Rp bmcgd29yayBpbiBJRVRGIGZvciB0aGlzIHJlcXVpcmVtZW50Pw0KW0x1Y3ldIFRoZSBiYXNlZCBM Mi9MM1ZQTiBhcmNoaXRlY3R1cmUgaXM6ICBDRS0oQUMpLVBFLShwcm92aWRlciBiYWNrYm9uZSBu ZXR3b3JrcyktUEUtKEFDKS1DRS4gIEwzU00gYWxyZWFkeSBhZGRyZXNzZXMgdGhhdCB0aGUgcHJv dmlkZXIgYmFja2JvbmUgbmV0d29ya3MgY2FuIGluY2x1ZGUgbXVsdGlwbGUgZG9tYWlucyB0aGF0 IGFyZSBpbnRlcmNvbm5lY3RlZCB2aWEgUEUtUEUgb3IgQVNCUi1BU0JSLiBBbm90aGVyIHBhcnQg aXMgdGhlIEFDIHRoYXQgY2FuIGJlIGNvbnN0cnVjdGVkIHRocm91Z2ggYW5vdGhlciBuZXR3b3Jr IGRvbWFpbiBzdWNoIGFzIGFjY2VzcyBuZXR3b3JrLiBJbiB0aGlzIGNhc2UsIHRoZSBhY2Nlc3Mg bmV0d29yayBwcm92aWRlcyBhbiBMMlZQTiBzZXJ2aWNlIHRvIHRoZSBlbmQtdG8tZW5kIFZQTiBz ZXJ2aWNlOyBmcm9tIHRoZSBlbmQtdG8tZW5kIFZQTiBzZXJ2aWNlIHBlcnNwZWN0aXZlLCBpdCB1 c2VzIHRoZSBhY2Nlc3MgbmV0d29yayB0byBwcm92aWRlIGEgbGluayBmb3IgQUMuIFdoYXQgSSBt ZWFucyBoZXJlLCBpZiBTUCBvcGVyYXRvciAoaS5lLiBlbmQtdG8tZW5kIFZQTiBvcGVyYXRvcikg d2FudHMgYSBzZXJ2aWNlIG1vZGVsIGluY2x1ZGluZyB0aGUgYWNjZXNzIG5ldHdvcmsgZG9tYWlu L2wydnBuIChmbGF0IG1vZGVsKSBvciBhIHNlcnZpY2UgbW9kZWwgIHdpdGggQUMgdGhhdCBBQyBy ZWZlcmVuY2UgdG8gYW5vdGhlciBMMlZQTiBzZXJ2aWNlLiAoaGllcmFyY2hpY2FsIG1vZGVsKSBU aGlzIGlzIHdoYXQgSSB3YW50IHRvIGV4cHJlc3MuIEwzU00gdXNlcyBoaWVyYXJjaGljYWwgYXBw cm9hY2guDQoNClRoYW5rcywNCkx1Y3kNCg0KVGhhbmtzLg0KUmljaGFyZA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQq7qs6qvLzK9dPQz965q8u+IEh1YXdlaSBUZWNobm9s b2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFueV9sb2dvXbXY1rejusnu29rK0MH6uNrH+NvgzO+7qs6q u/m12CDTyrHgo7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW50aWFu LCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KaHR0cDovL3d3 dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+vLDG 5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXE uPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rI q7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTt ytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpU aGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNv biBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhl DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rp b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQN CnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQq3orz+yMs6IEx1Y3kgeW9uZw0Kt6LLzcqxvOQ6IDIw MTbE6jEw1MIxNMjVIDM6MTUNCsrVvP7IyzogSHVpIERlbmc7IENoZW5ydWkgKFJpY2hhcmQpOyBv cHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCrOty806IG9wc2F3Zy1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+DQrW98ziOiBSRTogW09Q U0FXR10gPz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMt MDEudHh0DQoNCkhpIEh1aSBhbmQgUnVpLA0KDQpUaGUgZHJhZnQgaW50cm9kdWN0aW9uIHN0YXJ0 cyB0aGF0IElTUHMgaGF2ZSBpbnRlcmVzdCBvbiBwcm92aWRpbmcgUHJvdmlkZXIgRWRnZSAoUEUp IGJhc2VkIHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3JrIChWUE4pIHNlcnZpY2UgYW5kIG5hbWVzIGl0 IGFzIGNvbXBvc2VkIFZQTiBzZXJ2aWNlIGFuZCBpbnRlbmRzIHRvIHNwZWNpZnkgdGhlIHNlcnZp Y2UgbW9kZWwgcmVxdWlyZW1lbnRzIGZvciB0aGUgY29tcG9zZWQgVlBOLiBUaGVuIGl0IHN0YXRl cyB0aGF0IHRoaXMgc2VydmljZSBtb2RlbCBpcyBmcm9tIG9wZXJhdG9yIHBlcnNwZWN0aXZlLg0K DQpNeSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnM6DQoNCg0KoaQgICAgICAgICBJcyB0aGlzIGEg YnJhbmQgbmV3IFZQTiBzZXJ2aWNlIG9mZmVyZWQgYnkgSW50ZXJuZXQgU2VydmljZSBQcm92aWRl cnMgb3IgYSB1c2UgY2FzZSBmb3IgZXhpc3RpbmcgVlBOIHNlcnZpY2VzIHNwZWNpZmllZCBpbiBb UkZDNDM2NF0gW1JGQzY3NDJdW1JGQzc0MzJdPyBJZiB0aGlzIGlzIGEgbmV3IHNlcnZpY2UsIHBs ZWFzZSBtYWtlIHRoYXQgdmVyeSBjbGVhciBpbiB0aGUgYmVnaW5uaW5nIGFuZCBkZXNjcmliZSB3 aGF0IGlzIHRoZSBuZXcgc2VydmljZSwgc2VydmljZSBhcmNoaXRlY3R1cmUsIGFuZCBhcmNoaXRl Y3R1cmUgY29tcG9uZW50cy4gSWYgdGhpcyBpcyBhIHVzZSBjYXNlIGZvciBleGlzdGluZyBWUE4g c2VydmljZXM7IHBsZWFzZSBkbyBub3QgY2FsbCBpdCBjb21wb3NlZCBWUE4gc2VydmljZSAobWFr ZSBhIGxvdCBvZiBjb25mdXNpb25zLikNCg0KoaQgICAgICAgICBBc3N1bWUgdGhpcyBpcyBmb3Ig ZXhpc3RpbmcgVlBOcyBhbmQgZHJhZnQgd2FudHMgdG8gc3BlY2lmeSB0aGUgb3BlcmF0b3Igdmll dyBvZiBlLTItZSBWUE5zIHRoYXQgbWF5IGFjcm9zcyBtdWx0aXBsZSBvcGVyYXRvciBkb21haW5z LiBTdWdnZXN0cyB0byBzdGFydCB3aXRoIGV4aXN0aW5nIFZQTiBzZXJ2aWNlIGFyY2hpdGVjdHVy ZSB2aWV3IGFuZCBjb21wb25lbnRzOiBDRSwgUEUsIHByb3ZpZGVyIGJhY2tib25lIG5ldHdvcmtz LCBBQyBldGMuIGFuZCBleHBsYWluIGhvdyBvcGVyYXRvciBtYXkgdXNlIG11bHRpcGxlIG5ldHdv cmsgZG9tYWlucyB0byBhY2hpZXZlIGl0LiBGb3IgZXhhbXBsZXMsIFBFcyB0aGF0IGN1c3RvbWVy IHNpdGVzIGF0dGFjaCB0byBtYXkgZXhpc3QgaW4gZGlmZmVyZW50IEFTZXM7ICB0aGUgQUMgYmV0 d2VlbiBDRS1QRSBtYXkgYmUgYWNyb3NzIGFuIGFjY2VzcyBuZXR3b3JrLCBldGMuDQoNCqGkICAg ICAgICAgRXhpc3RpbmcgVlBOIHNlcnZpY2UgYWNyb3NzIG11bHRpcGxlIG5ldHdvcmtzIGFyZSBu b3QgbmV3IGFuZCBjdXJyZW50IHNvbHV0aW9ucyBzdXBwb3J0IHRoYXQuDQoNCqGkICAgICAgICAg VGV4dCChsFByb3ZpZGVyIEVkZ2UgKFBFIGJhc2VkIHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3JrIChW UE4gc2VydmljZXMsIGluIHdoaWNoIHRoZSB0dW5uZWwgZW5kcG9pbnRzIGFyZSB0aGUgUEUgZGV2 aWNlc6GxIGlzIHZlcnkgY29uZnVzZS4gV2lsbCB0aGUgdHVubmVsIGlzIGJldHdlZW4gUEUtUEUg b3IgUEUtQ0U/IFdpbGwgdGhpcyB0dW5uZWwgaXMgZGlmZmVyZW50IGZyb20gY3VycmVudCB0dW5u ZWwgdGVjaG5pcXVlcyBpbiBbUkZDNDM2NF0gW1JGQzY3NDJdW1JGQzc0MzJdPw0KDQqhpCAgICAg ICAgIEV4aXN0aW5nIFZQTiBzZXJ2aWNlIFBFIGFuZCBDRSBoYXZlIGl0cyByb2xlLiBUZXh0OiCh sENFIGRldmljZSBkbyBub3QgbmVlZCB0byBoYXZlIGFueSBzcGVjaWFsIFZQTiBjYXBhYmlsaXR5 obEgaXMgY29uZnVzZWQgdG9vLg0KDQqhpCAgICAgICAgIFdoZW4gYW4gb3BlcmF0b3IgZ2V0cyBj dXN0b21lciBWUE4gc2VydmljZSByZXF1ZXN0IHRoYXQgaXMgYW4gZTJlIHNlcnZpY2UgZGVzY3Jp cHRpb24gKGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsKSwgaGUgd2lsbCBkZXNp Z24gaW5kaXZpZHVhbCBzZWdtZW50cyAoQ0UtUEUgYW5kIFBFLVBFKSB0byBtZWV0IHRoZSByZXF1 ZXN0LiBUaGUgcmVzdWx0IG1heSBtZWFuIHRoYXQgdGhlIFZQTiBpcyBpbXBsZW1lbnRlZCBhY3Jv c3Mgc2V2ZXJhbCBkb21haW5zLg0KDQqhpCAgICAgICAgIFdoYXQgdmFsdWVzIHRoYXQgYSBmbGF0 IG9wZXJhdG9yIFZQTiBzZXJ2aWNlIG1vZGVsIHByb3ZpZGVzPyAgdHdvIHNlZ21lbnQgVlBOcyBt YXkgbm90IGV2ZW4gYXQgdGhlIHNhbWUgbGF5ZXJzLiBJZiBvbmUgc2VnbWVudCBWUE4ganVzdCBw cm92aWRlcyBhIHRyYW5zaXQgbGluayBvciBhY2Nlc3MgbGluayB0byB0aGUgVlBOIHNlcnZpY2Us IGRvIG9wZXJhdG9yIG5lZWQgYSBoaWVyYXJjaGljYWwgb3BlcmF0b3IgVlBOIHNlcnZpY2UgbW9k ZWwgb3IgYSBmbGF0IG9uZT8NCg0KoaQgICAgICAgICAgZmlndXJlIGluIHBhZ2UgNSB2ZXJ5IGNv bmZ1c2lvbi4gSWYgdGhpcyBpcyBmb3IgZXhpc3RpbmcgVlBOIHNlcnZpY2UsIHBsZWFzZSByZXBs YWNlIKGwQ29tcG9zZWQgVlBOobEgd2l0aCChsEwzVlBOobEgKG9yIKGwTDJWUE6hsSksIGFuZCBy ZXBsYWNlIEFQIHdpdGggQUMuDQoNCqGkICAgICAgICAgSWYgdGhpcyBpcyBhIG5ldyBWUE4gc2Vy dmljZSwgcGxlYXNlIGRlZmluZSB3aGF0IGlzIHRoZSBjb21wb3NlZCBWUE4gc2VydmljZSBhbmQg dGhlIGFyY2hpdGVjdHVyZS4gVGhlbiBjbGFyaWZ5IGlmIGN1cnJlbnQgSUVURiBoYXMgc29sdXRp b25zIGZvciB0aGlzIHNlcnZpY2UuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpGcm9tOiBPUFNB V0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1aSBEZW5n DQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTYgMTA6MjggQU0NClRvOiBDaGVucnVp IChSaWNoYXJkKTsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpDYzog b3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbT1BTQVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNt LXJlcXVpcmVtZW50cy0wMS50eHQNCg0KSGkgUmljaGFyZCwNCg0KSSBhZ3JlZSB3aXRoIHlvdXIg cG9pbnQsIGluIG9yZGVyIHRvIG1lZXQgdGhvc2Ugb3BlcmF0b3JzIGV4cGVjdGF0aW9uLCB0aGUg ZHJhZnQgbWF5IG5lZWQgdG8gYmUgdXBkYXRlZCBhbmQgcmVmbGVjdCB0aGF0IGFyY2hpdGVjdHVy ZS4NCg0KUmVnYXJkaW5nIHRvIHNvbHV0aW9uLCB0aGF0IHdpbGwgYmUgZ3JlYXQsIHRoYW5rcyBh IGxvdCBmb3IgeW91ciBjb250cmlidXRpb24gdG8gSUVURiBpZiB0aGVyZSBpcyBhbnkgcHJvb2Yg b2YgY29uY2VwdCB0byB0aGlzLg0KDQp0aGFua3MgYSBsb3QgZm9yIHlvdXIgc3VnZ2VzdGlvbg0K DQpCZXN0IHJlZ2FyZHMsDQoNCkRFTkcgSHVpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogY2hlbnJ1aUBodWF3ZWkuY29tPG1haWx0bzpjaGVucnVpQGh1YXdlaS5jb20+ DQpUbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tPG1haWx0bzpkZW5naHVpMDJAaG90bWFpbC5jb20+ OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCkNDOiBvcHNhd2ctY2hh aXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogtPC4 tDogW09QU0FXR10gZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50 cy0wMS50eHQNCkRhdGU6IFR1ZSwgMTEgT2N0IDIwMTYgMDI6Mjc6MTQgKzAwMDANCkhpIEh1aSwN Cg0KVGhhbmtzIGZvciB0aGVzZSBjbGFyaWZpY2F0aW9ucy4gTWF5YmUgd2UgY2FuIHRhbGsgYWJv dXQgaXQgbW9yZSBpbiBuZXh0IG1lZXRpbmcgYW5kIHdlIGNhbiBwcm92aWRlIGEgaW5pdGlhbCBz b2x1dGlvbiBhcm91bmQgdGhlc2UgaXNzdWVzLg0KDQpCVFcsIGlmIHdlIHRhbGtpbmcgYWJvdXQg ZmVkZXJhdGlvbiB1c2VkIGluIG11bHRpcGxlIG9wZXJhdG9ycyBzY2VuYXJpb3MsIEkgc3VnZ2Vz dCB0aGF0IHRoZXJlIHNob3VsZCBiZSBlYXN0LXdlc3QgaW50ZXJmYWNlIGJldHdlZW4gcGVlciBv cmNoZXN0cmF0aW9uIHN5c3RlbSBpbiB0aGVzZSBvcGVyYXRvcnMuIFRoYXQgZWFzZS13ZXN0IGlu dGVyZmFjZSBpcyBkaWZmZXJlbnQgd2l0aCBpbnRlcm5hbCBFMkUgc2VydmljZSBhY3RpdmF0aW9u IGludGVyZmFjZSBmb3Igc29tZSBzcGVjaWFsIHJlcXVpcmVtZW50IGJldHdlZW4gb3BlcmF0b3Jz LCBzdWNoIGFzIHNlY3VyaXR5LCByZXNvdXJjZSB2aXN1YWxpemF0aW9uLGV0Yy4NCg0KVGhhbmtz LA0KUmljaGFyZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQq7qs6qvLzK 9dPQz965q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQq12Na3o7rJ7tvaytDB+rja x/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRk Lg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmEN Cmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY 1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzA qLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+i oaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2x vtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9y IHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkg dXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNs dWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwg cmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhl IGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhp cyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3Ig ZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0Kt6K8/sjLOiBIdWkgRGVuZyBbbWFp bHRvOmRlbmdodWkwMkBob3RtYWlsLmNvbV0NCreiy83KsbzkOiAyMDE2xOoxMNTCMTDI1SAyMzox NQ0KytW8/sjLOiBDaGVucnVpIChSaWNoYXJkKTsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNh d2dAaWV0Zi5vcmc+DQqzrcvNOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ct Y2hhaXJzQGlldGYub3JnPg0K1vfM4jogUkU6IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNv bXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0DQoNCg0KSGkgUmljaGFyZCwNCg0KVGhh bmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLCBJIHJlY2FsbGVkIHRoYXQgb3RoZXIgdHdvIG9w ZXJhdG9ycyBkdXJpbmcgbGFzdCB0aW1lIGYyZiBtZWV0aW5nIGhhZCBtYWRlIHNvbWUgY29tbWVu dHMgYWJvdXQgZmVkZXJhdGlvbiBpc3N1ZSwgaG9wZSB0aGV5IGNhbiBlbGFib3JhdGUgbW9yZSBk ZXRhaWwgY29tbWVudHMgaGVyZSBhcyB3ZWxsLCBpbmxpbmUgd2l0aCA9PT4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBjaGVucnVpQGh1YXdlaS5jb208bWFpbHRvOmNo ZW5ydWlAaHVhd2VpLmNvbT4NClRvOiBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz47IGRlbmdodWkwMkBob3RtYWlsLmNvbTxtYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29t Pg0KQ0M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW09QU0FXR10gZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBu LXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCkRhdGU6IFN1biwgOSBPY3QgMjAxNiAwMzozNTo0NiAr MDAwMA0KSGkgSHVpIGFuZCBhbGwsDQoNCldoZW4gSSB3ZW50IHRocm91Z2ggdGhlIGRvY3VtZW50 cyBvZiBJRVRGIzk2LEkgbm90aWNlZCB0aGF0IHRoaXMgZHJhZnQgaGFzIHJhaXNlZCBhIGludGVy ZXN0aW5nIHJlcXVpcmVtZW50IGluIENoaW5hIE1vYmlsZSBvZiBFMkUgZGVwbG95bWVudCBpbnRl cmZhY2UgdG8gYSBtdWx0aXBsZSBWUE5zIGNvbXBvc2VkIGluZnJhc3RydWN0dXJlLCBzdWNoIGFz IEwyK0wzIG5ldHdvcmsuIFNvIHRoZSBpbnRlcmZhY2UgY291bGQgbWFrZSB0aGUgc2VydmljZSBm dWxmaWxsbWVudCBhbmQgbWFuYWdlbWVudCBtb3JlIGVhc3kuDQpJcyBteSB1bmRlcnN0YW5kaW5n IHJpZ2h0Pw0KDQo9PT4gWWVzLCBjdXJyZW50IGV4aXN0aW5nIEwzU00gYXJlIG1vc3RseSB0YWxr aW5nIGFib3V0IGN1c3RvbWVyIGZhY2luZyBzZXJ2aWNlIG1vZGVsLg0KdGhpcyByZXF1aXJlbWVu dCBleHBlY3RzIHRvIGhlbHAgb3BlcmF0b3JzIHdpdGggbGFyZ2Ugc2NhbGUgdG8gbWFuZ2UgdGhl IHVuZGVybGF5IG5ldHdvcmsgd2l0aCBhIGdsb2JhbCB2aWV3LiAgKGhlcmUgY291bGQgYmUgYSBt dWx0aXBsZSBvcGVyYXRvcnMsIHRoYXQgaXMgcmVsYXRlZCB0byBmZWRlcmF0aW9uKSBhbiBlbnRl cnByaXNlIGN1c3RvbWVyIG1heSBzaW1wbHkgcmVxdWVzdCBhIEwzIFZQTiBzZXJ2aWNlLCBidXQg b3BlcmF0b3IgaGFzIHRvIHByb3Zpc2lvbiBhbmQgbWFuZ2UgdGhlIGVuZCB0byBlbmQgdW5kZXJs YXkgbmV0d29yayBjb25zdHJ1Y3RlZCB3aXRoIG11bHRpcGxlIEFTZXMgYW5kIHRlY2huaXF1ZXMs IGFuZCBmdXJ0aGVyIGFzc3VyZSB0aGUgc2VydmljZS4gdGhpcyBpcyB0aGUga2V5IGlzc3VlIGZv ciB0b2RheSdzIG9wZXJhdG9ycy4NCg0KSSBkbyBiZWxpZXZlIHRoaXMgaW50ZXJmYWNlIGFuZCBp dHMgbW9kZWwgYXJlIGluZGVlZCBoZWxwZnVsIGZvciBvcGVyYXRvcnMgdG8gc2ltcGxpZnkgb3Bl cmF0aW9ucyBhbmQgbWFuYWdlbWVudC4NCkFuZCBJIHN0aWxsIGhhdmUgc29tZSBxdWVzdGlvbnMg bmVlZCB0byBiZSBkaXNjdXNzZWQgYW5kIGFsaWduZWQgd2l0aCB5b3UgYW5kIGV4cGVydHMgaW4g ZW1haWwgdGhyZWFkLg0KDQoxLldoaWxlIHJlZmVycmluZyB0byBhbm90aGVyIGRyYWZ0IGF0IHNh bWUgbWVldGluZyA8PHNlcnZpY2UgbW9kZWwgZXhwbGFpbmVkPj4gKGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAzLnR4dCks DQpJIGJlbGlldmUgdGhlIGFib3ZlIEUyRSBkZXBsb3ltZW50IGludGVyZmFjZSBzaG91bGQgYmUg cG9zaXRpb24gYmV0d2VlbiBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gYW5kICBuZXR3b3JrIG9yY2hl c3RyYXRpb24oRmlndXJlIDMpLg0KVGhhdCBtZWFuIGl0oa9zIGEgaW50ZXJuYWwgaW50ZXJmYWNl IGluIG9uZSBvcGVyYXRvciBhbmQgaXQgYWN0cyBub3Qgb25seSB0byBpbXBsZW1lbnQgdGhlIGN1 c3RvbWVyIGZhY2luZyBtb2RlbCAoaS5lLiBMM1NNKSxidXQgYWxzbyB0byBtYWludGFpbiwgbW9u aXRvciBhbmQgZGlhZ25vc2UgdGhlIGVuZCB0byBlbmQgUEUtYmFzZWQgVlBOIHNlcnZpY2VzIGNy b3NzaW5nIG11bHRpcGxlIHRlY2hub2xvZ2llcyBkZXBsb3llZCBuZXR3b3JrLg0KSXMgaXQgcmln aHQ/IGFuZCBzaG91bGQgdGhpcyBpbnRlcmZhY2UgbmVlZCB0byBzdXBwb3J0IFZQTiBzZXJ2aWNl IHdoaWNoIG1heWJlIGNyb3NzIG11bHRpcGxlIG9wZXJhdG9ycz8NCj09PiBnb29kIHBvaW50LCB0 aGUgZnV0dXJlIGluIHRoZSBsaW5rIGlzIHF1aXRlIGhlbHBmdWwsIHRoaXMgc2hvdWxkIGJlIHVw ZGF0ZWQgaW4gbmV4dCByZXZpc2lvbi4NCg0KPT0+IGZvciB5b3VyIHF1ZXN0aW9ucyBhYm91dCBt dWx0aXBsZSBvcGVyYXRvcnMsIHRoaXMgaXMgZXhhY3RseSB0aGUgaXNzdWUgcmFpc2VkIGR1cmlu ZyB0aGUgbWVldGluZywgb3BlcmF0b3IgYXJlIGludGVyY29ubmVjdGVkIGVhY2ggb3RoZXIgdGhy b3VnaCBmZWRlcmF0aW9uLCB0aGUgZW5kIHRvIGVuZCBzZXJ2aWNlIG1heSBnbyBhY3Jvc3MgbXVs dGlwbGUgb3BlcmF0b3JzJyBhY2Nlc3MgYW5kIGNvcmUgbmV0d29yay4gdGhhdCBpcyB0aGUgcmVh c29uIHdoeSB3ZSBkZWZpbmUgVlBOIHNlZ21lbnQgd2l0aGluIHRoZSBjb21wb3NlZCBWUE4uIHRo aXMgaGFzbid0IGJlZW4gY29uc2lkZXIgaW4gdGhlIGRvY3VtZW50IGJlZm9yZSwgYnV0IHRoZSBm bGV4aWJpbGl0eSBvZiBjb21wb3NlZCBWUE4gZnJhbWV3b3JrIHNob3VsZCBiZSBpbmNsdWRlZC4N Cg0KMi5BY3R1YWxseSBJoa9tIG5ldyBndXkgaW4gSUVURiwgc28gSaGvbSBub3Qgc3VyZSBpZiB0 aGVyZSBhcmUgZXhpc3Rpbmcgd29ya3MgaW4gSUVURiB3aGljaCBjb3VsZCBpbnN0cnVjdCBvciBt b2RlbGluZyB0aGUgaW50ZXJmYWNlL0UyRS12aWV3IHRvIG1hbmFnZSBhIG11bHRpcGxlIHRlY2hu b2xvZ2llcyBjb21wb3NlZCBuZXR3b3JrLCB3aGljaCBJIGJlbGlldmUgdmVyeSBjb21tb24gaW4g b3BlcmF0b3Khr3MgZGVwbG95bWVudCB3aGlsZSBzdGlsbCBuZWVkIHRvIHByb3ZpZGUgc2ltcGxl IEUyRSBzZXJ2aWNlIGV4cGVyaWVuY2UgdG8gdGhlaXIgY3VzdG9tZXJzLiBNYXliZSB3ZSBjYW4g aW1wcm92ZSBzb21ldGhpbmcgaGVyZS4gU28gaWYgZXhwZXJ0cyBoZXJlIGhhdmUgbW9yZSBiYWNr Z3JvdW5kLCBwbGVhc2UgaGVscCBtZS4gVGhhbmtzLg0KDQo9PT4gYWx0aG91Z2ggaXQgaXMgaW1w b3J0YW50LCBidXQgSSBkaWRuJ3Qgc2VlIGFueSBlMmUgZWZmb3J0IG9uIHRoZSBuZXR3b3JrIHll dC4gdGhlcmUgaXMgYSByZWxhdGVkIHdvcmsgaW4gTDNTTSBpbiBjdXN0b21lciBzZXJ2aWNlIGxl dmVsIGFuZCBzb21lIGRlZGljYXRlZCBWUE4gbW9kZWxzIGluIEJFU1MuIHRoYXQncyB3aHkgSSBy YWlzZSB0aGlzIHRvcGljLiBkZWZpbml0ZWx5IHdlbGNvbWUgYW55IGVmZm9ydCB0byBqb2luIHRo ZSBmb2xsb3dpbmcgZGF0YSBtb2RlbCBkZXNpZ24gaWYgeW91IHJlYWxseSBoYXZlIGEgc3Ryb25n IGJhY2tncm91bmQgb24gaXQuDQoNCjMuQXMgSSB1bmRlcnN0YW5kIHRoaXMgaW50ZXJmYWNlL21v ZGVsIHNob3VsZCBiZSBpbnRlcm5hbCBpbiBvcGVyYXRvcnMsIHNvIEmhr20gbm90IHN1cmUgaWYg dGhlcmUgYW55IG90aGVyIG9wZXJhdG9ycyBhcmUgaW50ZXJlc3RlZCBpdCBhbmQgbmVlZCBhIElF VEYgUkZDPw0KDQo9PT4gSSBkaWQgaGVhciB0d28gYmlnIG9wZXJhdG9ycyBzaG93ZWQgdGhlIGlu dGVyZXN0IGluIHRoaXMgdG9waWMsIGhvcGUgdGhleSBjYW4gam9pbiBhcyB3ZWxsIGluIG91ciBu ZXh0IHJldmlzaW9uLiB0aGlzIG1heSByZWxhdGVkIHRvIG5ldHdvcmsgb3JjaGVzdHJhdG9yLCBP U1MvQlNTIGFuZCBldmVuIGFuYWx5dGljcyBzeXN0ZW0gZnJvbSBkaWZmZXJlbnQgdmVuZG9ycy4g YSBzdGFuZGFyZCBtb2RlbCB3aWxsIGRlZmluaXRlbHkgIGhlcCB0aGUgZGl2ZXJzaXR5IGluIG9u ZSBvcGVyYXRvcidzIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQuDQoNCkJlc3QgcmVnYXJkcywNCg0K REVORyBIdWkNClRoYW5rcy4NCg0KUmVnYXJkcywNClJpY2hhcmQgQ2hlbg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQq7qs6qvLzK9dPQz965q8u+IEh1YXdlaSBUZWNobm9s b2dpZXMgQ28uLCBMdGQuDQq12Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4 MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlz dHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5 q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737 DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnC tqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfr xPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5k IGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhV QVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdo b3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0 bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1p bmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykg aXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSBpdCENCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D572E1351dfweml501mbb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

 

From: Chenrui = (Richard)
Sent: Friday, October 14, 2016 2:45 AM
To: Lucy yong; Hui Deng
Cc: opsawg-chairs@ietf.org; opsawg@ietf.org; Songxiaolin; zhangliya<= br> Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Lucy,

 <= /p>

Very good comments and su= ggestions. I believe I can understand the requirement from China Mobile but= I haven=A1=AFt reached as deep understanding as you.

I understand it=A1=AFs in= deed none business with a new VPN service. It=A1=AFs just how operator coul= d specify the end-2-end deployment view of existing L2/L3VPN service crossing multiple operator domains.

[Lucy] Good. I hope= this is the case.<= /span>

That can simplify the ser= vice activation or deployment progress to some extent due to orchestration = capability. Right?

So I believe it ,thoug= h not  sure if it=A1=AFs common needs  from operators.  I=A1= =AFm  looking for more comments.=

 <= /p>

Please Hui correct me if = I=A1=AFm mistaken the intent from you draft.

 <= /p>

BTW,in your sentence o= f  =A1=B0do operator need a hierarchical operator VPN service model or= a flat one?=A1=B1 .I=A1=AFm not sure the meaning of =A1=B0 hierarchical=A1= =B1 or =A1=B0flat=A1=B1, are they the same solutions for this requirement or different solutions? A= re they existing work in IETF for this requirement?

[Lucy] The based L2= /L3VPN architecture is:  CE-(AC)-PE-(provider backbone networks)-PE-(A= C)-CE.  L3SM already addresses that the provider backbone networks can include multiple domains that are interconnected via PE-PE or ASBR-ASB= R. Another part is the AC that can be constructed through another network d= omain such as access network. In this case, the access network provides an = L2VPN service to the end-to-end VPN service; from the end-to-end VPN service perspective, it uses the acce= ss network to provide a link for AC. What I means here, if SP operator (i.e= . end-to-end VPN operator) wants a service model including the access netwo= rk domain/l2vpn (flat model) or a service model  with AC that AC reference to another L2VPN service. = (hierarchical model) This is what I want to express. L3SM uses hierarchical= approach.

 

Thanks,<= /span>

Lucy=

 

Thanks.

Richard

 <= /p>


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
3D"Company_logo"=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF= =BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA= =B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB= =CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2= =C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!=

 <= /p>

=B7=A2=BC=FE=C8=CB: Lucy yong
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2016=C4=EA10=D4=C214<= span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:SimSun">=C8=D5 3:15
=CA=D5=BC=FE=C8=CB:= Hui Deng; Chenrui (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed= -vpn-sm-requirements-01.txt

 

Hi Hui and Rui,

 

The draft introduction= starts that ISPs have interest on providing Provider Edge (PE) based virtu= al private network (VPN) service and names it as composed VPN service and intends to specify the service model requirements for the = composed VPN. Then it states that this service model is from operator persp= ective.

 

My comments and sugges= tions:

 

=A1=A4      &= nbsp;  Is this a bran= d new VPN service offered by Internet Service Providers or a use case for e= xisting VPN services specified in [RFC4364] [RFC6742][RFC7432]? If this is a new service, please make that very clear in the beginning and= describe what is the new service, service architecture, and architecture c= omponents. If this is a use case for existing VPN services; please do not c= all it composed VPN service (make a lot of confusions.)

=A1=A4      &= nbsp;  Assume this is= for existing VPNs and draft wants to specify the operator view of e-2-e VP= Ns that may across multiple operator domains. Suggests to start with existing VPN service architecture view and components: CE, P= E, provider backbone networks, AC etc. and explain how operator may use mul= tiple network domains to achieve it. For examples, PEs that customer sites = attach to may exist in different ASes;  the AC between CE-PE may be across an access network, etc.

=A1=A4      &= nbsp;  Existing VPN s= ervice across multiple networks are not new and current solutions support t= hat.

=A1=A4      &= nbsp;  Text =A1=B0Pro= vider Edge (PE based virtual private network (VPN services, in which the tu= nnel endpoints are the PE devices=A1=B1 is very confuse. Will the tunnel is between PE-PE or PE-CE? Will this tunnel is different from curre= nt tunnel techniques in [RFC4364] [RFC6742][RFC7432]?=

=A1=A4      &= nbsp;  Existing VPN s= ervice PE and CE have its role. Text: =A1=B0CE device do not need to have a= ny special VPN capability=A1=B1 is confused too.

=A1=A4      &= nbsp;  When an operat= or gets customer VPN service request that is an e2e service description (dr= aft-ietf-l3sm-l3vpn-service-model), he will design individual segments (CE-PE and PE-PE) to meet the request. The result may mean that t= he VPN is implemented across several domains.   

=A1=A4      &= nbsp;  What values th= at a flat operator VPN service model provides?  two segment VPNs may n= ot even at the same layers. If one segment VPN just provides a transit link or access link to the VPN service, do operator need a hiera= rchical operator VPN service model or a flat one?

=A1=A4      &= nbsp;   figure i= n page 5 very confusion. If this is for existing VPN service, please replac= e =A1=B0Composed VPN=A1=B1 with =A1=B0L3VPN=A1=B1 (or =A1=B0L2VPN=A1=B1), a= nd replace AP with AC.

=A1=A4      &= nbsp;  If this is a n= ew VPN service, please define what is the composed VPN service and the arch= itecture. Then clarify if current IETF has solutions for this service.

 

Regards,

Lucy

 

 

 

 

Hi Richard,

 

I agree with your point, in order to meet those operator= s expectation, the draft may need to be updated and reflect that architectu= re.

 

Regarding to solution, that will be great, thanks a lot = for your contribution to IETF if there is any proof of concept to this.

 

thanks a lot for your suggestion

 

Best regards,

 

DENG Hui

From: chenrui@huawei.com
To: denghui02@hotmail.com; opsawg@ietf.org
CC: opsawg-chairs@ietf.org Subject: =B4=F0=B8= =B4: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
Date: Tue, 11 Oct 2016 02:27:14 +0000

Hi Hui,

 

Thanks for these clarific= ations. Maybe we can talk about it more in next meeting and we can provide = a initial solution around these issues.

 

BTW, if we talking about fe= deration used in multiple operators scenarios, I suggest that there should = be east-west interface between peer orchestration system in these operators= . That ease-west interface is different with internal E2E service activation interface for some special requirement bet= ween operators, such as security, resource visualization,etc.=

 

Thanks,

Richard

 


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC= =EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA= =B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB= =CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2= =C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

=B7=A2=BC=FE=C8=CB:= Hui Deng [mailto:denghui02@hotmail.com= ]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C210=C8=D5<= span style=3D"font-size:10.0pt;font-family:"Calibri","sans-s= erif""> 23:15
=CA=D5=BC=FE=C8=CB: Ch= enrui (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPS= AWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 


Hi Richard,

 

Thanks a lot for your comments, I recalled that other tw= o operators during last time f2f meeting had made some comments about feder= ation issue, hope they can elaborate more detail comments here as well, inline with =3D=3D>

From: chenrui@huawei.com
To: opsawg@ietf.org; denghui02@hotmail.com
CC: opsawg-chairs@ietf.org Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=
Date: Sun, 9 Oct 2016 03:35:46 +0000

Hi Hui and all,

 

When I went through the documents of IETF#96,I noticed that t= his draft has raised a interesting requirement in China Mobile of E2E deplo= yment interface to a multiple VPNs composed infrastructure, such as L2+L3 network. So the interface could make the service fulfill= ment and management more easy.

Is my understanding right?

 

=3D=3D> Yes, current existing L3SM are mostly talking abou= t customer facing service model.

this requirement expects to help operators with large scale t= o mange the underlay network with a global view.  (here could be a mul= tiple operators, that is related to federation) an enterprise customer may simply request a L3 VPN service, but operator has = to provision and mange the end to end underlay network constructed with mul= tiple ASes and techniques, and further assure the service. this is the key = issue for today's operators.

 

I do believe this interface and its model are indeed helpful = for operators to simplify operations and management.

And I still have some questions need to be discussed and alig= ned with you and experts in email thread.

 

1.While referring to another draft at same meeting <<se= rvice model explained>> (https://tools.i= etf.org/id/draft-wu-opsawg-service-model-explained-03.txt),

I believe the above E2E deployment interface should be positi= on between service orchestration and  network orchestration(Figure 3).=

That mean it=A1=AFs a internal interface in one operator and = it acts not only to implement the customer facing model (i.e. L3SM),but als= o to maintain, monitor and diagnose the end to end PE-based VPN services crossing multiple technologies deployed network.<= o:p>

Is it right? and should this interface need to support VPN se= rvice which maybe cross multiple operators?

=3D=3D> good point, the future in the link is quite helpfu= l, this should be updated in next revision.

 

=3D=3D> for your questions about multiple operators, this = is exactly the issue raised during the meeting, operator are interconnected= each other through federation, the end to end service may go across multiple operators' access and core network. that is the rea= son why we define VPN segment within the composed VPN. this hasn't been con= sider in the document before, but the flexibility of composed VPN framework= should be included.

 

2.Actually I=A1=AFm new guy in IETF, so I=A1=AFm not sure if = there are existing works in IETF which could instruct or modeling the inter= face/E2E-view to manage a multiple technologies composed network, which I believe very common in operator=A1=AFs deployment while s= till need to provide simple E2E service experience to their customers. Mayb= e we can improve something here. So if experts here have more background, p= lease help me. Thanks.

 

=3D=3D> although it is important, but I didn't see any e2e= effort on the network yet. there is a related work in L3SM in customer ser= vice level and some dedicated VPN models in BESS. that's why I raise this topic. definitely welcome any effort to join the followin= g data model design if you really have a strong background on it.

 

3.As I understand this interface/model should be internal in = operators, so I=A1=AFm not sure if there any other operators are interested= it and need a IETF RFC?

 

=3D=3D> I did hear two big operators showed the interest i= n this topic, hope they can join as well in our next revision. this may rel= ated to network orchestrator, OSS/BSS and even analytics system from different vendors. a standard model will definitely  hep = the diversity in one operator's production environment.

 

Best regards,

 

DENG Hui

Thanks.

 

Regards,

Richard Chen

 


=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC= =EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC= =D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF= =DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4= =B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_2691CE0099834E4A9C5044EEC662BB9D572E1351dfweml501mbb_-- From nobody Mon Oct 17 00:17:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A074F1295A3; Mon, 17 Oct 2016 00:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 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.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 UZLouahxue7t; Mon, 17 Oct 2016 00:17:01 -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 7969312949D; Mon, 17 Oct 2016 00:17:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTH45975; Mon, 17 Oct 2016 07:16:57 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 17 Oct 2016 08:16:55 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.186]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Mon, 17 Oct 2016 15:16:42 +0800 From: "Chenrui (Richard)" To: Lucy yong , Hui Deng Thread-Topic: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSJYYRaoB4EZHCnEeWdW72DK055qCnh9aA///0CACABL2CQA== Date: Mon, 17 Oct 2016 07:16:41 +0000 Message-ID: <0D5441A3DF1544449089458210966F29788F114A@SZXEMA501-MBX.china.huawei.com> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> <0D5441A3DF1544449089458210966F29788F0C95@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E1351@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572E1351@dfweml501-mbb> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.55.144] Content-Type: multipart/alternative; boundary="_000_0D5441A3DF1544449089458210966F29788F114ASZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58047AEA.00F3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e98f4378043959749a6b9d7441b2e582 Archived-At: Cc: Songxiaolin , "opsawg@ietf.org" , "opsawg-chairs@ietf.org" , zhangliya Subject: [OPSAWG] =?gb2312?b?tPC4tDogID8/OiAgZHJhZnQtZGVuZy1vcHNhd2ctY29t?= =?gb2312?b?cG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQ=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 07:17:05 -0000 --_000_0D5441A3DF1544449089458210966F29788F114ASZXEMA501MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTHVjeQ0KDQpUaGFua3MgZm9yIHRoZXNlIGNsYXJpZmljYXRpb25zLg0KDQoNCkZyb20gdGhl IEFic3RyYWN0IHNlY3Rpb24gb2YgTDNTTSBkcmFmdChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwtMTcpLCBJIHVuZGVyc3RhbmQg TDNTTSBpcyBhIGN1c3RvbWVyLWZhY2luZyBzZXJ2aWNlIG1vZGVsIHVzZWShsGJldHdlZW4gY3Vz dG9tZXJzIGFuZCBuZXR3b3JrIG9wZXJhdG9ycw0KDQp0byBkZWxpdmVyIGEgTGF5ZXIgMyBQcm92 aWRlciBQcm92aXNpb25lZCBWUE4gc2VydmljZaGxLg0KDQpJdKGvcyBub3QgdXNlZCBmb3IgcHJv dmlkaW5nIGEgZW5kLTItZW5kIGRlcGxveW1lbnQgdmlldyBvZiBleGlzdGluZyBMMi9MM1ZQTiBz ZXJ2aWNlIGNyb3NzaW5nIG11bHRpcGxlIG9wZXJhdG9yIGRvbWFpbnMuDQoNCg0KDQpTbyBJIHVu ZGVyc3RhbmQgeW91ciBtZWFuaW5nIGlzIHRoYXQgbWF5YmUgd2UgY291bGQgdXNlIHNpbWlsYXIg bWV0aG9kb2xvZ3koaGllcmFyY2hpY2FsIGFwcHJvYWNoKSB0byBkZWZpbmUgdGhlIGUyZSBkZXBs b3ltZW50IG1vZGVsLCB3aGljaCBoYXMgdGhlIEwyL0wzVlBOIGJhc2ljIHNlcnZpY2UgaW5mb3Jt YXRpb24gYW5kIGF0dHJpYnV0ZXMgcmVmZXJlbmNlIHRvIG11bHRpcGxlIHNlZ21lbnRzKEFDLGJh Y2tib25lLGV0YykgaW5mb3JtYXRpb24uDQoNCg0KDQpBbSBJIG1pc3Rha2VuIHNvbWV0aGluZz8N Cg0KDQoNClRoYW5rcywNCg0KUmljaGFyZA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRk Lg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXYINPKseCjujUxODEyOQ0KSHVhd2VpIFRl Y2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVu IDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6Kj rL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL 0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3 oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPK vP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVu dHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQpp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBh cnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVy c29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCrei vP7IyzogTHVjeSB5b25nDQq3osvNyrG85DogMjAxNsTqMTDUwjE0yNUgMjI6MjMNCsrVvP7Iyzog Q2hlbnJ1aSAoUmljaGFyZCk7IEh1aSBEZW5nDQqzrcvNOiBvcHNhd2ctY2hhaXJzQGlldGYub3Jn OyBvcHNhd2dAaWV0Zi5vcmc7IFNvbmd4aWFvbGluOyB6aGFuZ2xpeWENCtb3zOI6IFJFOiBbT1BT QVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0w MS50eHQNCg0KDQoNCkZyb206IENoZW5ydWkgKFJpY2hhcmQpDQpTZW50OiBGcmlkYXksIE9jdG9i ZXIgMTQsIDIwMTYgMjo0NSBBTQ0KVG86IEx1Y3kgeW9uZzsgSHVpIERlbmcNCkNjOiBvcHNhd2ct Y2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPjsgb3BzYXdnQGll dGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBTb25neGlhb2xpbjsgemhhbmdsaXlhDQpT dWJqZWN0OiA/PzogW09QU0FXR10gPz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1z bS1yZXF1aXJlbWVudHMtMDEudHh0DQoNCkhpIEx1Y3ksDQoNClZlcnkgZ29vZCBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMuIEkgYmVsaWV2ZSBJIGNhbiB1bmRlcnN0YW5kIHRoZSByZXF1aXJlbWVu dCBmcm9tIENoaW5hIE1vYmlsZSBidXQgSSBoYXZlbqGvdCByZWFjaGVkIGFzIGRlZXAgdW5kZXJz dGFuZGluZyBhcyB5b3UuDQpJIHVuZGVyc3RhbmQgaXShr3MgaW5kZWVkIG5vbmUgYnVzaW5lc3Mg d2l0aCBhIG5ldyBWUE4gc2VydmljZS4gSXShr3MganVzdCBob3cgb3BlcmF0b3IgY291bGQgc3Bl Y2lmeSB0aGUgZW5kLTItZW5kIGRlcGxveW1lbnQgdmlldyBvZiBleGlzdGluZyBMMi9MM1ZQTiBz ZXJ2aWNlIGNyb3NzaW5nIG11bHRpcGxlIG9wZXJhdG9yIGRvbWFpbnMuDQpbTHVjeV0gR29vZC4g SSBob3BlIHRoaXMgaXMgdGhlIGNhc2UuDQpUaGF0IGNhbiBzaW1wbGlmeSB0aGUgc2VydmljZSBh Y3RpdmF0aW9uIG9yIGRlcGxveW1lbnQgcHJvZ3Jlc3MgdG8gc29tZSBleHRlbnQgZHVlIHRvIG9y Y2hlc3RyYXRpb24gY2FwYWJpbGl0eS4gUmlnaHQ/DQpTbyBJIGJlbGlldmUgaXQgLHRob3VnaCBu b3QgIHN1cmUgaWYgaXShr3MgY29tbW9uIG5lZWRzICBmcm9tIG9wZXJhdG9ycy4gIEmhr20gIGxv b2tpbmcgZm9yIG1vcmUgY29tbWVudHMuDQoNClBsZWFzZSBIdWkgY29ycmVjdCBtZSBpZiBJoa9t IG1pc3Rha2VuIHRoZSBpbnRlbnQgZnJvbSB5b3UgZHJhZnQuDQoNCkJUVyxpbiB5b3VyIHNlbnRl bmNlIG9mICChsGRvIG9wZXJhdG9yIG5lZWQgYSBoaWVyYXJjaGljYWwgb3BlcmF0b3IgVlBOIHNl cnZpY2UgbW9kZWwgb3IgYSBmbGF0IG9uZT+hsSAuSaGvbSBub3Qgc3VyZSB0aGUgbWVhbmluZyBv ZiChsCBoaWVyYXJjaGljYWyhsSBvciChsGZsYXShsSwgYXJlIHRoZXkgdGhlIHNhbWUgc29sdXRp b25zIGZvciB0aGlzIHJlcXVpcmVtZW50IG9yIGRpZmZlcmVudCBzb2x1dGlvbnM/IEFyZSB0aGV5 IGV4aXN0aW5nIHdvcmsgaW4gSUVURiBmb3IgdGhpcyByZXF1aXJlbWVudD8NCltMdWN5XSBUaGUg YmFzZWQgTDIvTDNWUE4gYXJjaGl0ZWN0dXJlIGlzOiAgQ0UtKEFDKS1QRS0ocHJvdmlkZXIgYmFj a2JvbmUgbmV0d29ya3MpLVBFLShBQyktQ0UuICBMM1NNIGFscmVhZHkgYWRkcmVzc2VzIHRoYXQg dGhlIHByb3ZpZGVyIGJhY2tib25lIG5ldHdvcmtzIGNhbiBpbmNsdWRlIG11bHRpcGxlIGRvbWFp bnMgdGhhdCBhcmUgaW50ZXJjb25uZWN0ZWQgdmlhIFBFLVBFIG9yIEFTQlItQVNCUi4gQW5vdGhl ciBwYXJ0IGlzIHRoZSBBQyB0aGF0IGNhbiBiZSBjb25zdHJ1Y3RlZCB0aHJvdWdoIGFub3RoZXIg bmV0d29yayBkb21haW4gc3VjaCBhcyBhY2Nlc3MgbmV0d29yay4gSW4gdGhpcyBjYXNlLCB0aGUg YWNjZXNzIG5ldHdvcmsgcHJvdmlkZXMgYW4gTDJWUE4gc2VydmljZSB0byB0aGUgZW5kLXRvLWVu ZCBWUE4gc2VydmljZTsgZnJvbSB0aGUgZW5kLXRvLWVuZCBWUE4gc2VydmljZSBwZXJzcGVjdGl2 ZSwgaXQgdXNlcyB0aGUgYWNjZXNzIG5ldHdvcmsgdG8gcHJvdmlkZSBhIGxpbmsgZm9yIEFDLiBX aGF0IEkgbWVhbnMgaGVyZSwgaWYgU1Agb3BlcmF0b3IgKGkuZS4gZW5kLXRvLWVuZCBWUE4gb3Bl cmF0b3IpIHdhbnRzIGEgc2VydmljZSBtb2RlbCBpbmNsdWRpbmcgdGhlIGFjY2VzcyBuZXR3b3Jr IGRvbWFpbi9sMnZwbiAoZmxhdCBtb2RlbCkgb3IgYSBzZXJ2aWNlIG1vZGVsICB3aXRoIEFDIHRo YXQgQUMgcmVmZXJlbmNlIHRvIGFub3RoZXIgTDJWUE4gc2VydmljZS4gKGhpZXJhcmNoaWNhbCBt b2RlbCkgVGhpcyBpcyB3aGF0IEkgd2FudCB0byBleHByZXNzLiBMM1NNIHVzZXMgaGllcmFyY2hp Y2FsIGFwcHJvYWNoLg0KDQpUaGFua3MsDQpMdWN5DQoNClRoYW5rcy4NClJpY2hhcmQNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkg VGVjaG5vbG9naWVzIENvLiwgTHRkLg0KW0NvbXBhbnlfbG9nb1212Na3o7rJ7tvaytDB+rjax/jb 4Mzvu6rOqrv5tdgg08qx4KO6NTE4MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0K QmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCmh0 dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+ 08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW 0MHQs/a1xLj2yMu78si61+mho737DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWr srvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI 57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPK vP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRo ZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNl IG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRp bmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBl LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1h aWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0Kt6K8/sjLOiBMdWN5IHlvbmcNCreiy83K sbzkOiAyMDE2xOoxMNTCMTTI1SAzOjE1DQrK1bz+yMs6IEh1aSBEZW5nOyBDaGVucnVpIChSaWNo YXJkKTsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQqzrcvNOiBvcHNh d2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0K1vfM4jog UkU6IFtPUFNBV0ddID8/OiBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWly ZW1lbnRzLTAxLnR4dA0KDQpIaSBIdWkgYW5kIFJ1aSwNCg0KVGhlIGRyYWZ0IGludHJvZHVjdGlv biBzdGFydHMgdGhhdCBJU1BzIGhhdmUgaW50ZXJlc3Qgb24gcHJvdmlkaW5nIFByb3ZpZGVyIEVk Z2UgKFBFKSBiYXNlZCB2aXJ0dWFsIHByaXZhdGUgbmV0d29yayAoVlBOKSBzZXJ2aWNlIGFuZCBu YW1lcyBpdCBhcyBjb21wb3NlZCBWUE4gc2VydmljZSBhbmQgaW50ZW5kcyB0byBzcGVjaWZ5IHRo ZSBzZXJ2aWNlIG1vZGVsIHJlcXVpcmVtZW50cyBmb3IgdGhlIGNvbXBvc2VkIFZQTi4gVGhlbiBp dCBzdGF0ZXMgdGhhdCB0aGlzIHNlcnZpY2UgbW9kZWwgaXMgZnJvbSBvcGVyYXRvciBwZXJzcGVj dGl2ZS4NCg0KTXkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zOg0KDQoNCqGkICAgICAgICBJcyB0 aGlzIGEgYnJhbmQgbmV3IFZQTiBzZXJ2aWNlIG9mZmVyZWQgYnkgSW50ZXJuZXQgU2VydmljZSBQ cm92aWRlcnMgb3IgYSB1c2UgY2FzZSBmb3IgZXhpc3RpbmcgVlBOIHNlcnZpY2VzIHNwZWNpZmll ZCBpbiBbUkZDNDM2NF0gW1JGQzY3NDJdW1JGQzc0MzJdPyBJZiB0aGlzIGlzIGEgbmV3IHNlcnZp Y2UsIHBsZWFzZSBtYWtlIHRoYXQgdmVyeSBjbGVhciBpbiB0aGUgYmVnaW5uaW5nIGFuZCBkZXNj cmliZSB3aGF0IGlzIHRoZSBuZXcgc2VydmljZSwgc2VydmljZSBhcmNoaXRlY3R1cmUsIGFuZCBh cmNoaXRlY3R1cmUgY29tcG9uZW50cy4gSWYgdGhpcyBpcyBhIHVzZSBjYXNlIGZvciBleGlzdGlu ZyBWUE4gc2VydmljZXM7IHBsZWFzZSBkbyBub3QgY2FsbCBpdCBjb21wb3NlZCBWUE4gc2Vydmlj ZSAobWFrZSBhIGxvdCBvZiBjb25mdXNpb25zLikNCg0KoaQgICAgICAgIEFzc3VtZSB0aGlzIGlz IGZvciBleGlzdGluZyBWUE5zIGFuZCBkcmFmdCB3YW50cyB0byBzcGVjaWZ5IHRoZSBvcGVyYXRv ciB2aWV3IG9mIGUtMi1lIFZQTnMgdGhhdCBtYXkgYWNyb3NzIG11bHRpcGxlIG9wZXJhdG9yIGRv bWFpbnMuIFN1Z2dlc3RzIHRvIHN0YXJ0IHdpdGggZXhpc3RpbmcgVlBOIHNlcnZpY2UgYXJjaGl0 ZWN0dXJlIHZpZXcgYW5kIGNvbXBvbmVudHM6IENFLCBQRSwgcHJvdmlkZXIgYmFja2JvbmUgbmV0 d29ya3MsIEFDIGV0Yy4gYW5kIGV4cGxhaW4gaG93IG9wZXJhdG9yIG1heSB1c2UgbXVsdGlwbGUg bmV0d29yayBkb21haW5zIHRvIGFjaGlldmUgaXQuIEZvciBleGFtcGxlcywgUEVzIHRoYXQgY3Vz dG9tZXIgc2l0ZXMgYXR0YWNoIHRvIG1heSBleGlzdCBpbiBkaWZmZXJlbnQgQVNlczsgIHRoZSBB QyBiZXR3ZWVuIENFLVBFIG1heSBiZSBhY3Jvc3MgYW4gYWNjZXNzIG5ldHdvcmssIGV0Yy4NCg0K oaQgICAgICAgIEV4aXN0aW5nIFZQTiBzZXJ2aWNlIGFjcm9zcyBtdWx0aXBsZSBuZXR3b3JrcyBh cmUgbm90IG5ldyBhbmQgY3VycmVudCBzb2x1dGlvbnMgc3VwcG9ydCB0aGF0Lg0KDQqhpCAgICAg ICAgVGV4dCChsFByb3ZpZGVyIEVkZ2UgKFBFIGJhc2VkIHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3Jr IChWUE4gc2VydmljZXMsIGluIHdoaWNoIHRoZSB0dW5uZWwgZW5kcG9pbnRzIGFyZSB0aGUgUEUg ZGV2aWNlc6GxIGlzIHZlcnkgY29uZnVzZS4gV2lsbCB0aGUgdHVubmVsIGlzIGJldHdlZW4gUEUt UEUgb3IgUEUtQ0U/IFdpbGwgdGhpcyB0dW5uZWwgaXMgZGlmZmVyZW50IGZyb20gY3VycmVudCB0 dW5uZWwgdGVjaG5pcXVlcyBpbiBbUkZDNDM2NF0gW1JGQzY3NDJdW1JGQzc0MzJdPw0KDQqhpCAg ICAgICAgRXhpc3RpbmcgVlBOIHNlcnZpY2UgUEUgYW5kIENFIGhhdmUgaXRzIHJvbGUuIFRleHQ6 IKGwQ0UgZGV2aWNlIGRvIG5vdCBuZWVkIHRvIGhhdmUgYW55IHNwZWNpYWwgVlBOIGNhcGFiaWxp dHmhsSBpcyBjb25mdXNlZCB0b28uDQoNCqGkICAgICAgICBXaGVuIGFuIG9wZXJhdG9yIGdldHMg Y3VzdG9tZXIgVlBOIHNlcnZpY2UgcmVxdWVzdCB0aGF0IGlzIGFuIGUyZSBzZXJ2aWNlIGRlc2Ny aXB0aW9uIChkcmFmdC1pZXRmLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbCksIGhlIHdpbGwgZGVz aWduIGluZGl2aWR1YWwgc2VnbWVudHMgKENFLVBFIGFuZCBQRS1QRSkgdG8gbWVldCB0aGUgcmVx dWVzdC4gVGhlIHJlc3VsdCBtYXkgbWVhbiB0aGF0IHRoZSBWUE4gaXMgaW1wbGVtZW50ZWQgYWNy b3NzIHNldmVyYWwgZG9tYWlucy4NCg0KoaQgICAgICAgIFdoYXQgdmFsdWVzIHRoYXQgYSBmbGF0 IG9wZXJhdG9yIFZQTiBzZXJ2aWNlIG1vZGVsIHByb3ZpZGVzPyAgdHdvIHNlZ21lbnQgVlBOcyBt YXkgbm90IGV2ZW4gYXQgdGhlIHNhbWUgbGF5ZXJzLiBJZiBvbmUgc2VnbWVudCBWUE4ganVzdCBw cm92aWRlcyBhIHRyYW5zaXQgbGluayBvciBhY2Nlc3MgbGluayB0byB0aGUgVlBOIHNlcnZpY2Us IGRvIG9wZXJhdG9yIG5lZWQgYSBoaWVyYXJjaGljYWwgb3BlcmF0b3IgVlBOIHNlcnZpY2UgbW9k ZWwgb3IgYSBmbGF0IG9uZT8NCg0KoaQgICAgICAgICBmaWd1cmUgaW4gcGFnZSA1IHZlcnkgY29u ZnVzaW9uLiBJZiB0aGlzIGlzIGZvciBleGlzdGluZyBWUE4gc2VydmljZSwgcGxlYXNlIHJlcGxh Y2UgobBDb21wb3NlZCBWUE6hsSB3aXRoIKGwTDNWUE6hsSAob3IgobBMMlZQTqGxKSwgYW5kIHJl cGxhY2UgQVAgd2l0aCBBQy4NCg0KoaQgICAgICAgIElmIHRoaXMgaXMgYSBuZXcgVlBOIHNlcnZp Y2UsIHBsZWFzZSBkZWZpbmUgd2hhdCBpcyB0aGUgY29tcG9zZWQgVlBOIHNlcnZpY2UgYW5kIHRo ZSBhcmNoaXRlY3R1cmUuIFRoZW4gY2xhcmlmeSBpZiBjdXJyZW50IElFVEYgaGFzIHNvbHV0aW9u cyBmb3IgdGhpcyBzZXJ2aWNlLg0KDQpSZWdhcmRzLA0KTHVjeQ0KDQoNCg0KRnJvbTogT1BTQVdH IFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIdWkgRGVuZw0K U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDE2IDEwOjI4IEFNDQpUbzogQ2hlbnJ1aSAo UmljaGFyZCk7IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KQ2M6IG9w c2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW09QU0FXR10gPz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1y ZXF1aXJlbWVudHMtMDEudHh0DQoNCkhpIFJpY2hhcmQsDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHBv aW50LCBpbiBvcmRlciB0byBtZWV0IHRob3NlIG9wZXJhdG9ycyBleHBlY3RhdGlvbiwgdGhlIGRy YWZ0IG1heSBuZWVkIHRvIGJlIHVwZGF0ZWQgYW5kIHJlZmxlY3QgdGhhdCBhcmNoaXRlY3R1cmUu DQoNClJlZ2FyZGluZyB0byBzb2x1dGlvbiwgdGhhdCB3aWxsIGJlIGdyZWF0LCB0aGFua3MgYSBs b3QgZm9yIHlvdXIgY29udHJpYnV0aW9uIHRvIElFVEYgaWYgdGhlcmUgaXMgYW55IHByb29mIG9m IGNvbmNlcHQgdG8gdGhpcy4NCg0KdGhhbmtzIGEgbG90IGZvciB5b3VyIHN1Z2dlc3Rpb24NCg0K QmVzdCByZWdhcmRzLA0KDQpERU5HIEh1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IGNoZW5ydWlAaHVhd2VpLmNvbTxtYWlsdG86Y2hlbnJ1aUBodWF3ZWkuY29tPg0K VG86IGRlbmdodWkwMkBob3RtYWlsLmNvbTxtYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tPjsg b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpDQzogb3BzYXdnLWNoYWly c0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6ILTwuLQ6 IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMt MDEudHh0DQpEYXRlOiBUdWUsIDExIE9jdCAyMDE2IDAyOjI3OjE0ICswMDAwDQpIaSBIdWksDQoN ClRoYW5rcyBmb3IgdGhlc2UgY2xhcmlmaWNhdGlvbnMuIE1heWJlIHdlIGNhbiB0YWxrIGFib3V0 IGl0IG1vcmUgaW4gbmV4dCBtZWV0aW5nIGFuZCB3ZSBjYW4gcHJvdmlkZSBhIGluaXRpYWwgc29s dXRpb24gYXJvdW5kIHRoZXNlIGlzc3Vlcy4NCg0KQlRXLCBpZiB3ZSB0YWxraW5nIGFib3V0IGZl ZGVyYXRpb24gdXNlZCBpbiBtdWx0aXBsZSBvcGVyYXRvcnMgc2NlbmFyaW9zLCBJIHN1Z2dlc3Qg dGhhdCB0aGVyZSBzaG91bGQgYmUgZWFzdC13ZXN0IGludGVyZmFjZSBiZXR3ZWVuIHBlZXIgb3Jj aGVzdHJhdGlvbiBzeXN0ZW0gaW4gdGhlc2Ugb3BlcmF0b3JzLiBUaGF0IGVhc2Utd2VzdCBpbnRl cmZhY2UgaXMgZGlmZmVyZW50IHdpdGggaW50ZXJuYWwgRTJFIHNlcnZpY2UgYWN0aXZhdGlvbiBp bnRlcmZhY2UgZm9yIHNvbWUgc3BlY2lhbCByZXF1aXJlbWVudCBiZXR3ZWVuIG9wZXJhdG9ycywg c3VjaCBhcyBzZWN1cml0eSwgcmVzb3VyY2UgdmlzdWFsaXphdGlvbixldGMuDQoNClRoYW5rcywN ClJpY2hhcmQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT 0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KtdjWt6O6ye7b2srQwfq42sf4 2+DM77uqzqq7+bXYINPKseCjujUxODEyOQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4N CkJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpo dHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQqx vtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na3 1tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1 q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGj yOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7T yrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0 aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVz ZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVk aW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJl cHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMg ZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVt YWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCreivP7IyzogSHVpIERlbmcgW21haWx0 bzpkZW5naHVpMDJAaG90bWFpbC5jb21dDQq3osvNyrG85DogMjAxNsTqMTDUwjEwyNUgMjM6MTUN CsrVvP7IyzogQ2hlbnJ1aSAoUmljaGFyZCk7IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdn QGlldGYub3JnPg0Ks63LzTogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNo YWlyc0BpZXRmLm9yZz4NCtb3zOI6IFJFOiBbT1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21w b3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KDQoNCkhpIFJpY2hhcmQsDQoNClRoYW5r cyBhIGxvdCBmb3IgeW91ciBjb21tZW50cywgSSByZWNhbGxlZCB0aGF0IG90aGVyIHR3byBvcGVy YXRvcnMgZHVyaW5nIGxhc3QgdGltZSBmMmYgbWVldGluZyBoYWQgbWFkZSBzb21lIGNvbW1lbnRz IGFib3V0IGZlZGVyYXRpb24gaXNzdWUsIGhvcGUgdGhleSBjYW4gZWxhYm9yYXRlIG1vcmUgZGV0 YWlsIGNvbW1lbnRzIGhlcmUgYXMgd2VsbCwgaW5saW5lIHdpdGggPT0+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogY2hlbnJ1aUBodWF3ZWkuY29tPG1haWx0bzpjaGVu cnVpQGh1YXdlaS5jb20+DQpUbzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5v cmc+OyBkZW5naHVpMDJAaG90bWFpbC5jb208bWFpbHRvOmRlbmdodWkwMkBob3RtYWlsLmNvbT4N CkNDOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1z bS1yZXF1aXJlbWVudHMtMDEudHh0DQpEYXRlOiBTdW4sIDkgT2N0IDIwMTYgMDM6MzU6NDYgKzAw MDANCkhpIEh1aSBhbmQgYWxsLA0KDQpXaGVuIEkgd2VudCB0aHJvdWdoIHRoZSBkb2N1bWVudHMg b2YgSUVURiM5NixJIG5vdGljZWQgdGhhdCB0aGlzIGRyYWZ0IGhhcyByYWlzZWQgYSBpbnRlcmVz dGluZyByZXF1aXJlbWVudCBpbiBDaGluYSBNb2JpbGUgb2YgRTJFIGRlcGxveW1lbnQgaW50ZXJm YWNlIHRvIGEgbXVsdGlwbGUgVlBOcyBjb21wb3NlZCBpbmZyYXN0cnVjdHVyZSwgc3VjaCBhcyBM MitMMyBuZXR3b3JrLiBTbyB0aGUgaW50ZXJmYWNlIGNvdWxkIG1ha2UgdGhlIHNlcnZpY2UgZnVs ZmlsbG1lbnQgYW5kIG1hbmFnZW1lbnQgbW9yZSBlYXN5Lg0KSXMgbXkgdW5kZXJzdGFuZGluZyBy aWdodD8NCg0KPT0+IFllcywgY3VycmVudCBleGlzdGluZyBMM1NNIGFyZSBtb3N0bHkgdGFsa2lu ZyBhYm91dCBjdXN0b21lciBmYWNpbmcgc2VydmljZSBtb2RlbC4NCnRoaXMgcmVxdWlyZW1lbnQg ZXhwZWN0cyB0byBoZWxwIG9wZXJhdG9ycyB3aXRoIGxhcmdlIHNjYWxlIHRvIG1hbmdlIHRoZSB1 bmRlcmxheSBuZXR3b3JrIHdpdGggYSBnbG9iYWwgdmlldy4gIChoZXJlIGNvdWxkIGJlIGEgbXVs dGlwbGUgb3BlcmF0b3JzLCB0aGF0IGlzIHJlbGF0ZWQgdG8gZmVkZXJhdGlvbikgYW4gZW50ZXJw cmlzZSBjdXN0b21lciBtYXkgc2ltcGx5IHJlcXVlc3QgYSBMMyBWUE4gc2VydmljZSwgYnV0IG9w ZXJhdG9yIGhhcyB0byBwcm92aXNpb24gYW5kIG1hbmdlIHRoZSBlbmQgdG8gZW5kIHVuZGVybGF5 IG5ldHdvcmsgY29uc3RydWN0ZWQgd2l0aCBtdWx0aXBsZSBBU2VzIGFuZCB0ZWNobmlxdWVzLCBh bmQgZnVydGhlciBhc3N1cmUgdGhlIHNlcnZpY2UuIHRoaXMgaXMgdGhlIGtleSBpc3N1ZSBmb3Ig dG9kYXkncyBvcGVyYXRvcnMuDQoNCkkgZG8gYmVsaWV2ZSB0aGlzIGludGVyZmFjZSBhbmQgaXRz IG1vZGVsIGFyZSBpbmRlZWQgaGVscGZ1bCBmb3Igb3BlcmF0b3JzIHRvIHNpbXBsaWZ5IG9wZXJh dGlvbnMgYW5kIG1hbmFnZW1lbnQuDQpBbmQgSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zIG5l ZWQgdG8gYmUgZGlzY3Vzc2VkIGFuZCBhbGlnbmVkIHdpdGggeW91IGFuZCBleHBlcnRzIGluIGVt YWlsIHRocmVhZC4NCg0KMS5XaGlsZSByZWZlcnJpbmcgdG8gYW5vdGhlciBkcmFmdCBhdCBzYW1l IG1lZXRpbmcgPDxzZXJ2aWNlIG1vZGVsIGV4cGxhaW5lZD4+IChodHRwczovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMy50eHQpLA0K SSBiZWxpZXZlIHRoZSBhYm92ZSBFMkUgZGVwbG95bWVudCBpbnRlcmZhY2Ugc2hvdWxkIGJlIHBv c2l0aW9uIGJldHdlZW4gc2VydmljZSBvcmNoZXN0cmF0aW9uIGFuZCAgbmV0d29yayBvcmNoZXN0 cmF0aW9uKEZpZ3VyZSAzKS4NClRoYXQgbWVhbiBpdKGvcyBhIGludGVybmFsIGludGVyZmFjZSBp biBvbmUgb3BlcmF0b3IgYW5kIGl0IGFjdHMgbm90IG9ubHkgdG8gaW1wbGVtZW50IHRoZSBjdXN0 b21lciBmYWNpbmcgbW9kZWwgKGkuZS4gTDNTTSksYnV0IGFsc28gdG8gbWFpbnRhaW4sIG1vbml0 b3IgYW5kIGRpYWdub3NlIHRoZSBlbmQgdG8gZW5kIFBFLWJhc2VkIFZQTiBzZXJ2aWNlcyBjcm9z c2luZyBtdWx0aXBsZSB0ZWNobm9sb2dpZXMgZGVwbG95ZWQgbmV0d29yay4NCklzIGl0IHJpZ2h0 PyBhbmQgc2hvdWxkIHRoaXMgaW50ZXJmYWNlIG5lZWQgdG8gc3VwcG9ydCBWUE4gc2VydmljZSB3 aGljaCBtYXliZSBjcm9zcyBtdWx0aXBsZSBvcGVyYXRvcnM/DQo9PT4gZ29vZCBwb2ludCwgdGhl IGZ1dHVyZSBpbiB0aGUgbGluayBpcyBxdWl0ZSBoZWxwZnVsLCB0aGlzIHNob3VsZCBiZSB1cGRh dGVkIGluIG5leHQgcmV2aXNpb24uDQoNCj09PiBmb3IgeW91ciBxdWVzdGlvbnMgYWJvdXQgbXVs dGlwbGUgb3BlcmF0b3JzLCB0aGlzIGlzIGV4YWN0bHkgdGhlIGlzc3VlIHJhaXNlZCBkdXJpbmcg dGhlIG1lZXRpbmcsIG9wZXJhdG9yIGFyZSBpbnRlcmNvbm5lY3RlZCBlYWNoIG90aGVyIHRocm91 Z2ggZmVkZXJhdGlvbiwgdGhlIGVuZCB0byBlbmQgc2VydmljZSBtYXkgZ28gYWNyb3NzIG11bHRp cGxlIG9wZXJhdG9ycycgYWNjZXNzIGFuZCBjb3JlIG5ldHdvcmsuIHRoYXQgaXMgdGhlIHJlYXNv biB3aHkgd2UgZGVmaW5lIFZQTiBzZWdtZW50IHdpdGhpbiB0aGUgY29tcG9zZWQgVlBOLiB0aGlz IGhhc24ndCBiZWVuIGNvbnNpZGVyIGluIHRoZSBkb2N1bWVudCBiZWZvcmUsIGJ1dCB0aGUgZmxl eGliaWxpdHkgb2YgY29tcG9zZWQgVlBOIGZyYW1ld29yayBzaG91bGQgYmUgaW5jbHVkZWQuDQoN CjIuQWN0dWFsbHkgSaGvbSBuZXcgZ3V5IGluIElFVEYsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhl cmUgYXJlIGV4aXN0aW5nIHdvcmtzIGluIElFVEYgd2hpY2ggY291bGQgaW5zdHJ1Y3Qgb3IgbW9k ZWxpbmcgdGhlIGludGVyZmFjZS9FMkUtdmlldyB0byBtYW5hZ2UgYSBtdWx0aXBsZSB0ZWNobm9s b2dpZXMgY29tcG9zZWQgbmV0d29yaywgd2hpY2ggSSBiZWxpZXZlIHZlcnkgY29tbW9uIGluIG9w ZXJhdG9yoa9zIGRlcGxveW1lbnQgd2hpbGUgc3RpbGwgbmVlZCB0byBwcm92aWRlIHNpbXBsZSBF MkUgc2VydmljZSBleHBlcmllbmNlIHRvIHRoZWlyIGN1c3RvbWVycy4gTWF5YmUgd2UgY2FuIGlt cHJvdmUgc29tZXRoaW5nIGhlcmUuIFNvIGlmIGV4cGVydHMgaGVyZSBoYXZlIG1vcmUgYmFja2dy b3VuZCwgcGxlYXNlIGhlbHAgbWUuIFRoYW5rcy4NCg0KPT0+IGFsdGhvdWdoIGl0IGlzIGltcG9y dGFudCwgYnV0IEkgZGlkbid0IHNlZSBhbnkgZTJlIGVmZm9ydCBvbiB0aGUgbmV0d29yayB5ZXQu IHRoZXJlIGlzIGEgcmVsYXRlZCB3b3JrIGluIEwzU00gaW4gY3VzdG9tZXIgc2VydmljZSBsZXZl bCBhbmQgc29tZSBkZWRpY2F0ZWQgVlBOIG1vZGVscyBpbiBCRVNTLiB0aGF0J3Mgd2h5IEkgcmFp c2UgdGhpcyB0b3BpYy4gZGVmaW5pdGVseSB3ZWxjb21lIGFueSBlZmZvcnQgdG8gam9pbiB0aGUg Zm9sbG93aW5nIGRhdGEgbW9kZWwgZGVzaWduIGlmIHlvdSByZWFsbHkgaGF2ZSBhIHN0cm9uZyBi YWNrZ3JvdW5kIG9uIGl0Lg0KDQozLkFzIEkgdW5kZXJzdGFuZCB0aGlzIGludGVyZmFjZS9tb2Rl bCBzaG91bGQgYmUgaW50ZXJuYWwgaW4gb3BlcmF0b3JzLCBzbyBJoa9tIG5vdCBzdXJlIGlmIHRo ZXJlIGFueSBvdGhlciBvcGVyYXRvcnMgYXJlIGludGVyZXN0ZWQgaXQgYW5kIG5lZWQgYSBJRVRG IFJGQz8NCg0KPT0+IEkgZGlkIGhlYXIgdHdvIGJpZyBvcGVyYXRvcnMgc2hvd2VkIHRoZSBpbnRl cmVzdCBpbiB0aGlzIHRvcGljLCBob3BlIHRoZXkgY2FuIGpvaW4gYXMgd2VsbCBpbiBvdXIgbmV4 dCByZXZpc2lvbi4gdGhpcyBtYXkgcmVsYXRlZCB0byBuZXR3b3JrIG9yY2hlc3RyYXRvciwgT1NT L0JTUyBhbmQgZXZlbiBhbmFseXRpY3Mgc3lzdGVtIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIGEg c3RhbmRhcmQgbW9kZWwgd2lsbCBkZWZpbml0ZWx5ICBoZXAgdGhlIGRpdmVyc2l0eSBpbiBvbmUg b3BlcmF0b3IncyBwcm9kdWN0aW9uIGVudmlyb25tZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRF TkcgSHVpDQpUaGFua3MuDQoNClJlZ2FyZHMsDQpSaWNoYXJkIENoZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkgVGVjaG5vbG9n aWVzIENvLiwgTHRkLg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXYINPKseCjujUxODEy OQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4sIExvbmdnYW5nIERpc3Ry aWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavL vrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K 1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrah ori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6 waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBp dHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFX RUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9z ZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8s IHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5h dGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlz IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxl dGUgaXQhDQoNCg== --_000_0D5441A3DF1544449089458210966F29788F114ASZXEMA501MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Lucy

 = ;

Thanks for these clarifica= tions.

  

From the Abstract section of L3SM draft(=
https://tools.ietf.org/html/draft-ietf-l3s=
m-l3vpn-service-model-17), I understand L3SM is a customer-facin=
g service model used=A1=B0between customers=
 and network operators
to deliver a=
 Layer 3 Provider Provisioned VPN service=A1=B1.
It=A1=AFs not used for providing a end-2-end deployment view of existing L2/L3VPN servi=
ce crossing multiple operator domains.
 
So I understand your meaning is that maybe w=
e could use similar methodology(hierarchic=
al approach) to define the e2e deployment =
model, which has the L2/L3VPN basic service information and attributes reference to multiple segments(AC,backbone,etc=
) information.
 
Am I mistaken something?

 


Thanks,


Richard


 











=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.

=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=
=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8
 =D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com





=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=
=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=
=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=
=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=
=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=
=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=
=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attac=
hments contain confidential information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!

 = ;

=B7=A2=BC=FE=C8= =CB: Lucy yong
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C214=C8=D5 = 22:23
=CA=D5=BC=FE=C8=CB: Chenrui (Richard); Hui Deng
=B3=AD=CB=CD: opsawg-chairs@ietf.org; opsawg@ietf.org; Songxiaolin; zhangliya
=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 

&n= bsp;

&n= bsp;

From: Chenrui (Richard)
Sent: Friday, October 14, 2016 2:45 AM
To: Lucy yong; Hui Deng
Cc: opsawg-chairs@ietf.org= ; opsawg@ietf.org; Songxiaolin; zhangliya
Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Lucy,

 = ;

Very good = comments and suggestions. I believe I can understand the requirement from C= hina Mobile but I haven=A1=AFt reached as deep understanding as you.

I understa= nd it=A1=AFs indeed none business with a new VPN service. It=A1=AFs just ho= w operator could specify the end-2-end deployment view of existing L2/L3VPN service crossing multiple operator domains.

[Luc= y] Good. I hope this is the case.

That can s= implify the service activation or deployment progress to some extent due to= orchestration capability. Right?

So I be= lieve it ,though not  sure if it=A1=AFs common needs  from operat= ors.  I=A1=AFm  looking for more comments.

 = ;

Please Hui= correct me if I=A1=AFm mistaken the intent from you draft.

 = ;

BTW,in = your sentence of  =A1=B0do operator need a hierarchical operator VPN s= ervice model or a flat one?=A1=B1 .I=A1=AFm not sure the meaning of =A1=B0 = hierarchical=A1=B1 or =A1=B0flat=A1=B1, are they the same solutions for this requirement or d= ifferent solutions? Are they existing work in IETF for this requirement?

[Luc= y] The based L2/L3VPN architecture is:  CE-(AC)-PE-(provider backbone = networks)-PE-(AC)-CE.  L3SM already addresses that the provider backbone networks can include multiple domains that are interconnected via= PE-PE or ASBR-ASBR. Another part is the AC that can be constructed through= another network domain such as access network. In this case, the access ne= twork provides an L2VPN service to the end-to-end VPN service; from the end-to-end VPN service perspective= , it uses the access network to provide a link for AC. What I means here, i= f SP operator (i.e. end-to-end VPN operator) wants a service model includin= g the access network domain/l2vpn (flat model) or a service model  with AC that AC reference to another= L2VPN service. (hierarchical model) This is what I want to express. L3SM u= ses hierarchical approach.

 

Than= ks,

Lucy=

&n= bsp;

Thanks.=

Richard=

 = ;


=BB=AA=CE=AA=BC=BC=CA= =F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
3D"Company_logo"=B5=D8=D6=B7=A3=BA=C9=EE=DB= =DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0= =C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0= =C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7= =D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4= =CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5= =AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2= =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3= =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 = ;

=B7=A2=BC=FE=C8= =CB: Lucy yong
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C214=C8=D5 = 3:15
=CA=D5=BC=FE=C8=CB: Hui Deng; Chenrui (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 

Hi Hui = and Rui,

&n= bsp;

The dra= ft introduction starts that ISPs have interest on providing Provider Edge (= PE) based virtual private network (VPN) service and names it as composed VPN service and intends to specify the service model requir= ements for the composed VPN. Then it states that this service model is from= operator perspective.

&n= bsp;

My comm= ents and suggestions:

&n= bsp;

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Is this a brand new VPN service offered by Internet Service Providers or a= use case for existing VPN services specified in [RFC4364] [RFC6742][RFC7432]? If this is a new service, please make that very clear = in the beginning and describe what is the new service, service architecture= , and architecture components. If this is a use case for existing VPN servi= ces; please do not call it composed VPN service (make a lot of confusions.)

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Assume this is for existing VPNs and draft wants to specify the operator v= iew of e-2-e VPNs that may across multiple operator domains. Suggests to start with existing VPN service architecture view and componen= ts: CE, PE, provider backbone networks, AC etc. and explain how operator ma= y use multiple network domains to achieve it. For examples, PEs that custom= er sites attach to may exist in different ASes;  the AC between CE-PE may be across an access network= , etc.

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Existing VPN service across multiple networks are not new and current solu= tions support that.

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Text =A1=B0Provider Edge (PE based virtual private network (VPN services, = in which the tunnel endpoints are the PE devices=A1=B1 is very confuse. Will the tunnel is between PE-PE or PE-CE? Will this tunnel is different f= rom current tunnel techniques in [RFC4364] [RFC6742][RFC7432]?

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    Existing VPN service PE and CE have its role. Text: =A1=B0CE device do not= need to have any special VPN capability=A1=B1 is confused too.<= /span>

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    When an operator gets customer VPN service request that is an e2e service = description (draft-ietf-l3sm-l3vpn-service-model), he will design individual segments (CE-PE and PE-PE) to meet the request. The resu= lt may mean that the VPN is implemented across several domains.   = ;

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    What values that a flat operator VPN service model provides?  two seg= ment VPNs may not even at the same layers. If one segment VPN just provides a transit link or access link to the VPN service, do operato= r need a hierarchical operator VPN service model or a flat one?<= /span>

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;     figure in page 5 very confusion. If this is for existing VPN service= , please replace =A1=B0Composed VPN=A1=B1 with =A1=B0L3VPN=A1=B1 (or =A1=B0= L2VPN=A1=B1), and replace AP with AC.

=A1=A4<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;    If this is a new VPN service, please define what is the composed VPN servi= ce and the architecture. Then clarify if current IETF has solutions for this service.

&n= bsp;

Regards= ,

Lucy

&n= bsp;

&n= bsp;

&n= bsp;

From: OPSAWG [ma= ilto:opsawg-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Wednesday, October 12, 2016 10:28 AM
To: Chenrui (Richard); opsawg@iet= f.org
Cc: opsawg-chairs@ietf.org=
Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Richard,

 

I agree with your point, in order to meet= those operators expectation, the draft may need to be updated and reflect = that architecture.

 

Regarding to solution, that will be great= , thanks a lot for your contribution to IETF if there is any proof of conce= pt to this.

 

thanks a lot for your suggestion

 

Best regards,

 

DENG Hui

From: chenrui@huawei.com
To: denghui02@hotmail.com; opsawg@ietf.org
CC: opsawg-chairs@ietf.org Subject: =B4=F0=B8=B4: [OPSAWG] draft-deng-opsawg-compose= d-vpn-sm-requirements-01.txt
Date: Tue, 11 Oct 2016 02:27:14 +0000

Hi Hui,

 

Thanks for= these clarifications. Maybe we can talk about it more in next meeting and = we can provide a initial solution around these issues.

 

BTW, if we= talking about federation used in multiple operators scenarios, I suggest tha= t there should be east-west interface between peer orchestration system in = these operators. That ease-west interface is different with internal E2E service activation interface for some special requiremen= t between operators, such as security, resource visualization,etc.

 

Thanks,

Richard

 


=BB=AA=CE=AA=BC=BC=CA= =F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9= =EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0= =C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0= =C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7= =D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4= =CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5= =AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2= =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3= =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

=B7=A2=BC=FE=C8= =CB: Hui Deng [mailto:denghu= i02@hotmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4<= /b>: = 2016=C4=EA10=D4=C210=C8=D5 23:15
=CA=D5=BC=FE=C8=CB= : Chenru= i (Richard); opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: RE: [OPSAWG]= draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

 


Hi Richard,

 

Thanks a lot for your comments, I recalle= d that other two operators during last time f2f meeting had made some comme= nts about federation issue, hope they can elaborate more detail comments here as well, inline with =3D=3D>

From: chenrui@huawei.com
To: opsawg@ietf.org; denghui02@hotmail.com
CC: opsawg-chairs@ietf.org Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=
Date: Sun, 9 Oct 2016 03:35:46 +0000

Hi Hui and all,

 

When I went through the documents of IETF#96,I= noticed that this draft has raised a interesting requirement in China Mobi= le of E2E deployment interface to a multiple VPNs composed infrastructure, such as L2+L3 network. So the interface could= make the service fulfillment and management more easy.

Is my understanding right?

 

=3D=3D> Yes, current existing L3SM are most= ly talking about customer facing service model.

this requirement expects to help operators wit= h large scale to mange the underlay network with a global view.  (here= could be a multiple operators, that is related to federation) an enterprise customer may simply request a L3 VPN service, but operator h= as to provision and mange the end to end underlay network constructed with = multiple ASes and techniques, and further assure the service. this is the k= ey issue for today's operators.

 

I do believe this interface and its model are = indeed helpful for operators to simplify operations and management.<= span lang=3D"EN-US" style=3D"font-family:"Calibri","sans-ser= if"">

And I still have some questions need to be dis= cussed and aligned with you and experts in email thread.

 

1.While referring to another draft at same mee= ting <<service model explained>> (https://tools.ietf.org/id/draft-wu-opsawg-ser= vice-model-explained-03.txt),

I believe the above E2E deployment interface s= hould be position between service orchestration and  network orchestra= tion(Figure 3).

That mean it=A1=AFs a internal interface in on= e operator and it acts not only to implement the customer facing model (i.e= . L3SM),but also to maintain, monitor and diagnose the end to end PE-based VPN services crossing multiple technologies deployed n= etwork.

Is it right? and should this interface need to= support VPN service which maybe cross multiple operators?

=3D=3D> good point, the future in the link = is quite helpful, this should be updated in next revision.

 

=3D=3D> for your questions about multiple o= perators, this is exactly the issue raised during the meeting, operator are= interconnected each other through federation, the end to end service may go across multiple operators' access and core network. = that is the reason why we define VPN segment within the composed VPN. this = hasn't been consider in the document before, but the flexibility of compose= d VPN framework should be included.

 

2.Actually I=A1=AFm new guy in IETF, so I=A1= =AFm not sure if there are existing works in IETF which could instruct or m= odeling the interface/E2E-view to manage a multiple technologies composed network, which I believe very common in operator=A1=AFs deploymen= t while still need to provide simple E2E service experience to their custom= ers. Maybe we can improve something here. So if experts here have more back= ground, please help me. Thanks.

 

=3D=3D> although it is important, but I did= n't see any e2e effort on the network yet. there is a related work in L3SM = in customer service level and some dedicated VPN models in BESS. that's why I raise this topic. definitely welcome any effort to j= oin the following data model design if you really have a strong background = on it.

 

3.As I understand this interface/model should = be internal in operators, so I=A1=AFm not sure if there any other operators= are interested it and need a IETF RFC?=

 

=3D=3D> I did hear two big operators showed= the interest in this topic, hope they can join as well in our next revisio= n. this may related to network orchestrator, OSS/BSS and even analytics system from different vendors. a standard model will defini= tely  hep the diversity in one operator's production environment.

 

Best regards,

 

DENG Hui

Thanks.

 

Regards,

Richard Chen

 


=BB=AA=CE=AA=BC=BC=CA= =F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
=B5=D8=D6=B7=A3=BA=C9= =EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3= =CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4= =B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3= =E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3= =BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4= =CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5= =AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2= =B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3= =C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1= =A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2= =C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments = contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_0D5441A3DF1544449089458210966F29788F114ASZXEMA501MBXchi_-- From nobody Mon Oct 17 07:12:42 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241831296DD; Mon, 17 Oct 2016 07:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 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.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 3KMnV_kHLTVM; Mon, 17 Oct 2016 07:12:36 -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 E69071296D7; Mon, 17 Oct 2016 07:12:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYJ11988; Mon, 17 Oct 2016 14:12:30 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 17 Oct 2016 15:12:30 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 17 Oct 2016 07:12:19 -0700 From: Lucy yong To: "Chenrui (Richard)" , Hui Deng Thread-Topic: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSJJ18MZ4lC1eKjUqffVl88R3hraCnh9aA///0CACABL2CQIAAdiKQ Date: Mon, 17 Oct 2016 14:12:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D572E195A@dfweml501-mbb> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> <0D5441A3DF1544449089458210966F29788F0C95@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E1351@dfweml501-mbb> <0D5441A3DF1544449089458210966F29788F114A@SZXEMA501-MBX.china.huawei.com> In-Reply-To: <0D5441A3DF1544449089458210966F29788F114A@SZXEMA501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.254] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D572E195Adfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5804DC4F.010E, 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: 94ad12b15d90398a98d3c8c58bfe4488 Archived-At: Cc: Songxiaolin , "opsawg@ietf.org" , "opsawg-chairs@ietf.org" , zhangliya Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 14:12:41 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D572E195Adfweml501mbb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IENoZW5ydWkgKFJpY2hhcmQpDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTcsIDIw MTYgMjoxNyBBTQ0KVG86IEx1Y3kgeW9uZzsgSHVpIERlbmcNCkNjOiBvcHNhd2ctY2hhaXJzQGll dGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IFNvbmd4aWFvbGluOyB6aGFuZ2xpeWENClN1YmplY3Q6 ID8/OiBbT1BTQVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVp cmVtZW50cy0wMS50eHQNCg0KSGkgTHVjeQ0KDQpUaGFua3MgZm9yIHRoZXNlIGNsYXJpZmljYXRp b25zLg0KDQoNCkZyb20gdGhlIEFic3RyYWN0IHNlY3Rpb24gb2YgTDNTTSBkcmFmdChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwt MTcpLCBJIHVuZGVyc3RhbmQgTDNTTSBpcyBhIGN1c3RvbWVyLWZhY2luZyBzZXJ2aWNlIG1vZGVs IHVzZWShsGJldHdlZW4gY3VzdG9tZXJzIGFuZCBuZXR3b3JrIG9wZXJhdG9ycw0KDQp0byBkZWxp dmVyIGEgTGF5ZXIgMyBQcm92aWRlciBQcm92aXNpb25lZCBWUE4gc2VydmljZaGxLg0KDQpJdKGv cyBub3QgdXNlZCBmb3IgcHJvdmlkaW5nIGEgZW5kLTItZW5kIGRlcGxveW1lbnQgdmlldyBvZiBl eGlzdGluZyBMMi9MM1ZQTiBzZXJ2aWNlIGNyb3NzaW5nIG11bHRpcGxlIG9wZXJhdG9yIGRvbWFp bnMuDQoNCltMdWN5XSBMM1NNIGNvdmVycyBjdXN0b21lci1mYWNlIHNlcnZpY2UgbW9kZWwsIHdo aWNoIGNvdmVycyBlMmUgTDMgc2VydmljZSBhc3BlY3QuIEwzU00gbW9kZWxzIEFDIGFuZCBwcm92 aWRlcnMgYmFja2JvbmUgaW50ZXJ3b3JraW5nLCBldGMuICBUaGUgZW5kLXRvLWVuZCBkZXBsb3lt ZW50IGludm9sdmVzICBtdWx0aXBsZSBkb21haW5zIGFuZCBtdWx0aXBsZSBsYXllcnMuDQoNCg0K DQpTbyBJIHVuZGVyc3RhbmQgeW91ciBtZWFuaW5nIGlzIHRoYXQgbWF5YmUgd2UgY291bGQgdXNl IHNpbWlsYXIgbWV0aG9kb2xvZ3koaGllcmFyY2hpY2FsIGFwcHJvYWNoKSB0byBkZWZpbmUgdGhl IGUyZSBkZXBsb3ltZW50IG1vZGVsLCB3aGljaCBoYXMgdGhlIEwyL0wzVlBOIGJhc2ljIHNlcnZp Y2UgaW5mb3JtYXRpb24gYW5kIGF0dHJpYnV0ZXMgcmVmZXJlbmNlIHRvIG11bHRpcGxlIHNlZ21l bnRzKEFDLGJhY2tib25lLGV0YykgaW5mb3JtYXRpb24uDQoNCltMdWN5XSBJIHRoaW5rIHRoYXQg d2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UgaGVyZS4gSSBhbSBub3QgYW4gZXhwZXJ0IG9uIFlBTkcu IEhvdyB0byB1c2UgWUFORyB0byBtb2RlbCB0aGVzZSBoaWVyYXJjaGljYWwgcmVsYXRpb25zaGlw PyAgSWYgYSBzZXJ2aWNlIG9yY2hlc3RyYXRvciBoYXMgdGhlIGtub3dsZWRnZSBvZiBpbmRpdmlk dWFsIGRvbWFpbnMgYW5kIGRvbWFpbiBjYXBhYmlsaXR5LCB3aGVuIGdldHRpbmcgYSBMMyBzZXJ2 aWNlIHJlcXVlc3QgKGUyZSksIGl0IGNhbiBmaWd1cmUgb3V0IHdoaWNoIGRvbWFpbnMgdG8gdXNl IGZvciB0aGUgc2VydmljZSBpbnN0YW5jZSwgYW5kIHNlbmQgYSBkb21haW4gc2VydmljZSByZXF1 ZXN0ICB0byBlYWNoIGluZGl2aWR1YWwgZG9tYWluIGNvbnRyb2xsZXJzLg0KDQoNCg0KQW0gSSBt aXN0YWtlbiBzb21ldGhpbmc/DQoNCltMdWN5XSB3ZSBoYXZlIHRoZSBzYW1lIHVuZGVyc3RhbmRp bmcgbm93Lg0KDQoNCg0KTHVjeQ0KDQoNCg0KDQoNClRoYW5rcywNCg0KUmljaGFyZA0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KW0NvbXBhbnlfbG9nb1212Na3o7rJ7tvaytDB+rja x/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRk Lg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmEN Cmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY 1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzA qLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+i oaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2x vtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9y IHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkg dXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNs dWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwg cmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhl IGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhp cyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3Ig ZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0Kt6K8/sjLOiBMdWN5IHlvbmcNCrei y83KsbzkOiAyMDE2xOoxMNTCMTTI1SAyMjoyMw0KytW8/sjLOiBDaGVucnVpIChSaWNoYXJkKTsg SHVpIERlbmcNCrOty806IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFp cnNAaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IFNv bmd4aWFvbGluOyB6aGFuZ2xpeWENCtb3zOI6IFJFOiBbT1BTQVdHXSA/PzogZHJhZnQtZGVuZy1v cHNhd2ctY29tcG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCg0KDQoNCkZyb206IENo ZW5ydWkgKFJpY2hhcmQpDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTQsIDIwMTYgMjo0NSBBTQ0K VG86IEx1Y3kgeW9uZzsgSHVpIERlbmcNCkNjOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0 bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dA aWV0Zi5vcmc+OyBTb25neGlhb2xpbjsgemhhbmdsaXlhDQpTdWJqZWN0OiA/PzogW09QU0FXR10g Pz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0 DQoNCkhpIEx1Y3ksDQoNClZlcnkgZ29vZCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIEkgYmVs aWV2ZSBJIGNhbiB1bmRlcnN0YW5kIHRoZSByZXF1aXJlbWVudCBmcm9tIENoaW5hIE1vYmlsZSBi dXQgSSBoYXZlbqGvdCByZWFjaGVkIGFzIGRlZXAgdW5kZXJzdGFuZGluZyBhcyB5b3UuDQpJIHVu ZGVyc3RhbmQgaXShr3MgaW5kZWVkIG5vbmUgYnVzaW5lc3Mgd2l0aCBhIG5ldyBWUE4gc2Vydmlj ZS4gSXShr3MganVzdCBob3cgb3BlcmF0b3IgY291bGQgc3BlY2lmeSB0aGUgZW5kLTItZW5kIGRl cGxveW1lbnQgdmlldyBvZiBleGlzdGluZyBMMi9MM1ZQTiBzZXJ2aWNlIGNyb3NzaW5nIG11bHRp cGxlIG9wZXJhdG9yIGRvbWFpbnMuDQpbTHVjeV0gR29vZC4gSSBob3BlIHRoaXMgaXMgdGhlIGNh c2UuDQpUaGF0IGNhbiBzaW1wbGlmeSB0aGUgc2VydmljZSBhY3RpdmF0aW9uIG9yIGRlcGxveW1l bnQgcHJvZ3Jlc3MgdG8gc29tZSBleHRlbnQgZHVlIHRvIG9yY2hlc3RyYXRpb24gY2FwYWJpbGl0 eS4gUmlnaHQ/DQpTbyBJIGJlbGlldmUgaXQgLHRob3VnaCBub3QgIHN1cmUgaWYgaXShr3MgY29t bW9uIG5lZWRzICBmcm9tIG9wZXJhdG9ycy4gIEmhr20gIGxvb2tpbmcgZm9yIG1vcmUgY29tbWVu dHMuDQoNClBsZWFzZSBIdWkgY29ycmVjdCBtZSBpZiBJoa9tIG1pc3Rha2VuIHRoZSBpbnRlbnQg ZnJvbSB5b3UgZHJhZnQuDQoNCkJUVyxpbiB5b3VyIHNlbnRlbmNlIG9mICChsGRvIG9wZXJhdG9y IG5lZWQgYSBoaWVyYXJjaGljYWwgb3BlcmF0b3IgVlBOIHNlcnZpY2UgbW9kZWwgb3IgYSBmbGF0 IG9uZT+hsSAuSaGvbSBub3Qgc3VyZSB0aGUgbWVhbmluZyBvZiChsCBoaWVyYXJjaGljYWyhsSBv ciChsGZsYXShsSwgYXJlIHRoZXkgdGhlIHNhbWUgc29sdXRpb25zIGZvciB0aGlzIHJlcXVpcmVt ZW50IG9yIGRpZmZlcmVudCBzb2x1dGlvbnM/IEFyZSB0aGV5IGV4aXN0aW5nIHdvcmsgaW4gSUVU RiBmb3IgdGhpcyByZXF1aXJlbWVudD8NCltMdWN5XSBUaGUgYmFzZWQgTDIvTDNWUE4gYXJjaGl0 ZWN0dXJlIGlzOiAgQ0UtKEFDKS1QRS0ocHJvdmlkZXIgYmFja2JvbmUgbmV0d29ya3MpLVBFLShB QyktQ0UuICBMM1NNIGFscmVhZHkgYWRkcmVzc2VzIHRoYXQgdGhlIHByb3ZpZGVyIGJhY2tib25l IG5ldHdvcmtzIGNhbiBpbmNsdWRlIG11bHRpcGxlIGRvbWFpbnMgdGhhdCBhcmUgaW50ZXJjb25u ZWN0ZWQgdmlhIFBFLVBFIG9yIEFTQlItQVNCUi4gQW5vdGhlciBwYXJ0IGlzIHRoZSBBQyB0aGF0 IGNhbiBiZSBjb25zdHJ1Y3RlZCB0aHJvdWdoIGFub3RoZXIgbmV0d29yayBkb21haW4gc3VjaCBh cyBhY2Nlc3MgbmV0d29yay4gSW4gdGhpcyBjYXNlLCB0aGUgYWNjZXNzIG5ldHdvcmsgcHJvdmlk ZXMgYW4gTDJWUE4gc2VydmljZSB0byB0aGUgZW5kLXRvLWVuZCBWUE4gc2VydmljZTsgZnJvbSB0 aGUgZW5kLXRvLWVuZCBWUE4gc2VydmljZSBwZXJzcGVjdGl2ZSwgaXQgdXNlcyB0aGUgYWNjZXNz IG5ldHdvcmsgdG8gcHJvdmlkZSBhIGxpbmsgZm9yIEFDLiBXaGF0IEkgbWVhbnMgaGVyZSwgaWYg U1Agb3BlcmF0b3IgKGkuZS4gZW5kLXRvLWVuZCBWUE4gb3BlcmF0b3IpIHdhbnRzIGEgc2Vydmlj ZSBtb2RlbCBpbmNsdWRpbmcgdGhlIGFjY2VzcyBuZXR3b3JrIGRvbWFpbi9sMnZwbiAoZmxhdCBt b2RlbCkgb3IgYSBzZXJ2aWNlIG1vZGVsICB3aXRoIEFDIHRoYXQgQUMgcmVmZXJlbmNlIHRvIGFu b3RoZXIgTDJWUE4gc2VydmljZS4gKGhpZXJhcmNoaWNhbCBtb2RlbCkgVGhpcyBpcyB3aGF0IEkg d2FudCB0byBleHByZXNzLiBMM1NNIHVzZXMgaGllcmFyY2hpY2FsIGFwcHJvYWNoLg0KDQpUaGFu a3MsDQpMdWN5DQoNClRoYW5rcy4NClJpY2hhcmQNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRk Lg0KW0NvbXBhbnlfbG9nb1212Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4 MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlz dHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5 q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737 DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnC tqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfr xPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5k IGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhV QVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdo b3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24g Y29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0 bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1p bmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykg aXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRl bGV0ZSBpdCENCg0Kt6K8/sjLOiBMdWN5IHlvbmcNCreiy83KsbzkOiAyMDE2xOoxMNTCMTTI1SAz OjE1DQrK1bz+yMs6IEh1aSBEZW5nOyBDaGVucnVpIChSaWNoYXJkKTsgb3BzYXdnQGlldGYub3Jn PG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQqzrcvNOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPG1h aWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0K1vfM4jogUkU6IFtPUFNBV0ddID8/OiBkcmFm dC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KDQpIaSBI dWkgYW5kIFJ1aSwNCg0KVGhlIGRyYWZ0IGludHJvZHVjdGlvbiBzdGFydHMgdGhhdCBJU1BzIGhh dmUgaW50ZXJlc3Qgb24gcHJvdmlkaW5nIFByb3ZpZGVyIEVkZ2UgKFBFKSBiYXNlZCB2aXJ0dWFs IHByaXZhdGUgbmV0d29yayAoVlBOKSBzZXJ2aWNlIGFuZCBuYW1lcyBpdCBhcyBjb21wb3NlZCBW UE4gc2VydmljZSBhbmQgaW50ZW5kcyB0byBzcGVjaWZ5IHRoZSBzZXJ2aWNlIG1vZGVsIHJlcXVp cmVtZW50cyBmb3IgdGhlIGNvbXBvc2VkIFZQTi4gVGhlbiBpdCBzdGF0ZXMgdGhhdCB0aGlzIHNl cnZpY2UgbW9kZWwgaXMgZnJvbSBvcGVyYXRvciBwZXJzcGVjdGl2ZS4NCg0KTXkgY29tbWVudHMg YW5kIHN1Z2dlc3Rpb25zOg0KDQoNCqGkICAgICAgICAgSXMgdGhpcyBhIGJyYW5kIG5ldyBWUE4g c2VydmljZSBvZmZlcmVkIGJ5IEludGVybmV0IFNlcnZpY2UgUHJvdmlkZXJzIG9yIGEgdXNlIGNh c2UgZm9yIGV4aXN0aW5nIFZQTiBzZXJ2aWNlcyBzcGVjaWZpZWQgaW4gW1JGQzQzNjRdIFtSRkM2 NzQyXVtSRkM3NDMyXT8gSWYgdGhpcyBpcyBhIG5ldyBzZXJ2aWNlLCBwbGVhc2UgbWFrZSB0aGF0 IHZlcnkgY2xlYXIgaW4gdGhlIGJlZ2lubmluZyBhbmQgZGVzY3JpYmUgd2hhdCBpcyB0aGUgbmV3 IHNlcnZpY2UsIHNlcnZpY2UgYXJjaGl0ZWN0dXJlLCBhbmQgYXJjaGl0ZWN0dXJlIGNvbXBvbmVu dHMuIElmIHRoaXMgaXMgYSB1c2UgY2FzZSBmb3IgZXhpc3RpbmcgVlBOIHNlcnZpY2VzOyBwbGVh c2UgZG8gbm90IGNhbGwgaXQgY29tcG9zZWQgVlBOIHNlcnZpY2UgKG1ha2UgYSBsb3Qgb2YgY29u ZnVzaW9ucy4pDQoNCqGkICAgICAgICAgQXNzdW1lIHRoaXMgaXMgZm9yIGV4aXN0aW5nIFZQTnMg YW5kIGRyYWZ0IHdhbnRzIHRvIHNwZWNpZnkgdGhlIG9wZXJhdG9yIHZpZXcgb2YgZS0yLWUgVlBO cyB0aGF0IG1heSBhY3Jvc3MgbXVsdGlwbGUgb3BlcmF0b3IgZG9tYWlucy4gU3VnZ2VzdHMgdG8g c3RhcnQgd2l0aCBleGlzdGluZyBWUE4gc2VydmljZSBhcmNoaXRlY3R1cmUgdmlldyBhbmQgY29t cG9uZW50czogQ0UsIFBFLCBwcm92aWRlciBiYWNrYm9uZSBuZXR3b3JrcywgQUMgZXRjLiBhbmQg ZXhwbGFpbiBob3cgb3BlcmF0b3IgbWF5IHVzZSBtdWx0aXBsZSBuZXR3b3JrIGRvbWFpbnMgdG8g YWNoaWV2ZSBpdC4gRm9yIGV4YW1wbGVzLCBQRXMgdGhhdCBjdXN0b21lciBzaXRlcyBhdHRhY2gg dG8gbWF5IGV4aXN0IGluIGRpZmZlcmVudCBBU2VzOyAgdGhlIEFDIGJldHdlZW4gQ0UtUEUgbWF5 IGJlIGFjcm9zcyBhbiBhY2Nlc3MgbmV0d29yaywgZXRjLg0KDQqhpCAgICAgICAgIEV4aXN0aW5n IFZQTiBzZXJ2aWNlIGFjcm9zcyBtdWx0aXBsZSBuZXR3b3JrcyBhcmUgbm90IG5ldyBhbmQgY3Vy cmVudCBzb2x1dGlvbnMgc3VwcG9ydCB0aGF0Lg0KDQqhpCAgICAgICAgIFRleHQgobBQcm92aWRl ciBFZGdlIChQRSBiYXNlZCB2aXJ0dWFsIHByaXZhdGUgbmV0d29yayAoVlBOIHNlcnZpY2VzLCBp biB3aGljaCB0aGUgdHVubmVsIGVuZHBvaW50cyBhcmUgdGhlIFBFIGRldmljZXOhsSBpcyB2ZXJ5 IGNvbmZ1c2UuIFdpbGwgdGhlIHR1bm5lbCBpcyBiZXR3ZWVuIFBFLVBFIG9yIFBFLUNFPyBXaWxs IHRoaXMgdHVubmVsIGlzIGRpZmZlcmVudCBmcm9tIGN1cnJlbnQgdHVubmVsIHRlY2huaXF1ZXMg aW4gW1JGQzQzNjRdIFtSRkM2NzQyXVtSRkM3NDMyXT8NCg0KoaQgICAgICAgICBFeGlzdGluZyBW UE4gc2VydmljZSBQRSBhbmQgQ0UgaGF2ZSBpdHMgcm9sZS4gVGV4dDogobBDRSBkZXZpY2UgZG8g bm90IG5lZWQgdG8gaGF2ZSBhbnkgc3BlY2lhbCBWUE4gY2FwYWJpbGl0eaGxIGlzIGNvbmZ1c2Vk IHRvby4NCg0KoaQgICAgICAgICBXaGVuIGFuIG9wZXJhdG9yIGdldHMgY3VzdG9tZXIgVlBOIHNl cnZpY2UgcmVxdWVzdCB0aGF0IGlzIGFuIGUyZSBzZXJ2aWNlIGRlc2NyaXB0aW9uIChkcmFmdC1p ZXRmLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbCksIGhlIHdpbGwgZGVzaWduIGluZGl2aWR1YWwg c2VnbWVudHMgKENFLVBFIGFuZCBQRS1QRSkgdG8gbWVldCB0aGUgcmVxdWVzdC4gVGhlIHJlc3Vs dCBtYXkgbWVhbiB0aGF0IHRoZSBWUE4gaXMgaW1wbGVtZW50ZWQgYWNyb3NzIHNldmVyYWwgZG9t YWlucy4NCg0KoaQgICAgICAgICBXaGF0IHZhbHVlcyB0aGF0IGEgZmxhdCBvcGVyYXRvciBWUE4g c2VydmljZSBtb2RlbCBwcm92aWRlcz8gIHR3byBzZWdtZW50IFZQTnMgbWF5IG5vdCBldmVuIGF0 IHRoZSBzYW1lIGxheWVycy4gSWYgb25lIHNlZ21lbnQgVlBOIGp1c3QgcHJvdmlkZXMgYSB0cmFu c2l0IGxpbmsgb3IgYWNjZXNzIGxpbmsgdG8gdGhlIFZQTiBzZXJ2aWNlLCBkbyBvcGVyYXRvciBu ZWVkIGEgaGllcmFyY2hpY2FsIG9wZXJhdG9yIFZQTiBzZXJ2aWNlIG1vZGVsIG9yIGEgZmxhdCBv bmU/DQoNCqGkICAgICAgICAgIGZpZ3VyZSBpbiBwYWdlIDUgdmVyeSBjb25mdXNpb24uIElmIHRo aXMgaXMgZm9yIGV4aXN0aW5nIFZQTiBzZXJ2aWNlLCBwbGVhc2UgcmVwbGFjZSChsENvbXBvc2Vk IFZQTqGxIHdpdGggobBMM1ZQTqGxIChvciChsEwyVlBOobEpLCBhbmQgcmVwbGFjZSBBUCB3aXRo IEFDLg0KDQqhpCAgICAgICAgIElmIHRoaXMgaXMgYSBuZXcgVlBOIHNlcnZpY2UsIHBsZWFzZSBk ZWZpbmUgd2hhdCBpcyB0aGUgY29tcG9zZWQgVlBOIHNlcnZpY2UgYW5kIHRoZSBhcmNoaXRlY3R1 cmUuIFRoZW4gY2xhcmlmeSBpZiBjdXJyZW50IElFVEYgaGFzIHNvbHV0aW9ucyBmb3IgdGhpcyBz ZXJ2aWNlLg0KDQpSZWdhcmRzLA0KTHVjeQ0KDQoNCg0KRnJvbTogT1BTQVdHIFttYWlsdG86b3Bz YXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIdWkgRGVuZw0KU2VudDogV2VkbmVz ZGF5LCBPY3RvYmVyIDEyLCAyMDE2IDEwOjI4IEFNDQpUbzogQ2hlbnJ1aSAoUmljaGFyZCk7IG9w c2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KQ2M6IG9wc2F3Zy1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09Q U0FXR10gPz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMt MDEudHh0DQoNCkhpIFJpY2hhcmQsDQoNCkkgYWdyZWUgd2l0aCB5b3VyIHBvaW50LCBpbiBvcmRl ciB0byBtZWV0IHRob3NlIG9wZXJhdG9ycyBleHBlY3RhdGlvbiwgdGhlIGRyYWZ0IG1heSBuZWVk IHRvIGJlIHVwZGF0ZWQgYW5kIHJlZmxlY3QgdGhhdCBhcmNoaXRlY3R1cmUuDQoNClJlZ2FyZGlu ZyB0byBzb2x1dGlvbiwgdGhhdCB3aWxsIGJlIGdyZWF0LCB0aGFua3MgYSBsb3QgZm9yIHlvdXIg Y29udHJpYnV0aW9uIHRvIElFVEYgaWYgdGhlcmUgaXMgYW55IHByb29mIG9mIGNvbmNlcHQgdG8g dGhpcy4NCg0KdGhhbmtzIGEgbG90IGZvciB5b3VyIHN1Z2dlc3Rpb24NCg0KQmVzdCByZWdhcmRz LA0KDQpERU5HIEh1aQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGNo ZW5ydWlAaHVhd2VpLmNvbTxtYWlsdG86Y2hlbnJ1aUBodWF3ZWkuY29tPg0KVG86IGRlbmdodWkw MkBob3RtYWlsLmNvbTxtYWlsdG86ZGVuZ2h1aTAyQGhvdG1haWwuY29tPjsgb3BzYXdnQGlldGYu b3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpDQzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxt YWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6ILTwuLQ6IFtPUFNBV0ddIGRy YWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0DQpEYXRl OiBUdWUsIDExIE9jdCAyMDE2IDAyOjI3OjE0ICswMDAwDQpIaSBIdWksDQoNClRoYW5rcyBmb3Ig dGhlc2UgY2xhcmlmaWNhdGlvbnMuIE1heWJlIHdlIGNhbiB0YWxrIGFib3V0IGl0IG1vcmUgaW4g bmV4dCBtZWV0aW5nIGFuZCB3ZSBjYW4gcHJvdmlkZSBhIGluaXRpYWwgc29sdXRpb24gYXJvdW5k IHRoZXNlIGlzc3Vlcy4NCg0KQlRXLCBpZiB3ZSB0YWxraW5nIGFib3V0IGZlZGVyYXRpb24gdXNl ZCBpbiBtdWx0aXBsZSBvcGVyYXRvcnMgc2NlbmFyaW9zLCBJIHN1Z2dlc3QgdGhhdCB0aGVyZSBz aG91bGQgYmUgZWFzdC13ZXN0IGludGVyZmFjZSBiZXR3ZWVuIHBlZXIgb3JjaGVzdHJhdGlvbiBz eXN0ZW0gaW4gdGhlc2Ugb3BlcmF0b3JzLiBUaGF0IGVhc2Utd2VzdCBpbnRlcmZhY2UgaXMgZGlm ZmVyZW50IHdpdGggaW50ZXJuYWwgRTJFIHNlcnZpY2UgYWN0aXZhdGlvbiBpbnRlcmZhY2UgZm9y IHNvbWUgc3BlY2lhbCByZXF1aXJlbWVudCBiZXR3ZWVuIG9wZXJhdG9ycywgc3VjaCBhcyBzZWN1 cml0eSwgcmVzb3VyY2UgdmlzdWFsaXphdGlvbixldGMuDQoNClRoYW5rcywNClJpY2hhcmQNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXY INPKseCjujUxODEyOQ0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4sIExv bmdnYW5nIERpc3RyaWN0LFNoZW56aGVuIDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1 YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28 /rqs09C7qs6quavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjL u/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+7 8rK/t9a12NC5wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHL sb7Tyrz+o6zH68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMg ZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9y IGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90 IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwg b3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVj aXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgaXQhDQoNCreivP7IyzogSHVpIERlbmcgW21haWx0bzpkZW5naHVpMDJA aG90bWFpbC5jb21dDQq3osvNyrG85DogMjAxNsTqMTDUwjEwyNUgMjM6MTUNCsrVvP7IyzogQ2hl bnJ1aSAoUmljaGFyZCk7IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0K s63LzTogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9y Zz4NCtb3zOI6IFJFOiBbT1BTQVdHXSBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20t cmVxdWlyZW1lbnRzLTAxLnR4dA0KDQoNCkhpIFJpY2hhcmQsDQoNClRoYW5rcyBhIGxvdCBmb3Ig eW91ciBjb21tZW50cywgSSByZWNhbGxlZCB0aGF0IG90aGVyIHR3byBvcGVyYXRvcnMgZHVyaW5n IGxhc3QgdGltZSBmMmYgbWVldGluZyBoYWQgbWFkZSBzb21lIGNvbW1lbnRzIGFib3V0IGZlZGVy YXRpb24gaXNzdWUsIGhvcGUgdGhleSBjYW4gZWxhYm9yYXRlIG1vcmUgZGV0YWlsIGNvbW1lbnRz IGhlcmUgYXMgd2VsbCwgaW5saW5lIHdpdGggPT0+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogY2hlbnJ1aUBodWF3ZWkuY29tPG1haWx0bzpjaGVucnVpQGh1YXdlaS5j b20+DQpUbzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBkZW5naHVp MDJAaG90bWFpbC5jb208bWFpbHRvOmRlbmdodWkwMkBob3RtYWlsLmNvbT4NCkNDOiBvcHNhd2ct Y2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtPUFNBV0ddIGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVu dHMtMDEudHh0DQpEYXRlOiBTdW4sIDkgT2N0IDIwMTYgMDM6MzU6NDYgKzAwMDANCkhpIEh1aSBh bmQgYWxsLA0KDQpXaGVuIEkgd2VudCB0aHJvdWdoIHRoZSBkb2N1bWVudHMgb2YgSUVURiM5NixJ IG5vdGljZWQgdGhhdCB0aGlzIGRyYWZ0IGhhcyByYWlzZWQgYSBpbnRlcmVzdGluZyByZXF1aXJl bWVudCBpbiBDaGluYSBNb2JpbGUgb2YgRTJFIGRlcGxveW1lbnQgaW50ZXJmYWNlIHRvIGEgbXVs dGlwbGUgVlBOcyBjb21wb3NlZCBpbmZyYXN0cnVjdHVyZSwgc3VjaCBhcyBMMitMMyBuZXR3b3Jr LiBTbyB0aGUgaW50ZXJmYWNlIGNvdWxkIG1ha2UgdGhlIHNlcnZpY2UgZnVsZmlsbG1lbnQgYW5k IG1hbmFnZW1lbnQgbW9yZSBlYXN5Lg0KSXMgbXkgdW5kZXJzdGFuZGluZyByaWdodD8NCg0KPT0+ IFllcywgY3VycmVudCBleGlzdGluZyBMM1NNIGFyZSBtb3N0bHkgdGFsa2luZyBhYm91dCBjdXN0 b21lciBmYWNpbmcgc2VydmljZSBtb2RlbC4NCnRoaXMgcmVxdWlyZW1lbnQgZXhwZWN0cyB0byBo ZWxwIG9wZXJhdG9ycyB3aXRoIGxhcmdlIHNjYWxlIHRvIG1hbmdlIHRoZSB1bmRlcmxheSBuZXR3 b3JrIHdpdGggYSBnbG9iYWwgdmlldy4gIChoZXJlIGNvdWxkIGJlIGEgbXVsdGlwbGUgb3BlcmF0 b3JzLCB0aGF0IGlzIHJlbGF0ZWQgdG8gZmVkZXJhdGlvbikgYW4gZW50ZXJwcmlzZSBjdXN0b21l ciBtYXkgc2ltcGx5IHJlcXVlc3QgYSBMMyBWUE4gc2VydmljZSwgYnV0IG9wZXJhdG9yIGhhcyB0 byBwcm92aXNpb24gYW5kIG1hbmdlIHRoZSBlbmQgdG8gZW5kIHVuZGVybGF5IG5ldHdvcmsgY29u c3RydWN0ZWQgd2l0aCBtdWx0aXBsZSBBU2VzIGFuZCB0ZWNobmlxdWVzLCBhbmQgZnVydGhlciBh c3N1cmUgdGhlIHNlcnZpY2UuIHRoaXMgaXMgdGhlIGtleSBpc3N1ZSBmb3IgdG9kYXkncyBvcGVy YXRvcnMuDQoNCkkgZG8gYmVsaWV2ZSB0aGlzIGludGVyZmFjZSBhbmQgaXRzIG1vZGVsIGFyZSBp bmRlZWQgaGVscGZ1bCBmb3Igb3BlcmF0b3JzIHRvIHNpbXBsaWZ5IG9wZXJhdGlvbnMgYW5kIG1h bmFnZW1lbnQuDQpBbmQgSSBzdGlsbCBoYXZlIHNvbWUgcXVlc3Rpb25zIG5lZWQgdG8gYmUgZGlz Y3Vzc2VkIGFuZCBhbGlnbmVkIHdpdGggeW91IGFuZCBleHBlcnRzIGluIGVtYWlsIHRocmVhZC4N Cg0KMS5XaGlsZSByZWZlcnJpbmcgdG8gYW5vdGhlciBkcmFmdCBhdCBzYW1lIG1lZXRpbmcgPDxz ZXJ2aWNlIG1vZGVsIGV4cGxhaW5lZD4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0 LXd1LW9wc2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC0wMy50eHQpLA0KSSBiZWxpZXZlIHRo ZSBhYm92ZSBFMkUgZGVwbG95bWVudCBpbnRlcmZhY2Ugc2hvdWxkIGJlIHBvc2l0aW9uIGJldHdl ZW4gc2VydmljZSBvcmNoZXN0cmF0aW9uIGFuZCAgbmV0d29yayBvcmNoZXN0cmF0aW9uKEZpZ3Vy ZSAzKS4NClRoYXQgbWVhbiBpdKGvcyBhIGludGVybmFsIGludGVyZmFjZSBpbiBvbmUgb3BlcmF0 b3IgYW5kIGl0IGFjdHMgbm90IG9ubHkgdG8gaW1wbGVtZW50IHRoZSBjdXN0b21lciBmYWNpbmcg bW9kZWwgKGkuZS4gTDNTTSksYnV0IGFsc28gdG8gbWFpbnRhaW4sIG1vbml0b3IgYW5kIGRpYWdu b3NlIHRoZSBlbmQgdG8gZW5kIFBFLWJhc2VkIFZQTiBzZXJ2aWNlcyBjcm9zc2luZyBtdWx0aXBs ZSB0ZWNobm9sb2dpZXMgZGVwbG95ZWQgbmV0d29yay4NCklzIGl0IHJpZ2h0PyBhbmQgc2hvdWxk IHRoaXMgaW50ZXJmYWNlIG5lZWQgdG8gc3VwcG9ydCBWUE4gc2VydmljZSB3aGljaCBtYXliZSBj cm9zcyBtdWx0aXBsZSBvcGVyYXRvcnM/DQo9PT4gZ29vZCBwb2ludCwgdGhlIGZ1dHVyZSBpbiB0 aGUgbGluayBpcyBxdWl0ZSBoZWxwZnVsLCB0aGlzIHNob3VsZCBiZSB1cGRhdGVkIGluIG5leHQg cmV2aXNpb24uDQoNCj09PiBmb3IgeW91ciBxdWVzdGlvbnMgYWJvdXQgbXVsdGlwbGUgb3BlcmF0 b3JzLCB0aGlzIGlzIGV4YWN0bHkgdGhlIGlzc3VlIHJhaXNlZCBkdXJpbmcgdGhlIG1lZXRpbmcs IG9wZXJhdG9yIGFyZSBpbnRlcmNvbm5lY3RlZCBlYWNoIG90aGVyIHRocm91Z2ggZmVkZXJhdGlv biwgdGhlIGVuZCB0byBlbmQgc2VydmljZSBtYXkgZ28gYWNyb3NzIG11bHRpcGxlIG9wZXJhdG9y cycgYWNjZXNzIGFuZCBjb3JlIG5ldHdvcmsuIHRoYXQgaXMgdGhlIHJlYXNvbiB3aHkgd2UgZGVm aW5lIFZQTiBzZWdtZW50IHdpdGhpbiB0aGUgY29tcG9zZWQgVlBOLiB0aGlzIGhhc24ndCBiZWVu IGNvbnNpZGVyIGluIHRoZSBkb2N1bWVudCBiZWZvcmUsIGJ1dCB0aGUgZmxleGliaWxpdHkgb2Yg Y29tcG9zZWQgVlBOIGZyYW1ld29yayBzaG91bGQgYmUgaW5jbHVkZWQuDQoNCjIuQWN0dWFsbHkg SaGvbSBuZXcgZ3V5IGluIElFVEYsIHNvIEmhr20gbm90IHN1cmUgaWYgdGhlcmUgYXJlIGV4aXN0 aW5nIHdvcmtzIGluIElFVEYgd2hpY2ggY291bGQgaW5zdHJ1Y3Qgb3IgbW9kZWxpbmcgdGhlIGlu dGVyZmFjZS9FMkUtdmlldyB0byBtYW5hZ2UgYSBtdWx0aXBsZSB0ZWNobm9sb2dpZXMgY29tcG9z ZWQgbmV0d29yaywgd2hpY2ggSSBiZWxpZXZlIHZlcnkgY29tbW9uIGluIG9wZXJhdG9yoa9zIGRl cGxveW1lbnQgd2hpbGUgc3RpbGwgbmVlZCB0byBwcm92aWRlIHNpbXBsZSBFMkUgc2VydmljZSBl eHBlcmllbmNlIHRvIHRoZWlyIGN1c3RvbWVycy4gTWF5YmUgd2UgY2FuIGltcHJvdmUgc29tZXRo aW5nIGhlcmUuIFNvIGlmIGV4cGVydHMgaGVyZSBoYXZlIG1vcmUgYmFja2dyb3VuZCwgcGxlYXNl IGhlbHAgbWUuIFRoYW5rcy4NCg0KPT0+IGFsdGhvdWdoIGl0IGlzIGltcG9ydGFudCwgYnV0IEkg ZGlkbid0IHNlZSBhbnkgZTJlIGVmZm9ydCBvbiB0aGUgbmV0d29yayB5ZXQuIHRoZXJlIGlzIGEg cmVsYXRlZCB3b3JrIGluIEwzU00gaW4gY3VzdG9tZXIgc2VydmljZSBsZXZlbCBhbmQgc29tZSBk ZWRpY2F0ZWQgVlBOIG1vZGVscyBpbiBCRVNTLiB0aGF0J3Mgd2h5IEkgcmFpc2UgdGhpcyB0b3Bp Yy4gZGVmaW5pdGVseSB3ZWxjb21lIGFueSBlZmZvcnQgdG8gam9pbiB0aGUgZm9sbG93aW5nIGRh dGEgbW9kZWwgZGVzaWduIGlmIHlvdSByZWFsbHkgaGF2ZSBhIHN0cm9uZyBiYWNrZ3JvdW5kIG9u IGl0Lg0KDQozLkFzIEkgdW5kZXJzdGFuZCB0aGlzIGludGVyZmFjZS9tb2RlbCBzaG91bGQgYmUg aW50ZXJuYWwgaW4gb3BlcmF0b3JzLCBzbyBJoa9tIG5vdCBzdXJlIGlmIHRoZXJlIGFueSBvdGhl ciBvcGVyYXRvcnMgYXJlIGludGVyZXN0ZWQgaXQgYW5kIG5lZWQgYSBJRVRGIFJGQz8NCg0KPT0+ IEkgZGlkIGhlYXIgdHdvIGJpZyBvcGVyYXRvcnMgc2hvd2VkIHRoZSBpbnRlcmVzdCBpbiB0aGlz IHRvcGljLCBob3BlIHRoZXkgY2FuIGpvaW4gYXMgd2VsbCBpbiBvdXIgbmV4dCByZXZpc2lvbi4g dGhpcyBtYXkgcmVsYXRlZCB0byBuZXR3b3JrIG9yY2hlc3RyYXRvciwgT1NTL0JTUyBhbmQgZXZl biBhbmFseXRpY3Mgc3lzdGVtIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIGEgc3RhbmRhcmQgbW9k ZWwgd2lsbCBkZWZpbml0ZWx5ICBoZXAgdGhlIGRpdmVyc2l0eSBpbiBvbmUgb3BlcmF0b3IncyBw cm9kdWN0aW9uIGVudmlyb25tZW50Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRFTkcgSHVpDQpUaGFu a3MuDQoNClJlZ2FyZHMsDQpSaWNoYXJkIENoZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0Ku6rOqry8yvXT0M/euavLviBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRk Lg0KtdjWt6O6ye7b2srQwfq42sf42+DM77uqzqq7+bXYINPKseCjujUxODEyOQ0KSHVhd2VpIFRl Y2hub2xvZ2llcyBDby4sIEx0ZC4NCkJhbnRpYW4sIExvbmdnYW5nIERpc3RyaWN0LFNoZW56aGVu IDUxODEyOSwgUC5SLkNoaW5hDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDFz6Kj rL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL+8jL 0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvyyaK3 oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C78tPK vP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVu dHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQpp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJl aW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBh cnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVy c29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D572E195Adfweml501mbb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

 

From: Chenrui = (Richard)
Sent: Monday, October 17, 2016 2:17 AM
To: Lucy yong; Hui Deng
Cc: opsawg-chairs@ietf.org; opsawg@ietf.org; Songxiaolin; zhangliya<= br> Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Lucy

 <= /p>

Thanks for these clarifications.

 

From the Abstract section of L3SM draft(https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service=
-model-17), I understand L3SM is a customer-facing service model=
 used=A1=B0between customers and network operators
to deliver a Layer 3 Provider Provisioned =
VPN service=A1=B1.
It=A1=AFs not used for providing a end-2-e=
nd deployment view of existing L2/L3VPN service crossing multiple operator =
domains.
[Lucy] L3SM covers customer-face serv=
ice model, which covers e2e L3 service aspect. L3SM models AC and providers=
 backbone interworking, etc.  The end-to-end deployment involves  =
;multiple domains and multiple layers. 
 
So I understand your meaning is that maybe we could use sim=
ilar methodology(hierarchical approach=
) to define the e2e deployment model, which has the L2/L3VPN basic service =
information and attributes reference to multiple segments=
(AC,backbone,etc) information.
[Lucy] I think that we are on the sam=
e page here. I am not an expert on YANG. How to use YANG to model these hie=
rarchical relationship?  If a service orchestrator has the knowledge o=
f individual domains and domain capability, when getting a L3 service reque=
st (e2e), it can figure out which domains to use for the service instance, =
and send a domain service request  to each individual domain controlle=
rs.   
 
Am I mistaken something?
[Lucy] we have the same understanding=
 now.
 

Lucy


 


 


Thanks,


Richard=



 












=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie=
s Co., Ltd.

3D"Company_logo"<=
![endif]>=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=
=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=
=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=
=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=
=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=
=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=
=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=
=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=
=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=
=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain confide=
ntial information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!=





 <=
/p>







=B7=A2=BC=FE=C8=CB: Lucy yong


=B7=A2=CB=CD=CA=B1=BC=E4:<=
/span> 2016=C4=EA10=D4=C214<=
span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:SimSun">=C8=D5
 22:23

=CA=D5=BC=FE=C8=CB:=
 Chenrui (Richard); Hui Deng

=B3=AD=CB=CD:
opsawg-chairs@ietf.org; 
opsawg@ietf.org; Songxiaolin; zhangliya

=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed=
-vpn-sm-requirements-01.txt






 


 


 






From: Chenrui =
(Richard)


Sent: Friday, October 14, 2016 2:45 AM

To: Lucy yong; Hui Deng

Cc: opsawg-chairs@ietf.org=
; 
opsawg@ietf.org; Songxiaolin; zhangliya

Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem=
ents-01.txt






 


Hi Lucy,


 <=
/p>

Very good comments and su=
ggestions. I believe I can understand the requirement from China Mobile but=
 I haven=A1=AFt reached as deep understanding as you.



I understand it=A1=AFs in=
deed none business with a new VPN service. It=A1=AFs just how operator coul=
d specify the end-2-end deployment view of existing L2/L3VPN service
 crossing multiple operator domains.


[Lucy] Good. I hope=
 this is the case.<=
/span>


That can simplify the ser=
vice activation or deployment progress to some extent due to orchestration =
capability. Right?


So I believe it ,thoug=
h not  sure if it=A1=AFs common needs  from operators.  I=A1=
=AFm  looking for more comments.=



 <=
/p>

Please Hui correct me if =
I=A1=AFm mistaken the intent from you draft.


 <=
/p>

BTW,in your sentence o=
f  =A1=B0do operator need a hierarchical operator VPN service model or=
 a flat one?=A1=B1 .I=A1=AFm not sure the meaning of =A1=B0 hierarchical=A1=
=B1 or =A1=B0flat=A1=B1,
 are they the same solutions for this requirement or different solutions? A=
re they existing work in IETF for this requirement?

[Lucy] The based L2=
/L3VPN architecture is:  CE-(AC)-PE-(provider backbone networks)-PE-(A=
C)-CE.  L3SM already addresses that the provider backbone networks
 can include multiple domains that are interconnected via PE-PE or ASBR-ASB=
R. Another part is the AC that can be constructed through another network d=
omain such as access network. In this case, the access network provides an =
L2VPN service to the end-to-end
 VPN service; from the end-to-end VPN service perspective, it uses the acce=
ss network to provide a link for AC. What I means here, if SP operator (i.e=
. end-to-end VPN operator) wants a service model including the access netwo=
rk domain/l2vpn (flat model) or
 a service model  with AC that AC reference to another L2VPN service. =
(hierarchical model) This is what I want to express. L3SM uses hierarchical=
 approach.


 


Thanks,<=
/span>


Lucy=



 


Thanks.


Richard


 <=
/p>











=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie=
s Co., Ltd.

3D"Company_logo"=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=
=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=
=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=
=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=
=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=
=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=
=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=
=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=
=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=
=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain confide=
ntial information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!=





 <=
/p>







=B7=A2=BC=FE=C8=CB: Lucy yong


=B7=A2=CB=CD=CA=B1=BC=E4:<=
/span> 2016=C4=EA10=D4=C214<=
span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:SimSun">=C8=D5
 3:15

=CA=D5=BC=FE=C8=CB:=
 Hui Deng; Chenrui (Richard);
opsawg@ietf.org

=B3=AD=CB=CD:
opsawg-chairs@ietf.org

=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed=
-vpn-sm-requirements-01.txt






 


Hi Hui and Rui,


 


The draft introduction=
 starts that ISPs have interest on providing Provider Edge (PE) based virtu=
al private network (VPN) service and names it as composed
 VPN service and intends to specify the service model requirements for the =
composed VPN. Then it states that this service model is from operator persp=
ective.


 


My comments and sugges=
tions:


 


=A1=A4      &=
nbsp; 
Is this a bran=
d new VPN service offered by Internet Service Providers or a use case for e=
xisting VPN services specified in [RFC4364] [RFC6742][RFC7432]?
 If this is a new service, please make that very clear in the beginning and=
 describe what is the new service, service architecture, and architecture c=
omponents. If this is a use case for existing VPN services; please do not c=
all it composed VPN service (make
 a lot of confusions.) 


=A1=A4      &=
nbsp; 
Assume this is=
 for existing VPNs and draft wants to specify the operator view of e-2-e VP=
Ns that may across multiple operator domains. Suggests
 to start with existing VPN service architecture view and components: CE, P=
E, provider backbone networks, AC etc. and explain how operator may use mul=
tiple network domains to achieve it. For examples, PEs that customer sites =
attach to may exist in different
 ASes;  the AC between CE-PE may be across an access network, etc. 


=A1=A4      &=
nbsp; 
Existing VPN s=
ervice across multiple networks are not new and current solutions support t=
hat.



=A1=A4      &=
nbsp; 
Text =A1=B0Pro=
vider Edge (PE based virtual private network (VPN services, in which the tu=
nnel endpoints are the PE devices=A1=B1 is very confuse. Will the
 tunnel is between PE-PE or PE-CE? Will this tunnel is different from curre=
nt tunnel techniques in [RFC4364] [RFC6742][RFC7432]?=



=A1=A4      &=
nbsp; 
Existing VPN s=
ervice PE and CE have its role. Text: =A1=B0CE device do not need to have a=
ny special VPN capability=A1=B1 is confused too.


=A1=A4      &=
nbsp; 
When an operat=
or gets customer VPN service request that is an e2e service description (dr=
aft-ietf-l3sm-l3vpn-service-model), he will design individual
 segments (CE-PE and PE-PE) to meet the request. The result may mean that t=
he VPN is implemented across several domains.   


=A1=A4      &=
nbsp; 
What values th=
at a flat operator VPN service model provides?  two segment VPNs may n=
ot even at the same layers. If one segment VPN just provides
 a transit link or access link to the VPN service, do operator need a hiera=
rchical operator VPN service model or a flat one?


=A1=A4      &=
nbsp; 
 figure i=
n page 5 very confusion. If this is for existing VPN service, please replac=
e =A1=B0Composed VPN=A1=B1 with =A1=B0L3VPN=A1=B1 (or =A1=B0L2VPN=A1=B1), a=
nd replace AP
 with AC.


=A1=A4      &=
nbsp; 
If this is a n=
ew VPN service, please define what is the composed VPN service and the arch=
itecture. Then clarify if current IETF has solutions for
 this service. 


 


Regards,


Lucy



 


 


 



 




Hi Richard,




 






I agree with your point, in order to meet those operator=
s expectation, the draft may need to be updated and reflect that architectu=
re.






 






Regarding to solution, that will be great, thanks a lot =
for your contribution to IETF if there is any proof of concept to this.






 






thanks a lot for your suggestion






 






Best regards,






 






DENG Hui










From:
chenrui@huawei.com

To: denghui02@hotmail.com; 
opsawg@ietf.org

CC: opsawg-chairs@ietf.org
Subject: =B4=F0=B8=
=B4: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

Date: Tue, 11 Oct 2016 02:27:14 +0000




Hi Hui,


 


Thanks for these clarific=
ations. Maybe we can talk about it more in next meeting and we can provide =
a initial solution around these issues.


 


BTW, if we talking about
fe=
deration used in multiple operators scenarios, I suggest that there should =
be east-west interface between peer orchestration system in these operators=
. That ease-west interface is different with
 internal E2E service activation interface for some special requirement bet=
ween operators, such as security, resource visualization,etc.=



 


Thanks,


Richard


 












=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie=
s Co., Ltd.

=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=
=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=
=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=
=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=
=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=
=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=
=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=
=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=
=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=
=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain confide=
ntial information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!




 








=B7=A2=BC=FE=C8=CB:=
 Hui Deng
 [mailto:denghui02@hotmail.com=
] 

=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C210=C8=D5<=
span style=3D"font-size:10.0pt;font-family:"Calibri","sans-s=
erif"">
 23:15

=CA=D5=BC=FE=C8=CB: Ch=
enrui (Richard);
opsawg@ietf.org

=B3=AD=CB=CD:
opsawg-chairs@ietf.org

=D6=F7=CC=E2: RE: [OPS=
AWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt






 






Hi Richard,




 






Thanks a lot for your comments, I recalled that other tw=
o operators during last time f2f meeting had made some comments about feder=
ation issue, hope they can elaborate more detail comments
 here as well, inline with =3D=3D>










From: 
chenrui@huawei.com

To: opsawg@ietf.org; 
denghui02@hotmail.com

CC: opsawg-chairs@ietf.org
Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=


Date: Sun, 9 Oct 2016 03:35:46 +0000




Hi Hui and all,


 


When I went through the documents of IETF#96,I noticed that t=
his draft has raised a interesting requirement in China Mobile of E2E deplo=
yment interface to a multiple VPNs composed infrastructure,
 such as L2+L3 network. So the interface could make the service fulfill=
ment and management more easy.


Is my understanding right?


 


=3D=3D> Yes, current existing L3SM are mostly talking abou=
t customer facing service model.


this requirement expects to help operators with large scale t=
o mange the underlay network with a global view.  (here could be a mul=
tiple operators, that is related to federation) an
 enterprise customer may simply request a L3 VPN service, but operator has =
to provision and mange the end to end underlay network constructed with mul=
tiple ASes and techniques, and further assure the service. this is the key =
issue for today's operators.


 


I do believe this interface and its model are indeed helpful =
for operators to simplify operations and management.

And I still have some questions need to be discussed and alig=
ned with you and experts in email thread.


 


1.While referring to another draft at same meeting <<se=
rvice model explained>> (https://tools.i=
etf.org/id/draft-wu-opsawg-service-model-explained-03.txt),


I believe the above E2E deployment interface should be positi=
on between service orchestration and  network orchestration(Figure 3).=



That mean it=A1=AFs a internal interface in one operator and =
it acts not only to implement the customer facing model (i.e. L3SM),but als=
o to maintain, monitor and diagnose the end to end
 PE-based VPN services crossing multiple technologies deployed network.<=
o:p>


Is it right? and should this interface need to support VPN se=
rvice which maybe cross multiple operators?


=3D=3D> good point, the future in the link is quite helpfu=
l, this should be updated in next revision.


 


=3D=3D> for your questions about multiple operators, this =
is exactly the issue raised during the meeting, operator are interconnected=
 each other through federation, the end to end service
 may go across multiple operators' access and core network. that is the rea=
son why we define VPN segment within the composed VPN. this hasn't been con=
sider in the document before, but the flexibility of composed VPN framework=
 should be included.


 


2.Actually I=A1=AFm new guy in IETF, so I=A1=AFm not sure if =
there are existing works in IETF which could instruct or modeling the inter=
face/E2E-view to manage a multiple technologies composed
 network, which I believe very common in operator=A1=AFs deployment while s=
till need to provide simple E2E service experience to their customers. Mayb=
e we can improve something here. So if experts here have more background, p=
lease help me. Thanks.


 


=3D=3D> although it is important, but I didn't see any e2e=
 effort on the network yet. there is a related work in L3SM in customer ser=
vice level and some dedicated VPN models in BESS. that's
 why I raise this topic. definitely welcome any effort to join the followin=
g data model design if you really have a strong background on it.


 


3.As I understand this interface/model should be internal in =
operators, so I=A1=AFm not sure if there any other operators are interested=
 it and need a IETF RFC?


 


=3D=3D> I did hear two big operators showed the interest i=
n this topic, hope they can join as well in our next revision. this may rel=
ated to network orchestrator, OSS/BSS and even analytics
 system from different vendors. a standard model will definitely  hep =
the diversity in one operator's production environment.


 


Best regards,


 


DENG Hui


Thanks.


 


Regards,


Richard Chen


 










=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie=
s Co., Ltd.

=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=
=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=
=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=
=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=
=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=
=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=
=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=
=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=
=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=
=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain confide=
ntial information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!


 
--_000_2691CE0099834E4A9C5044EEC662BB9D572E195Adfweml501mbb_-- From nobody Tue Oct 18 00:12:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46112950E for ; Tue, 18 Oct 2016 00:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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.431, 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 juArkRpvErOW for ; Tue, 18 Oct 2016 00:12:01 -0700 (PDT) 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 E89D51294F3 for ; Tue, 18 Oct 2016 00:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11342; q=dns/txt; s=iport; t=1476774720; x=1477984320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ceAC1iJuXliuFReAcZsmZwHXZpXYebLq8OvmhzsnLNg=; b=R8ySsh0PGKYqyAQsCi2fnGbm+uZUZqn09SJvjY6IMLxi1v8WSea99Rcr pFdhTioJBqp72qF0wJxk6xnZpRvMRLWXBN+o9Dp5xwuykRX6DqqviHKwR AEFt6xLGgW1U1qtwt8ZoAqs+vJuT6imRJgsZEnmLP7GiFHZ3KPGO2L5H0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAQDnyQVY/51dJa1VBhsBAQEDAQEBC?= =?us-ascii?q?QEBAYM8AQEBAQEdgVMHjS2XBZIpgg+CCIJsgzYCgXI4FAECAQEBAQEBAV4nhGI?= =?us-ascii?q?BAQMBbAoDBQsCAQgwFjIlAgQBDQWISgjCPgEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2LEoQxAgYVR4R0HQWOeosMAZADgW6EZ4M3hWmHEIVrg38BHjZSgnkGG1cBe3K?= =?us-ascii?q?GKIEugQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,508,1473120000"; d="scan'208";a="336205326" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2016 07:11:59 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9I7BxuU021816 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Oct 2016 07:11:59 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 02:11:58 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 02:11:58 -0500 From: "Douglas Gash (dcmgash)" To: Alan DeKok , Warren Kumari Thread-Topic: [OPSAWG] Start of WGLC for TACACS+ document. Thread-Index: AQHSKQ7qMG5uxhlHFkmqhKxqAd3Cew== Date: Tue, 18 Oct 2016 07:11:58 +0000 Message-ID: References: <5019ABA9-BB74-4C69-A455-12C17A2958CE@deployingradius.com> <638AC1BA-02A7-4346-8DC0-B7E762DA334D@deployingradius.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.3] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <40B788FBA318DD4996DAD59436D5A4BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-tacacs-05@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for TACACS+ document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 07:12:02 -0000 Many thanks Alan for the thorough review. We=B9ll collate all your comments and respond shortly. On 12/10/2016 22:35, "Alan DeKok" wrote: > My $0.02 on the contents of the Security Considerations section. I'm >sure I've missed things. > > Please also comment if the suggestions here are wrong or unworkable. > >---- >9. Security Considerations > >The protocol described in this document has been in widespread use >since specified in "The Draft" (1998). However it does not meet >modern security standards, and faces vulnerabilities with privacy and >authenticity. > >This section describes issues with the TACACS+ specification, then the >protocol, deployments, followed by recommendations for implementations. > >Because of the security issues with TACACS+, the authors intend to >follow up this document with an enhanced specification of the >protocol employing modern security mechanisms. > > >9.1 Security of The Draft Specification > >TACACS+ was originally specified in "The Draft" (1998). However, this >draft is incomplete, and leaves key points unspecified. As a result, >software authors have had to make implementation choices about what >should, or should not, be done in certain situations. These >implementation choices are somewhat constrained by ad hoc >interoperability tests. That is, all TACACS+ clients and servers >interoperate, so there is a rough consensus on how the protocol works. > >While the authors have made every effort to maintain compatibility, >there is no guarantee, however, that this specification matches the >behavior of current or historical implementations. We believe that >any incompatibilites are due to modern security requirements. We >therefore suggest that implementors should read this document, and >verify that their implementations follow the security practices >recommended here. > > >9.2 Security of The Protocol > >The major security issue with the TACACS+ protocol is the ad hoc >"encryption" defined in Section 3.6. This "encryption" is more >properly called "obfuscation", and has had no security analysis. That >is, the security or insecurity of the protocol is entirely unknown. > >Attacks on cryptographic hashes are well known and are getting better >with time, as discussed in [RFC4270]. The security of the TACACS+ >protocol is dependent on MD5 [RFC1321], which has security issues as >discussed in [RFC6151]. It is not known if the issues described in >[RFC6151] apply to TACACS+. <> > >The choice of encrypting the body but not the packet header is >unusual. The lack of security on the packet header means that an >attacker can modify the header without detection. > >For example, a "session_id" can be replaced by an alternate one, which >could allow an unprivileged administrator to "steal" the authorization >from a session for a privileged administrator. An attacker could also >update the "flags" field to indicate that one or the other end of a >connection requires TAC_PLUS_UNENCRYPTED_FLAG, which could remove what >little security is available. > >What little security that exists is dependent on implementations >limiting access to known clients, and on the strenght of the secret >key. Attacks who can guess the key or break the obfuscastion method >can gain unrestricted and undetected access to all TACACS+ traffic. >This access permits the attacker to execute any command on any system, >leaving the attacker in complete control of the network. The negative >side effects of such a successful attack cannot be overstated. > >9.2.1 Security of Authentication Sessions > >There are a number of security issues with authentication sessions. >As the sessions enable the exchange of clear-text passwords, an >attacker capable of observing the unencrypted traffic or breakign the >encrypted traffic, can gain complete network access. Similarly, >MSCHAPv1 and MS-CHAPv2 offer little additional security, while ARAP is >insecure and MUST NOT be used. As of the publication of this >document, there has been no similar attacks on the CHAP protocol. > >Section 4.4.3 permits the redirection of a session to another server >via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this >process, the secret key for a new server can be sent to the client. >This public exchange of secret keys means that once one session is >broken, it may be possible to leverage that attack to attacking >connections to other servers. Section 9.4, below, has recommendations >for securing this portion of the protocol. > >9.2.2 Security of Authorization Sessions > >The primary issue with authorization sessions is that unauthenticated >authorization is allowed. Almost as bad, authorization is permitted >where authentication was done by a third party, such as with >TAC_PLUS_AUTHEN_METH_KRB5. This third party authentication is based >entirely on the client claiming that the user has been authenticated, >and the server trusting that request. This practice is entirely >insecure. > >There is also no way to cryptographically tie an authorization session >to a particular authentication session. That is, when the client >indicates "authen_method" in the packet header, the authentication and >authorization sessions are tied together implicitly by the contents of >the other fields, such as "use", "port", "rem_addr", etc. > ><how the server can use these fields to tie together authentication / >authorization sessions. Perhaps recommend that all AAA include a >"task_id"? >> > >The specification allows for the exchange of attribute-value pairs. >While a few such attributes are defined here, the protocol is >extensible, and vendors can define their own attributes. There is no >registry for such attributes, and in the absence of a published >specification, no way for a client or server to know the meaning of a >new attribute. > >As a result, vendors SHOULD NOT define new attribute-value pairs, >unless such pairs are used only to communicate between client and >server implementations both written by the same vendor. > >The "cmd" and "cmd-arg" attributes define shell commands and >arguments, but does not specify what these are. The specific >commands, therefore, are undefined. > > >9.2.3 Security of Accounting Sessions > >The security considerations for accounting sessions are largely the >same as for authorization sessions. This section describes additional >issues specific to accounting sessions. > >There is no way in TACACS+ to signal that accounting is required. >There is no way for a server to signal a client how often accounting >is required. The accounting packets are received solely at the >clients discretion. Adding such functionality would assist with >auditing of user actions. > >The "task_id" field is defined only for accounting packets, and not >for authentication or authorization packets. As such, it is difficult >to correlate accounting data with a previous authentication or >authorization request. > ><> > > >9.4 Security of Deployments > >Due to the above concerns with the protocol, it is critical that it be >deployed in a secure manner. > >Systems using TACACS+ MUST be configured so that TACACS+ traffic is >secured. Any user or service who is not interacting with the TACACS+ >protocol MUST NOT be able to observe TACACS+ traffic, even when >TACACS+ "encryption" is used. > >When used inside of enterprises, TACACS+ traffic MUST be sent over >management networks. When used on the wider internet, TACACS+ traffic >MUST be secured via a modern security protocol such as TLS or IPSec. >As this specification describes the historic protocol, recommendations >on TLS and IPSec parameters are outside of the scope of this document. > > >9.4 Recommendations for Implementations > >The following recommendations are for clients and servers which >implement the TACACS+ protocol. These recommendations describe end >user interaction or user interface design. While not part of the >protocol itself, good designs can prevent insecure configurations. > >Clients and servers MUST default to rejecting all connections which >have the TAC_PLUS_UNENCRYPTED_FLAG set. Clients and servers MAY >permit such connections when a debugging or test flag is set. Clients >and servers MUST NOT run with this flag set in normal environments. > >Similarly, the default for both clients and servers MUST be to require >a secret key when configuring a new server or client. The secret key >MUST NOT be empty, and SHOULD be at least eight (8) characters in >length. Clients and servers SHOULD permit the user of keys unique to >each server or client which they are connecting to. They SHOULD warn >the administrator if a secret key is re-used. Documentation for >implementations SHOULD recommend the use of strong secret keys. > >Servers should maintain list of known clients, and reject connections >which originate from other systems. Servers SHOULD NOT permit the >configuration of wildcard clients. e.g. clients which map to a >network range. > >Where a client or server detects that the secret key is incorrect, it >SHOULD terminate the underlying TCP connection, and log a message to >the system administrator. There is no good reason to keep a >connection open when the systems are unable to communicate in a >meaningful fashion. > >Implementions MUST default to using TAC_PLUS_AUTHEN_TYPE_CHAP for >authentication. We recognize, however, that this authentication >method is incompatible with many password storage systems. As a >result, other authentication methods are still in the protocol, and >can be used so long as administrators recognize the security issues >with their use. > >Clients MUST default to treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as if >TAC_PLUS_AUTHEN_STATUS_FAIL had been received instead. Clients >SHOULD allow administrators to explicitly enable the >TAC_PLUS_AUTHEN_STATUS_FOLLOW functionality. When the functionality >is enabled, clients SHOULD permit administrators to specify ranges of >addresses, and/or sets of hosts, along with corresponding secret keys, >for which redirection will be permitted. Clients SHOULD ignore >redirects to hosts which are outside of the pre-configured range or >list. Clients SHOULD ignore any key provided via >TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a preconfigured >key for that host. > >For authorization, servers SHOULD default to requiring >TAC_PLUS_AUTHEN_METH_TACACSPLUS. Servers SHOULD track authentication >sessions via methods "to be described" in Section 5.1. > >Where a server receives an unknown attribute-value pair, it SHOULD >reply with TAC_PLUS_AUTHOR_STATUS_FAIL. Where a server receives an >unrecognized values in authorization attributes such as "cmd", >"cmd-arg", "acl", etc., the server SHOULD reply with >TAC_PLUS_AUTHOR_STATUS_FAIL. When a client receives an unknown >authorization attribute, it SHOULD behave as if it had received >TAC_PLUS_AUTHOR_STATUS_FAIL. > From nobody Tue Oct 18 00:49:49 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337A3129597; Tue, 18 Oct 2016 00:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 YZbV-N7vc9uV; Tue, 18 Oct 2016 00:49:45 -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 C653812959C; Tue, 18 Oct 2016 00:49:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTJ20373; Tue, 18 Oct 2016 07:49:40 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 18 Oct 2016 08:48:39 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 18 Oct 2016 15:48:32 +0800 From: Duzongpeng To: Joe Touch Thread-Topic: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel Thread-Index: AQHSGD4DWumMsag3LEKPYa8luKqN4qCLxZmAgAsD84CAFyEiIA== Date: Tue, 18 Oct 2016 07:48:32 +0000 Message-ID: References: <78f07b6d-3c78-e002-b2f5-487da9c8be72@isi.edu> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] 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.5805D415.001C, 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: 13d103779c9ef6ea9811da5ae04ee68e Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org" Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 07:49:48 -0000 Hello, Joe Although not as an author of the draft, I would like to talk about your su= ggestions. Please see inline.=20 Best Regards Zongpeng Du > Major issues: > > As already noted in draft-intarea-tunnels, many existing tunnel=20 > mechanisms are inconsistent or incorrect in their support for IPv6 MTU=20 > requirements, both as transits for IP packets and as IP endpoints.=20 > Although this document cites existing standards, the inconsistency and=20 > incorrectness of these standards should be addressed. It might be=20 > sufficient to indicate that any tunneling mechanism selected MUST=20 > support the minimum IPv6 MTU requirements independent of this=20 > signalling mechanism (i.e, the signalling mechanism doesn't address or=20 > correct any errors or inconsistencies in the tunnel mechanism selected). > [duzongpeng]=20 Would it ok if the authors add a section to declare that every tunneling me= chanism=20 MUST support the minimum IPv6 MTU requirements said in "draft-ietf-intarea-= tunnels-03" If the draft, the tunnel between the WTP and Access Router needs to be esta= blished, and the WTP and AC already have a CAPWAP connection. According to the tunneling mechanism supported, MTU information perhaps can= be computed by the AR. AC can have the information, and inform the WTP in the "Tunnel Info Element= " field.=20 [duzongpeng] > Regarding IP endpoint requirements, it might be useful to consider=20 > whether this protocol could be extended to indicate the receiver=20 > payload reassembly limit when indicating support for each tunnel type,=20 > to assist the source in determining whether the resulting tunnel will=20 > be IPv6 compliant (rather than becoming a black hole for valid packet siz= es). > [duzongpeng]=20 Is it the same information talked above?=20 I think it is flexible to indicate something in the "Tunnel Info Element" f= ield. If you can provide detailed modification suggestions, perhaps the author wi= ll be glad to accept it. BTW, I have also given some suggestions to the draft. [duzongpeng] > Additionally, for the transport protocol-based tunnels, it would be=20 > useful to consider whether the protocol could indicate not only the=20 > endpoint IP address but the port number as well. > [duzongpeng]=20 If any tunnel type needs this port information, it should be ok to carry it= in the "Tunnel Info Element" field. [duzongpeng] > Minor issues: > > It might be useful to consider IPsec TLS, and DTLS tunnels as well as=20 > those already listed. [duzongpeng]=20 According to my understanding, it is ok to add some tunnel types.=20 However, the authors have decided to only talk some essential ones in this = draft, and perhaps talk about others in latter drafts if necessary. [duzongpeng] -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Tuesday, October 04, 2016 5:50 AM To: Joe Touch Cc: opsawg@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org Subject: Re: [OPSAWG] TSV ART IETF LC review of draft-ietf-opsawg-capwap-al= t-tunnel [ - Discuss, tsv-art (first for clutter, second because I'm not subscribed)= ] Dear authors, I just wanted to make sure that you had seen these are well... W On Mon, Sep 26, 2016 at 5:36 PM, Joe Touch wrote: > CC'ing tsv-art... > > > On 9/26/2016 2:34 PM, Joe Touch wrote: > > Hi, all, > > I've reviewed this document as part of the Transport Area Review=20 > Team's > (TSVART) ongoing effort to review key IETF documents. These comments=20 > were written primarily for the transport area directors, but are=20 > copied to the document's authors for their information and to allow=20 > them to address any issues raised. When done at the time of IETF Last=20 > Call, the authors should consider this review together with any other=20 > last-call comments they receive. Please always CC tsv-art@ietf.org if=20 > you reply to or forward this review. > > Please resolve these comments along with any other Last Call comments=20 > you may receive. Please wait for direction from your document shepherd=20 > or AD before posting a new version of the draft. > > Document: draft-ietf-opsawg-capwap-alt-tunnel > Title: Alternate Tunnel Encapsulation for Data Frames in CAPWAP > Reviewer: J. Touch > Review Date: Sept 26, 2016 > IETF Last Call Date: Sept 16, 2016 > > Summary: This doc refers to existing tunneling specifications, many of=20 > which are inconsistent or incorrect. In particular, there are=20 > potential complicatinos with MTU support and signalling that could=20 > affect transport protocols. > > Major issues: > > As already noted in draft-intarea-tunnels, many existing tunnel=20 > mechanisms are inconsistent or incorrect in their support for IPv6 MTU=20 > requirements, both as transits for IP packets and as IP endpoints.=20 > Although this document cites existing standards, the inconsistency and=20 > incorrectness of these standards should be addressed. It might be=20 > sufficient to indicate that any tunneling mechanism selected MUST=20 > support the minimum IPv6 MTU requirements independent of this=20 > signalling mechanism (i.e, the signalling mechanism doesn't address or=20 > correct any errors or inconsistencies in the tunnel mechanism selected). > > Regarding IP endpoint requirements, it might be useful to consider=20 > whether this protocol could be extended to indicate the receiver=20 > payload reassembly limit when indicating support for each tunnel type,=20 > to assist the source in determining whether the resulting tunnel will=20 > be IPv6 compliant (rather than becoming a black hole for valid packet siz= es). > > Additionally, for the transport protocol-based tunnels, it would be=20 > useful to consider whether the protocol could indicate not only the=20 > endpoint IP address but the port number as well. > > Minor issues: > > It might be useful to consider IPsec TLS, and DTLS tunnels as well as=20 > those already listed. > > --- > > -- I don't think the execution is relevant when it was obviously a bad idea in= the first place. This is like putting rabid weasels in your pants, and later expressing regr= et at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Oct 20 09:23:56 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C761C12966C for ; Thu, 20 Oct 2016 09:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 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.431, 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 zZOFqdOcCO6Y for ; Thu, 20 Oct 2016 09:23:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B71F1295A1 for ; Thu, 20 Oct 2016 09:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2233; q=dns/txt; s=iport; t=1476980633; x=1478190233; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/+W0B8+pb2CNIWKbviLoV1pi0dWX8kFNZxpvsCP1p34=; b=JzF42vlzXg8XND5WmrSY7lJAP1tSOJcaw08+HKPtMAuVHY/m2zqGlsQL guQrLaxkmDawKznKdJYBaogjS0EqoJLOgHFA9kf43KD+ANC3RXfje4bO/ uMEEIAAYyOKmb1iFqts2Eh6IXRw3b34wGhvPE/x2NQsbzmv241h9soJ7/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgBU7ghY/40NJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz4BAQEBAR1XfQeNLas5gggcDYUuSoF7PxQBAgEBAQEBAQFiHQuEYwE?= =?us-ascii?q?BBAEBATctBwkCEgEINjcLGwEGBQQOBRQHiDcOw1EBAQEBAQEBAwEBAQEBAQEBA?= =?us-ascii?q?R6LEoomBY5Fi0kBhimJY4FuToQbiSSMf4N/AR42WIM+gTpyh0GBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,371,1473120000"; d="scan'208";a="159778026" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2016 16:23:52 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u9KGNqTw021211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Oct 2016 16:23:52 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Oct 2016 11:23:51 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Thu, 20 Oct 2016 11:23:51 -0500 From: "Byju Pularikkal (byjupg)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] FW: New Version Notification for draft-pularikkal-opsawg-wifi-calling-01.txt Thread-Index: AQHSKu5W1xum/RUPPEyz3tiZdjcz+Q== Date: Thu, 20 Oct 2016 16:23:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.26.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <46E6A26225125145B0E07A7CE4618D1A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] FW: FW: New Version Notification for draft-pularikkal-opsawg-wifi-calling-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 16:23:55 -0000 Hello Everyone We are seeking some inputs feedback from the community on this draft. We believe this will be very use for Service Providers who supports or planning to support Carrier Wi-Fi calling. Appreciate it if you can review and provide some comments in the coming days. Regards Byju > >> >>A new version of I-D, draft-pularikkal-opsawg-wifi-calling-01.txt >>has been successfully submitted by Byju Pularikkal and posted to the >>IETF repository. >> >>Name: draft-pularikkal-opsawg-wifi-calling >>Revision: 01 >>Title: Carrier Wi-Fi Calling Deployment Considerations >>Document date: 2016-07-07 >>Group: Individual Submission >>Pages: 26 >>URL: =20 >>https://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-wifi-calling >>- >>01.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-pularikkal-opsawg-wifi-calling/ >>Htmlized: =20 >>https://tools.ietf.org/html/draft-pularikkal-opsawg-wifi-calling-01 >>Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-pularikkal-opsawg-wifi-calling-= 01 >> >>Abstract: >> Carrier Wi-Fi Calling is a solution that allows mobile operators to >> seamlessly offload mobile voice signaling and bearer traffic onto Wi- >> Fi access networks, which may or may not be managed by the mobile >> operators. Mobile data offload onto Wi-Fi access networks has >> already become very common, as Wi-Fi access has become more >> ubiquitous. However, the offload of mobile voice traffic onto Wi-Fi >> networks has become prevalent only in recent years. This was >> primarily driven by the native Wi-Fi Calling client support >> introduced by device vendors. The objective of this document is to >> provide a high level deployment reference to Mobile Operators and Wi- >> Fi Operators on Carrier Wi-Fi Calling. >> >> =20 >> =20 >> >> >>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. >> >>The IETF Secretariat >> > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Oct 20 12:31:02 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1BB1295B0 for ; Thu, 20 Oct 2016 12:31:00 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 kMBPtfqM9Yom for ; Thu, 20 Oct 2016 12:30:57 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460F512964C for ; Thu, 20 Oct 2016 12:30:56 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f128so109133551qkb.1 for ; Thu, 20 Oct 2016 12:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WB6EBiOj5rGXp7lBVK10npwlh5Nk630n1YW4mijoIdw=; b=15clsBbb2LJzCv2gKnUrymL8XB9u1JnfMQRrtDVve5uLCIu575c3x/BJ/EFufMnp4h 3wzr3SAFkGV/+9O2WEnCz3rQVaBVus/eH9Gvv882oPRQa4QvWvxDl1M380ooYg3nQElX 70zNMbkb3Gco+YEsvnx9tTc04XCyaY6FllZrOIvxLY3vsThC/J/9I4vtynzZBV4RGkSt hPW0HmwQt8u/Y16we8YzgvseIJVgJuwLgxLiwWw1iKILz89slbSL/kVA7d07dPOGSYDq VNC+QzDPZtv06hqwcn0hH/AwKf7j9nt6CW48bCFsDaUThL03pSPoDFr8vskNaBLuCq7s pCTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WB6EBiOj5rGXp7lBVK10npwlh5Nk630n1YW4mijoIdw=; b=cjR8L2LI0miIRdJWayBZPQbrZRZ1uERupER330jHRX1JTAazDRWIp+4ynFx8VKXOAM wfZuQfbimqjlq3Uz1hj7r4+d0dvVij54YodqEvIhQlLBKHXQa6nagLS10F3F3y2r4X0U 7XM5BeytKY4BYuV+1lB4R8L5G5rDqKDU+HLG2bCdd/pcopGPXH1la4+kHqB8cRvMhHIj Sz7Jb/Ze3u4IrWnhSoMFd3DjMDn3tiIeWNCo9ddtcgjKvapQvNJNvPmnYDkXxW/AyZaM FvsVBiPppCxTEgd/JJTf+kdVDQngNxw8FoaNPkgtvoE2UlyeAwVuIv2zTL7XW8N2xoxa NVgw== X-Gm-Message-State: ABUngvc+lPrsRrojQwKFZ1sb84Q3391vf8/5sIp7WQxL5nTYmApDlMAIdtst2iJSAVZzaBGthcia+YcNfmugW+cD X-Received: by 10.55.151.70 with SMTP id z67mr2238772qkd.185.1476991854363; Thu, 20 Oct 2016 12:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Thu, 20 Oct 2016 12:30:23 -0700 (PDT) In-Reply-To: References: <3FCB4CBE-6885-4708-AD21-4D4B2D1AA7EE@juniper.net> <058F02CC-5369-4A4D-96E9-B81FB6407973@juniper.net> <53f367e8-f011-a0e2-d027-8d21476a47dd@cisco.com> <2708A743-B900-41D2-9485-8EF901EBBE3B@juniper.net> From: Warren Kumari Date: Thu, 20 Oct 2016 15:30:23 -0400 Message-ID: To: Joel Jaeggli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:31:00 -0000 So, we chatted with our AD (CCed). He feels that RFC 7120 is clear enough that he can just request early allocation using the draft. So, the chairs believe that there is sufficient consensus to request these. Thanks y'all, and a reminder that we still have OpsAWG agenda time -- if you have a document **which has been discussed AND would benefit from meeting time** please let us know. Please include talk title & how much time you *need*. If you want to mail the chairs alias directly instead, please include "[SCHEDULE]" in the email subject - we get lots of mail before meetings, and don't want any agenda requests to slip through the cracks. If we happen to have some extra time at the end of the meeting we *may* allow presentations on new work, but in general we require that the draft has been published and has had significant discussion on list, so make sure you publish and get feedback early. Thanks, W A few reminders / tips to help your presentation be effective: ---------------------------------------------------------------------- 1: Please rehearse your talk, make sure that it fits within the allocated time slot, and that you have left some time for questions. It is very impolite to the working group to run over your allocated time, and we are likely to simply cut you off if you do. 2: We require slides at least *3* days before the meeting; you can revise them after this point if needed. Please include the version number on the first page of the slide deck. Please send them to the WG chairs alias - sending them to just one of us leads to confusion. 3: Please send these in PDF format - we=E2=80=99ve had a number of instance= s where the convertor doesn=E2=80=99t handle certain fonts, etc and the presenter becomes sad. 4: Please include slide numbers on all slides - it=E2=80=99s much easier to ask someone to go back to slide number 5 than =E2=80=9Cthe slide that was a couple after the second diagram=E2=80=A6 no, not that one, the next one=E2= =80=A6 erm=E2=80=A6 next?" 5: Slides are a summary of what you want to say - please don=E2=80=99t just put everything on the slides and read them verbatim (we all know how to read!) On Sat, Oct 8, 2016 at 1:52 PM, Warren Kumari wrote: > Hi all, > > So, reviving this thread... > > I think that there is sufficient merit to request early allocations > according to RFC7120 criteria. > Please note that if we request early allocations, it is good for one > year, renewable once. Assuming that the document progresses within > that two year timeframe to become and RFC, the IANA will convert the > early allocations into a permanent one -- if we don't, it will > automatically expire and be marked as such in the registry (or, if the > WG decided that they want to abandon this work, we can request that > they be released early). While the document is still in flux, the > parts around the allocations should be stable. > > The majority of the requests are for allocations from large (or > unlimited) code-spaces, and so it does not seem like there is > scarcity. The exception is the DHCPv4 > (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-paramet= ers.xhtml#options); > the v4 option space is 8bit, and ~68 (or, around a quarter) are > unassigned. The IPv6 option space is 16bit (65535 entries) and so > close to unlimited. > > Because I am not at all familiar with the sensitivity / implications > of the registrations in the various registries, I'm planning on asking > an expert reviewer from each of the below registries to please take an > early (before early allocation!) look at the document / relevant parts > of the document to confirm that we are doing the right thing, that > there isn't a more appropriate sub-registry, etc. > > "SMI Security for PKIX Certificate Extension" Registry > (http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number= s-1.3.6.1.5.5.7.1) > - "id-pe-mud-uri"; Registration Procedure: Specification Required. > The IANA considerations for this say: "The expert is expected to > ensure that any new values are strongly related to the work that was > done by the PKIX Working Group. That is, additional object > identifiers are to be related to X.509 certificates, X.509 attribute > certificates, X.509 certificate revocation lists (CRLs), or protocols > associated with them. Object identifiers for other purposes should not > be assigned in this arc.", so it is unclear if this is the appropriate > place for this, but perhaps Russ can suggest a better location / > system. > > Well Known URIs > (http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml) > - "mud"; Registration Procedure: Expert Review, mnot. > > MIME Media-type Registration > (http://www.iana.org/assignments/media-types/media-types.xhtml) - > "application/mud+json"; For allocations under the "Standards Tree > requests made through IETF documents will be reviewed and approved by > the IESG..." - this sounds like 'IESG Approval', but I'm planning on > asking our AD, Ned and / or Murray. > > Well Known Universal Resource Name (URNs) > (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) > - "urn:mud" ; Registration Procedure: IETF Consensus. > > The final issue is the creation of a registry for "IANA Link Layer > Discovery Protocol (LLDP) TLV subtype values" - this would create a > registry under the IANA OUI, as a "vendor-specific TLV". It appears > that there currently is no registry under the IANA vendor specific OUI > for LLDP, and this is creates an 8 bit registry. I'm *assuming* that > we could have something like 1-253 are useable, and 254 can later be > defined to be an "extension", but I'd like to get some additional > feedback. https://tools.ietf.org/html/rfc7042 seems to be the closest > that I could find..... > > The "IANA Considerations" section of the document also needs some > polishing -- it would be nice if it pointed more definitely at the > registry from which it is making requests, if the "{{secon}}" label > expanded, and if the formatting of the URN bit were better. > > > So, does anyone object to this plan? If so, please let us know by > October 13th If not, the chairs will reach out to our AD / the > Designated Experts as described above. > > On Tue, Aug 30, 2016 at 9:47 PM, Zhoutianran wro= te: >> Hi Kent, >> >> Here are some words copied from RFC 7120. I think they can address your = question. >> >> Request: >> 6. IANA makes an allocation from the appropriate registry, marking >> it as "Temporary", valid for a period of one year from the date >> of allocation. The date of first allocation and the date of >> expiry are also recorded in the registry and made visible to the >> public. >> >> Follow up: >> If the document progresses to the point at which IANA normally makes >> code point allocations, it is the responsibility of the authors and >> the WG chairs to remind IANA that there were early allocations and of >> the code point values allocated in the IANA Considerations section of >> the RFC-to-be. Allocation is then just a matter of removing the >> "Temporary" tag from the allocation description. >> >> Expiry: >> If an early allocation expires before the document progresses to the poi= nt where >> IANA normally makes allocations, the authors and WG chairs may repeat >> the process described in Section 3.1 to request renewal of the code >> points. At most, one renewal request may be made; thus, authors >> should choose carefully when the original request is to be made. >> >> If a follow-up request is not made, or the document fails to progress >> to an RFC, the assignment will remain visible in the registry, but >> the temporary assignment will be shown to have expired as indicated >> by the expiry date. The WG chairs are responsible for informing IANA >> that the expired assignments are not required and that the code >> points are to be marked "deprecated". >> >> A deprecated code point is not marked as allocated for use as >> described in any document (that is, it is not allocated) and is not >> available for allocation in a future document. The WG chairs may >> inform IANA that a deprecated code point can be completely >> de-allocated (i.e., made available for new allocations) at any time >> after it has been deprecated. >> >> >> Regards, >> Tianran >> >>> -----Original Message----- >>> From: Kent Watsen [mailto:kwatsen@juniper.net] >>> Sent: Tuesday, August 30, 2016 9:56 PM >>> To: Warren Kumari; Eliot Lear >>> Cc: Zhoutianran; opsawg@ietf.org; opsawg-chairs@ietf.org >>> Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment /= /RE: >>> Adoption poll for draft-lear-ietf-netmod-mud-04 >>> >>> >>> I didn=E2=80=99t know that, thanks for the clarification. I retract my= comment. >>> >>> But I wonder then, if they are temporary and reclaimed, will Elliot=E2= =80=99s goal >>> be achieved? - or is it the case that the temporary assignments can be= come >>> permanent through the RFC process? - an optimistic long-term allocation= ? >>> >>> Thanks, >>> Kent >>> >>> >>> On 8/29/16, 4:39 PM, "Warren Kumari" wrote: >>> >>> ... and just as a reminder to the WG, early allocations are explici= tly >>> temporary, and are marked in the registry as such. >>> >>> This isn't burning a critical resource forever - the allocations >>> spaces are not very rare, and they can be reclaimed if needed... >>> >>> W >>> >>> On Thu, Aug 25, 2016 at 4:49 PM, Eliot Lear wrote: >>> > Yes, there is. And Early assignment is not an unusual request. = See >>> RFC >>> > 7120. >>> > >>> > >>> > On 8/25/16 10:01 PM, Kent Watsen wrote: >>> > >>> > >>> > >>> > I don=E2=80=99t know. It seems that every draft could make simil= ar claims, >>> and yet >>> > having IANA make early assignments all the time wouldn=E2=80=99t = be good. I >>> don=E2=80=99t >>> > see why this draft should get a pass. Is there any documentatio= n >>> detailing >>> > criteria for early assignments? >>> > >>> > >>> > >>> > Kent >>> > >>> > >>> > >>> > From: Eliot Lear >>> > Date: Thursday, August 25, 2016 at 2:36 PM >>> > To: Kent Watsen , Zhoutianran >>> , >>> > Warren Kumari >>> > Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" >>> > >>> > Subject: Re: [OPSAWG] WG consensus call for the IANA early assign= ment >>> //RE: >>> > Adoption poll for draft-lear-ietf-netmod-mud-04 >>> > >>> > >>> > >>> > Hi Kent, >>> > >>> > We're doing some open source and would like to make it easier for= those >>> who >>> > are coding to have to do a little less REcoding. I doubt very mu= ch >>> we're >>> > going to see much change in the content or format the URL or the = option. >>> > That's what most of the requests are for. Where I expect we will= see >>> change >>> > is in the content of the YANG file. There we have the option to = bump >>> the >>> > version # in the URL if we think there has been any real uptake o= f >>> earlier >>> > versions. >>> > >>> > Fair enough? >>> > >>> > Eliot >>> > >>> > >>> > >>> > On 8/25/16 7:27 PM, Kent Watsen wrote: >>> > >>> > >>> > >>> > Why is an early assignment being requested? I think it unusual, >>> especially >>> > for a draft that was just adopted, and no justification is given = for >>> why >>> > it=E2=80=99s needed other than =E2=80=9Cto assist with interopera= ble development=E2=80=9D... >>> > >>> > >>> > >>> > Kent >>> > >>> > >>> > >>> > From: OPSAWG on behalf of Zhoutianran >>> > >>> > Date: Tuesday, August 23, 2016 at 5:46 AM >>> > To: Eliot Lear , Warren Kumari >>> > Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" >>> > >>> > Subject: [OPSAWG] WG consensus call for the IANA early assignment= //RE: >>> > Adoption poll for draft-lear-ietf-netmod-mud-04 >>> > >>> > >>> > >>> > Hi All, >>> > >>> > >>> > >>> > Since the authors of the draft-ietf-opsawg-mud-00 asked for the e= arly >>> > assignment for various registries from IANA, I would like to ask = the >>> WG >>> > consensus. >>> > >>> > >>> > >>> > There will be 1 week since today. You can express your support or >>> objection. >>> > >>> > >>> > >>> > If there is no objection, I would like to request from the WG. >>> > >>> > >>> > >>> > The following is a list of IANA considerations copied from the dr= aft. >>> > >>> > >>> > >>> > >>> > >>> > Best, >>> > >>> > Tianran >>> > >>> > >>> > >>> > ------------------------------------- >>> > >>> > >>> > >>> > 15. IANA Considerations >>> > >>> > >>> > >>> > 15.1. DHCPv4 and DHCPv6 Options >>> > >>> > >>> > >>> > IANA is requested to allocated the DHCPv4 and v6 options as sp= ecified >>> > >>> > in Section 9. >>> > >>> > >>> > >>> > 15.2. PKIX Extensions >>> > >>> > >>> > >>> > The IANA is requested to assign a value for id-pe-mud-uri in t= he >>> "SMI >>> > >>> > Security for PKIX Certificate Extension" Registry. Its use is >>> > >>> > specified in Section 10. >>> > >>> > >>> > >>> > 15.3. Well Known URI Suffix >>> > >>> > >>> > >>> > The IANA is requested to register the URL suffix of "mud" as f= ollows: >>> > >>> > >>> > >>> > o URI Suffix: "mud" o Specification documents: this document o >>> > >>> > Related information: n/a >>> > >>> > >>> > >>> > 15.4. MIME Media-type Registration for MUD files >>> > >>> > >>> > >>> > The following media-type is defined for transfer of MUD file: >>> > >>> > >>> > >>> > o Type name: application >>> > >>> > o Subtype name: mud+json >>> > >>> > o Required parameters: n/a >>> > >>> > o Optional parameters: n/a >>> > >>> > o Encoding considerations: 8bit; application/mud+json values >>> > >>> > are represented as a JSON object; UTF-8 encoding SHOULD be >>> > >>> > employed. >>> > >>> > o Security considerations: See {{secon}} of this document. >>> > >>> > o Interoperability considerations: n/a >>> > >>> > o Published specification: this document >>> > >>> > o Applications that use this media type: MUD controllers as >>> > >>> > specified by this document. >>> > >>> > o Fragment identifier considerations: n/a >>> > >>> > o Additional information: >>> > >>> > >>> > >>> > Magic number(s): n/a >>> > >>> > File extension(s): n/a >>> > >>> > Macintosh file type code(s): n/a >>> > >>> > >>> > >>> > o Person & email address to contact for further information: >>> > >>> > Eliot Lear , Ralph Droms >>> > >>> > o Intended usage: COMMON >>> > >>> > o Restrictions on usage: none >>> > >>> > >>> > >>> > o Author: Eliot Lear , Ralph Droms >>> >>> > >>> > o Change controller: IESG >>> > >>> > o Provisional registration? (standards tree only): No. >>> > >>> > >>> > >>> > >>> > >>> > 15.5. LLDP IANA TLV Subtype Registry >>> > >>> > >>> > >>> > IANA is requested to create a new registry for IANA Link Layer >>> > >>> > Discovery Protocol (LLDP) TLV subtype values. The recommended >>> policy >>> > >>> > for this registry is Expert Review. The maximum number of ent= ries >>> in >>> > >>> > the registry is 256. >>> > >>> > >>> > >>> > IANA is required to populate the initial registry with the val= ue: >>> > >>> > >>> > >>> > LLDP subtype value =3D 1 >>> > >>> > >>> > >>> > Description =3D the Manufacturer Usage Description (MUD) Unifo= rm >>> > >>> > Resource Locator (URL) >>> > >>> > >>> > >>> > Reference =3D < this document > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > From: Eliot Lear [mailto:lear@cisco.com] >>> > Sent: Monday, August 22, 2016 7:04 PM >>> > To: Warren Kumari >>> > Cc: Zhoutianran; opsawg@ietf.org; opsawg-chairs@ietf.org >>> > Subject: Re: Adoption poll for draft-lear-ietf-netmod-mud-04 >>> > >>> > >>> > >>> > Hi Warren, Tianran, and all, >>> > >>> > >>> > >>> > On 8/17/16 4:17 PM, Warren Kumari wrote: >>> > >>> > >>> > >>> > >>> > Second, and hopefully not that more of a controversy, I would lik= e >>> to >>> > request early IANA assignments to assist with interoperable >>> > development. These would be listed in the IANA considerations se= ction >>> > of the current draft. If we need a WG draft to make this happen,= that's >>> > fine with me, but we should do a quick rev after the assignments. >>> > >>> > >>> > >>> > I believe that this *can* be accomplished without it being a WG d= oc, >>> but it >>> > is better / cleaner / easier if we make it a WG doc and then ask = for >>> early >>> > assistant. We are fine with lots of revisions / it being submitte= d >>> and then >>> > quickly revised. >>> > >>> > >>> > Just following up on this point: we'd like to request early assig= nment >>> from >>> > IANA for the various registries. Does that go through the chairs= or >>> the >>> > authors at this point? >>> > >>> > Thanks, >>> > >>> > Eliot >>> > >>> > >>> > >>> > >>> >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a bad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later express= ing >>> regret at having chosen those particular rabid weasels and that pai= r >>> of pants. >>> ---maf >>> >> > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Oct 20 12:32:31 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6C1296B3 for ; Thu, 20 Oct 2016 12:32:29 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 9pmBSFbShudP for ; Thu, 20 Oct 2016 12:32:28 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4C812964C for ; Thu, 20 Oct 2016 12:32:28 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n189so114232156qke.0 for ; Thu, 20 Oct 2016 12:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Mrn/LCzEc8rqnD8GHkKlizyhtkOQFV0xbyKMaEfnD24=; b=oq2d0zDmn8Ijxi5FoiSf7vywToT315wbKKzgapTnZ3e/vMSrn1W69Ze5ELz7WQXDZi JBjkipo8qbYvWsTOjippODVvkR2X539tXIylwc9Q8wSKVW6jzCitXqFkkS5tAmDp5T47 Fga8xsjLsZwKAKogQTLfvrE+q1zsg8A/vMeSc1v1Qjm4xcc49/EaFbwd7mWh3YCS0E2w e+fLbiEBDueNnnKetFw12bZzrVyDvyqpIyJ/vOsAZ5YhBz7UOKu3vuCkXMuftF9BqH7p ohViQnpaXji5YOlQ++KtX21L9jzFp6VKKGUavNEKc4yVtLIBk19qZqgB05J3QQbVf/Pm WKrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mrn/LCzEc8rqnD8GHkKlizyhtkOQFV0xbyKMaEfnD24=; b=jWI8Ce0lDRcZ8Pkm1jTo0l/ah/3YTZ1X0/42XGAdI7/6S/dNsPIhVHNUcSFQtez2/x W4ix50yVNxa/Fo+vQGHifMklfopW/V2iXuNbiDXapu5VA+xR9ZEkbu05HVJUXDFzgN9K xtGrbI2ATMAbi6HRjdYec6e2xI7uCgLNJeIWJYNdAT29wy8k+UwAlotdRs5x21/MieG4 tayv5CeY1b0V6OJQJKSsaoXYvB9VRNuMAxdJ+nIgCZgZR/5eyJUcyZU6FSVG1o7bfW00 bvRkLW0Xymd3kaM07dsoH4Uy62fOLhgYNG6X5GkegjZJK2BQnxc+daF3wj0m/ywtcWZe l/uQ== X-Gm-Message-State: ABUngveyHAerriwEMtMMgD7LKgPmmSEk6TIe7LpDQ5mWzk0+Sbjp0WLIdQFx0UQTEz8JwmYqNMz5XWE7juiadWWE X-Received: by 10.55.183.2 with SMTP id h2mr1819977qkf.134.1476991946785; Thu, 20 Oct 2016 12:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Thu, 20 Oct 2016 12:31:56 -0700 (PDT) From: Warren Kumari Date: Thu, 20 Oct 2016 15:31:56 -0400 Message-ID: To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Draft cutt-off is Monday... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:32:29 -0000 Just a reminder that the last day you can submit a document before Seoul is: 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Oct 20 12:43:56 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC201296D0 for ; Thu, 20 Oct 2016 12:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 U1oDrxUiDObH for ; Thu, 20 Oct 2016 12:43:47 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 BDBE41296F2 for ; Thu, 20 Oct 2016 12:43:45 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id n189so114842406qke.0 for ; Thu, 20 Oct 2016 12:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HMWyn4N8vULPppfYZ6kuaLZSdpmvM+7jSkVdvBZCS2I=; b=Qez0omE5JdEOpuNcwQk3/pGXckIVUIveD8do+VwwcEREEAqa7Q8CEDDXhweeJxdNuC hRxlmIAIUIquByaFHPPP5p1dfNmw8QzFV6xGEVSzhbfd65hnK2LpcSIHODMqXbLOS22l JwxasADxtl11xPbxP4V48EYcWpFXMpZT0IjibGzaxZ8f5EzbdKuZruWKIe+EDQVaBCgO 2fpN3ZSN4sJ0sK22C48AydOhyJTHnTWPPu1G92MiFL5WLRe8XrxzWhgAN8Bjo0TX4Gxx OUU6u/az85vkVuxdwd9cSsSBVyxDId64UfjdNvkdKfZnl/XZNz3butUoUDKSuLEA6qwS Ue6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HMWyn4N8vULPppfYZ6kuaLZSdpmvM+7jSkVdvBZCS2I=; b=blc/L3onjEAqqvgHafOnk+1TQXRd5BGHuBsGMiIEgFM5iV28qWxBMbAzpTlKJipAKu Ex+qcQ1X7zYhiH8rdp9CPdt3QXdicJsXRtLEYDUhvvEhg0xSX9XoG85yfJN6hU7T9iSZ JYUxS1VZ8oB7oszFBffalXj0CaTc79Zow2IdZ20bDqVmrEcTv39j1PR1iTiwRhntLoTP 4qIOPpJX0eY0QrllhyruiWuxiQVSEYg8ofFsY7QineUuP7WbN4GK7buJ5jIm7LEGfMlO A8ZKk9I6RBhyb1lNun/ZoMAd4vnz1mIrRCDe6OnOXRxMQDMyKgeRt6nWVXBvvTi4cWME PFiQ== X-Gm-Message-State: ABUngvfJGFMxN1+upcax4/lazwARQahpQGq1657kRbiVYc9bJOdJ/a+ed+E2iTrZy4C+Elom1o9CgMXFlss7FANO X-Received: by 10.233.237.209 with SMTP id c200mr1898933qkg.29.1476992624587; Thu, 20 Oct 2016 12:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Thu, 20 Oct 2016 12:43:14 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Thu, 20 Oct 2016 15:43:14 -0400 Message-ID: To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] Draft cutt-off is Monday... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:43:55 -0000 On Thu, Oct 20, 2016 at 3:31 PM, Warren Kumari wrote: > Just a reminder that the last day you can submit a document before Seoul is: > > 2016-10-31 (Monday): Internet Draft submission cut-off (for all > drafts, including -00) by UTC 23:59, upload using IETF ID Submission > Tool. > ... and someone poked me off-list and pointed out that the 31st is /next/ Monday, not /this/ Monday.... Let's just pretend that I knew that all along and that this was just a clever ploy to save people from missing the deadline, okay?! W > W > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Oct 20 12:52:39 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BDB129562 for ; Thu, 20 Oct 2016 12:52:37 -0700 (PDT) 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=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 sLzOzMwY405B for ; Thu, 20 Oct 2016 12:52:35 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0124.outbound.protection.outlook.com [104.47.1.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EEF1296BC for ; Thu, 20 Oct 2016 12:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pPb9rj/gMEjfVCC+hJyK2r7rgUwztlnfEHx/vI+DfCY=; b=I/m0iazNpK1p1p8mJVpOU+6FAI7a0ymK6cRNqZr4+2pgrplgv25ayXp45SLAWNEf6cbSnEQNmIMukMxHT2ksZoxl+n7VVPAfwOBVWv5clmWb0j7KE4J55bYseqh/OUa0biHcQMphPlsZXPi/NSS10eIWmv0QzUuNwNQQlYZMlsg= Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 20 Oct 2016 19:52:26 +0000 Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0669.011; Thu, 20 Oct 2016 19:52:26 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Draft cutt-off is Monday... Thread-Index: AQHSKwpVNEBIFAeDb0uM181niG/sBaCxv4Rw Date: Thu, 20 Oct 2016 19:52:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; x-originating-ip: [131.228.2.29] x-ms-office365-filtering-correlation-id: b6594c11-7004-426f-de1c-08d3f9229e48 x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2859; 7:9irc3qSdxmLrbSxxJWCN6GBQpwrcWteXzzPT7aMf3JxIKUqda6sNP85sYmbBBSPV3lc/EiGfhm+Lw6plCs3Jrk6AgeI76bM0kKtJOtlFFtoX4UAnWJ7Fbk4pnTRkLEfHrqKJ4IsZJGkN4xyPsUFeXCwdnj7qgfG38Id/kZctrySVbSWOWDxHSAMNPKZzGX3n+W3ARTMAlFKtnpjvvv2gwjgXwbZyExEnexvk/GlhCA79eisz245Cr7YTLfvJjWpzaYME+5c1iLm4E9Q4VWxqKv4VvFrcolZSGsgpEUR1R42Y8SIvup0nCfZoSLRbWxr5hRQzUgS66N2wTX596XhEC/S2rYrWTdUYuXCUADTQI6M= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2859; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0701MB2859; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2859; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(53434003)(377454003)(24454002)(13464003)(377424004)(15975445007)(2900100001)(5001770100001)(7846002)(92566002)(81156014)(5002640100001)(3280700002)(5660300001)(8676002)(3660700001)(66066001)(10400500002)(2501003)(7696004)(81166006)(9686002)(68736007)(50986999)(86362001)(54356999)(87936001)(122556002)(19580395003)(107886002)(8936002)(11100500001)(2906002)(19580405001)(77096005)(33656002)(4001150100001)(76176999)(101416001)(97736004)(189998001)(105586002)(74316002)(305945005)(2950100002)(6116002)(3846002)(102836003)(106116001)(76576001)(586003)(7736002)(106356001)(372894003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2859; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2016 19:52:26.7590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2859 Archived-At: Subject: Re: [OPSAWG] Draft cutt-off is Monday... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 19:52:37 -0000 Hi W, isn't "this", "coming" and "next" Monday the same? What you probably mean is "the next Monday but one".=20 If this sounds too British maybe "the Monday after next"? PLMK WYT. Cheers,=20 Mehmet=20 -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Thursday, October 20, 2016 9:43 PM To: opsawg@ietf.org Subject: Re: [OPSAWG] Draft cutt-off is Monday... On Thu, Oct 20, 2016 at 3:31 PM, Warren Kumari wrote: > Just a reminder that the last day you can submit a document before Seoul = is: > > 2016-10-31 (Monday): Internet Draft submission cut-off (for all > drafts, including -00) by UTC 23:59, upload using IETF ID Submission > Tool. > ... and someone poked me off-list and pointed out that the 31st is /next/ Monday, not /this/ Monday.... Let's just pretend that I knew that all along and that this was just a clever ploy to save people from missing the deadline, okay?! W > W > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Oct 20 14:24:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C129A1296EC for ; Thu, 20 Oct 2016 14:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 SgINM1Zr3A4c for ; Thu, 20 Oct 2016 14:24:40 -0700 (PDT) Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com [209.85.216.173]) (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 08EB91296EA for ; Thu, 20 Oct 2016 14:24:39 -0700 (PDT) Received: by mail-qt0-f173.google.com with SMTP id s49so69833630qta.0 for ; Thu, 20 Oct 2016 14:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R/bnOOT7d33+79P5fQIAvFEpbWOzJNx6naoHwtbZA2Y=; b=KmS7I3zap0LsqyLHA6iSgHFG5XeFz19D/da+u8h7OxMN95AytxbGpL3OvO+dIQgdg7 O6onVKPYgL8/I724o5VodfKvQLXJp3VSX4H2uWndoguvcjpYslHUc3k2A2jwmGFZwPHC vTJPAjCmB5c2xGOoCFKm97W14wTZgzoCyU74k2VgO4VbscEZkvUcaSIkBr6xcda+bpyo bxzFQBmKPiqQBU7IySf0hhQ+HP7SFc1I9ZBY8Mke4Fn3AuVtuu5D3RZoJlgBYzPgfvtg ZJSaVTxxcCB1YkWD5tRzeY0H99VKPk4p2dF/ObaVZjZ4MbLpAG73JCt3IatSfMhQVplU 5Stg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R/bnOOT7d33+79P5fQIAvFEpbWOzJNx6naoHwtbZA2Y=; b=JIAFU8U4tNYgVnpMnIxligdI7nSI17zCoeUmoHuozCiQiUOxiipUWR6awpV+KAEh3z Wz4UVOOYK3rbuNkVDW8Zz7HshSdXgW+5Ppa5oolCyHcunYInPiJxW6Pec1ujOSU88lZw YfDE0mJvYOmHf+Yh1S8dIn5Ka5Bcu14kkYxxjgIUko9bql3jfbKqU6uRxh9HZnqQnoHX Xrq3mGT9NgBGRzjjz+L0OtSmK79APycykCeiP9UNuTi2DEc6bNvNk1DyBQK2cAwwLuiw gRkco+JpZznQz/r7EPtkeBFl0JHHtKVdHFC3ACLaWEoIzGfKeHqMnPG6uzJtoImje6Qr yeQQ== X-Gm-Message-State: ABUngveeJ5/Z4CdHO0H3kCoWp/EHFiVSMMheRDhuIMT75zJIAiEwlogEMgLouKj+S4bc9auqlAdX7UHVt72v89sg X-Received: by 10.200.53.165 with SMTP id k34mr2575876qtb.119.1476998618904; Thu, 20 Oct 2016 14:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Thu, 20 Oct 2016 14:23:08 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Thu, 20 Oct 2016 17:23:08 -0400 Message-ID: To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Draft cutt-off is Monday... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:24:42 -0000 On Thu, Oct 20, 2016 at 3:52 PM, Ersue, Mehmet (Nokia - DE/Munich) wrote: > Hi W, > > isn't "this", "coming" and "next" Monday the same? Probably, maybe... This seems to be a standard Americanism, which causes much confusion. Equally stupid is "biweeky" -- depending on context this can be either once every 2 weeks, or twice a week. The Brits have the useful "fortnight" to disambiguate this... > > What you probably mean is "the next Monday but one". > If this sounds too British maybe "the Monday after next"? How about "The Monday which is 2016-10-31" ? :-) > > PLMK WYT. > > Cheers, > Mehmet > > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Thursday, October 20, 2016 9:43 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] Draft cutt-off is Monday... > > On Thu, Oct 20, 2016 at 3:31 PM, Warren Kumari wrote: >> Just a reminder that the last day you can submit a document before Seoul is: >> >> 2016-10-31 (Monday): Internet Draft submission cut-off (for all >> drafts, including -00) by UTC 23:59, upload using IETF ID Submission >> Tool. >> > > ... and someone poked me off-list and pointed out that the 31st is > /next/ Monday, not /this/ Monday.... > > Let's just pretend that I knew that all along and that this was just a > clever ploy to save people from missing the deadline, okay?! > > W > >> W >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Oct 20 14:30:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A286129443 for ; Thu, 20 Oct 2016 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 aPyxw6VJpzPZ for ; Thu, 20 Oct 2016 14:30:20 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50114.outbound.protection.outlook.com [40.107.5.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A56A12945E for ; Thu, 20 Oct 2016 14:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AcQNKQPKFdC+d/m4fxrv7myBnP2n9tJ9iUhSIVHXr4A=; b=GCfme1m4eyFCGCpMCnwJSNCVTcKePY4yysVbWMNkBjbNAXwdQg9pKxoFAL40a/8DdCHObcmGP984CmnIACWDOTWLcr5YwjoZ1N+U5j04iY4Mn4G4xTC/feZGe0CJiv8omjBC0kq3NdY7VGtS9gLDyf75pRWIZtcorEPmn/rKt4w= Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.4; Thu, 20 Oct 2016 21:30:17 +0000 Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0669.011; Thu, 20 Oct 2016 21:30:17 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Warren Kumari Thread-Topic: [OPSAWG] Draft cutt-off is Monday... Thread-Index: AQHSKwpVNEBIFAeDb0uM181niG/sBaCxv4RwgAAatQCAAADqkA== Date: Thu, 20 Oct 2016 21:30:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; x-originating-ip: [131.228.2.29] x-ms-office365-filtering-correlation-id: 354c9554-aa93-4eb8-70a0-08d3f930498a x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2857; 7:Dwzm58ZXAsNjump+DKM3u19nFn+x9tV1sGHvTFs5EJg4RJHWZSXgMvQZ8UBX/xnpJ7Fcbwlg8PKqvJrECp+c9xBVYcujZ1hAHMrb2sUoV3FHAV9nua9x+cVT/24QJXs5b4zmWuraIrmWhOnWG1LB/9e6enDlgIUAsfdXBHBOzUiiOmWMPR4kwyT7m8f1EjUWnItJASUSqQrfRaVyh4qeXqzLTUkETdGFQMS3dsskfxVmq8Npq/CCpgZYeHlNFome3dSHgvhfeQmb+7oVBgwND380+VP+2m33ocof4QqcXdFtddud5NOLP9Mc0b2NIXf7sBmrnl63/TWJHQ6R4I+IgDpZjOgolynVoMMs5QZ+Rcc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2857; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR0701MB2857; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2857; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(13464003)(53434003)(24454002)(377424004)(377454003)(19580405001)(8676002)(189998001)(7696004)(19580395003)(9686002)(101416001)(92566002)(122556002)(81166006)(3846002)(66066001)(77096005)(68736007)(81156014)(15975445007)(6116002)(2900100001)(102836003)(586003)(54356999)(106116001)(3280700002)(106356001)(97736004)(50986999)(76176999)(7736002)(74316002)(110136003)(5660300001)(2950100002)(7846002)(10400500002)(33656002)(93886004)(305945005)(11100500001)(2906002)(4326007)(6916009)(4001150100001)(86362001)(3660700001)(8936002)(76576001)(5002640100001)(87936001)(105586002)(372894003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2857; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2016 21:30:17.5196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2857 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Draft cutt-off is Monday... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:30:22 -0000 U291bmRzIGdvb2QgYnV0IGlzIG5vdCByZWFsbHkgcGVyZmVjdCA7KQ0KDQpJIHdvdWxkIHByZWZl cjogIk1vbmRheSwgT2N0b2JlciAzMSwgMjAxNiBVVEMgMjM6NTkiICA6LSkNCg0KRG8geW91IGFj dHVhbGx5IGtub3cgd2h5IHRoZSBsYXN0IG1pbnV0ZSBvZiB0aGUgZGF5IGlzIG1pc3Npbmc/DQoN CkNoZWVycywgDQpNZWhtZXQgDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFdhcnJlbiBLdW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0gDQpTZW50OiBUaHVyc2Rh eSwgT2N0b2JlciAyMCwgMjAxNiAxMToyMyBQTQ0KVG86IEVyc3VlLCBNZWhtZXQgKE5va2lhIC0g REUvTXVuaWNoKSA8bWVobWV0LmVyc3VlQG5va2lhLmNvbT4NCkNjOiBvcHNhd2dAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbT1BTQVdHXSBEcmFmdCBjdXR0LW9mZiBpcyBNb25kYXkuLi4NCg0KT24g VGh1LCBPY3QgMjAsIDIwMTYgYXQgMzo1MiBQTSwgRXJzdWUsIE1laG1ldCAoTm9raWEgLSBERS9N dW5pY2gpDQo8bWVobWV0LmVyc3VlQG5va2lhLmNvbT4gd3JvdGU6DQo+IEhpIFcsDQo+DQo+IGlz bid0ICJ0aGlzIiwgImNvbWluZyIgYW5kICJuZXh0IiBNb25kYXkgdGhlIHNhbWU/DQoNClByb2Jh Ymx5LCBtYXliZS4uLg0KDQpUaGlzIHNlZW1zIHRvIGJlIGEgc3RhbmRhcmQgQW1lcmljYW5pc20s IHdoaWNoIGNhdXNlcyBtdWNoIGNvbmZ1c2lvbi4NCkVxdWFsbHkgc3R1cGlkIGlzICJiaXdlZWt5 IiAtLSBkZXBlbmRpbmcgb24gY29udGV4dCB0aGlzIGNhbiBiZSBlaXRoZXINCm9uY2UgZXZlcnkg MiB3ZWVrcywgb3IgdHdpY2UgYSB3ZWVrLg0KVGhlIEJyaXRzIGhhdmUgdGhlIHVzZWZ1bCAiZm9y dG5pZ2h0IiB0byBkaXNhbWJpZ3VhdGUgdGhpcy4uLg0KDQo+DQo+IFdoYXQgeW91IHByb2JhYmx5 IG1lYW4gaXMgInRoZSBuZXh0IE1vbmRheSBidXQgb25lIi4NCj4gSWYgdGhpcyBzb3VuZHMgdG9v IEJyaXRpc2ggbWF5YmUgInRoZSBNb25kYXkgYWZ0ZXIgbmV4dCI/DQoNCkhvdyBhYm91dCAiVGhl IE1vbmRheSB3aGljaCBpcyAyMDE2LTEwLTMxIiA/IDotKQ0KDQoNCj4NCj4gUExNSyBXWVQuDQo+ DQo+IENoZWVycywNCj4gTWVobWV0DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgV2FycmVuIEt1bWFyaQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMCwgMjAxNiA5OjQz IFBNDQo+IFRvOiBvcHNhd2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPUFNBV0ddIERyYWZ0 IGN1dHQtb2ZmIGlzIE1vbmRheS4uLg0KPg0KPiBPbiBUaHUsIE9jdCAyMCwgMjAxNiBhdCAzOjMx IFBNLCBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5ldD4gd3JvdGU6DQo+PiBKdXN0IGEg cmVtaW5kZXIgdGhhdCB0aGUgbGFzdCBkYXkgeW91IGNhbiBzdWJtaXQgYSBkb2N1bWVudCBiZWZv cmUgU2VvdWwgaXM6DQo+Pg0KPj4gMjAxNi0xMC0zMSAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQg c3VibWlzc2lvbiBjdXQtb2ZmIChmb3IgYWxsDQo+PiBkcmFmdHMsIGluY2x1ZGluZyAtMDApIGJ5 IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgSUQgU3VibWlzc2lvbg0KPj4gVG9vbC4NCj4+ DQo+DQo+IC4uLiBhbmQgc29tZW9uZSBwb2tlZCBtZSBvZmYtbGlzdCBhbmQgcG9pbnRlZCBvdXQg dGhhdCB0aGUgMzFzdCBpcw0KPiAvbmV4dC8gTW9uZGF5LCBub3QgL3RoaXMvIE1vbmRheS4uLi4N Cj4NCj4gTGV0J3MganVzdCBwcmV0ZW5kIHRoYXQgSSBrbmV3IHRoYXQgYWxsIGFsb25nIGFuZCB0 aGF0IHRoaXMgd2FzIGp1c3QgYQ0KPiBjbGV2ZXIgcGxveSB0byBzYXZlIHBlb3BsZSBmcm9tIG1p c3NpbmcgdGhlIGRlYWRsaW5lLCBva2F5PyENCj4NCj4gVw0KPg0KPj4gVw0KPj4NCj4+IC0tDQo+ PiBJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2 aW91c2x5IGEgYmFkDQo+PiBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4+IFRoaXMgaXMgbGlr ZSBwdXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3Np bmcNCj4+IHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vh c2VscyBhbmQgdGhhdCBwYWlyDQo+PiBvZiBwYW50cy4NCj4+ICAgIC0tLW1hZg0KPg0KPg0KPg0K PiAtLQ0KPiBJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3 YXMgb2J2aW91c2x5IGEgYmFkDQo+IGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiBUaGlzIGlz IGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHBy ZXNzaW5nDQo+IHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQg d2Vhc2VscyBhbmQgdGhhdCBwYWlyDQo+IG9mIHBhbnRzLg0KPiAgICAtLS1tYWYNCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT1BTQVdHIG1h aWxpbmcgbGlzdA0KPiBPUFNBV0dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vcHNhd2cNCg0KDQoNCi0tIA0KSSBkb24ndCB0aGluayB0aGUgZXhlY3V0 aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBhIGJhZA0KaWRlYSBpbiB0aGUg Zmlyc3QgcGxhY2UuDQpUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlvdXIg cGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nDQpyZWdyZXQgYXQgaGF2aW5nIGNob3NlbiB0aG9z ZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpcg0Kb2YgcGFudHMuDQogICAt LS1tYWYNCg== From nobody Thu Oct 20 17:03:54 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F85127735 for ; Thu, 20 Oct 2016 17:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 xXGSp_x2LroC for ; Thu, 20 Oct 2016 17:03:50 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 472F9129471 for ; Thu, 20 Oct 2016 17:03:50 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f128so119498632qkb.1 for ; Thu, 20 Oct 2016 17:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tp85ZYbTPoVRZxsS8FzDV3msaPeAKWzj0XpV/NQy//A=; b=AB2COdhhi3FnBRZYaUmErIZTfsQUOgz4AYnjDTGefEmI0vYu8Qcea9i3v0zfxuk90S yEF0y+G9qPdx7fyPb+nhN8KyQbmDJekxhk4PTjP1aUSE/4f0awJHvt9XkzCvkzK4wsN5 B88d5ncTtZKIMZbUdJutFDwIF2dTSL81AUlgWzCbpii9e1wUp1bdQ9sT2zYUG+BwNwtB k8lgH3HZcJiZorxY8Egv9zqouOPC9FI/t2v5D01EOxORoUtZ12HBJSkh7l4YD8Ple27G S07ua/WAu87s6Qo40PsRO5STWxDf0bPKFsmX/pNwPmk9ea3+G3JnhxWqlB9UKM5IsQcd /cwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tp85ZYbTPoVRZxsS8FzDV3msaPeAKWzj0XpV/NQy//A=; b=kAaaPFL71WSMOGi5gfxO6rzZZ/YfEoO/pbRRAYzayJJ0zdPNX6wIX6qcaLk3Vw68a+ QrV8sAtgHFoH1BfVCNKAzZRE8j/ok/zChLdS1gICdM33ejW6hzLbasjS/E9JQzqmzIsM SKiu/1TwHJc9BKnsedIVbVqsNXmNTz39x0nDnOrEldXqQ7x+tUpg65rB8kpLuForsdcZ taIiLhaJOtRyqXIpL2LDALojJMp0CKx6gMwPiyYaw9mFxlhk9GPU/gAlPsKAMbNHkEyI jKt9I9rP3yWO/YMlfgymbPCzXOg459zzGAGkksfhb/c83Cmy6EE+zs38EgzFi2v5Ljzn c12Q== X-Gm-Message-State: ABUngvc9SPwy58fLLj7QikEg3Qi8Xddfq01+ea8/b6kR3rIGXCe48MU/femc/2+d393YogBE1fsirJa4+MK1PDUi X-Received: by 10.233.237.194 with SMTP id c185mr431338qkg.29.1477008229270; Thu, 20 Oct 2016 17:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.147.196 with HTTP; Thu, 20 Oct 2016 17:03:48 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Thu, 20 Oct 2016 20:03:48 -0400 Message-ID: To: "Ersue, Mehmet (Nokia - DE/Munich)" Content-Type: multipart/alternative; boundary=94eb2c097a10d62196053f54c6cc Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Draft cutt-off is Monday... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 00:03:53 -0000 --94eb2c097a10d62196053f54c6cc Content-Type: text/plain; charset=UTF-8 On Thursday, October 20, 2016, Ersue, Mehmet (Nokia - DE/Munich) < mehmet.ersue@nokia.com> wrote: > Sounds good but is not really perfect ;) > > I would prefer: "Monday, October 31, 2016 UTC 23:59" :-) > > Do you actually know why the last minute of the day is missing? > > Well, it *could* say 23:59:59.999999.... But there is some slack built in in case your clock is a bit slow -- if you click "Submit" when your clock says 23:59 (as long as it hasn't drifted by more than 60 seconds) you should still be able to submit[0]. Oh, and because 00:00 means something completely different :-) W [0]: yes, I did just make that up... > Cheers, > Mehmet > > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net ] > Sent: Thursday, October 20, 2016 11:23 PM > To: Ersue, Mehmet (Nokia - DE/Munich) > > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Draft cutt-off is Monday... > > On Thu, Oct 20, 2016 at 3:52 PM, Ersue, Mehmet (Nokia - DE/Munich) > > wrote: > > Hi W, > > > > isn't "this", "coming" and "next" Monday the same? > > Probably, maybe... > > This seems to be a standard Americanism, which causes much confusion. > Equally stupid is "biweeky" -- depending on context this can be either > once every 2 weeks, or twice a week. > The Brits have the useful "fortnight" to disambiguate this... > > > > > What you probably mean is "the next Monday but one". > > If this sounds too British maybe "the Monday after next"? > > How about "The Monday which is 2016-10-31" ? :-) > > > > > > PLMK WYT. > > > > Cheers, > > Mehmet > > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org ] On Behalf > Of Warren Kumari > > Sent: Thursday, October 20, 2016 9:43 PM > > To: opsawg@ietf.org > > Subject: Re: [OPSAWG] Draft cutt-off is Monday... > > > > On Thu, Oct 20, 2016 at 3:31 PM, Warren Kumari > wrote: > >> Just a reminder that the last day you can submit a document before > Seoul is: > >> > >> 2016-10-31 (Monday): Internet Draft submission cut-off (for all > >> drafts, including -00) by UTC 23:59, upload using IETF ID Submission > >> Tool. > >> > > > > ... and someone poked me off-list and pointed out that the 31st is > > /next/ Monday, not /this/ Monday.... > > > > Let's just pretend that I knew that all along and that this was just a > > clever ploy to save people from missing the deadline, okay?! > > > > W > > > >> W > >> > >> -- > >> I don't think the execution is relevant when it was obviously a bad > >> idea in the first place. > >> This is like putting rabid weasels in your pants, and later expressing > >> regret at having chosen those particular rabid weasels and that pair > >> of pants. > >> ---maf > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --94eb2c097a10d62196053f54c6cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, October 20, 2016, Ersue, Mehmet (Nokia - DE/Munich) &l= t;mehmet.ersue@nokia.com> = wrote:
Sounds good but is not really perf= ect ;)

I would prefer: "Monday, October 31, 2016 UTC 23:59"=C2=A0 :-)
Do you actually know why the last minute of the day is missing?


Well, it *could* say 23:59:59.999999..= .. But there is some slack built in in case your clock is a bit slow -- if = you click "Submit" when your clock says 23:59 (as long as it hasn= 't drifted by more than 60 seconds) you should still be able to submit[= 0].

Oh, and because 00:00 means something complete= ly different :-)
=C2=A0W

[0]: yes, I did just make that u= p...



=C2=A0
Cheers,
Mehmet


-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net]
Sent: Thursday, October 20, 2016 11:23 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ers= ue@nokia.com>
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] Draft cutt-off is Monday...

On Thu, Oct 20, 2016 at 3:52 PM, Ersue, Mehmet (Nokia - DE/Munich)
<mehmet.ersue@nokia.com> wrote:
> Hi W,
>
> isn't "this", "coming" and "next" Mo= nday the same?

Probably, maybe...

This seems to be a standard Americanism, which causes much confusion.
Equally stupid is "biweeky" -- depending on context this can be e= ither
once every 2 weeks, or twice a week.
The Brits have the useful "fortnight" to disambiguate this...

>
> What you probably mean is "the next Monday but one".
> If this sounds too British maybe "the Monday after next"?
How about "The Monday which is 2016-10-31" ? :-)


>
> PLMK WYT.
>
> Cheers,
> Mehmet
>
> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Warren Kumari
> Sent: Thursday, October 20, 2016 9:43 PM
> To: opsawg@ietf.org
> Subject: Re: [OPSAWG] Draft cutt-off is Monday...
>
> On Thu, Oct 20, 2016 at 3:31 PM, Warren Kumari <wa= rren@kumari.net> wrote:
>> Just a reminder that the last day you can submit a document before= Seoul is:
>>
>> 2016-10-31 (Monday): Internet Draft submission cut-off (for all >> drafts, including -00) by UTC 23:59, upload using IETF ID Submissi= on
>> Tool.
>>
>
> ... and someone poked me off-list and pointed out that the 31st is
> /next/ Monday, not /this/ Monday....
>
> Let's just pretend that I knew that all along and that this was ju= st a
> clever ploy to save people from missing the deadline, okay?!
>
> W
>
>> W
>>
>> --
>> I don't think the execution is relevant when it was obviously = a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expres= sing
>> regret at having chosen those particular rabid weasels and that pa= ir
>> of pants.
>>=C2=A0 =C2=A0 ---maf
>
>
>
> --
> I don't think the execution is relevant when it was obviously a ba= d
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing=
> regret at having chosen those particular rabid weasels and that pair > of pants.
>=C2=A0 =C2=A0 ---maf
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf


--
I don't think the execution is = relevant when it was obviously a bad idea in the first place.
This is li= ke putting rabid weasels in your pants, and later expressing regret at havi= ng chosen those particular rabid weasels and that pair of pants.
=C2=A0 = =C2=A0---maf
--94eb2c097a10d62196053f54c6cc-- From nobody Fri Oct 21 16:24:37 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF7129884; Fri, 21 Oct 2016 16:21:12 -0700 (PDT) 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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207274.28214.11382034123344484618.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:12 -0700 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] opsawg - Requested session has been scheduled for IETF 97 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:13 -0000 Dear Warren Kumari, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. opsawg Session 1 (2:00:00) Tuesday, Afternoon Session II 1550-1820 Room Name: Park Ballroom 2 size: 125 --------------------------------------------- Special Note: Combined with OPSAREA Request Information: --------------------------------------------------------- Working Group Name: Operations and Management Area Working Group Area Name: Operations and Management Area Session Requester: Warren Kumari Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: capport dane dprive Second Priority: dnsop v6ops Special Requests: PLEASE NOTE: Combined OpsAWG / OpsAREA. --------------------------------------------------------- From nobody Sun Oct 23 09:57:28 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 278A1127076; Sun, 23 Oct 2016 09:57:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> Date: Sun, 23 Oct 2016 09:57:25 -0700 Archived-At: Cc: opsawg-chairs@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg@ietf.org Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 16:57:25 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm surprised to see security is optional and an assertion that RFCs published in 2009 covers everything. Threats have evolved since then. In looking at RFC5415, Section 12.1, I see: Within CAPWAP, DTLS is used to secure the link between the WTP and AC. In addition to securing control messages, it's also a link in this chain of trust for establishing link layer keys. Consequently, much rests on the security of DTLS. In some CAPWAP deployment scenarios, there are two channels between the WTP and AC: the control channel, carrying CAPWAP Control messages, and the data channel, over which client data packets are tunneled between the AC and WTP. Typically, the control channel is secured by DTLS, while the data channel is not. The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into unprotected data and attempting to convert un-protected data into protected data. These concerns are addressed below. Wouldn't interception and tampering of that traffic pose a threat? How about gaining access to the control channel? While I don't think this is the right draft to make changes for RFC5415, I don't think it's adequate to say the control channel is optional for encryption. I could see how the data might be handled elsewhere. The description discusses this as talking to hundreds of thousands of access points, isn't that access a threat? This draft allows for additional encapsulation methods, we could require encryption for these new encapsulation methods. This should probably be a discuss, so I would appreciate some discussion on this to see if we have option here or if something will change in the referenced RFCs soon. Thank you. From nobody Sun Oct 23 10:24:15 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BD2120726; Sun, 23 Oct 2016 10:24:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147724345399.15955.5426739479458655058.idtracker@ietfa.amsl.com> Date: Sun, 23 Oct 2016 10:24:13 -0700 Archived-At: Cc: opsawg-chairs@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg@ietf.org Subject: [OPSAWG] Alexey Melnikov's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 17:24:14 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- +1 to Katleen's comment about optional data channel protection. In 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication Length == 4, but should it be >4 due to IPv4/IPv6 address at the end? From nobody Sun Oct 23 18:50:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C902012948B for ; Sun, 23 Oct 2016 18:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.331 X-Spam-Level: X-Spam-Status: No, score=-7.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431] 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 UQOGN6ZQbnRV for ; Sun, 23 Oct 2016 18:50:03 -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 00A9C1293DF for ; Sun, 23 Oct 2016 18:50:02 -0700 (PDT) Received: from mb-2.local (50-0-150-57.dsl.static.fusionbroadband.com [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u9O1noQf001469 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 24 Oct 2016 01:49:53 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host 50-0-150-57.dsl.static.fusionbroadband.com [50.0.150.57] claimed to be mb-2.local To: Warren Kumari References: <3FCB4CBE-6885-4708-AD21-4D4B2D1AA7EE@juniper.net> <058F02CC-5369-4A4D-96E9-B81FB6407973@juniper.net> <53f367e8-f011-a0e2-d027-8d21476a47dd@cisco.com> <2708A743-B900-41D2-9485-8EF901EBBE3B@juniper.net> From: joel jaeggli Message-ID: <8324dd0b-bb95-33a0-bc19-23c3091c0a72@bogus.com> Date: Sun, 23 Oct 2016 18:49:44 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FmRj6fOTVoekdfaXveHUqIraLBk8SqOaq" Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 01:50:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FmRj6fOTVoekdfaXveHUqIraLBk8SqOaq Content-Type: multipart/mixed; boundary="D9b0Jaok1OsSlKKQsfiWX556CHiULN26F"; protected-headers="v1" From: joel jaeggli To: Warren Kumari Cc: Eliot Lear , "opsawg@ietf.org" , Zhoutianran Message-ID: <8324dd0b-bb95-33a0-bc19-23c3091c0a72@bogus.com> Subject: Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04 References: <3FCB4CBE-6885-4708-AD21-4D4B2D1AA7EE@juniper.net> <058F02CC-5369-4A4D-96E9-B81FB6407973@juniper.net> <53f367e8-f011-a0e2-d027-8d21476a47dd@cisco.com> <2708A743-B900-41D2-9485-8EF901EBBE3B@juniper.net> In-Reply-To: --D9b0Jaok1OsSlKKQsfiWX556CHiULN26F Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks, I'll open up a line of disucssion with iana on this. regards joel On 10/20/16 12:30 PM, Warren Kumari wrote: > So, we chatted with our AD (CCed). > He feels that RFC 7120 is clear enough that he can just request early > allocation using the draft. >=20 > So, the chairs believe that there is sufficient consensus to request th= ese. >=20 > Thanks y'all, and a reminder that we still have OpsAWG agenda time -- > if you have a document **which has been discussed AND would benefit > from meeting time** please let us know. >=20 > Please include talk title & how much time you *need*. >=20 >=20 >=20 > If you want to mail the chairs alias directly instead, please include > "[SCHEDULE]" in the email subject - we get lots of mail before > meetings, and don't want any agenda requests to slip through the > cracks. >=20 > If we happen to have some extra time at the end of the meeting we > *may* allow presentations on new work, but in general we require that > the draft has been published and has had significant discussion on > list, so make sure you publish and get feedback early. >=20 > Thanks, > W >=20 > A few reminders / tips to help your presentation be effective: > ---------------------------------------------------------------------- > 1: Please rehearse your talk, make sure that it fits within the > allocated time slot, and that you have left some time for questions. > It is very impolite to the working group to run over your allocated > time, and we are likely to simply cut you off if you do. >=20 > 2: We require slides at least *3* days before the meeting; you can > revise them after this point if needed. Please include the version > number on the first page of the slide deck. Please send them to the WG > chairs alias - sending them to just one of us leads to confusion. >=20 > 3: Please send these in PDF format - we=E2=80=99ve had a number of inst= ances > where the convertor doesn=E2=80=99t handle certain fonts, etc and the > presenter becomes sad. >=20 > 4: Please include slide numbers on all slides - it=E2=80=99s much easie= r to > ask someone to go back to slide number 5 than =E2=80=9Cthe slide that w= as a > couple after the second diagram=E2=80=A6 no, not that one, the next one= =E2=80=A6 erm=E2=80=A6 > next?" >=20 > 5: Slides are a summary of what you want to say - please don=E2=80=99t = just > put everything on the slides and read them verbatim (we all know how > to read!) >=20 >=20 >=20 > On Sat, Oct 8, 2016 at 1:52 PM, Warren Kumari wrote= : >> Hi all, >> >> So, reviving this thread... >> >> I think that there is sufficient merit to request early allocations >> according to RFC7120 criteria. >> Please note that if we request early allocations, it is good for one >> year, renewable once. Assuming that the document progresses within >> that two year timeframe to become and RFC, the IANA will convert the >> early allocations into a permanent one -- if we don't, it will >> automatically expire and be marked as such in the registry (or, if the= >> WG decided that they want to abandon this work, we can request that >> they be released early). While the document is still in flux, the >> parts around the allocations should be stable. >> >> The majority of the requests are for allocations from large (or >> unlimited) code-spaces, and so it does not seem like there is >> scarcity. The exception is the DHCPv4 >> (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-para= meters.xhtml#options); >> the v4 option space is 8bit, and ~68 (or, around a quarter) are >> unassigned. The IPv6 option space is 16bit (65535 entries) and so >> close to unlimited. >> >> Because I am not at all familiar with the sensitivity / implications >> of the registrations in the various registries, I'm planning on asking= >> an expert reviewer from each of the below registries to please take an= >> early (before early allocation!) look at the document / relevant parts= >> of the document to confirm that we are doing the right thing, that >> there isn't a more appropriate sub-registry, etc. >> >> "SMI Security for PKIX Certificate Extension" Registry >> (http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-num= bers-1.3.6.1.5.5.7.1) >> - "id-pe-mud-uri"; Registration Procedure: Specification Required. >> The IANA considerations for this say: "The expert is expected to >> ensure that any new values are strongly related to the work that was >> done by the PKIX Working Group. That is, additional object >> identifiers are to be related to X.509 certificates, X.509 attribute >> certificates, X.509 certificate revocation lists (CRLs), or protocols >> associated with them. Object identifiers for other purposes should not= >> be assigned in this arc.", so it is unclear if this is the appropriate= >> place for this, but perhaps Russ can suggest a better location / >> system. >> >> Well Known URIs >> (http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml= ) >> - "mud"; Registration Procedure: Expert Review, mnot. >> >> MIME Media-type Registration >> (http://www.iana.org/assignments/media-types/media-types.xhtml) - >> "application/mud+json"; For allocations under the "Standards Tree >> requests made through IETF documents will be reviewed and approved by >> the IESG..." - this sounds like 'IESG Approval', but I'm planning on >> asking our AD, Ned and / or Murray. >> >> Well Known Universal Resource Name (URNs) >> (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) >> - "urn:mud" ; Registration Procedure: IETF Consensus. >> >> The final issue is the creation of a registry for "IANA Link Layer >> Discovery Protocol (LLDP) TLV subtype values" - this would create a >> registry under the IANA OUI, as a "vendor-specific TLV". It appears >> that there currently is no registry under the IANA vendor specific OUI= >> for LLDP, and this is creates an 8 bit registry. I'm *assuming* that >> we could have something like 1-253 are useable, and 254 can later be >> defined to be an "extension", but I'd like to get some additional >> feedback. https://tools.ietf.org/html/rfc7042 seems to be the closest >> that I could find..... >> >> The "IANA Considerations" section of the document also needs some >> polishing -- it would be nice if it pointed more definitely at the >> registry from which it is making requests, if the "{{secon}}" label >> expanded, and if the formatting of the URN bit were better. >> >> >> So, does anyone object to this plan? If so, please let us know by >> October 13th If not, the chairs will reach out to our AD / the >> Designated Experts as described above. >> >> On Tue, Aug 30, 2016 at 9:47 PM, Zhoutianran = wrote: >>> Hi Kent, >>> >>> Here are some words copied from RFC 7120. I think they can address yo= ur question. >>> >>> Request: >>> 6. IANA makes an allocation from the appropriate registry, marking >>> it as "Temporary", valid for a period of one year from the date >>> of allocation. The date of first allocation and the date of >>> expiry are also recorded in the registry and made visible to the >>> public. >>> >>> Follow up: >>> If the document progresses to the point at which IANA normally makes >>> code point allocations, it is the responsibility of the authors and >>> the WG chairs to remind IANA that there were early allocations and of= >>> the code point values allocated in the IANA Considerations section of= >>> the RFC-to-be. Allocation is then just a matter of removing the >>> "Temporary" tag from the allocation description. >>> >>> Expiry: >>> If an early allocation expires before the document progresses to the = point where >>> IANA normally makes allocations, the authors and WG chairs may repeat= >>> the process described in Section 3.1 to request renewal of the code >>> points. At most, one renewal request may be made; thus, authors >>> should choose carefully when the original request is to be made. >>> >>> If a follow-up request is not made, or the document fails to progress= >>> to an RFC, the assignment will remain visible in the registry, but >>> the temporary assignment will be shown to have expired as indicated >>> by the expiry date. The WG chairs are responsible for informing IANA >>> that the expired assignments are not required and that the code >>> points are to be marked "deprecated". >>> >>> A deprecated code point is not marked as allocated for use as >>> described in any document (that is, it is not allocated) and is not >>> available for allocation in a future document. The WG chairs may >>> inform IANA that a deprecated code point can be completely >>> de-allocated (i.e., made available for new allocations) at any time >>> after it has been deprecated. >>> >>> >>> Regards, >>> Tianran >>> >>>> -----Original Message----- >>>> From: Kent Watsen [mailto:kwatsen@juniper.net] >>>> Sent: Tuesday, August 30, 2016 9:56 PM >>>> To: Warren Kumari; Eliot Lear >>>> Cc: Zhoutianran; opsawg@ietf.org; opsawg-chairs@ietf.org >>>> Subject: Re: [OPSAWG] WG consensus call for the IANA early assignmen= t //RE: >>>> Adoption poll for draft-lear-ietf-netmod-mud-04 >>>> >>>> >>>> I didn=E2=80=99t know that, thanks for the clarification. I retract= my comment. >>>> >>>> But I wonder then, if they are temporary and reclaimed, will Elliot=E2= =80=99s goal >>>> be achieved? - or is it the case that the temporary assignments can= become >>>> permanent through the RFC process? - an optimistic long-term allocat= ion? >>>> >>>> Thanks, >>>> Kent >>>> >>>> >>>> On 8/29/16, 4:39 PM, "Warren Kumari" wrote: >>>> >>>> ... and just as a reminder to the WG, early allocations are expl= icitly >>>> temporary, and are marked in the registry as such. >>>> >>>> This isn't burning a critical resource forever - the allocations= >>>> spaces are not very rare, and they can be reclaimed if needed...= >>>> >>>> W >>>> >>>> On Thu, Aug 25, 2016 at 4:49 PM, Eliot Lear wro= te: >>>> > Yes, there is. And Early assignment is not an unusual request= =2E See >>>> RFC >>>> > 7120. >>>> > >>>> > >>>> > On 8/25/16 10:01 PM, Kent Watsen wrote: >>>> > >>>> > >>>> > >>>> > I don=E2=80=99t know. It seems that every draft could make si= milar claims, >>>> and yet >>>> > having IANA make early assignments all the time wouldn=E2=80=99= t be good. I >>>> don=E2=80=99t >>>> > see why this draft should get a pass. Is there any documenta= tion >>>> detailing >>>> > criteria for early assignments? >>>> > >>>> > >>>> > >>>> > Kent >>>> > >>>> > >>>> > >>>> > From: Eliot Lear >>>> > Date: Thursday, August 25, 2016 at 2:36 PM >>>> > To: Kent Watsen , Zhoutianran >>>> , >>>> > Warren Kumari >>>> > Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.o= rg" >>>> > >>>> > Subject: Re: [OPSAWG] WG consensus call for the IANA early ass= ignment >>>> //RE: >>>> > Adoption poll for draft-lear-ietf-netmod-mud-04 >>>> > >>>> > >>>> > >>>> > Hi Kent, >>>> > >>>> > We're doing some open source and would like to make it easier = for those >>>> who >>>> > are coding to have to do a little less REcoding. I doubt very= much >>>> we're >>>> > going to see much change in the content or format the URL or t= he option. >>>> > That's what most of the requests are for. Where I expect we w= ill see >>>> change >>>> > is in the content of the YANG file. There we have the option = to bump >>>> the >>>> > version # in the URL if we think there has been any real uptak= e of >>>> earlier >>>> > versions. >>>> > >>>> > Fair enough? >>>> > >>>> > Eliot >>>> > >>>> > >>>> > >>>> > On 8/25/16 7:27 PM, Kent Watsen wrote: >>>> > >>>> > >>>> > >>>> > Why is an early assignment being requested? I think it unusu= al, >>>> especially >>>> > for a draft that was just adopted, and no justification is giv= en for >>>> why >>>> > it=E2=80=99s needed other than =E2=80=9Cto assist with interop= erable development=E2=80=9D... >>>> > >>>> > >>>> > >>>> > Kent >>>> > >>>> > >>>> > >>>> > From: OPSAWG on behalf of Zhoutianra= n >>>> > >>>> > Date: Tuesday, August 23, 2016 at 5:46 AM >>>> > To: Eliot Lear , Warren Kumari >>>> > Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.o= rg" >>>> > >>>> > Subject: [OPSAWG] WG consensus call for the IANA early assignm= ent //RE: >>>> > Adoption poll for draft-lear-ietf-netmod-mud-04 >>>> > >>>> > >>>> > >>>> > Hi All, >>>> > >>>> > >>>> > >>>> > Since the authors of the draft-ietf-opsawg-mud-00 asked for th= e early >>>> > assignment for various registries from IANA, I would like to a= sk the >>>> WG >>>> > consensus. >>>> > >>>> > >>>> > >>>> > There will be 1 week since today. You can express your support= or >>>> objection. >>>> > >>>> > >>>> > >>>> > If there is no objection, I would like to request from the WG.= >>>> > >>>> > >>>> > >>>> > The following is a list of IANA considerations copied from the= draft. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Best, >>>> > >>>> > Tianran >>>> > >>>> > >>>> > >>>> > ------------------------------------- >>>> > >>>> > >>>> > >>>> > 15. IANA Considerations >>>> > >>>> > >>>> > >>>> > 15.1. DHCPv4 and DHCPv6 Options >>>> > >>>> > >>>> > >>>> > IANA is requested to allocated the DHCPv4 and v6 options as= specified >>>> > >>>> > in Section 9. >>>> > >>>> > >>>> > >>>> > 15.2. PKIX Extensions >>>> > >>>> > >>>> > >>>> > The IANA is requested to assign a value for id-pe-mud-uri i= n the >>>> "SMI >>>> > >>>> > Security for PKIX Certificate Extension" Registry. Its use= is >>>> > >>>> > specified in Section 10. >>>> > >>>> > >>>> > >>>> > 15.3. Well Known URI Suffix >>>> > >>>> > >>>> > >>>> > The IANA is requested to register the URL suffix of "mud" a= s follows: >>>> > >>>> > >>>> > >>>> > o URI Suffix: "mud" o Specification documents: this documen= t o >>>> > >>>> > Related information: n/a >>>> > >>>> > >>>> > >>>> > 15.4. MIME Media-type Registration for MUD files >>>> > >>>> > >>>> > >>>> > The following media-type is defined for transfer of MUD fil= e: >>>> > >>>> > >>>> > >>>> > o Type name: application >>>> > >>>> > o Subtype name: mud+json >>>> > >>>> > o Required parameters: n/a >>>> > >>>> > o Optional parameters: n/a >>>> > >>>> > o Encoding considerations: 8bit; application/mud+json value= s >>>> > >>>> > are represented as a JSON object; UTF-8 encoding SHOULD b= e >>>> > >>>> > employed. >>>> > >>>> > o Security considerations: See {{secon}} of this document. >>>> > >>>> > o Interoperability considerations: n/a >>>> > >>>> > o Published specification: this document >>>> > >>>> > o Applications that use this media type: MUD controllers as= >>>> > >>>> > specified by this document. >>>> > >>>> > o Fragment identifier considerations: n/a >>>> > >>>> > o Additional information: >>>> > >>>> > >>>> > >>>> > Magic number(s): n/a >>>> > >>>> > File extension(s): n/a >>>> > >>>> > Macintosh file type code(s): n/a >>>> > >>>> > >>>> > >>>> > o Person & email address to contact for further information= : >>>> > >>>> > Eliot Lear , Ralph Droms >>>> > >>>> > o Intended usage: COMMON >>>> > >>>> > o Restrictions on usage: none >>>> > >>>> > >>>> > >>>> > o Author: Eliot Lear , Ralph Droms >>>> >>>> > >>>> > o Change controller: IESG >>>> > >>>> > o Provisional registration? (standards tree only): No. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > 15.5. LLDP IANA TLV Subtype Registry >>>> > >>>> > >>>> > >>>> > IANA is requested to create a new registry for IANA Link La= yer >>>> > >>>> > Discovery Protocol (LLDP) TLV subtype values. The recommen= ded >>>> policy >>>> > >>>> > for this registry is Expert Review. The maximum number of = entries >>>> in >>>> > >>>> > the registry is 256. >>>> > >>>> > >>>> > >>>> > IANA is required to populate the initial registry with the = value: >>>> > >>>> > >>>> > >>>> > LLDP subtype value =3D 1 >>>> > >>>> > >>>> > >>>> > Description =3D the Manufacturer Usage Description (MUD) Un= iform >>>> > >>>> > Resource Locator (URL) >>>> > >>>> > >>>> > >>>> > Reference =3D < this document > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > From: Eliot Lear [mailto:lear@cisco.com] >>>> > Sent: Monday, August 22, 2016 7:04 PM >>>> > To: Warren Kumari >>>> > Cc: Zhoutianran; opsawg@ietf.org; opsawg-chairs@ietf.org >>>> > Subject: Re: Adoption poll for draft-lear-ietf-netmod-mud-04 >>>> > >>>> > >>>> > >>>> > Hi Warren, Tianran, and all, >>>> > >>>> > >>>> > >>>> > On 8/17/16 4:17 PM, Warren Kumari wrote: >>>> > >>>> > >>>> > >>>> > >>>> > Second, and hopefully not that more of a controversy, I would = like >>>> to >>>> > request early IANA assignments to assist with interoperable >>>> > development. These would be listed in the IANA considerations= section >>>> > of the current draft. If we need a WG draft to make this happ= en, that's >>>> > fine with me, but we should do a quick rev after the assignmen= ts. >>>> > >>>> > >>>> > >>>> > I believe that this *can* be accomplished without it being a W= G doc, >>>> but it >>>> > is better / cleaner / easier if we make it a WG doc and then a= sk for >>>> early >>>> > assistant. We are fine with lots of revisions / it being submi= tted >>>> and then >>>> > quickly revised. >>>> > >>>> > >>>> > Just following up on this point: we'd like to request early as= signment >>>> from >>>> > IANA for the various registries. Does that go through the cha= irs or >>>> the >>>> > authors at this point? >>>> > >>>> > Thanks, >>>> > >>>> > Eliot >>>> > >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> I don't think the execution is relevant when it was obviously a = bad >>>> idea in the first place. >>>> This is like putting rabid weasels in your pants, and later expr= essing >>>> regret at having chosen those particular rabid weasels and that = pair >>>> of pants. >>>> ---maf >>>> >>> >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing= >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >=20 >=20 >=20 --D9b0Jaok1OsSlKKQsfiWX556CHiULN26F-- --FmRj6fOTVoekdfaXveHUqIraLBk8SqOaq 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 iEYEARECAAYFAlgNaLkACgkQ8AA1q7Z/VrKCtgCfZLxz45RnW/zI2l+sIrphPASs ijgAnRaFwTm9DpfSXWVSE0aPyxBdA6GM =cD8p -----END PGP SIGNATURE----- --FmRj6fOTVoekdfaXveHUqIraLBk8SqOaq-- From nobody Mon Oct 24 06:34:14 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6258D12947B; Mon, 24 Oct 2016 06:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147731605236.15405.5667810699473009609.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 06:34:12 -0700 Archived-At: Cc: opsawg-chairs@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg@ietf.org Subject: [OPSAWG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-opsawg-capwap-alt-tunnel-08=3A_=28with_COMMENT=29?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 13:34:12 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nit: s/This specification defines the values from zero (0) to five (5)/This specification defines the values from zero (0) to six (6)/ From nobody Mon Oct 24 08:03:47 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 314891294BE; Mon, 24 Oct 2016 08:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147732142319.15471.2700261643744383617.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 08:03:43 -0700 Archived-At: Cc: opsawg-chairs@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg@ietf.org Subject: [OPSAWG] Joel Jaeggli's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-08: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 15:03:43 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- sorry we came to some comclusions on the basis of late review that make this hard to advance without correcting. this will be withdrawn from this review cycle. From nobody Tue Oct 25 05:42:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB86129669; Tue, 25 Oct 2016 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 bYpE1S-t7NPf; Tue, 25 Oct 2016 05:41:55 -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 14ECF12954B; Tue, 25 Oct 2016 05:41:54 -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 CYZ42579; Tue, 25 Oct 2016 12:41:51 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 25 Oct 2016 13:41:50 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 25 Oct 2016 20:41:46 +0800 From: Duzongpeng To: Kathleen Moriarty , The IESG Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) Thread-Index: AQHSLU6UGsyDr2C0GkembPtV1MR43KC5ErQg Date: Tue, 25 Oct 2016 12:41:45 +0000 Message-ID: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> In-Reply-To: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] 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.580F5310.00BE, 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: bbd6cc0e6328defdceefb68eef9285f1 Archived-At: Cc: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 12:41:59 -0000 Hello, I would like to give some suggestions as below. Some operators deploys their WiFi networks with the data channel unsecured= , and even for the wireless part, there are some unsecured deployment examp= les. It is not a good choice; however, it is simpler. Of course, some secure ensured methods should also be provided. For the wireless part, IEEE has provided several secure mechanism; For the wireline part, IPsec can be deployed to protect the security. Would it be ok for the draft to suggest that IPsec should be deployed if t= he tunnel type itself is unsecured. Best Regards Zongpeng Du -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Kathleen Moriart= y Sent: Monday, October 24, 2016 12:57 AM To: The IESG Cc: opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; o= psawg@ietf.org Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-cap= wap-alt-tunnel-08: (with COMMENT) Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm surprised to see security is optional and an assertion that RFCs publis= hed in 2009 covers everything. Threats have evolved since then.=20 In looking at RFC5415, Section 12.1, I see: Within CAPWAP, DTLS is used to secure the link between the WTP and AC. In addition to securing control messages, it's also a link in this chain of trust for establishing link layer keys. Consequently, much rests on the security of DTLS. =20 In some CAPWAP deployment scenarios, there are two channels between the WTP and AC: the control channel, carrying CAPWAP Control messages, and the data channel, over which client data packets are tunneled between the AC and WTP. Typically, the control channel is secured by DTLS, while the data channel is not. The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into unprotected data and attempting to convert un-protected data into protected data. These concerns are addressed below. Wouldn't interception and tampering of that traffic pose a threat? How abo= ut gaining access to the control channel? While I don't think this is the right draft to make changes for RFC5415, I = don't think it's adequate to say the control channel is optional for encryp= tion. I could see how the data might be handled elsewhere. The descriptio= n discusses this as talking to hundreds of thousands of access points, isn'= t that access a threat? =20 This draft allows for additional encapsulation methods, we could require en= cryption for these new encapsulation methods. This should probably be a discuss, so I would appreciate some discussion on= this to see if we have option here or if something will change in the refe= renced RFCs soon. Thank you. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Oct 25 06:25:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D458F129496 for ; Tue, 25 Oct 2016 06:25:03 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 nw0J7rJRjScb for ; Tue, 25 Oct 2016 06:25:01 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 D53A5129436 for ; Tue, 25 Oct 2016 06:25:00 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id i34so19843710qkh.6 for ; Tue, 25 Oct 2016 06:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ExCnnQjxa1twlgOe/7d/PKsy7DktZHa2+fEjgBkU96k=; b=Sk+OYgMYLvi8Z6YCH6uhYwijQVUrSECiqamdPcvuAKpnYvVEVu0REvQKCBEeYIMKmr JAmH86WTmnRHwjGyvkdy0N/fss/jM7h8wxDZegwIXmmy5OeUmVZrOaUwfYJW8XGMCWoY DZ1bQ6vD57VFhlJ6zBpcmtWsqL4sgPC7N5FwVaX9ioLJklguX8Jk8MHUPOgc2WHo1tOK X9HFGb6L6hQLY9fAwj1X2FuptMlRjCLZAh2z0m/bQ+im4jaX5KCIBZ2bX0p/xD+LT/5Q BI0xMzkx28Jhnv/RApSER39x1KpkXxV/voGElt77cyuku7nDTmTL9YoppZWv+u2yd2Ha xAsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ExCnnQjxa1twlgOe/7d/PKsy7DktZHa2+fEjgBkU96k=; b=asyxUO4mfwVcivz8sczQOYi5ikmjl4/W+GP6z+dnNWcWQ6x49j+1PrQfAHryOcOmaf y98CD2U5bZZTCnrvZRUCwxHBjqHPLDAJ1Rvm9gZFKPDm/GszjC9kH69hn9xY7jIfrrd3 N1Ah+7WI8ksGH/5N3yyywcEom3+jCtCn85oRQozsINHme0GZ6CZipEpEUKbse0ugXu0F nBJnWcbM30e2OTel+QWi1d+EPthca8KUA0ZXqfhvN53OTHy+1yG/YjAFcjxFRJLRGlUX SeHSs/08JZ1rzj4W7uJckDZ0vU9nw75WahUUIsB0nUJ0516uDcsB36HGbR27iI1zjRtm p3JQ== X-Gm-Message-State: ABUngvdUA66ulDR7Zwys97Xi1orucbhMzPumqDzxkE1kcLfNhE27Wyj3Sgyk6VJ3R6M8daSdp+UrEMEiQoIkce9q X-Received: by 10.55.70.77 with SMTP id t74mr21471583qka.78.1477401899802; Tue, 25 Oct 2016 06:24:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.147.100 with HTTP; Tue, 25 Oct 2016 06:24:29 -0700 (PDT) In-Reply-To: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Tue, 25 Oct 2016 15:24:29 +0200 Message-ID: To: Duzongpeng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Kathleen Moriarty , "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 13:25:04 -0000 On Tue, Oct 25, 2016 at 2:41 PM, Duzongpeng wrote: > Hello, > > I would like to give some suggestions as below. > > Some operators deploys their WiFi networks with the data channel = unsecured, and even for the wireless part, there are some unsecured deploym= ent examples. > It is not a good choice; however, it is simpler. > > Of course, some secure ensured methods should also be provided. > For the wireless part, IEEE has provided several secure mechanism= ; > For the wireline part, IPsec can be deployed to protect the secur= ity. > > Would it be ok for the draft to suggest that IPsec should be depl= oyed if the tunnel type itself is unsecured. Personally I don't think that this is a useful suggestion -- *who* exactly would you be advising to do this? Users? They don't (and shouldn't have to) read the RFCs. Suggesting something which we know will not be used seems disingenuous - acknowledging that this is a real issue seems better than suggesting something which we know won't be done to users who we know are not reachable. W > > > Best Regards > Zongpeng Du > > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Kathleen Moria= rty > Sent: Monday, October 24, 2016 12:57 AM > To: The IESG > Cc: opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org;= opsawg@ietf.org > Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-c= apwap-alt-tunnel-08: (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm surprised to see security is optional and an assertion that RFCs publ= ished in 2009 covers everything. Threats have evolved since then. > In looking at RFC5415, Section 12.1, I see: > > Within CAPWAP, DTLS is used to secure the link between the WTP and > AC. In addition to securing control messages, it's also a link in > this chain of trust for establishing link layer keys. Consequently, > much rests on the security of DTLS. > > In some CAPWAP deployment scenarios, there are two channels between > the WTP and AC: the control channel, carrying CAPWAP Control > messages, and the data channel, over which client data packets are > tunneled between the AC and WTP. Typically, the control channel is > secured by DTLS, while the data channel is not. > > The use of parallel protected and unprotected channels deserves > special consideration, but does not create a threat. There are two > potential concerns: attempting to convert protected data into > unprotected data and attempting to convert un-protected data into > protected data. These concerns are addressed below. > > Wouldn't interception and tampering of that traffic pose a threat? How a= bout gaining access to the control channel? > > While I don't think this is the right draft to make changes for RFC5415, = I don't think it's adequate to say the control channel is optional for encr= yption. I could see how the data might be handled elsewhere. The descript= ion discusses this as talking to hundreds of thousands of access points, is= n't that access a threat? > > This draft allows for additional encapsulation methods, we could require = encryption for these new encapsulation methods. > > This should probably be a discuss, so I would appreciate some discussion = on this to see if we have option here or if something will change in the re= ferenced RFCs soon. > > Thank you. > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Oct 25 06:47:41 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010261294A2; Tue, 25 Oct 2016 06:47:34 -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, HTML_MESSAGE=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 cbsh_XYOVsoO; Tue, 25 Oct 2016 06:47:26 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 B512C1294E4; Tue, 25 Oct 2016 06:47:26 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id u14so13306596uau.7; Tue, 25 Oct 2016 06:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dxuX/aF6lLfBdbCjLD156y+9MlRrVXzUK+o41x2l7fs=; b=lJ5tt1uI8ZRUubXqAY3rpGKaQWw8Vwxhh9Z9ONGL2OQX1outf8Pz70SWO3mJzKqkaL ZIDhDa8AK/bsPfO/Y4w7C3ssA2dq3yCalULr4nOLZvZ/6lyE8dtZsypnotRyoKgbKU/K uVwDGqUU1kAYBmpaeJJVQKQUvqUhlpUqMWCR8to0NHxQWf+X29wFVZSm8jMaab8ww3mH wCCBMCKTMFflOLKm7X/wDOxlxPQMe2QrV14smfNrTAmqR+K6AteT28GbgL29AktnFwkN DL62EcndHhI3OyNK/vZsPUBYxmBT1JLCdXBcO36VP9lbcSH5ptDyAHctrlu0At+CEyNV 8d1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dxuX/aF6lLfBdbCjLD156y+9MlRrVXzUK+o41x2l7fs=; b=eDwElfxCr2dgUnTgA61hfQiwK2cPes0k40c7eLd4KTlW8ntgPlRty2WHY6IkPpLsgZ q5QoDmV5R2KzS2kgET/gIPh+X0JAHuU1G2dsw/KJaJNtB1pbIXGBw5l3q8t7VzBYXRKt ABJQ6e0Eyd0CC+S76IT8kceWXWyWxYDBTNQH2a0JRyqGbnm4E7puUPVasw4x/p6fZGCn Bx6X/dZnV4TDwagXSDrIRkA0NBpEnShKxM1VO9WweI1sJNSUUHh2SMlAUJBm6fnhDxds iOhJ5p+U8KEtC0CZXQL/ozgHdotF1SmOXi+RKbBmgKYxJF6xVSrK4IOdjPze1hbfSNxy kEPw== X-Gm-Message-State: ABUngve3YOK9OEdOcpUfGquSsXVM/ppHM/ph1wtvfveBZMC1ollGfZ/xcTWaqbR9NJ+KOkWKd1IQAMmxRgg6ag== X-Received: by 10.176.4.86 with SMTP id 80mr6903648uav.20.1477403245817; Tue, 25 Oct 2016 06:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.143 with HTTP; Tue, 25 Oct 2016 06:47:25 -0700 (PDT) In-Reply-To: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 25 Oct 2016 09:47:25 -0400 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=94eb2c0cca36a8326e053fb0bfef Archived-At: Cc: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 13:47:34 -0000 --94eb2c0cca36a8326e053fb0bfef Content-Type: text/plain; charset=UTF-8 On Tue, Oct 25, 2016 at 9:24 AM, Warren Kumari wrote: > On Tue, Oct 25, 2016 at 2:41 PM, Duzongpeng wrote: > > Hello, > > > > I would like to give some suggestions as below. > > > > Some operators deploys their WiFi networks with the data channel > unsecured, and even for the wireless part, there are some unsecured > deployment examples. > > It is not a good choice; however, it is simpler. > > > > Of course, some secure ensured methods should also be provided. > > For the wireless part, IEEE has provided several secure > mechanism; > > For the wireline part, IPsec can be deployed to protect the > security. > > > > Would it be ok for the draft to suggest that IPsec should be > deployed if the tunnel type itself is unsecured. > > > Personally I don't think that this is a useful suggestion -- *who* > exactly would you be advising to do this? Users? They don't (and > shouldn't have to) read the RFCs. Suggesting something which we know > will not be used seems disingenuous - acknowledging that this is a > real issue seems better than suggesting something which we know won't > be done to users who we know are not reachable. > W > For this draft and the protocol, we are more worried about MTI, not MTU so that the option is there and traffic can be encrypted. Then encouraging the use of encryption is possible. Kathleen > > > > > > > > Best Regards > > Zongpeng Du > > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Kathleen > Moriarty > > Sent: Monday, October 24, 2016 12:57 AM > > To: The IESG > > Cc: opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; > opsawg@ietf.org > > Subject: [OPSAWG] Kathleen Moriarty's No Objection on > draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection > > > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I'm surprised to see security is optional and an assertion that RFCs > published in 2009 covers everything. Threats have evolved since then. > > In looking at RFC5415, Section 12.1, I see: > > > > Within CAPWAP, DTLS is used to secure the link between the WTP and > > AC. In addition to securing control messages, it's also a link in > > this chain of trust for establishing link layer keys. Consequently, > > much rests on the security of DTLS. > > > > In some CAPWAP deployment scenarios, there are two channels between > > the WTP and AC: the control channel, carrying CAPWAP Control > > messages, and the data channel, over which client data packets are > > tunneled between the AC and WTP. Typically, the control channel is > > secured by DTLS, while the data channel is not. > > > > The use of parallel protected and unprotected channels deserves > > special consideration, but does not create a threat. There are two > > potential concerns: attempting to convert protected data into > > unprotected data and attempting to convert un-protected data into > > protected data. These concerns are addressed below. > > > > Wouldn't interception and tampering of that traffic pose a threat? How > about gaining access to the control channel? > > > > While I don't think this is the right draft to make changes for RFC5415, > I don't think it's adequate to say the control channel is optional for > encryption. I could see how the data might be handled elsewhere. The > description discusses this as talking to hundreds of thousands of access > points, isn't that access a threat? > > > > This draft allows for additional encapsulation methods, we could require > encryption for these new encapsulation methods. > > > > This should probably be a discuss, so I would appreciate some discussion > on this to see if we have option here or if something will change in the > referenced RFCs soon. > > > > Thank you. > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > -- Best regards, Kathleen --94eb2c0cca36a8326e053fb0bfef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 25, 2016 at 9:24 AM, Warren Kumari <warren@kumari.net&= gt; wrote:
On Tue= , Oct 25, 2016 at 2:41 PM, Duzongpeng <duzongpeng@huawei.com> wrote:
> Hello,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I would like to give some suggestions= as below.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Some operators deploys their WiFi net= works with the data channel unsecured, and even for the wireless part, ther= e are some unsecured deployment examples.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is not a good choice; however, it = is simpler.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Of course, some secure ensured method= s should also be provided.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For the wireless part, IEEE has provi= ded several secure mechanism;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For the wireline part, IPsec can be d= eployed to protect the security.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would it be ok for the draft to sugge= st that IPsec should be deployed if the tunnel type itself is unsecured.

Personally I don't think that this is a useful suggestion -- *wh= o*
exactly would you be advising to do this? Users? They don't (and
shouldn't have to) read the RFCs. Suggesting something which we know will not be used seems disingenuous - acknowledging that this is a
real issue seems better than suggesting something which we know won't be done to users who we know are not reachable.
W

For this draft and the protocol, we a= re more worried about MTI, not MTU so that the option is there and traffic = can be encrypted.=C2=A0 Then encouraging the use of encryption is possible.=

Kathleen=C2=A0


>
>
> Best Regards
> Zongpeng Du
>
> -----Original Message-----
> From: OPSAWG [mailto:opsawg= -bounces@ietf.org] On Behalf Of Kathleen Moriarty
> Sent: Monday, October 24, 2016 12:57 AM
> To: The IESG
> Cc: opsawg-chairs@ietf.org; draft-i= etf-opsawg-capwap-alt-tunnel@ietf.org; opsawg@ietf.org
> Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-o= psawg-capwap-alt-tunnel-08: (with COMMENT)
>
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection
>
> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this int= roductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.o= rg/doc/draft-ietf-opsawg-capwap-alt-tunnel/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I'm surprised to see security is optional and an assertion that RF= Cs published in 2009 covers everything.=C2=A0 Threats have evolved since th= en.
> In looking at RFC5415, Section 12.1, I see:
>
>=C2=A0 =C2=A0 Within CAPWAP, DTLS is used to secure the link between th= e WTP and
>=C2=A0 =C2=A0 AC.=C2=A0 In addition to securing control messages, it= 9;s also a link in
>=C2=A0 =C2=A0 this chain of trust for establishing link layer keys.=C2= =A0 Consequently,
>=C2=A0 =C2=A0 much rests on the security of DTLS.
>
>=C2=A0 =C2=A0 =C2=A0In some CAPWAP deployment scenarios, there are two = channels between
>=C2=A0 =C2=A0 the WTP and AC: the control channel, carrying CAPWAP Cont= rol
>=C2=A0 =C2=A0 messages, and the data channel, over which client data pa= ckets are
>=C2=A0 =C2=A0 tunneled between the AC and WTP.=C2=A0 Typically, the con= trol channel is
>=C2=A0 =C2=A0 secured by DTLS, while the data channel is not.
>
>=C2=A0 =C2=A0 The use of parallel protected and unprotected channels de= serves
>=C2=A0 =C2=A0 special consideration, but does not create a threat.=C2= =A0 There are two
>=C2=A0 =C2=A0 potential concerns: attempting to convert protected data = into
>=C2=A0 =C2=A0 unprotected data and attempting to convert un-protected d= ata into
>=C2=A0 =C2=A0 protected data.=C2=A0 These concerns are addressed below.=
>
> Wouldn't interception and tampering of that traffic pose a threat?= =C2=A0 How about gaining access to the control channel?
>
> While I don't think this is the right draft to make changes for RF= C5415, I don't think it's adequate to say the control channel is op= tional for encryption.=C2=A0 I could see how the data might be handled else= where.=C2=A0 The description discusses this as talking to hundreds of thous= ands of access points, isn't that access a threat?
>
> This draft allows for additional encapsulation methods, we could requi= re encryption for these new encapsulation methods.
>
> This should probably be a discuss, so I would appreciate some discussi= on on this to see if we have option here or if something will change in the= referenced RFCs soon.
>
> Thank you.
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf



--

Best regards,
Kathleen
--94eb2c0cca36a8326e053fb0bfef-- From nobody Tue Oct 25 11:31:45 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2D129951 for ; Tue, 25 Oct 2016 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.331 X-Spam-Level: X-Spam-Status: No, score=-7.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431] 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 Z-vy3VEtrwek for ; Tue, 25 Oct 2016 11:31:30 -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 1808312995F for ; Tue, 25 Oct 2016 11:31:29 -0700 (PDT) Received: from mbp-4.local ([IPv6:2620:11a:c081:20:5ce4:5f21:9538:3a87]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u9PIVLVI007456 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 25 Oct 2016 18:31:22 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:5ce4:5f21:9538:3a87] claimed to be mbp-4.local To: Warren Kumari , Duzongpeng References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: <407c5f0d-bebe-b492-b77e-fc1871648906@bogus.com> Date: Tue, 25 Oct 2016 11:31:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wKTUQuQLq73EA5cVpT56w5StoFLMMwcUK" Archived-At: Cc: Kathleen Moriarty , "opsawg-chairs@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg@ietf.org" , The IESG Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 18:31:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wKTUQuQLq73EA5cVpT56w5StoFLMMwcUK Content-Type: multipart/mixed; boundary="TBLMucpNf142Rd3E3TC6l1KQ7OlbfUbie"; protected-headers="v1" From: joel jaeggli To: Warren Kumari , Duzongpeng Cc: Kathleen Moriarty , "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Message-ID: <407c5f0d-bebe-b492-b77e-fc1871648906@bogus.com> Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> In-Reply-To: --TBLMucpNf142Rd3E3TC6l1KQ7OlbfUbie Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 10/25/16 6:24 AM, Warren Kumari wrote: > On Tue, Oct 25, 2016 at 2:41 PM, Duzongpeng wro= te: >> Hello, >> >> I would like to give some suggestions as below. >> >> Some operators deploys their WiFi networks with the data chann= el unsecured, and even for the wireless part, there are some unsecured de= ployment examples. >> It is not a good choice; however, it is simpler. >> >> Of course, some secure ensured methods should also be provided= =2E >> For the wireless part, IEEE has provided several secure mechan= ism; >> For the wireline part, IPsec can be deployed to protect the se= curity. >> >> Would it be ok for the draft to suggest that IPsec should be d= eployed if the tunnel type itself is unsecured. > > Personally I don't think that this is a useful suggestion -- *who* > exactly would you be advising to do this? Users? They don't (and > shouldn't have to) read the RFCs. Suggesting something which we know > will not be used seems disingenuous - acknowledging that this is a > real issue seems better than suggesting something which we know won't > be done to users who we know are not reachable. > W indeed, ipsec has a tendency to only be used by consenting adults on the basis of prior coordination. if it's a mnadatory component if a design that cannot be deployed without it, great; if not it smacks of a token gesture. > >> >> Best Regards >> Zongpeng Du >> >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Kathleen Mo= riarty >> Sent: Monday, October 24, 2016 12:57 AM >> To: The IESG >> Cc: opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.o= rg; opsawg@ietf.org >> Subject: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsaw= g-capwap-alt-tunnel-08: (with COMMENT) >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection >> >> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this i= ntroductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ >> >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> I'm surprised to see security is optional and an assertion that RFCs p= ublished in 2009 covers everything. Threats have evolved since then. >> In looking at RFC5415, Section 12.1, I see: >> >> Within CAPWAP, DTLS is used to secure the link between the WTP and >> AC. In addition to securing control messages, it's also a link in >> this chain of trust for establishing link layer keys. Consequently= , >> much rests on the security of DTLS. >> >> In some CAPWAP deployment scenarios, there are two channels betwee= n >> the WTP and AC: the control channel, carrying CAPWAP Control >> messages, and the data channel, over which client data packets are >> tunneled between the AC and WTP. Typically, the control channel is= >> secured by DTLS, while the data channel is not. >> >> The use of parallel protected and unprotected channels deserves >> special consideration, but does not create a threat. There are two= >> potential concerns: attempting to convert protected data into >> unprotected data and attempting to convert un-protected data into >> protected data. These concerns are addressed below. >> >> Wouldn't interception and tampering of that traffic pose a threat? Ho= w about gaining access to the control channel? >> >> While I don't think this is the right draft to make changes for RFC541= 5, I don't think it's adequate to say the control channel is optional for= encryption. I could see how the data might be handled elsewhere. The d= escription discusses this as talking to hundreds of thousands of access p= oints, isn't that access a threat? >> >> This draft allows for additional encapsulation methods, we could requi= re encryption for these new encapsulation methods. >> >> This should probably be a discuss, so I would appreciate some discussi= on on this to see if we have option here or if something will change in t= he referenced RFCs soon. >> >> Thank you. >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > --TBLMucpNf142Rd3E3TC6l1KQ7OlbfUbie-- --wKTUQuQLq73EA5cVpT56w5StoFLMMwcUK 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 iEYEARECAAYFAlgPpPgACgkQ8AA1q7Z/VrJlBQCcD8oVKqKuLJNOSEfuoskEQGQR KBkAn1RUtlnm9JHw8lyaNuNCxQa22W68 =slei -----END PGP SIGNATURE----- --wKTUQuQLq73EA5cVpT56w5StoFLMMwcUK-- From nobody Tue Oct 25 18:50:37 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43EB1293FD; Tue, 25 Oct 2016 18:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 TMVyPDRswDbi; Tue, 25 Oct 2016 18:50:27 -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 07DAA126CD8; Tue, 25 Oct 2016 18:50:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZA24420; Wed, 26 Oct 2016 01:50:23 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Oct 2016 02:50:22 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 26 Oct 2016 09:50:16 +0800 From: Duzongpeng To: Warren Kumari Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) Thread-Index: AQHSLU6UGsyDr2C0GkembPtV1MR43KC5ErQg//+SzICAAVQCMA== Date: Wed, 26 Oct 2016 01:50:16 +0000 Message-ID: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.58100BE0.000E, 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: bbd6cc0e6328defdceefb68eef9285f1 Archived-At: Cc: Kathleen Moriarty , "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 01:50:30 -0000 SGksIFdhcnJlbg0KDQoJVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJIHdhbnQgdG8gY2xhcmlmeSB0 aGF0IEkgYW0gbm90IHN1Z2dlc3RpbmcgdXNlcnMgdG8gdXNlIElQc2VjLg0KDQoJSW4gdGhlIGRy YWZ0LCB0aGUgdHVubmVscyBiZXR3ZWVuIHRoZSBXVFAgYW5kIEFSIG5lZWQgdG8gYmUgcHJvdGVj dGVkLCBzbyB0aGUgSVBzZWMgaXMgYmV0d2VlbiB0aGUgV1RQIGFuZCBBUi4NCg0KCVRoZSBuZXR3 b3JrIHByb3ZpZGUgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBzZWN1cml0eSBvZiB0aGUgdXNlcnMs IGFuZCBzaG91bGQgZGVwbG95IHRoZSBJUFNlYyBiZXR3ZWVuIHRoZSBXVFAgYW5kIEFSLg0KDQoJ V2UgY2FuIHN1Z2dlc3QgdG8gdGhlIG5ldHdvcmsgcHJvdmlkZXJzIHRoYXQgaXQgaXMgbm90IGEg Z29vZCBjaG9pY2UgdG8gdXNlIHVuc2VjdXJlZCB0dW5uZWwuDQoJQWxzbywgdGhlIG5ldHdvcmsg cHJvdmlkZSBzaG91bGQgbm90aWZ5IHRoZSB1c2VycyB0aGF0IHRoZSBzZXJ2aWNlIGlzIHVuc2Vj dXJlZCBpZiB0aGV5IGNob29zZSBzb21lIHVuc2VjdXJlZCB0dW5uZWwgdHlwZXMuDQoNCkJlc3Qg UmVnYXJkcw0KWm9uZ3BlbmcgRHUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFdhcnJlbiBLdW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0gDQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDI1LCAyMDE2IDk6MjQgUE0NClRvOiBEdXpvbmdwZW5nDQpDYzogS2F0aGxlZW4g TW9yaWFydHk7IFRoZSBJRVNHOyBvcHNhd2ctY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW9w c2F3Zy1jYXB3YXAtYWx0LXR1bm5lbEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09QU0FXR10gS2F0aGxlZW4gTW9yaWFydHkncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwtMDg6ICh3aXRoIENPTU1FTlQpDQoNCk9uIFR1 ZSwgT2N0IDI1LCAyMDE2IGF0IDI6NDEgUE0sIER1em9uZ3BlbmcgPGR1em9uZ3BlbmdAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+IEhlbGxvLA0KPg0KPiAgICAgICAgIEkgd291bGQgbGlrZSB0byBnaXZl IHNvbWUgc3VnZ2VzdGlvbnMgYXMgYmVsb3cuDQo+DQo+ICAgICAgICAgU29tZSBvcGVyYXRvcnMg ZGVwbG95cyB0aGVpciBXaUZpIG5ldHdvcmtzIHdpdGggdGhlIGRhdGEgY2hhbm5lbCB1bnNlY3Vy ZWQsIGFuZCBldmVuIGZvciB0aGUgd2lyZWxlc3MgcGFydCwgdGhlcmUgYXJlIHNvbWUgdW5zZWN1 cmVkIGRlcGxveW1lbnQgZXhhbXBsZXMuDQo+ICAgICAgICAgSXQgaXMgbm90IGEgZ29vZCBjaG9p Y2U7IGhvd2V2ZXIsIGl0IGlzIHNpbXBsZXIuDQo+DQo+ICAgICAgICAgT2YgY291cnNlLCBzb21l IHNlY3VyZSBlbnN1cmVkIG1ldGhvZHMgc2hvdWxkIGFsc28gYmUgcHJvdmlkZWQuDQo+ICAgICAg ICAgRm9yIHRoZSB3aXJlbGVzcyBwYXJ0LCBJRUVFIGhhcyBwcm92aWRlZCBzZXZlcmFsIHNlY3Vy ZSBtZWNoYW5pc207DQo+ICAgICAgICAgRm9yIHRoZSB3aXJlbGluZSBwYXJ0LCBJUHNlYyBjYW4g YmUgZGVwbG95ZWQgdG8gcHJvdGVjdCB0aGUgc2VjdXJpdHkuDQo+DQo+ICAgICAgICAgV291bGQg aXQgYmUgb2sgZm9yIHRoZSBkcmFmdCB0byBzdWdnZXN0IHRoYXQgSVBzZWMgc2hvdWxkIGJlIGRl cGxveWVkIGlmIHRoZSB0dW5uZWwgdHlwZSBpdHNlbGYgaXMgdW5zZWN1cmVkLg0KDQoNClBlcnNv bmFsbHkgSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgYSB1c2VmdWwgc3VnZ2VzdGlvbiAtLSAq d2hvKiBleGFjdGx5IHdvdWxkIHlvdSBiZSBhZHZpc2luZyB0byBkbyB0aGlzPyBVc2Vycz8gVGhl eSBkb24ndCAoYW5kIHNob3VsZG4ndCBoYXZlIHRvKSByZWFkIHRoZSBSRkNzLiBTdWdnZXN0aW5n IHNvbWV0aGluZyB3aGljaCB3ZSBrbm93IHdpbGwgbm90IGJlIHVzZWQgc2VlbXMgZGlzaW5nZW51 b3VzIC0gYWNrbm93bGVkZ2luZyB0aGF0IHRoaXMgaXMgYSByZWFsIGlzc3VlIHNlZW1zIGJldHRl ciB0aGFuIHN1Z2dlc3Rpbmcgc29tZXRoaW5nIHdoaWNoIHdlIGtub3cgd29uJ3QgYmUgZG9uZSB0 byB1c2VycyB3aG8gd2Uga25vdyBhcmUgbm90IHJlYWNoYWJsZS4NClcNCg0KDQo+DQo+DQo+IEJl c3QgUmVnYXJkcw0KPiBab25ncGVuZyBEdQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEthdGhsZWVuIA0KPiBNb3JpYXJ0eQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjQs IDIwMTYgMTI6NTcgQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBvcHNhd2ctY2hhaXJzQGlldGYu b3JnOyANCj4gZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWxAaWV0Zi5vcmc7IG9w c2F3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbT1BTQVdHXSBLYXRobGVlbiBNb3JpYXJ0eSdzIE5v IE9iamVjdGlvbiBvbiANCj4gZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwtMDg6 ICh3aXRoIENPTU1FTlQpDQo+DQo+IEthdGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAt YWx0LXR1bm5lbC0wODogTm8gT2JqZWN0aW9uDQo+DQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCANCj4gZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IA0KPiB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0KPiBQ bGVhc2UgcmVmZXIgdG8gDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJ U0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQt dHVubmVsLw0KPg0KPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4NCj4gSSdtIHN1cnByaXNlZCB0byBzZWUgc2VjdXJpdHkgaXMgb3B0aW9uYWwgYW5k IGFuIGFzc2VydGlvbiB0aGF0IFJGQ3MgcHVibGlzaGVkIGluIDIwMDkgY292ZXJzIGV2ZXJ5dGhp bmcuICBUaHJlYXRzIGhhdmUgZXZvbHZlZCBzaW5jZSB0aGVuLg0KPiBJbiBsb29raW5nIGF0IFJG QzU0MTUsIFNlY3Rpb24gMTIuMSwgSSBzZWU6DQo+DQo+ICAgIFdpdGhpbiBDQVBXQVAsIERUTFMg aXMgdXNlZCB0byBzZWN1cmUgdGhlIGxpbmsgYmV0d2VlbiB0aGUgV1RQIGFuZA0KPiAgICBBQy4g IEluIGFkZGl0aW9uIHRvIHNlY3VyaW5nIGNvbnRyb2wgbWVzc2FnZXMsIGl0J3MgYWxzbyBhIGxp bmsgaW4NCj4gICAgdGhpcyBjaGFpbiBvZiB0cnVzdCBmb3IgZXN0YWJsaXNoaW5nIGxpbmsgbGF5 ZXIga2V5cy4gIENvbnNlcXVlbnRseSwNCj4gICAgbXVjaCByZXN0cyBvbiB0aGUgc2VjdXJpdHkg b2YgRFRMUy4NCj4NCj4gICAgIEluIHNvbWUgQ0FQV0FQIGRlcGxveW1lbnQgc2NlbmFyaW9zLCB0 aGVyZSBhcmUgdHdvIGNoYW5uZWxzIGJldHdlZW4NCj4gICAgdGhlIFdUUCBhbmQgQUM6IHRoZSBj b250cm9sIGNoYW5uZWwsIGNhcnJ5aW5nIENBUFdBUCBDb250cm9sDQo+ICAgIG1lc3NhZ2VzLCBh bmQgdGhlIGRhdGEgY2hhbm5lbCwgb3ZlciB3aGljaCBjbGllbnQgZGF0YSBwYWNrZXRzIGFyZQ0K PiAgICB0dW5uZWxlZCBiZXR3ZWVuIHRoZSBBQyBhbmQgV1RQLiAgVHlwaWNhbGx5LCB0aGUgY29u dHJvbCBjaGFubmVsIGlzDQo+ICAgIHNlY3VyZWQgYnkgRFRMUywgd2hpbGUgdGhlIGRhdGEgY2hh bm5lbCBpcyBub3QuDQo+DQo+ICAgIFRoZSB1c2Ugb2YgcGFyYWxsZWwgcHJvdGVjdGVkIGFuZCB1 bnByb3RlY3RlZCBjaGFubmVscyBkZXNlcnZlcw0KPiAgICBzcGVjaWFsIGNvbnNpZGVyYXRpb24s IGJ1dCBkb2VzIG5vdCBjcmVhdGUgYSB0aHJlYXQuICBUaGVyZSBhcmUgdHdvDQo+ICAgIHBvdGVu dGlhbCBjb25jZXJuczogYXR0ZW1wdGluZyB0byBjb252ZXJ0IHByb3RlY3RlZCBkYXRhIGludG8N Cj4gICAgdW5wcm90ZWN0ZWQgZGF0YSBhbmQgYXR0ZW1wdGluZyB0byBjb252ZXJ0IHVuLXByb3Rl Y3RlZCBkYXRhIGludG8NCj4gICAgcHJvdGVjdGVkIGRhdGEuICBUaGVzZSBjb25jZXJucyBhcmUg YWRkcmVzc2VkIGJlbG93Lg0KPg0KPiBXb3VsZG4ndCBpbnRlcmNlcHRpb24gYW5kIHRhbXBlcmlu ZyBvZiB0aGF0IHRyYWZmaWMgcG9zZSBhIHRocmVhdD8gIEhvdyBhYm91dCBnYWluaW5nIGFjY2Vz cyB0byB0aGUgY29udHJvbCBjaGFubmVsPw0KPg0KPiBXaGlsZSBJIGRvbid0IHRoaW5rIHRoaXMg aXMgdGhlIHJpZ2h0IGRyYWZ0IHRvIG1ha2UgY2hhbmdlcyBmb3IgUkZDNTQxNSwgSSBkb24ndCB0 aGluayBpdCdzIGFkZXF1YXRlIHRvIHNheSB0aGUgY29udHJvbCBjaGFubmVsIGlzIG9wdGlvbmFs IGZvciBlbmNyeXB0aW9uLiAgSSBjb3VsZCBzZWUgaG93IHRoZSBkYXRhIG1pZ2h0IGJlIGhhbmRs ZWQgZWxzZXdoZXJlLiAgVGhlIGRlc2NyaXB0aW9uIGRpc2N1c3NlcyB0aGlzIGFzIHRhbGtpbmcg dG8gaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGFjY2VzcyBwb2ludHMsIGlzbid0IHRoYXQgYWNj ZXNzIGEgdGhyZWF0Pw0KPg0KPiBUaGlzIGRyYWZ0IGFsbG93cyBmb3IgYWRkaXRpb25hbCBlbmNh cHN1bGF0aW9uIG1ldGhvZHMsIHdlIGNvdWxkIHJlcXVpcmUgZW5jcnlwdGlvbiBmb3IgdGhlc2Ug bmV3IGVuY2Fwc3VsYXRpb24gbWV0aG9kcy4NCj4NCj4gVGhpcyBzaG91bGQgcHJvYmFibHkgYmUg YSBkaXNjdXNzLCBzbyBJIHdvdWxkIGFwcHJlY2lhdGUgc29tZSBkaXNjdXNzaW9uIG9uIHRoaXMg dG8gc2VlIGlmIHdlIGhhdmUgb3B0aW9uIGhlcmUgb3IgaWYgc29tZXRoaW5nIHdpbGwgY2hhbmdl IGluIHRoZSByZWZlcmVuY2VkIFJGQ3Mgc29vbi4NCj4NCj4gVGhhbmsgeW91Lg0KPg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNBV0cg bWFpbGluZyBsaXN0DQo+IE9QU0FXR0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KDQoNCg0KLS0NCkkgZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1 dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQgaWRlYSBpbiB0aGUg Zmlyc3QgcGxhY2UuDQpUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlvdXIg cGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3Nl IHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyIG9mIHBhbnRzLg0KICAgLS0t bWFmDQo= From nobody Tue Oct 25 19:38:08 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93C129692; Tue, 25 Oct 2016 19:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 L-Qf4FYWTFB7; Tue, 25 Oct 2016 19:38:00 -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 0A79F126FDC; Tue, 25 Oct 2016 19:37:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZA28448; Wed, 26 Oct 2016 02:37:56 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Oct 2016 03:37:55 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 26 Oct 2016 10:37:50 +0800 From: Duzongpeng To: Alexey Melnikov , The IESG Thread-Topic: [OPSAWG] Alexey Melnikov's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) Thread-Index: AQHSLVJYeC+4qtlae0OdJkEz5yBSFqC6Bo+A Date: Wed, 26 Oct 2016 02:37:50 +0000 Message-ID: References: <147724345399.15955.5426739479458655058.idtracker@ietfa.amsl.com> In-Reply-To: <147724345399.15955.5426739479458655058.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] 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.58101705.0045, 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: 35878f88acdb009641ed1b8e0c623d61 Archived-At: Cc: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Alexey Melnikov's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 02:38:02 -0000 Hi, Alexey, I agree with your comments. Some clarifications as below. +1 to Katleen's comment about optional data channel protection. [duzongpeng]=20 I agree that security issues should be considered more in the draft.=20 But I think it is resolvable as said in my another email. [duzongpeng] In 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication Length =3D=3D 4, but should it be >4 due to IPv4/IPv6 address at the end? [duzongpeng]=20 I agree. Perhaps the authors can correct it. [duzongpeng] Best Regards Zongpeng Du -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Alexey Melnikov Sent: Monday, October 24, 2016 1:24 AM To: The IESG Cc: opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; o= psawg@ietf.org Subject: [OPSAWG] Alexey Melnikov's No Objection on draft-ietf-opsawg-capwa= p-alt-tunnel-08: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- +1 to Katleen's comment about optional data channel protection. In 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication Length =3D=3D 4, but should it be >4 due to IPv4/IPv6 address at the end? _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Oct 25 19:47:13 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C812944E; Tue, 25 Oct 2016 19:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 LKpf_LUMjEJf; Tue, 25 Oct 2016 19:47:11 -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 3ACCA128DF6; Tue, 25 Oct 2016 19:47:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZA29316; Wed, 26 Oct 2016 02:47:08 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Oct 2016 03:45:25 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 26 Oct 2016 10:45:19 +0800 From: Duzongpeng To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?W09QU0FXR10gTWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBk?= =?utf-8?B?cmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbC0wODogKHdpdGgg?= =?utf-8?Q?COMMENT)?= Thread-Index: AQHSLftgus14w4/HG0CHFhWvGqS3/aC6CNfQ Date: Wed, 26 Oct 2016 02:45:18 +0000 Message-ID: References: <147731605236.15405.5667810699473009609.idtracker@ietfa.amsl.com> In-Reply-To: <147731605236.15405.5667810699473009609.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5810192C.0113, 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: 1dd1c8aea3fe8ca8eae1fab5f6ceeb4d Archived-At: Cc: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-opsawg-capwap-alt-tunnel-08=3A_=28with_COMMENT=29?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 02:47:12 -0000 SGkgTWlyamE6DQoNCglUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgYWdyZWUgd2l0aCB5b3VyIGNv bW1lbnRzLiBUaGUgYXV0aG9ycyBzaG91bGQgY29ycmVjdCBpdC4NCg0KQmVzdCBSZWdhcmRzDQpa b25ncGVuZyBEdQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT1BTQVdHIFtt YWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaXJqYSBLdWVobGV3 aW5kDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjQsIDIwMTYgOTozNCBQTQ0KVG86IFRoZSBJRVNH DQpDYzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFs dC10dW5uZWxAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0KU3ViamVjdDogW09QU0FXR10gTWly amEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAt YWx0LXR1bm5lbC0wODogKHdpdGggQ09NTUVOVCkNCg0KTWlyamEgS8O8aGxld2luZCBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtb3BzYXdn LWNhcHdhcC1hbHQtdHVubmVsLTA4OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwvDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOaXQ6DQoNCnMvVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgdGhlIHZhbHVlcyBmcm9tIHplcm8gKDApIHRvIGZpdmUgKDUpL1Ro aXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRoZSB2YWx1ZXMgZnJvbSB6ZXJvICgwKSB0byBzaXgg KDYpLw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQo= From nobody Tue Oct 25 19:52:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0F12979D; Tue, 25 Oct 2016 19:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 nHG2Nun5thno; Tue, 25 Oct 2016 19:52:01 -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 E102C129722; Tue, 25 Oct 2016 19:51:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTX23000; Wed, 26 Oct 2016 02:51:56 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Oct 2016 03:51:55 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 26 Oct 2016 10:51:49 +0800 From: Duzongpeng To: Joel Jaeggli , The IESG Thread-Topic: [OPSAWG] Joel Jaeggli's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-08: (with DISCUSS) Thread-Index: AQHSLgina/d2+LFyPE2m7miZgQkNBaC6CjiQ Date: Wed, 26 Oct 2016 02:51:49 +0000 Message-ID: References: <147732142319.15471.2700261643744383617.idtracker@ietfa.amsl.com> In-Reply-To: <147732142319.15471.2700261643744383617.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] 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.58101A4D.002D, 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: db4d97fec67fc7cc2a8f65a4358f85a3 Archived-At: Cc: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] Joel Jaeggli's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-08: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 02:52:03 -0000 Hi, Joel Thanks for your time and attention. I would like to modify the draft according to the discussion if Sri is sti= ll too busy to do it, and other authors do not oppose. Best Regards Zongpeng Du -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Joel Jaeggli Sent: Monday, October 24, 2016 11:04 PM To: The IESG Cc: opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; o= psawg@ietf.org Subject: [OPSAWG] Joel Jaeggli's Discuss on draft-ietf-opsawg-capwap-alt-tu= nnel-08: (with DISCUSS) Joel Jaeggli has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-08: Discuss When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- sorry we came to some comclusions on the basis of late review that make thi= s hard to advance without correcting. this will be withdrawn from this review cycle. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Oct 25 21:43:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4873412950A; Tue, 25 Oct 2016 21:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.332 X-Spam-Level: X-Spam-Status: No, score=-7.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.431, 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 dZfnPTYpmgb8; Tue, 25 Oct 2016 21:43:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 6D0791293F0; Tue, 25 Oct 2016 21:43:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bzG3Z-0002a7-RF; Wed, 26 Oct 2016 04:43:18 +0000 Date: Wed, 26 Oct 2016 13:43:29 +0900 Message-ID: From: Randy Bush To: Duzongpeng In-Reply-To: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Kathleen Moriarty , The IESG , opsawg@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 04:43:26 -0000 > Thanks for your reply. I want to clarify that I am not > suggesting users to use IPsec. > > In the draft, the tunnels between the WTP and AR need to be > protected, so the IPsec is between the WTP and AR. > > The network provide is responsible for the security of the > users, and should deploy the IPSec between the WTP and AR. > > We can suggest to the network providers that it is not a good > choice to use unsecured tunnel. Also, the network provide > should notify the users that the service is unsecured if they > choose some unsecured tunnel types. on my more paranoid days, this being one, i think ipsec was designed to deter use and hence privacy; we have become married to sabatoge. is there some simpler easily deployed auth/privacy mechanism which could be mti? md5/4808 would at least be deployable, disgusting as it is. randy From nobody Wed Oct 26 00:14:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED77F1294A0; Wed, 26 Oct 2016 00:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 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.431, 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 1yTrW6O3K3fO; Wed, 26 Oct 2016 00:14:37 -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 8C7CA1293F8; Wed, 26 Oct 2016 00:14:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTX52418; Wed, 26 Oct 2016 07:14:32 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Oct 2016 08:14:31 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 26 Oct 2016 15:14:24 +0800 From: Duzongpeng To: Randy Bush Thread-Topic: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) Thread-Index: AQHSLU6UGsyDr2C0GkembPtV1MR43KC5ErQg//+SzICAAVQCMP//rMKAgACu1hA= Date: Wed, 26 Oct 2016 07:14:24 +0000 Message-ID: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] 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.0A090204.581057DA.0009, 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: 3bfa24bd33f6a70a149de2c709033462 Archived-At: Cc: Kathleen Moriarty , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 07:14:40 -0000 Hi, Randy I agree that other solutions exist. But IPSec should be the preferred one = by the public WiFi operators because it is more mature and widely used. Of course, we can clarify that other solutions are also ok for protecting = the security of the users. Best Regards Zongpeng Du -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Wednesday, October 26, 2016 12:43 PM To: Duzongpeng Cc: Warren Kumari; Kathleen Moriarty; The IESG; opsawg@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg= -capwap-alt-tunnel-08: (with COMMENT) > Thanks for your reply. I want to clarify that I am not suggesting=20 > users to use IPsec. >=20 > In the draft, the tunnels between the WTP and AR need to be protected,=20 > so the IPsec is between the WTP and AR. >=20 > The network provide is responsible for the security of the users, and=20 > should deploy the IPSec between the WTP and AR. >=20 > We can suggest to the network providers that it is not a good choice=20 > to use unsecured tunnel. Also, the network provide should notify the=20 > users that the service is unsecured if they choose some unsecured=20 > tunnel types. on my more paranoid days, this being one, i think ipsec was designed to det= er use and hence privacy; we have become married to sabatoge. is there some simpler easily deployed auth/privacy mechanism which could be= mti? md5/4808 would at least be deployable, disgusting as it is. randy From nobody Wed Oct 26 03:38:28 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F6E12948B for ; Wed, 26 Oct 2016 03:38:20 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 BkVPN2QDX4tK for ; Wed, 26 Oct 2016 03:38:19 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 26D84129A5E for ; Wed, 26 Oct 2016 03:38:15 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d23so3510136qke.7 for ; Wed, 26 Oct 2016 03:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=We4ZEDyuZl0k8Qh/frsSrjtYFbYcytULdV5H1PeBpmc=; b=bxUPc9uj2mfGAOimsrCeJriJsLvEWHGPvpik1LsXXMlwVGG8KbWAUI9Z6m5Anlg+DZ iV87AqfT8SYN3HMRMVmVrPKlYdI9Gb2jn0uDFNZywO2z9pivAtM+U7NbSpo0e1sPjv8Z 2vZURW9nZ3aqJriItsJS1uI4e0s/k1Se4GxgCsuOQ+HWE/PELQiZALqlHjwdxZc4fi/g Yxlb4hFRxSBnnhAu3IPJj+emdODD9eEWmLoPnYbmyee8NncAvhNScnOyMgGyXe6C7p5B wJnYLnllrKmsNYCo5v8e9EmSZjq1I26tiIxXMJeKEULANmT4LZilQknYZz4kZ7hYDnlf oMTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=We4ZEDyuZl0k8Qh/frsSrjtYFbYcytULdV5H1PeBpmc=; b=kFcNJIyjvVjn6RnkCFh17GPmBixgCT6zrl8TzpS6HL2dL2+26TEs9O/X2QEnDt9zjA A/L29dtw50xbpIL2HEX41UK0hJuu3q78lFvUcdhVfUG17PrL2m6s93fWfV+oXYTukqLH Vo9VzIIkEMpB3slYtY6kYqpxAMnT35JeQsFr1wL/x3VPcXMCktqbPu2KalfKg/25gZTO DPymA2EF0Rjq5zG+pdrOC2pIqtNRNrR3ljA+SbM2jsf77qfJcQ+50FdjIb5gJk1kfssU ju+LtlmIebcqtjuZGlG3obYGTziLaf69u2WdJD+b0oEh56oR07pfZ8FAKUAE6yKIjIKY ia9Q== X-Gm-Message-State: ABUngvdlwwy8vBKbv4kxpUR+h1OUyLF5r/+NIplkxKdueG5VtpSgD1cNBjmLWcOre6gc2RStrt7LcGiwuI4o61kj X-Received: by 10.55.70.84 with SMTP id t81mr742622qka.309.1477478294127; Wed, 26 Oct 2016 03:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.147.100 with HTTP; Wed, 26 Oct 2016 03:37:43 -0700 (PDT) In-Reply-To: References: <147724184512.16086.16613553618779081340.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Wed, 26 Oct 2016 12:37:43 +0200 Message-ID: To: Duzongpeng Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Kathleen Moriarty , "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 10:38:20 -0000 On Wed, Oct 26, 2016 at 3:50 AM, Duzongpeng wrote: > Hi, Warren > > Thanks for your reply. I want to clarify that I am not suggesting= users to use IPsec. In that case I completely misunderstood and take back my grumpiness. > > In the draft, the tunnels between the WTP and AR need to be prote= cted, so the IPsec is between the WTP and AR. Got it. W > > The network provide is responsible for the security of the users,= and should deploy the IPSec between the WTP and AR. > > We can suggest to the network providers that it is not a good cho= ice to use unsecured tunnel. > Also, the network provide should notify the users that the servic= e is unsecured if they choose some unsecured tunnel types. > > Best Regards > Zongpeng Du > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Tuesday, October 25, 2016 9:24 PM > To: Duzongpeng > Cc: Kathleen Moriarty; The IESG; opsawg-chairs@ietf.org; draft-ietf-opsaw= g-capwap-alt-tunnel@ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsa= wg-capwap-alt-tunnel-08: (with COMMENT) > > On Tue, Oct 25, 2016 at 2:41 PM, Duzongpeng wrote= : >> Hello, >> >> I would like to give some suggestions as below. >> >> Some operators deploys their WiFi networks with the data channel= unsecured, and even for the wireless part, there are some unsecured deploy= ment examples. >> It is not a good choice; however, it is simpler. >> >> Of course, some secure ensured methods should also be provided. >> For the wireless part, IEEE has provided several secure mechanis= m; >> For the wireline part, IPsec can be deployed to protect the secu= rity. >> >> Would it be ok for the draft to suggest that IPsec should be dep= loyed if the tunnel type itself is unsecured. > > > Personally I don't think that this is a useful suggestion -- *who* exactl= y would you be advising to do this? Users? They don't (and shouldn't have t= o) read the RFCs. Suggesting something which we know will not be used seems= disingenuous - acknowledging that this is a real issue seems better than s= uggesting something which we know won't be done to users who we know are no= t reachable. > W > > >> >> >> Best Regards >> Zongpeng Du >> >> -----Original Message----- >> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Kathleen >> Moriarty >> Sent: Monday, October 24, 2016 12:57 AM >> To: The IESG >> Cc: opsawg-chairs@ietf.org; >> draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; opsawg@ietf.org >> Subject: [OPSAWG] Kathleen Moriarty's No Objection on >> draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT) >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm surprised to see security is optional and an assertion that RFCs pub= lished in 2009 covers everything. Threats have evolved since then. >> In looking at RFC5415, Section 12.1, I see: >> >> Within CAPWAP, DTLS is used to secure the link between the WTP and >> AC. In addition to securing control messages, it's also a link in >> this chain of trust for establishing link layer keys. Consequently, >> much rests on the security of DTLS. >> >> In some CAPWAP deployment scenarios, there are two channels between >> the WTP and AC: the control channel, carrying CAPWAP Control >> messages, and the data channel, over which client data packets are >> tunneled between the AC and WTP. Typically, the control channel is >> secured by DTLS, while the data channel is not. >> >> The use of parallel protected and unprotected channels deserves >> special consideration, but does not create a threat. There are two >> potential concerns: attempting to convert protected data into >> unprotected data and attempting to convert un-protected data into >> protected data. These concerns are addressed below. >> >> Wouldn't interception and tampering of that traffic pose a threat? How = about gaining access to the control channel? >> >> While I don't think this is the right draft to make changes for RFC5415,= I don't think it's adequate to say the control channel is optional for enc= ryption. I could see how the data might be handled elsewhere. The descrip= tion discusses this as talking to hundreds of thousands of access points, i= sn't that access a threat? >> >> This draft allows for additional encapsulation methods, we could require= encryption for these new encapsulation methods. >> >> This should probably be a discuss, so I would appreciate some discussion= on this to see if we have option here or if something will change in the r= eferenced RFCs soon. >> >> Thank you. >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > > > -- > I don't think the execution is relevant when it was obviously a bad idea = in the first place. > This is like putting rabid weasels in your pants, and later expressing re= gret at having chosen those particular rabid weasels and that pair of pants= . > ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Oct 27 13:54:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54C51296EF; Thu, 27 Oct 2016 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.641 X-Spam-Level: X-Spam-Status: No, score=-4.641 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.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 yyR9tlEAw1Bx; Thu, 27 Oct 2016 13:53:58 -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 AC82F1295A9; Thu, 27 Oct 2016 13:53:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUA37051; Thu, 27 Oct 2016 20:53:53 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 27 Oct 2016 21:53:51 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.186]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Fri, 28 Oct 2016 04:53:38 +0800 From: "Chenrui (Richard)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Thread-Index: AQHSJYYRaoB4EZHCnEeWdW72DK055qCnh9aA///0CACABL2CQP//9miAgBCg5HM= Date: Thu, 27 Oct 2016 20:53:37 +0000 Message-ID: <0D5441A3DF1544449089458210966F29788F23A4@SZXEMA501-MBX.china.huawei.com> References: <0D5441A3DF1544449089458210966F29788EFCD9@SZXEMA501-MBX.china.huawei.com>, , <0D5441A3DF1544449089458210966F29788F021F@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E0E5E@dfweml501-mbb> <0D5441A3DF1544449089458210966F29788F0C95@SZXEMA501-MBX.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D572E1351@dfweml501-mbb> <0D5441A3DF1544449089458210966F29788F114A@SZXEMA501-MBX.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D572E195A@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D572E195A@dfweml501-mbb> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.206] Content-Type: multipart/alternative; boundary="_000_0D5441A3DF1544449089458210966F29788F23A4SZXEMA501MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58126963.001B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.186, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e98f4378043959749a6b9d7441b2e582 Archived-At: Cc: Chongfeng Xie , zhangliya , "opsawg-chairs@ietf.org" , Liang Geng , Songxiaolin Subject: [OPSAWG] =?gb2312?b?tPC4tDogID8/OiAgZHJhZnQtZGVuZy1vcHNhd2ctY29t?= =?gb2312?b?cG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQ=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 20:54:04 -0000 --_000_0D5441A3DF1544449089458210966F29788F23A4SZXEMA501MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpKdXN0IHVzZSB0aGlzIHRocmVhZCB0byBub3RpZnkgdGhhdCB3ZSBoYXZlIHBv c3QgYSBuZXcgZHJhZnQgb24gdGhpcyByZXF1aXJlbWVudC5QbGVhc2UgZm9sbG93IHRoZSBiZWxv dyBsaW5rIHRvIHJlYWNoIGl0LllvdSBjb21tZW50cyBhcmUgd2FybWx5IHdlbGNvbWVkLg0KQWZ0 ZXIgZGlzY3Vzc2VkIHdpdGggZXhwZXJ0cyBmcm9tIENoaW5hIE1vYmlsZShMaWFuZyBHZW5nKWFu ZCBDaGluYSBUZWxlY29tKENob25nZmVuZ1hpZSksd2UgaGF2ZSByZWZpbmVkIHRoZSByZXF1aXJl bWVudCBkZXNjcmlwdGlvbiBhbmQgcHJvdmlkZSBhIHJvdWdoIGlkZWEgb24gaG93IHRvIGJ1aWxk IGEgRTJFIGRlcGxveW1lbnQgbW9kZWwgb2YgbXVsaXBsZSBkb21haW4vdGVjaG5vbG9naWVzIG5l dHdvcmsgd2hpY2ggcHJvdmlkZSBMMi9MM1ZQTiBzZXJ2aWNlLg0KVGhlIHRpdGxlIG9mIHRoZSBk cmFmdChZQU5HIERhdGEgTW9kZWwgZm9yIENvbXBvc2l0ZSBWUE4gU2VydmljZSBEZWxpdmVyeSkg c2hvdWxkIGJlIGludGVwcmV0ZWQgYXMgIkEgRGF0YSBNb2RlbCBmb3IgQ29tcG9zaXRlIERlbGl2 ZXJ5IHB1cnBvc2Ugb2YgVlBOIFNlcnZpY2UiLCBJdCdzIG5vdCBhIG1vZGVsIG9mIG5ldyBWUE4g c2VydmljZSwNCkl0J3MganVzdCBhIG1vZGVsIHVzZWQgYnkgYSBvbmUtc3RvcCBkZWxpdmVyeSBp bnRlcmZhY2UgdG8gbXVsdGlwbGUgZG9taWFuIG5ldHdvcmsgLHNvIGl0IGNvdWxkIHNpbXBsaWZ5 IHRoZSBmdWxmaWxtZW50IG9mIFZQTiBzZXJ2aWNlLg0KWW91IGNvdWxkIGZpbmQgIG1vcmUgYmFj a2d1YW5kIGFuZCBkaXNjdXNzaW9uIGluIHRoaXMgdGhyZWFkLiBUaGF0J3Mgd2h5IHdlIGRvbid0 IGNoYW5nZSB0aGUgdGl0bGUgdG9vIG11Y2ggZm9yIHlvdXIgY29udmVuaWVuY2UgdG8gdHJhY2sg aXRzIGNvbnRleHQuDQoNClRoYW5rcy4NClJpY2hhcmQNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQq3osvNyrG85DogMjAxNsTqMTDUwjI3yNUgMTk6MjYNCsrV vP7IyzogQ2hlbnJ1aSAoUmljaGFyZCk7IERFTkcgSHVpOyBMaWFuZyBHZW5nOyA0YyA2NzsgQ2hv bmdmZW5nIFhpZTsgSHVpIERlbmc7IHpoYW5nbGl5YQ0K1vfM4jogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1jaGVuLW9wc2F3Zy1jb21wb3NpdGUtdnBuLWRtLTAwLnR4dA0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2hlbi1vcHNhd2ctY29tcG9zaXRlLXZwbi1kbS0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUnVpIENoZW4gYW5kIHBv c3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWNo ZW4tb3BzYXdnLWNvbXBvc2l0ZS12cG4tZG0NClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAg ICAgICAgIFlBTkcgRGF0YSBNb2RlbCBmb3IgQ29tcG9zaXRlIFZQTiBTZXJ2aWNlIERlbGl2ZXJ5 DQpEb2N1bWVudCBkYXRlOiAgMjAxNi0xMC0yNA0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDQ3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4tb3BzYXdnLWNvbXBvc2l0ZS12 cG4tZG0tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtY2hlbi1vcHNhd2ctY29tcG9zaXRlLXZwbi1kbS8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1vcHNhd2ctY29tcG9zaXRl LXZwbi1kbS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIG9wZXJhdG9yIGZhY2luZyBkYXRhIG1v ZGVsIGlzIHZhbHVhYmxlIHRvIHJlZHVjZSB0aGUgb3BlcmF0aW9ucw0KICAgYW5kIG1hbmFnZW1l bnQuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgWUFORyBkYXRhIG1vZGVsIG9mIHRoZQ0K ICAgY29tcG9zaXRlIFZQTiBmb3Igb3BlcmF0b3JzIHRvIHByb3Zpc2lvbiwgb3B0aW1pemUsIG1v bml0b3IgYW5kDQogICBkaWFnbm9zZSB0aGUgZW5kIHRvIGVuZCBQRS1iYXNlZCBWUE4gc2Vydmlj ZXMgYWNyb3NzIG11bHRpcGxlDQogICBhdXRvbm9tb3VzIHN5c3RlbXMgKEFTZXMpLiAgVGhlIG1v ZGVsIGZyb20gdGhpcyBkb2N1bWVudCBhcmUgbGltaXRlZA0KICAgdG8gbXVsdGlwbGUgQVNlcyB3 aXRoaW4gb25lIHNlcnZpY2UgcHJvdmlkZXIuDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0Kt6K8/sjLOiBMdWN5IHlvbmcNCreiy83KsbzkOiAyMDE2xOox MNTCMTfI1SAyMjoxMg0KytW8/sjLOiBDaGVucnVpIChSaWNoYXJkKTsgSHVpIERlbmcNCrOty806 IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgU29uZ3hpYW9saW47IHpo YW5nbGl5YQ0K1vfM4jogUkU6IFtPUFNBV0ddID8/OiBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3Nl ZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KDQoNCg0KRnJvbTogQ2hlbnJ1aSAoUmljaGFy ZCkNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNywgMjAxNiAyOjE3IEFNDQpUbzogTHVjeSB5b25n OyBIdWkgRGVuZw0KQ2M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsg U29uZ3hpYW9saW47IHpoYW5nbGl5YQ0KU3ViamVjdDogPz86IFtPUFNBV0ddID8/OiBkcmFmdC1k ZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVxdWlyZW1lbnRzLTAxLnR4dA0KDQpIaSBMdWN5 DQoNClRoYW5rcyBmb3IgdGhlc2UgY2xhcmlmaWNhdGlvbnMuDQoNCg0KRnJvbSB0aGUgQWJzdHJh Y3Qgc2VjdGlvbiBvZiBMM1NNIGRyYWZ0KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbC0xNyksIEkgdW5kZXJzdGFuZCBMM1NNIGlz IGEgY3VzdG9tZXItZmFjaW5nIHNlcnZpY2UgbW9kZWwgdXNlZKGwYmV0d2VlbiBjdXN0b21lcnMg YW5kIG5ldHdvcmsgb3BlcmF0b3JzDQoNCnRvIGRlbGl2ZXIgYSBMYXllciAzIFByb3ZpZGVyIFBy b3Zpc2lvbmVkIFZQTiBzZXJ2aWNlobEuDQoNCkl0oa9zIG5vdCB1c2VkIGZvciBwcm92aWRpbmcg YSBlbmQtMi1lbmQgZGVwbG95bWVudCB2aWV3IG9mIGV4aXN0aW5nIEwyL0wzVlBOIHNlcnZpY2Ug Y3Jvc3NpbmcgbXVsdGlwbGUgb3BlcmF0b3IgZG9tYWlucy4NCg0KW0x1Y3ldIEwzU00gY292ZXJz IGN1c3RvbWVyLWZhY2Ugc2VydmljZSBtb2RlbCwgd2hpY2ggY292ZXJzIGUyZSBMMyBzZXJ2aWNl IGFzcGVjdC4gTDNTTSBtb2RlbHMgQUMgYW5kIHByb3ZpZGVycyBiYWNrYm9uZSBpbnRlcndvcmtp bmcsIGV0Yy4gIFRoZSBlbmQtdG8tZW5kIGRlcGxveW1lbnQgaW52b2x2ZXMgIG11bHRpcGxlIGRv bWFpbnMgYW5kIG11bHRpcGxlIGxheWVycy4NCg0KDQoNClNvIEkgdW5kZXJzdGFuZCB5b3VyIG1l YW5pbmcgaXMgdGhhdCBtYXliZSB3ZSBjb3VsZCB1c2Ugc2ltaWxhciBtZXRob2RvbG9neShoaWVy YXJjaGljYWwgYXBwcm9hY2gpIHRvIGRlZmluZSB0aGUgZTJlIGRlcGxveW1lbnQgbW9kZWwsIHdo aWNoIGhhcyB0aGUgTDIvTDNWUE4gYmFzaWMgc2VydmljZSBpbmZvcm1hdGlvbiBhbmQgYXR0cmli dXRlcyByZWZlcmVuY2UgdG8gbXVsdGlwbGUgc2VnbWVudHMoQUMsYmFja2JvbmUsZXRjKSBpbmZv cm1hdGlvbi4NCg0KW0x1Y3ldIEkgdGhpbmsgdGhhdCB3ZSBhcmUgb24gdGhlIHNhbWUgcGFnZSBo ZXJlLiBJIGFtIG5vdCBhbiBleHBlcnQgb24gWUFORy4gSG93IHRvIHVzZSBZQU5HIHRvIG1vZGVs IHRoZXNlIGhpZXJhcmNoaWNhbCByZWxhdGlvbnNoaXA/ICBJZiBhIHNlcnZpY2Ugb3JjaGVzdHJh dG9yIGhhcyB0aGUga25vd2xlZGdlIG9mIGluZGl2aWR1YWwgZG9tYWlucyBhbmQgZG9tYWluIGNh cGFiaWxpdHksIHdoZW4gZ2V0dGluZyBhIEwzIHNlcnZpY2UgcmVxdWVzdCAoZTJlKSwgaXQgY2Fu IGZpZ3VyZSBvdXQgd2hpY2ggZG9tYWlucyB0byB1c2UgZm9yIHRoZSBzZXJ2aWNlIGluc3RhbmNl LCBhbmQgc2VuZCBhIGRvbWFpbiBzZXJ2aWNlIHJlcXVlc3QgIHRvIGVhY2ggaW5kaXZpZHVhbCBk b21haW4gY29udHJvbGxlcnMuDQoNCg0KDQpBbSBJIG1pc3Rha2VuIHNvbWV0aGluZz8NCg0KW0x1 Y3ldIHdlIGhhdmUgdGhlIHNhbWUgdW5kZXJzdGFuZGluZyBub3cuDQoNCg0KDQpMdWN5DQoNCg0K DQoNCg0KVGhhbmtzLA0KDQpSaWNoYXJkDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQq7qs6qvLzK9dPQz965q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQu DQpbQ29tcGFueV9sb2dvXbXY1rejusnu29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHgo7o1MTgx MjkNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpCYW50aWFuLCBMb25nZ2FuZyBEaXN0 cmljdCxTaGVuemhlbiA1MTgxMjksIFAuUi5DaGluYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmr y761xLGjw9zQxc+io6y99s/e09q3osvNuPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsN Cta5yM66zsbky/vIy9LUyM66ztDOyr3KudPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2 oaK4tNbGoaK78smit6KjqbG+08q8/tbQDQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE +sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQg aXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVB V0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hv c2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRv LCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWlu YXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBp cyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVs ZXRlIGl0IQ0KDQq3orz+yMs6IEx1Y3kgeW9uZw0Kt6LLzcqxvOQ6IDIwMTbE6jEw1MIxNMjVIDIy OjIzDQrK1bz+yMs6IENoZW5ydWkgKFJpY2hhcmQpOyBIdWkgRGVuZw0Ks63LzTogb3BzYXdnLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz47IG9wc2F3Z0BpZXRm Lm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsgU29uZ3hpYW9saW47IHpoYW5nbGl5YQ0K1vfM 4jogUkU6IFtPUFNBV0ddID8/OiBkcmFmdC1kZW5nLW9wc2F3Zy1jb21wb3NlZC12cG4tc20tcmVx dWlyZW1lbnRzLTAxLnR4dA0KDQoNCg0KRnJvbTogQ2hlbnJ1aSAoUmljaGFyZCkNClNlbnQ6IEZy aWRheSwgT2N0b2JlciAxNCwgMjAxNiAyOjQ1IEFNDQpUbzogTHVjeSB5b25nOyBIdWkgRGVuZw0K Q2M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+ OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IFNvbmd4aWFvbGluOyB6 aGFuZ2xpeWENClN1YmplY3Q6ID8/OiBbT1BTQVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29t cG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCg0KSGkgTHVjeSwNCg0KVmVyeSBnb29k IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gSSBiZWxpZXZlIEkgY2FuIHVuZGVyc3RhbmQgdGhl IHJlcXVpcmVtZW50IGZyb20gQ2hpbmEgTW9iaWxlIGJ1dCBJIGhhdmVuoa90IHJlYWNoZWQgYXMg ZGVlcCB1bmRlcnN0YW5kaW5nIGFzIHlvdS4NCkkgdW5kZXJzdGFuZCBpdKGvcyBpbmRlZWQgbm9u ZSBidXNpbmVzcyB3aXRoIGEgbmV3IFZQTiBzZXJ2aWNlLiBJdKGvcyBqdXN0IGhvdyBvcGVyYXRv ciBjb3VsZCBzcGVjaWZ5IHRoZSBlbmQtMi1lbmQgZGVwbG95bWVudCB2aWV3IG9mIGV4aXN0aW5n IEwyL0wzVlBOIHNlcnZpY2UgY3Jvc3NpbmcgbXVsdGlwbGUgb3BlcmF0b3IgZG9tYWlucy4NCltM dWN5XSBHb29kLiBJIGhvcGUgdGhpcyBpcyB0aGUgY2FzZS4NClRoYXQgY2FuIHNpbXBsaWZ5IHRo ZSBzZXJ2aWNlIGFjdGl2YXRpb24gb3IgZGVwbG95bWVudCBwcm9ncmVzcyB0byBzb21lIGV4dGVu dCBkdWUgdG8gb3JjaGVzdHJhdGlvbiBjYXBhYmlsaXR5LiBSaWdodD8NClNvIEkgYmVsaWV2ZSBp dCAsdGhvdWdoIG5vdCAgc3VyZSBpZiBpdKGvcyBjb21tb24gbmVlZHMgIGZyb20gb3BlcmF0b3Jz LiAgSaGvbSAgbG9va2luZyBmb3IgbW9yZSBjb21tZW50cy4NCg0KUGxlYXNlIEh1aSBjb3JyZWN0 IG1lIGlmIEmhr20gbWlzdGFrZW4gdGhlIGludGVudCBmcm9tIHlvdSBkcmFmdC4NCg0KQlRXLGlu IHlvdXIgc2VudGVuY2Ugb2YgIKGwZG8gb3BlcmF0b3IgbmVlZCBhIGhpZXJhcmNoaWNhbCBvcGVy YXRvciBWUE4gc2VydmljZSBtb2RlbCBvciBhIGZsYXQgb25lP6GxIC5Joa9tIG5vdCBzdXJlIHRo ZSBtZWFuaW5nIG9mIKGwIGhpZXJhcmNoaWNhbKGxIG9yIKGwZmxhdKGxLCBhcmUgdGhleSB0aGUg c2FtZSBzb2x1dGlvbnMgZm9yIHRoaXMgcmVxdWlyZW1lbnQgb3IgZGlmZmVyZW50IHNvbHV0aW9u cz8gQXJlIHRoZXkgZXhpc3Rpbmcgd29yayBpbiBJRVRGIGZvciB0aGlzIHJlcXVpcmVtZW50Pw0K W0x1Y3ldIFRoZSBiYXNlZCBMMi9MM1ZQTiBhcmNoaXRlY3R1cmUgaXM6ICBDRS0oQUMpLVBFLShw cm92aWRlciBiYWNrYm9uZSBuZXR3b3JrcyktUEUtKEFDKS1DRS4gIEwzU00gYWxyZWFkeSBhZGRy ZXNzZXMgdGhhdCB0aGUgcHJvdmlkZXIgYmFja2JvbmUgbmV0d29ya3MgY2FuIGluY2x1ZGUgbXVs dGlwbGUgZG9tYWlucyB0aGF0IGFyZSBpbnRlcmNvbm5lY3RlZCB2aWEgUEUtUEUgb3IgQVNCUi1B U0JSLiBBbm90aGVyIHBhcnQgaXMgdGhlIEFDIHRoYXQgY2FuIGJlIGNvbnN0cnVjdGVkIHRocm91 Z2ggYW5vdGhlciBuZXR3b3JrIGRvbWFpbiBzdWNoIGFzIGFjY2VzcyBuZXR3b3JrLiBJbiB0aGlz IGNhc2UsIHRoZSBhY2Nlc3MgbmV0d29yayBwcm92aWRlcyBhbiBMMlZQTiBzZXJ2aWNlIHRvIHRo ZSBlbmQtdG8tZW5kIFZQTiBzZXJ2aWNlOyBmcm9tIHRoZSBlbmQtdG8tZW5kIFZQTiBzZXJ2aWNl IHBlcnNwZWN0aXZlLCBpdCB1c2VzIHRoZSBhY2Nlc3MgbmV0d29yayB0byBwcm92aWRlIGEgbGlu ayBmb3IgQUMuIFdoYXQgSSBtZWFucyBoZXJlLCBpZiBTUCBvcGVyYXRvciAoaS5lLiBlbmQtdG8t ZW5kIFZQTiBvcGVyYXRvcikgd2FudHMgYSBzZXJ2aWNlIG1vZGVsIGluY2x1ZGluZyB0aGUgYWNj ZXNzIG5ldHdvcmsgZG9tYWluL2wydnBuIChmbGF0IG1vZGVsKSBvciBhIHNlcnZpY2UgbW9kZWwg IHdpdGggQUMgdGhhdCBBQyByZWZlcmVuY2UgdG8gYW5vdGhlciBMMlZQTiBzZXJ2aWNlLiAoaGll cmFyY2hpY2FsIG1vZGVsKSBUaGlzIGlzIHdoYXQgSSB3YW50IHRvIGV4cHJlc3MuIEwzU00gdXNl cyBoaWVyYXJjaGljYWwgYXBwcm9hY2guDQoNClRoYW5rcywNCkx1Y3kNCg0KVGhhbmtzLg0KUmlj aGFyZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQq7qs6qvLzK9dPQz965 q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFueV9sb2dvXbXY1rejusnu 29rK0MH6uNrH+NvgzO+7qs6qu/m12CDTyrHgo7o1MTgxMjkNCkh1YXdlaSBUZWNobm9sb2dpZXMg Q28uLCBMdGQuDQpCYW50aWFuLCBMb25nZ2FuZyBEaXN0cmljdCxTaGVuemhlbiA1MTgxMjksIFAu Ui5DaGluYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Ksb7Tyrz+vLDG5Li9vP66rNPQu6rOqrmry761xLGjw9zQxc+io6y99s/e09q3osvN uPjJz8PmtdjWt9bQwdCz9rXEuPbIy7vyyLrX6aGjvfsNCta5yM66zsbky/vIy9LUyM66ztDOyr3K udPDo6iw/MCotauyu8/e09rIq7K/u/Kyv7fWtdjQucK2oaK4tNbGoaK78smit6KjqbG+08q8/tbQ DQq1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8/qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7I y7Kiyb6z/bG+08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4g Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQg b25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJv dmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3 YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIg dGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVj ZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpw aG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQq3orz+yMs6IEx1Y3kg eW9uZw0Kt6LLzcqxvOQ6IDIwMTbE6jEw1MIxNMjVIDM6MTUNCsrVvP7IyzogSHVpIERlbmc7IENo ZW5ydWkgKFJpY2hhcmQpOyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4N CrOty806IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5v cmc+DQrW98ziOiBSRTogW09QU0FXR10gPz86IGRyYWZ0LWRlbmctb3BzYXdnLWNvbXBvc2VkLXZw bi1zbS1yZXF1aXJlbWVudHMtMDEudHh0DQoNCkhpIEh1aSBhbmQgUnVpLA0KDQpUaGUgZHJhZnQg aW50cm9kdWN0aW9uIHN0YXJ0cyB0aGF0IElTUHMgaGF2ZSBpbnRlcmVzdCBvbiBwcm92aWRpbmcg UHJvdmlkZXIgRWRnZSAoUEUpIGJhc2VkIHZpcnR1YWwgcHJpdmF0ZSBuZXR3b3JrIChWUE4pIHNl cnZpY2UgYW5kIG5hbWVzIGl0IGFzIGNvbXBvc2VkIFZQTiBzZXJ2aWNlIGFuZCBpbnRlbmRzIHRv IHNwZWNpZnkgdGhlIHNlcnZpY2UgbW9kZWwgcmVxdWlyZW1lbnRzIGZvciB0aGUgY29tcG9zZWQg VlBOLiBUaGVuIGl0IHN0YXRlcyB0aGF0IHRoaXMgc2VydmljZSBtb2RlbCBpcyBmcm9tIG9wZXJh dG9yIHBlcnNwZWN0aXZlLg0KDQpNeSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnM6DQoNCg0KKiAg ICAgICAgIElzIHRoaXMgYSBicmFuZCBuZXcgVlBOIHNlcnZpY2Ugb2ZmZXJlZCBieSBJbnRlcm5l dCBTZXJ2aWNlIFByb3ZpZGVycyBvciBhIHVzZSBjYXNlIGZvciBleGlzdGluZyBWUE4gc2Vydmlj ZXMgc3BlY2lmaWVkIGluIFtSRkM0MzY0XSBbUkZDNjc0Ml1bUkZDNzQzMl0/IElmIHRoaXMgaXMg YSBuZXcgc2VydmljZSwgcGxlYXNlIG1ha2UgdGhhdCB2ZXJ5IGNsZWFyIGluIHRoZSBiZWdpbm5p bmcgYW5kIGRlc2NyaWJlIHdoYXQgaXMgdGhlIG5ldyBzZXJ2aWNlLCBzZXJ2aWNlIGFyY2hpdGVj dHVyZSwgYW5kIGFyY2hpdGVjdHVyZSBjb21wb25lbnRzLiBJZiB0aGlzIGlzIGEgdXNlIGNhc2Ug Zm9yIGV4aXN0aW5nIFZQTiBzZXJ2aWNlczsgcGxlYXNlIGRvIG5vdCBjYWxsIGl0IGNvbXBvc2Vk IFZQTiBzZXJ2aWNlIChtYWtlIGEgbG90IG9mIGNvbmZ1c2lvbnMuKQ0KDQoqICAgICAgICAgQXNz dW1lIHRoaXMgaXMgZm9yIGV4aXN0aW5nIFZQTnMgYW5kIGRyYWZ0IHdhbnRzIHRvIHNwZWNpZnkg dGhlIG9wZXJhdG9yIHZpZXcgb2YgZS0yLWUgVlBOcyB0aGF0IG1heSBhY3Jvc3MgbXVsdGlwbGUg b3BlcmF0b3IgZG9tYWlucy4gU3VnZ2VzdHMgdG8gc3RhcnQgd2l0aCBleGlzdGluZyBWUE4gc2Vy dmljZSBhcmNoaXRlY3R1cmUgdmlldyBhbmQgY29tcG9uZW50czogQ0UsIFBFLCBwcm92aWRlciBi YWNrYm9uZSBuZXR3b3JrcywgQUMgZXRjLiBhbmQgZXhwbGFpbiBob3cgb3BlcmF0b3IgbWF5IHVz ZSBtdWx0aXBsZSBuZXR3b3JrIGRvbWFpbnMgdG8gYWNoaWV2ZSBpdC4gRm9yIGV4YW1wbGVzLCBQ RXMgdGhhdCBjdXN0b21lciBzaXRlcyBhdHRhY2ggdG8gbWF5IGV4aXN0IGluIGRpZmZlcmVudCBB U2VzOyAgdGhlIEFDIGJldHdlZW4gQ0UtUEUgbWF5IGJlIGFjcm9zcyBhbiBhY2Nlc3MgbmV0d29y aywgZXRjLg0KDQoqICAgICAgICAgRXhpc3RpbmcgVlBOIHNlcnZpY2UgYWNyb3NzIG11bHRpcGxl IG5ldHdvcmtzIGFyZSBub3QgbmV3IGFuZCBjdXJyZW50IHNvbHV0aW9ucyBzdXBwb3J0IHRoYXQu DQoNCiogICAgICAgICBUZXh0IKGwUHJvdmlkZXIgRWRnZSAoUEUgYmFzZWQgdmlydHVhbCBwcml2 YXRlIG5ldHdvcmsgKFZQTiBzZXJ2aWNlcywgaW4gd2hpY2ggdGhlIHR1bm5lbCBlbmRwb2ludHMg YXJlIHRoZSBQRSBkZXZpY2VzobEgaXMgdmVyeSBjb25mdXNlLiBXaWxsIHRoZSB0dW5uZWwgaXMg YmV0d2VlbiBQRS1QRSBvciBQRS1DRT8gV2lsbCB0aGlzIHR1bm5lbCBpcyBkaWZmZXJlbnQgZnJv bSBjdXJyZW50IHR1bm5lbCB0ZWNobmlxdWVzIGluIFtSRkM0MzY0XSBbUkZDNjc0Ml1bUkZDNzQz Ml0/DQoNCiogICAgICAgICBFeGlzdGluZyBWUE4gc2VydmljZSBQRSBhbmQgQ0UgaGF2ZSBpdHMg cm9sZS4gVGV4dDogobBDRSBkZXZpY2UgZG8gbm90IG5lZWQgdG8gaGF2ZSBhbnkgc3BlY2lhbCBW UE4gY2FwYWJpbGl0eaGxIGlzIGNvbmZ1c2VkIHRvby4NCg0KKiAgICAgICAgIFdoZW4gYW4gb3Bl cmF0b3IgZ2V0cyBjdXN0b21lciBWUE4gc2VydmljZSByZXF1ZXN0IHRoYXQgaXMgYW4gZTJlIHNl cnZpY2UgZGVzY3JpcHRpb24gKGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsKSwg aGUgd2lsbCBkZXNpZ24gaW5kaXZpZHVhbCBzZWdtZW50cyAoQ0UtUEUgYW5kIFBFLVBFKSB0byBt ZWV0IHRoZSByZXF1ZXN0LiBUaGUgcmVzdWx0IG1heSBtZWFuIHRoYXQgdGhlIFZQTiBpcyBpbXBs ZW1lbnRlZCBhY3Jvc3Mgc2V2ZXJhbCBkb21haW5zLg0KDQoqICAgICAgICAgV2hhdCB2YWx1ZXMg dGhhdCBhIGZsYXQgb3BlcmF0b3IgVlBOIHNlcnZpY2UgbW9kZWwgcHJvdmlkZXM/ICB0d28gc2Vn bWVudCBWUE5zIG1heSBub3QgZXZlbiBhdCB0aGUgc2FtZSBsYXllcnMuIElmIG9uZSBzZWdtZW50 IFZQTiBqdXN0IHByb3ZpZGVzIGEgdHJhbnNpdCBsaW5rIG9yIGFjY2VzcyBsaW5rIHRvIHRoZSBW UE4gc2VydmljZSwgZG8gb3BlcmF0b3IgbmVlZCBhIGhpZXJhcmNoaWNhbCBvcGVyYXRvciBWUE4g c2VydmljZSBtb2RlbCBvciBhIGZsYXQgb25lPw0KDQoqICAgICAgICAgIGZpZ3VyZSBpbiBwYWdl IDUgdmVyeSBjb25mdXNpb24uIElmIHRoaXMgaXMgZm9yIGV4aXN0aW5nIFZQTiBzZXJ2aWNlLCBw bGVhc2UgcmVwbGFjZSChsENvbXBvc2VkIFZQTqGxIHdpdGggobBMM1ZQTqGxIChvciChsEwyVlBO obEpLCBhbmQgcmVwbGFjZSBBUCB3aXRoIEFDLg0KDQoqICAgICAgICAgSWYgdGhpcyBpcyBhIG5l dyBWUE4gc2VydmljZSwgcGxlYXNlIGRlZmluZSB3aGF0IGlzIHRoZSBjb21wb3NlZCBWUE4gc2Vy dmljZSBhbmQgdGhlIGFyY2hpdGVjdHVyZS4gVGhlbiBjbGFyaWZ5IGlmIGN1cnJlbnQgSUVURiBo YXMgc29sdXRpb25zIGZvciB0aGlzIHNlcnZpY2UuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpG cm9tOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEh1aSBEZW5nDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTYgMTA6MjggQU0NClRv OiBDaGVucnVpIChSaWNoYXJkKTsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5v cmc+DQpDYzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbT1BTQVdHXSA/PzogZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9z ZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCg0KSGkgUmljaGFyZCwNCg0KSSBhZ3JlZSB3 aXRoIHlvdXIgcG9pbnQsIGluIG9yZGVyIHRvIG1lZXQgdGhvc2Ugb3BlcmF0b3JzIGV4cGVjdGF0 aW9uLCB0aGUgZHJhZnQgbWF5IG5lZWQgdG8gYmUgdXBkYXRlZCBhbmQgcmVmbGVjdCB0aGF0IGFy Y2hpdGVjdHVyZS4NCg0KUmVnYXJkaW5nIHRvIHNvbHV0aW9uLCB0aGF0IHdpbGwgYmUgZ3JlYXQs IHRoYW5rcyBhIGxvdCBmb3IgeW91ciBjb250cmlidXRpb24gdG8gSUVURiBpZiB0aGVyZSBpcyBh bnkgcHJvb2Ygb2YgY29uY2VwdCB0byB0aGlzLg0KDQp0aGFua3MgYSBsb3QgZm9yIHlvdXIgc3Vn Z2VzdGlvbg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkRFTkcgSHVpDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogY2hlbnJ1aUBodWF3ZWkuY29tPG1haWx0bzpjaGVucnVpQGh1 YXdlaS5jb20+DQpUbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tPG1haWx0bzpkZW5naHVpMDJAaG90 bWFpbC5jb20+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCkNDOiBv cHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KU3Vi amVjdDogtPC4tDogW09QU0FXR10gZHJhZnQtZGVuZy1vcHNhd2ctY29tcG9zZWQtdnBuLXNtLXJl cXVpcmVtZW50cy0wMS50eHQNCkRhdGU6IFR1ZSwgMTEgT2N0IDIwMTYgMDI6Mjc6MTQgKzAwMDAN CkhpIEh1aSwNCg0KVGhhbmtzIGZvciB0aGVzZSBjbGFyaWZpY2F0aW9ucy4gTWF5YmUgd2UgY2Fu IHRhbGsgYWJvdXQgaXQgbW9yZSBpbiBuZXh0IG1lZXRpbmcgYW5kIHdlIGNhbiBwcm92aWRlIGEg aW5pdGlhbCBzb2x1dGlvbiBhcm91bmQgdGhlc2UgaXNzdWVzLg0KDQpCVFcsIGlmIHdlIHRhbGtp bmcgYWJvdXQgZmVkZXJhdGlvbiB1c2VkIGluIG11bHRpcGxlIG9wZXJhdG9ycyBzY2VuYXJpb3Ms IEkgc3VnZ2VzdCB0aGF0IHRoZXJlIHNob3VsZCBiZSBlYXN0LXdlc3QgaW50ZXJmYWNlIGJldHdl ZW4gcGVlciBvcmNoZXN0cmF0aW9uIHN5c3RlbSBpbiB0aGVzZSBvcGVyYXRvcnMuIFRoYXQgZWFz ZS13ZXN0IGludGVyZmFjZSBpcyBkaWZmZXJlbnQgd2l0aCBpbnRlcm5hbCBFMkUgc2VydmljZSBh Y3RpdmF0aW9uIGludGVyZmFjZSBmb3Igc29tZSBzcGVjaWFsIHJlcXVpcmVtZW50IGJldHdlZW4g b3BlcmF0b3JzLCBzdWNoIGFzIHNlY3VyaXR5LCByZXNvdXJjZSB2aXN1YWxpemF0aW9uLGV0Yy4N Cg0KVGhhbmtzLA0KUmljaGFyZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQq7qs6qvLzK9dPQz965q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQq12Na3o7rJ 7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVz IENvLiwgTHRkLg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQ LlIuQ2hpbmENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LL zbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9 yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W 0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+ yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWlu IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFi b3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkg d2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlz Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVy IHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJl Y2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0K cGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0Kt6K8/sjLOiBIdWkg RGVuZyBbbWFpbHRvOmRlbmdodWkwMkBob3RtYWlsLmNvbV0NCreiy83KsbzkOiAyMDE2xOoxMNTC MTDI1SAyMzoxNQ0KytW8/sjLOiBDaGVucnVpIChSaWNoYXJkKTsgb3BzYXdnQGlldGYub3JnPG1h aWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQqzrcvNOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0 bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0K1vfM4jogUkU6IFtPUFNBV0ddIGRyYWZ0LWRlbmct b3BzYXdnLWNvbXBvc2VkLXZwbi1zbS1yZXF1aXJlbWVudHMtMDEudHh0DQoNCg0KSGkgUmljaGFy ZCwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLCBJIHJlY2FsbGVkIHRoYXQgb3Ro ZXIgdHdvIG9wZXJhdG9ycyBkdXJpbmcgbGFzdCB0aW1lIGYyZiBtZWV0aW5nIGhhZCBtYWRlIHNv bWUgY29tbWVudHMgYWJvdXQgZmVkZXJhdGlvbiBpc3N1ZSwgaG9wZSB0aGV5IGNhbiBlbGFib3Jh dGUgbW9yZSBkZXRhaWwgY29tbWVudHMgaGVyZSBhcyB3ZWxsLCBpbmxpbmUgd2l0aCA9PT4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBjaGVucnVpQGh1YXdlaS5jb208 bWFpbHRvOmNoZW5ydWlAaHVhd2VpLmNvbT4NClRvOiBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9w c2F3Z0BpZXRmLm9yZz47IGRlbmdodWkwMkBob3RtYWlsLmNvbTxtYWlsdG86ZGVuZ2h1aTAyQGhv dG1haWwuY29tPg0KQ0M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1jaGFp cnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09QU0FXR10gZHJhZnQtZGVuZy1vcHNhd2ctY29t cG9zZWQtdnBuLXNtLXJlcXVpcmVtZW50cy0wMS50eHQNCkRhdGU6IFN1biwgOSBPY3QgMjAxNiAw MzozNTo0NiArMDAwMA0KSGkgSHVpIGFuZCBhbGwsDQoNCldoZW4gSSB3ZW50IHRocm91Z2ggdGhl IGRvY3VtZW50cyBvZiBJRVRGIzk2LEkgbm90aWNlZCB0aGF0IHRoaXMgZHJhZnQgaGFzIHJhaXNl ZCBhIGludGVyZXN0aW5nIHJlcXVpcmVtZW50IGluIENoaW5hIE1vYmlsZSBvZiBFMkUgZGVwbG95 bWVudCBpbnRlcmZhY2UgdG8gYSBtdWx0aXBsZSBWUE5zIGNvbXBvc2VkIGluZnJhc3RydWN0dXJl LCBzdWNoIGFzIEwyK0wzIG5ldHdvcmsuIFNvIHRoZSBpbnRlcmZhY2UgY291bGQgbWFrZSB0aGUg c2VydmljZSBmdWxmaWxsbWVudCBhbmQgbWFuYWdlbWVudCBtb3JlIGVhc3kuDQpJcyBteSB1bmRl cnN0YW5kaW5nIHJpZ2h0Pw0KDQo9PT4gWWVzLCBjdXJyZW50IGV4aXN0aW5nIEwzU00gYXJlIG1v c3RseSB0YWxraW5nIGFib3V0IGN1c3RvbWVyIGZhY2luZyBzZXJ2aWNlIG1vZGVsLg0KdGhpcyBy ZXF1aXJlbWVudCBleHBlY3RzIHRvIGhlbHAgb3BlcmF0b3JzIHdpdGggbGFyZ2Ugc2NhbGUgdG8g bWFuZ2UgdGhlIHVuZGVybGF5IG5ldHdvcmsgd2l0aCBhIGdsb2JhbCB2aWV3LiAgKGhlcmUgY291 bGQgYmUgYSBtdWx0aXBsZSBvcGVyYXRvcnMsIHRoYXQgaXMgcmVsYXRlZCB0byBmZWRlcmF0aW9u KSBhbiBlbnRlcnByaXNlIGN1c3RvbWVyIG1heSBzaW1wbHkgcmVxdWVzdCBhIEwzIFZQTiBzZXJ2 aWNlLCBidXQgb3BlcmF0b3IgaGFzIHRvIHByb3Zpc2lvbiBhbmQgbWFuZ2UgdGhlIGVuZCB0byBl bmQgdW5kZXJsYXkgbmV0d29yayBjb25zdHJ1Y3RlZCB3aXRoIG11bHRpcGxlIEFTZXMgYW5kIHRl Y2huaXF1ZXMsIGFuZCBmdXJ0aGVyIGFzc3VyZSB0aGUgc2VydmljZS4gdGhpcyBpcyB0aGUga2V5 IGlzc3VlIGZvciB0b2RheSdzIG9wZXJhdG9ycy4NCg0KSSBkbyBiZWxpZXZlIHRoaXMgaW50ZXJm YWNlIGFuZCBpdHMgbW9kZWwgYXJlIGluZGVlZCBoZWxwZnVsIGZvciBvcGVyYXRvcnMgdG8gc2lt cGxpZnkgb3BlcmF0aW9ucyBhbmQgbWFuYWdlbWVudC4NCkFuZCBJIHN0aWxsIGhhdmUgc29tZSBx dWVzdGlvbnMgbmVlZCB0byBiZSBkaXNjdXNzZWQgYW5kIGFsaWduZWQgd2l0aCB5b3UgYW5kIGV4 cGVydHMgaW4gZW1haWwgdGhyZWFkLg0KDQoxLldoaWxlIHJlZmVycmluZyB0byBhbm90aGVyIGRy YWZ0IGF0IHNhbWUgbWVldGluZyA8PHNlcnZpY2UgbW9kZWwgZXhwbGFpbmVkPj4gKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtd3Utb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVk LTAzLnR4dCksDQpJIGJlbGlldmUgdGhlIGFib3ZlIEUyRSBkZXBsb3ltZW50IGludGVyZmFjZSBz aG91bGQgYmUgcG9zaXRpb24gYmV0d2VlbiBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gYW5kICBuZXR3 b3JrIG9yY2hlc3RyYXRpb24oRmlndXJlIDMpLg0KVGhhdCBtZWFuIGl0oa9zIGEgaW50ZXJuYWwg aW50ZXJmYWNlIGluIG9uZSBvcGVyYXRvciBhbmQgaXQgYWN0cyBub3Qgb25seSB0byBpbXBsZW1l bnQgdGhlIGN1c3RvbWVyIGZhY2luZyBtb2RlbCAoaS5lLiBMM1NNKSxidXQgYWxzbyB0byBtYWlu dGFpbiwgbW9uaXRvciBhbmQgZGlhZ25vc2UgdGhlIGVuZCB0byBlbmQgUEUtYmFzZWQgVlBOIHNl cnZpY2VzIGNyb3NzaW5nIG11bHRpcGxlIHRlY2hub2xvZ2llcyBkZXBsb3llZCBuZXR3b3JrLg0K SXMgaXQgcmlnaHQ/IGFuZCBzaG91bGQgdGhpcyBpbnRlcmZhY2UgbmVlZCB0byBzdXBwb3J0IFZQ TiBzZXJ2aWNlIHdoaWNoIG1heWJlIGNyb3NzIG11bHRpcGxlIG9wZXJhdG9ycz8NCj09PiBnb29k IHBvaW50LCB0aGUgZnV0dXJlIGluIHRoZSBsaW5rIGlzIHF1aXRlIGhlbHBmdWwsIHRoaXMgc2hv dWxkIGJlIHVwZGF0ZWQgaW4gbmV4dCByZXZpc2lvbi4NCg0KPT0+IGZvciB5b3VyIHF1ZXN0aW9u cyBhYm91dCBtdWx0aXBsZSBvcGVyYXRvcnMsIHRoaXMgaXMgZXhhY3RseSB0aGUgaXNzdWUgcmFp c2VkIGR1cmluZyB0aGUgbWVldGluZywgb3BlcmF0b3IgYXJlIGludGVyY29ubmVjdGVkIGVhY2gg b3RoZXIgdGhyb3VnaCBmZWRlcmF0aW9uLCB0aGUgZW5kIHRvIGVuZCBzZXJ2aWNlIG1heSBnbyBh Y3Jvc3MgbXVsdGlwbGUgb3BlcmF0b3JzJyBhY2Nlc3MgYW5kIGNvcmUgbmV0d29yay4gdGhhdCBp cyB0aGUgcmVhc29uIHdoeSB3ZSBkZWZpbmUgVlBOIHNlZ21lbnQgd2l0aGluIHRoZSBjb21wb3Nl ZCBWUE4uIHRoaXMgaGFzbid0IGJlZW4gY29uc2lkZXIgaW4gdGhlIGRvY3VtZW50IGJlZm9yZSwg YnV0IHRoZSBmbGV4aWJpbGl0eSBvZiBjb21wb3NlZCBWUE4gZnJhbWV3b3JrIHNob3VsZCBiZSBp bmNsdWRlZC4NCg0KMi5BY3R1YWxseSBJoa9tIG5ldyBndXkgaW4gSUVURiwgc28gSaGvbSBub3Qg c3VyZSBpZiB0aGVyZSBhcmUgZXhpc3Rpbmcgd29ya3MgaW4gSUVURiB3aGljaCBjb3VsZCBpbnN0 cnVjdCBvciBtb2RlbGluZyB0aGUgaW50ZXJmYWNlL0UyRS12aWV3IHRvIG1hbmFnZSBhIG11bHRp cGxlIHRlY2hub2xvZ2llcyBjb21wb3NlZCBuZXR3b3JrLCB3aGljaCBJIGJlbGlldmUgdmVyeSBj b21tb24gaW4gb3BlcmF0b3Khr3MgZGVwbG95bWVudCB3aGlsZSBzdGlsbCBuZWVkIHRvIHByb3Zp ZGUgc2ltcGxlIEUyRSBzZXJ2aWNlIGV4cGVyaWVuY2UgdG8gdGhlaXIgY3VzdG9tZXJzLiBNYXli ZSB3ZSBjYW4gaW1wcm92ZSBzb21ldGhpbmcgaGVyZS4gU28gaWYgZXhwZXJ0cyBoZXJlIGhhdmUg bW9yZSBiYWNrZ3JvdW5kLCBwbGVhc2UgaGVscCBtZS4gVGhhbmtzLg0KDQo9PT4gYWx0aG91Z2gg aXQgaXMgaW1wb3J0YW50LCBidXQgSSBkaWRuJ3Qgc2VlIGFueSBlMmUgZWZmb3J0IG9uIHRoZSBu ZXR3b3JrIHlldC4gdGhlcmUgaXMgYSByZWxhdGVkIHdvcmsgaW4gTDNTTSBpbiBjdXN0b21lciBz ZXJ2aWNlIGxldmVsIGFuZCBzb21lIGRlZGljYXRlZCBWUE4gbW9kZWxzIGluIEJFU1MuIHRoYXQn cyB3aHkgSSByYWlzZSB0aGlzIHRvcGljLiBkZWZpbml0ZWx5IHdlbGNvbWUgYW55IGVmZm9ydCB0 byBqb2luIHRoZSBmb2xsb3dpbmcgZGF0YSBtb2RlbCBkZXNpZ24gaWYgeW91IHJlYWxseSBoYXZl IGEgc3Ryb25nIGJhY2tncm91bmQgb24gaXQuDQoNCjMuQXMgSSB1bmRlcnN0YW5kIHRoaXMgaW50 ZXJmYWNlL21vZGVsIHNob3VsZCBiZSBpbnRlcm5hbCBpbiBvcGVyYXRvcnMsIHNvIEmhr20gbm90 IHN1cmUgaWYgdGhlcmUgYW55IG90aGVyIG9wZXJhdG9ycyBhcmUgaW50ZXJlc3RlZCBpdCBhbmQg bmVlZCBhIElFVEYgUkZDPw0KDQo9PT4gSSBkaWQgaGVhciB0d28gYmlnIG9wZXJhdG9ycyBzaG93 ZWQgdGhlIGludGVyZXN0IGluIHRoaXMgdG9waWMsIGhvcGUgdGhleSBjYW4gam9pbiBhcyB3ZWxs IGluIG91ciBuZXh0IHJldmlzaW9uLiB0aGlzIG1heSByZWxhdGVkIHRvIG5ldHdvcmsgb3JjaGVz dHJhdG9yLCBPU1MvQlNTIGFuZCBldmVuIGFuYWx5dGljcyBzeXN0ZW0gZnJvbSBkaWZmZXJlbnQg dmVuZG9ycy4gYSBzdGFuZGFyZCBtb2RlbCB3aWxsIGRlZmluaXRlbHkgIGhlcCB0aGUgZGl2ZXJz aXR5IGluIG9uZSBvcGVyYXRvcidzIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQuDQoNCkJlc3QgcmVn YXJkcywNCg0KREVORyBIdWkNClRoYW5rcy4NCg0KUmVnYXJkcywNClJpY2hhcmQgQ2hlbg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQq7qs6qvLzK9dPQz965q8u+IEh1YXdl aSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQq12Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgg 08qx4KO6NTE4MTI5DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KQmFudGlhbiwgTG9u Z2dhbmcgRGlzdHJpY3QsU2hlbnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCmh0dHA6Ly93d3cuaHVh d2VpLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+ uqzT0Luqzqq5q8u+tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu7 8si61+mho737DQrWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vy sr+31rXY0LnCtqGiuLTWxqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcux vtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBl LW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3Ig ZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5m b3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3Qg bGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv ciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNp cGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSBpdCENCg0K --_000_0D5441A3DF1544449089458210966F29788F23A4SZXEMA501MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Just use this thread to notify that we have post a new draft on this r= equirement.Please follow the below link to reach it.You comments = are warmly welcomed. 
After discussed with experts from China Mobile(Liang Geng)and China Te= lecom(ChongfengXie),we have refined the requirement description and provide= a rough idea on how to build a E2E deployment model of muliple domain= /technologies network which provide L2/L3VPN service.
The title of the draft(YANG Data Model for Composite VPN Service Deliv= ery) should be intepreted as "A Data Model for Composite Del= ivery purpose of VPN Service", It's not a model of new VPN servic= e,
It's just a model used by a one-stop delivery interface to multiple do= mian network ,so it could simplify the fulfilment of VPN service.
You could find  more backguand and discussion in this thread= . That's why we don't change the title too much for your convenience to tra= ck its context.
 
Thanks.
Richard
________________________________________
=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [internet-drafts@ietf.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C227=C8=D5 19:26
=CA=D5=BC=FE=C8=CB: Chenrui (Richard); DENG Hui; Liang Geng; 4c 67; Chongfe= ng Xie; Hui Deng; zhangliya
=D6=F7=CC=E2: New Version Notification for draft-chen-opsawg-composite-vpn-= dm-00.txt

A new version of I-D, draft-chen-opsawg-composite-vpn-dm-00.txt
has been successfully submitted by Rui Chen and posted to the
IETF repository.

Name:           draft-che= n-opsawg-composite-vpn-dm
Revision:       00
Title:          YANG Data Mode= l for Composite VPN Service Delivery
Document date:  2016-10-24
Group:          Individual Sub= mission
Pages:          47
URL:            http= s://www.ietf.org/internet-drafts/draft-chen-opsawg-composite-vpn-dm-00.txt<= br> Status:         https://datatracker= .ietf.org/doc/draft-chen-opsawg-composite-vpn-dm/
Htmlized:       https://tools.ietf.org/html/d= raft-chen-opsawg-composite-vpn-dm-00


Abstract:
   The operator facing data model is valuable to reduce the opera= tions
   and management.  This document describes the YANG data mo= del of the
   composite VPN for operators to provision, optimize, monitor an= d
   diagnose the end to end PE-based VPN services across multiple<= br>    autonomous systems (ASes).  The model from this document = are limited
   to multiple ASes within one service provider.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=B7=A2=BC=FE=C8=CB: Lucy yong
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C217=C8=D5 22:12
=CA=D5=BC=FE=C8=CB: Chenrui (Richard); Hui Deng
=B3=AD=CB=CD: opsawg-chairs@ietf.org; opsawg@ietf.org; Songxiaolin; = zhangliya
=D6=F7=CC=E2: RE: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-req= uirements-01.txt

 

 

From: Chenru= i (Richard)
Sent: Monday, October 17, 2016 2:17 AM
To: Lucy yong; Hui Deng
Cc: opsawg-chairs@ietf.org; opsawg@ietf.org; Songxiaolin; zhangliya<= br> Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem= ents-01.txt

 

Hi Lucy

 

Thanks for these clarifications.

 

From the Abstract section of L3SM draft(https://tools.ietf.org/html/draft-i=
etf-l3sm-l3vpn-service-model-17), I understand L3SM is a custome=
r-facing service model used=A1=B0between customers and ne=
twork operators
to deliver a Layer 3 Provider Provisio=
ned VPN service=A1=B1.
It=A1=AFs not used for providing a end=
-2-end deployment view of existing L2/L3VPN service crossing multiple opera=
tor domains.
[Lucy] L3SM covers customer-face s=
ervice model, which covers e2e L3 service aspect. L3SM models AC and provid=
ers backbone interworking, etc.  The end-to-end deployment involves &n=
bsp;multiple domains and multiple layers. 
 
So I understand your meaning is that maybe we could use =
similar methodology(hierarchical approach) to define the e2e deployment model, which has the L2/L3VPN basic se=
rvice information and attributes reference to multiple s=
egments(AC,backbone,etc) information.
[Lucy] I think that we are on the =
same page here. I am not an expert on YANG. How to use YANG to model these =
hierarchical relationship?  If a service orchestrator has the knowledg=
e of individual domains and domain capability, when getting a L3 service re=
quest (e2e), it can figure out which domains to use for the service instanc=
e, and send a domain service request  to each individual domain contro=
llers.   <=
/i>
 
Am I mistaken something?
[Lucy] we have the same understand=
ing now.
 
Lucy
 
 
Thanks,
Richard

 












=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Techn=
ologies Co., Ltd.

3D"Company_logo"=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=
=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=
=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=
=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=
=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=
=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=
=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=
=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=
=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1=
=


This e-mail and its attachments contain co=
nfidential information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!




 





 


 

 





From: Chenru=
i (Richard)


Sent: Friday, October 14, 2016 2:45 AM

To: Lucy yong; Hui Deng

Cc: opsa=
wg-chairs@ietf.org;
opsawg@ietf.org; S=
ongxiaolin; zhangliya

Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem=
ents-01.txt






 


Hi Lucy,


 


Very good comments a=
nd suggestions. I believe I can understand the requirement from China Mobil=
e but I haven=A1=AFt reached as deep understanding as you.



I understand it=A1=
=AFs indeed none business with a new VPN service. It=A1=AFs just how operat=
or could specify the end-2-end deployment view of existing L2/L3VPN
 service crossing multiple operator domains.


[Lucy] Good. I h=
ope this is the case.


That can simplify th=
e service activation or deployment progress to some extent due to orchestra=
tion capability. Right?


So I believe it ,th=
ough not  sure if it=A1=AFs common needs  from operators.  I=
=A1=AFm  looking for more comments.


 


Please Hui correct m=
e if I=A1=AFm mistaken the intent from you draft.


 


BTW,in your sentenc=
e of  =A1=B0do operator need a hierarchical operator VPN service model=
 or a flat one?=A1=B1 .I=A1=AFm not sure the meaning of =A1=B0 hierarchical=
=A1=B1 or =A1=B0flat=A1=B1,
 are they the same solutions for this requirement or different solutions? A=
re they existing work in IETF for this requirement?


[Lucy] The based=
 L2/L3VPN architecture is:  CE-(AC)-PE-(provider backbone networks)-PE=
-(AC)-CE.  L3SM already addresses that the provider backbone
 networks can include multiple domains that are interconnected via PE-PE or=
 ASBR-ASBR. Another part is the AC that can be constructed through another =
network domain such as access network. In this case, the access network pro=
vides an L2VPN service to the end-to-end
 VPN service; from the end-to-end VPN service perspective, it uses the acce=
ss network to provide a link for AC. What I means here, if SP operator (i.e=
. end-to-end VPN operator) wants a service model including the access netwo=
rk domain/l2vpn (flat model) or
 a service model  with AC that AC reference to another L2VPN service. =
(hierarchical model) This is what I want to express. L3SM uses hierarchical=
 approach.


&=
nbsp;


Thanks,


Lucy<=
/b>


 

Thanks.<=
/p>

Richard<=
/p>

 












=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Techn=
ologies Co., Ltd.

3D"Company_logo"=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=
=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=
=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=
=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=
=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=
=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=
=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=
=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=
=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1=
=


This e-mail and its attachments contain co=
nfidential information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!




 





 


Hi Hui and Rui,


 

The draft introduct=
ion starts that ISPs have interest on providing Provider Edge (PE) based vi=
rtual private network (VPN) service and names it as composed
 VPN service and intends to specify the service model requirements for the =
composed VPN. Then it states that this service model is from operator persp=
ective.


 

My comments and sug=
gestions:


 

=A1=A4     =
;   
Is this a brand new V=
PN service offered by Internet Service Providers or a use case for existing=
 VPN services specified in [RFC4364] [RFC6742][RFC7432]?
 If this is a new service, please make that very clear in the beginning and=
 describe what is the new service, service architecture, and architecture c=
omponents. If this is a use case for existing VPN services; please do not c=
all it composed VPN service (make
 a lot of confusions.) 


=A1=A4     =
;   
Assume this is for ex=
isting VPNs and draft wants to specify the operator view of e-2-e VPNs that=
 may across multiple operator domains. Suggests to start
 with existing VPN service architecture view and components: CE, PE, provid=
er backbone networks, AC etc. and explain how operator may use multiple net=
work domains to achieve it. For examples, PEs that customer sites attach to=
 may exist in different ASes;  the
 AC between CE-PE may be across an access network, etc. 


=A1=A4     =
;   
Existing VPN service =
across multiple networks are not new and current solutions support that.



=A1=A4     =
;   
Text =A1=B0Provider E=
dge (PE based virtual private network (VPN services, in which the tunnel en=
dpoints are the PE devices=A1=B1 is very confuse. Will the tunnel
 is between PE-PE or PE-CE? Will this tunnel is different from current tunn=
el techniques in [RFC4364] [RFC6742][RFC7432]?


=A1=A4     =
;   
Existing VPN service =
PE and CE have its role. Text: =A1=B0CE device do not need to have any spec=
ial VPN capability=A1=B1 is confused too.


=A1=A4     =
;   
When an operator gets=
 customer VPN service request that is an e2e service description (draft-iet=
f-l3sm-l3vpn-service-model), he will design individual
 segments (CE-PE and PE-PE) to meet the request. The result may mean that t=
he VPN is implemented across several domains.   


=A1=A4     =
;   
What values that a fl=
at operator VPN service model provides?  two segment VPNs may not even=
 at the same layers. If one segment VPN just provides a transit
 link or access link to the VPN service, do operator need a hierarchical op=
erator VPN service model or a flat one?


=A1=A4     =
;   
 figure in page =
5 very confusion. If this is for existing VPN service, please replace =A1=
=B0Composed VPN=A1=B1 with =A1=B0L3VPN=A1=B1 (or =A1=B0L2VPN=A1=B1), and re=
place AP with AC.


=A1=A4     =
;   
If this is a new VPN =
service, please define what is the composed VPN service and the architectur=
e. Then clarify if current IETF has solutions for this
 service. 


 

Regards,=



Lucy



 

 

 





From: OPSAWG=
 [mailto:opsaw=
g-bounces@ietf.org]
On Behalf Of Hui Deng

Sent: Wednesday, October 12, 2016 10:28 AM

To: Chenrui (Richard); opsawg@ietf.org

Cc: opsa=
wg-chairs@ietf.org

Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirem=
ents-01.txt






 




Hi Richard,




 






I agree with your point, in order to meet those operato=
rs expectation, the draft may need to be updated and reflect that architect=
ure.






 






Regarding to solution, that will be great, thanks a lot=
 for your contribution to IETF if there is any proof of concept to this.






 






thanks a lot for your suggestion






 






Best regards,






 






DENG Hui










From:
chenrui@huawei.com<=
/a>

To: denghui02@ho=
tmail.com;
opsawg@ietf.org
CC: opsawg-chai=
rs@ietf.org

Subject: =B4=F0=
=B8=B4: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt<=
br>
Date: Tue, 11 Oct 2016 02:27:14 +0000




Hi Hui,

 <=
/p>

Thanks for these cla=
rifications. Maybe we can talk about it more in next meeting and we can pro=
vide a initial solution around these issues.


 <=
/p>

BTW, if we talking a=
bout
federation used in multiple operators scenarios, I suggest that there shou=
ld be east-west interface between peer orchestration system in these operat=
ors. That ease-west interface is different with
 internal E2E service activation interface for some special requirement bet=
ween operators, such as security, resource visualization,etc.

 


Thanks,

Richard

 <=
/p>











=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Techn=
ologies Co., Ltd.

=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=
=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=
=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=
=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=
=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=
=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=
=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=
=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=
=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1=
=


This e-mail and its attachments contain co=
nfidential information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!




 <=
/p>







=B7=A2=BC=FE=C8=CB: Hui Deng
 [mailto:denghui=
02@hotmail.com]


=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA10=D4=C210=C8=
=D5
 23:15

=CA=D5=BC=FE=C8=CB:=
 Chenrui (Richard);
opsawg@ietf.org
=B3=AD=CB=CD:
opsawg-chairs@i=
etf.org

=D6=F7=CC=E2: RE: [=
OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt





 






Hi Richard,




 






Thanks a lot for your comments, I recalled that other t=
wo operators during last time f2f meeting had made some comments about fede=
ration issue, hope they can elaborate more detail comments
 here as well, inline with =3D=3D>










From: 
chenrui@huawei.com

To: opsawg@ietf.org; 
denghui02@hotmail.com

CC: opsawg-chai=
rs@ietf.org

Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt=


Date: Sun, 9 Oct 2016 03:35:46 +0000




Hi Hui and all,


 


When I went through the documents of IETF#96,I noticed tha=
t this draft has raised a interesting requirement in China Mobile of E2E de=
ployment interface to a multiple VPNs composed
 infrastructure, such as L2+L3 network. So the interface could make the=
 service fulfillment and management more easy.


Is my understanding right?


 


=3D=3D> Yes, current existing L3SM are mostly talking a=
bout customer facing service model.


this requirement expects to help operators with large scal=
e to mange the underlay network with a global view.  (here could be a =
multiple operators, that is related to federation)
 an enterprise customer may simply request a L3 VPN service, but operator h=
as to provision and mange the end to end underlay network constructed with =
multiple ASes and techniques, and further assure the service. this is the k=
ey issue for today's operators.


 


I do believe this interface and its model are indeed helpf=
ul for operators to simplify operations and management.


And I still have some questions need to be discussed and a=
ligned with you and experts in email thread.


 


1.While referring to another draft at same meeting <<=
;service model explained>> (https://=
tools.ietf.org/id/draft-wu-opsawg-service-model-explained-03.txt),<=
/span>


I believe the above E2E deployment interface should be pos=
ition between service orchestration and  network orchestration(Figure =
3).


That mean it=A1=AFs a internal interface in one operator a=
nd it acts not only to implement the customer facing model (i.e. L3SM),but =
also to maintain, monitor and diagnose the end to end
 PE-based VPN services crossing multiple technologies deployed network.=



Is it right? and should this interface need to support VPN=
 service which maybe cross multiple operators?


=3D=3D> good point, the future in the link is quite hel=
pful, this should be updated in next revision.


 


=3D=3D> for your questions about multiple operators, th=
is is exactly the issue raised during the meeting, operator are interconnec=
ted each other through federation, the end to end service
 may go across multiple operators' access and core network. that is the rea=
son why we define VPN segment within the composed VPN. this hasn't been con=
sider in the document before, but the flexibility of composed VPN framework=
 should be included.


 


2.Actually I=A1=AFm new guy in IETF, so I=A1=AFm not sure =
if there are existing works in IETF which could instruct or modeling the in=
terface/E2E-view to manage a multiple technologies composed
 network, which I believe very common in operator=A1=AFs deployment while s=
till need to provide simple E2E service experience to their customers. Mayb=
e we can improve something here. So if experts here have more background, p=
lease help me. Thanks.


 


=3D=3D> although it is important, but I didn't see any =
e2e effort on the network yet. there is a related work in L3SM in customer =
service level and some dedicated VPN models in BESS.
 that's why I raise this topic. definitely welcome any effort to join the f=
ollowing data model design if you really have a strong background on it.


 


3.As I understand this interface/model should be internal =
in operators, so I=A1=AFm not sure if there any other operators are interes=
ted it and need a IETF RFC?


 


=3D=3D> I did hear two big operators showed the interes=
t in this topic, hope they can join as well in our next revision. this may =
related to network orchestrator, OSS/BSS and even analytics
 system from different vendors. a standard model will definitely  hep =
the diversity in one operator's production environment.


 


Best regards,


 


DENG Hui


Thanks.


 


Regards,


Richard Chen


 










=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Techn=
ologies Co., Ltd.

=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=
=CC=EF=BB=AA=CE=AA=BB=F9=B5=D8
=D3=CA=B1=E0=A3=BA518129

Huawei Technologies Co., Ltd.

Bantian, Longgang District,Shenzhen 518129, P.R.China

http://www.huawei.com









=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=
=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=
=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=
=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=
=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=
=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=
=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=
=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1=
=


This e-mail and its attachments contain co=
nfidential information from HUAWEI, which


is intended only for the person or entity whose address is listed above. An=
y use of the


information contained herein in any way (including, but not limited to, tot=
al or partial


disclosure, reproduction, or dissemination) by persons other than the inten=
ded 

recipient(s) is prohibited. If you receive this e-mail in error, please not=
ify the sender by


phone or email immediately and delete it!


 
--_000_0D5441A3DF1544449089458210966F29788F23A4SZXEMA501MBXchi_-- From nobody Mon Oct 31 05:04:04 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E051295BB; Mon, 31 Oct 2016 05:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 7jvFmbQu6W1I; Mon, 31 Oct 2016 05:04:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AA81294A5; Mon, 31 Oct 2016 05:03:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC3uoE026126; Mon, 31 Oct 2016 12:03:56 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC3sLf026099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2016 12:03:55 GMT From: "Adrian Farrel" To: "'opsawg@ietf.org'" Date: Mon, 31 Oct 2016 12:03:50 -0000 Message-ID: <00f701d2336e$d892e390$89b8aab0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIzbq9EP4RJAzxtQQ667SmsQfy/Ow== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22670.006 X-TM-AS-Result: No--8.359-10.0-31-10 X-imss-scan-details: No--8.359-10.0-31-10 X-TMASE-MatchedRID: 5d5UyYH8moER9y8WJPyXEPp1plqEbuqxCQ3xS+zL6e1/T6JSxYggpS1l xAVVUrr25RlEVaicFdu5NNaj2lpbTo7VvZCLNnEn04Rmz/agfdwHg23OuPl1dLNcuCb8CAxuFll 1gqCkr0N0cjCLkcGjWQ+tU2/Wp19VJXb8mGWA8s/tP6Pv+A+w81AsQ+5PgsP5/1vUyJ9kJXL0K7 ZB8xwtHK44KKsu90SxmSvMlyme0UDsSfhHYXfCBH9NanCUA4VemoKXVHfiMM+D1OfYfymjIwC0e KsJmESJ5q7gfVab4Kl13TkHObNXgRgHZ8655DOPOX/V8P8ail1bCjvvWZW+Sabj/c4OO+6RKrau Xd3MZDWwW8fa2IttjLSrQFM9ByoGsTh04AzaWbwgwS4UHP3CVByNwXiFz51IwL6SxPpr1/I= Archived-At: Cc: draft-wu-opsawg-service-model-explained@ietf.org Subject: [OPSAWG] Soliciting thoughts on draft-ietf-netmod-yang-model-classification X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 12:04:04 -0000 Hi, We previously discussed draft-wu-opsawg-service-model-explained a bit on this list and also at a face-to-face meeting. Since then the I-D has moved on to a -03 revision picking up and addressing comments from the list, private emails, and the authors' gradual understanding of the field. We do not think that this I-D is conflicted by, with, or from draft-ietf-netmod-yang-model-classification (which we understand may be approaching WG last call in NETMOD). We believe there are some issues that would benefit from focused discussion in the OPSAWG. Is there agreement on our separation of models into customer service models, service delivery models, and network/device configuration models? We think that we have the right split of function, but not necessarily the right names for the terms. Can we refine the definition of "service"? There was some discussion of this at the last meeting, and it led us to refine the language a bit, but it would be helpful to have more feedback. Is this stuff "obvious" or is there value in publishing an RFC? Our experience working in L3SM has been that there is a tension with the protocol working groups (particularly BESS) that arises from the equipment vendors being closer to how services are delivered within a network (i.e., by configuring a set of devices in the network) than they are to an understanding of how an operator presents a service for consumption by their customer. Our intention is to make that distinction clearer. Have we got the correlation with the MEF's LSO right? We have heard a conflicting view to what we have written, but we have also heard supporting views. Should we drop all discussion of the MEF's model as it is out of scope for the IETF? Thanks for any opinions. Adrian From nobody Mon Oct 31 05:06:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5983E1297A5; Mon, 31 Oct 2016 05:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 g8NQACdkBW03; Mon, 31 Oct 2016 05:06:16 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C03B1297C4; Mon, 31 Oct 2016 05:06:04 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC61Zf024169; Mon, 31 Oct 2016 12:06:01 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC60vr024142 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2016 12:06:01 GMT From: "Adrian Farrel" To: "'opsawg@ietf.org'" References: In-Reply-To: Date: Mon, 31 Oct 2016 12:05:56 -0000 Message-ID: <00fe01d2336f$239fb020$6adf1060$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIzbq9EP4RJAzxtQQ667SmsQfy/OwAAGHww Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22670.006 X-TM-AS-Result: No--10.724-10.0-31-10 X-imss-scan-details: No--10.724-10.0-31-10 X-TMASE-MatchedRID: eVEkOcJu0F66Tcnzd5LWmZVRzPxemJL0t3aeg7g/usAutoY2UtFqGFUD KcjY0c1Egi3ppCc1OV6suhRwRE1H6WJqIuHqFLYoQVFGg2tr7UVA8JZETQujwmSWOq+2g0h2r5f 9mtOTh3QLXPAHvh6du6pdteqYqu1/3lQT8tdBhBQo0OKLHX2pgZZ6zKu0q4rtfmHrLgoJIlw+Tu GSxNt0+JbYKBhkekeulb+Q8CAqfilYYHiuQEqVVygAQWWdzz5Ft07/cudGAnuynk7TnYzMuoLHC EoCGjCgWZy+62a7b1/KydJIxX/KhRjWaWrUflnejdlx/pD6Y4zEGBoHKd3a+Q+8ritGY4+5nKQg Yq4pRtkhJ/ufappeEpGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPIfiAqrjYtFiSSyPi 8FCwAjNmUIDnUM9ciL5D5uTYEJ9kmq4+YYSdEEX7cGd19dSFd Archived-At: Cc: draft-wu-opsawg-service-model-explained@ietf.org Subject: Re: [OPSAWG] Soliciting thoughts on draft-ietf-netmod-yang-model-classification X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 12:06:21 -0000 Ooops wrong subject line :-( Will re-start thread Adrian > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 31 October 2016 12:04 > To: 'opsawg@ietf.org' > Cc: draft-wu-opsawg-service-model-explained@ietf.org > Subject: Soliciting thoughts on draft-ietf-netmod-yang-model-classification > > Hi, > > We previously discussed draft-wu-opsawg-service-model-explained a bit on this > list and also at a face-to-face meeting. > > Since then the I-D has moved on to a -03 revision picking up and addressing > comments from the list, private emails, and the authors' gradual understanding > of the field. > > We do not think that this I-D is conflicted by, with, or from draft-ietf-netmod- > yang-model-classification (which we understand may be approaching WG last call > in NETMOD). > > We believe there are some issues that would benefit from focused discussion in > the OPSAWG. > > Is there agreement on our separation of models into customer service models, > service delivery models, and network/device configuration models? We think > that we have the right split of function, but not necessarily the right names for > the terms. > > Can we refine the definition of "service"? There was some discussion of this at > the last meeting, and it led us to refine the language a bit, but it would be helpful > to have more feedback. > > Is this stuff "obvious" or is there value in publishing an RFC? Our experience > working in L3SM has been that there is a tension with the protocol working > groups (particularly BESS) that arises from the equipment vendors being closer to > how services are delivered within a network (i.e., by configuring a set of devices > in the network) than they are to an understanding of how an operator presents a > service for consumption by their customer. Our intention is to make that > distinction clearer. > > Have we got the correlation with the MEF's LSO right? We have heard a > conflicting view to what we have written, but we have also heard supporting > views. Should we drop all discussion of the MEF's model as it is out of scope for > the IETF? > > Thanks for any opinions. > > Adrian From nobody Mon Oct 31 05:07:20 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD831297A8; Mon, 31 Oct 2016 05:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 IhoL04opq-nn; Mon, 31 Oct 2016 05:07:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F1312965F; Mon, 31 Oct 2016 05:07:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC7EGN019321; Mon, 31 Oct 2016 12:07:14 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VC7CE8019267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2016 12:07:14 GMT From: "Adrian Farrel" To: "'opsawg@ietf.org'" Date: Mon, 31 Oct 2016 12:07:08 -0000 Message-ID: <010801d2336f$4ee0d6b0$eca28410$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIzb0u3XgEifG9PT1KV0aNna7sPDQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22670.006 X-TM-AS-Result: No--6.130-10.0-31-10 X-imss-scan-details: No--6.130-10.0-31-10 X-TMASE-MatchedRID: byfwvk+IcRleDtEKgt5AZlaOpp/sV5nVeJ1OirYwzAOTMTaQzhvoekay HyAne2M6AQNYtMFCSG3ZFQFW9+fZXLcP6OCfbw/mfh/0N74LJALSde/CNbaZJT3BZApXJkDbwH/ 2ZXIbuaslOQc6UpR7HIf0POOW18UdosJM7VQrKm9v/kcFnp29GDa9tZoo+dDbwxCsHBEjkKBdED 4T8KhgFj3ajQIGPiKqoV/DXcEgCX8OzRGCUqXmentItsHAduPxviRliDV2nyx3vUA6/Pi03J6GQ BATB7RIAHh0mI6GBAPJCvqUi7QmJGResrHRY7dKe7MO8jvmPSzWSrKtwxqWpb0CHtIgSetxFnSf 0Md8O16ahMqmNXa3RXK8/F7lsaDps4k4ZsD2/tUwo+sXt0rns2PIqSS8BzKhmyiLZetSf8nJ4y0 wP1A6AMaUO+wtQNbajoczmuoPCq19MBMm1dYF13za/hkl0Sg3BfbfLtzZL7M9ejzQpreWRl3cJ4 TjkglL Archived-At: Cc: draft-wu-opsawg-service-model-explained@ietf.org Subject: Re: [OPSAWG] Soliciting thoughts on draft-wu-opsawg-service-model-explained X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 12:07:19 -0000 Hi, We previously discussed draft-wu-opsawg-service-model-explained a bit on this list and also at a face-to-face meeting. Since then the I-D has moved on to a -03 revision picking up and addressing comments from the list, private emails, and the authors' gradual understanding of the field. We do not think that this I-D is conflicted by, with, or from draft-ietf-netmod- yang-model-classification (which we understand may be approaching WG last call in NETMOD). We believe there are some issues that would benefit from focused discussion in the OPSAWG. Is there agreement on our separation of models into customer service models, service delivery models, and network/device configuration models? We think that we have the right split of function, but not necessarily the right names for the terms. Can we refine the definition of "service"? There was some discussion of this at the last meeting, and it led us to refine the language a bit, but it would be helpful to have more feedback. Is this stuff "obvious" or is there value in publishing an RFC? Our experience working in L3SM has been that there is a tension with the protocol working groups (particularly BESS) that arises from the equipment vendors being closer to how services are delivered within a network (i.e., by configuring a set of devices in the network) than they are to an understanding of how an operator presents a service for consumption by their customer. Our intention is to make that distinction clearer. Have we got the correlation with the MEF's LSO right? We have heard a conflicting view to what we have written, but we have also heard supporting views. Should we drop all discussion of the MEF's model as it is out of scope for the IETF? Thanks for any opinions. Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. From nobody Mon Oct 31 15:10:08 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F935129B39; Mon, 31 Oct 2016 15:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 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=-1.497, 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 j15nFxnwZ6I7; Mon, 31 Oct 2016 15:10:04 -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 DC691129B3F; Mon, 31 Oct 2016 15:09:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZL05879; Mon, 31 Oct 2016 22:09:55 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Oct 2016 22:09:54 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 31 Oct 2016 15:09:52 -0700 From: Linda Dunbar To: "adrian@olddog.co.uk" , "'opsawg@ietf.org'" Thread-Topic: [OPSAWG] Soliciting thoughts on draft-wu-opsawg-service-model-explained Thread-Index: AdIzb0u3XgEifG9PT1KV0aNna7sPDQAU3AhQ Date: Mon, 31 Oct 2016 22:09:51 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F64353@dfweml501-mbb> References: <010801d2336f$4ee0d6b0$eca28410$@olddog.co.uk> In-Reply-To: <010801d2336f$4ee0d6b0$eca28410$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="iso-2022-jp" 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.5817C133.0248, 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: 3ed5233fc6d0c440b0af74f499ab873d Archived-At: Cc: "draft-wu-opsawg-service-model-explained@ietf.org" Subject: Re: [OPSAWG] Soliciting thoughts on draft-wu-opsawg-service-model-explained X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:10:06 -0000 Adrian,=20 Does your draft intend to cover model for all possible services? Such as Pr= ivate Line service?=20 Simple vanilla IP Internet access services, SD-WAN services, or others?=20 As of now, the draft is primarily on L3VPN services. Is it intended? Or to = be expanded to more? Linda -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 2016=1B$BG/=1B(B10=1B$B7n=1B(B31=1B$BF|=1B(B 7:07 To: 'opsawg@ietf.org' Cc: draft-wu-opsawg-service-model-explained@ietf.org Subject: Re: [OPSAWG] Soliciting thoughts on draft-wu-opsawg-service-model-= explained Hi, We previously discussed draft-wu-opsawg-service-model-explained a bit on th= is list and also at a face-to-face meeting. Since then the I-D has moved on to a -03 revision picking up and addressing= comments from the list, private emails, and the authors' gradual understan= ding of the field. =20 We do not think that this I-D is conflicted by, with, or from draft-ietf-ne= tmod- yang-model-classification (which we understand may be approaching WG = last call in NETMOD). We believe there are some issues that would benefit from focused discussion= in the OPSAWG. Is there agreement on our separation of models into customer service models= , service delivery models, and network/device configuration models? We thin= k that we have the right split of function, but not necessarily the right n= ames for the terms. Can we refine the definition of "service"? There was some discussion of thi= s at the last meeting, and it led us to refine the language a bit, but it w= ould be helpful to have more feedback. Is this stuff "obvious" or is there value in publishing an RFC? Our experie= nce working in L3SM has been that there is a tension with the protocol work= ing groups (particularly BESS) that arises from the equipment vendors being= closer to how services are delivered within a network (i.e., by configurin= g a set of devices in the network) than they are to an understanding of how= an operator presents a service for consumption by their customer. Our inte= ntion is to make that distinction clearer. Have we got the correlation with the MEF's LSO right? We have heard a confl= icting view to what we have written, but we have also heard supporting view= s. Should we drop all discussion of the MEF's model as it is out of scope f= or the IETF? Thanks for any opinions. Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Oct 31 15:50:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8715129B3B; Mon, 31 Oct 2016 15:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 rcstWlp5l8k1; Mon, 31 Oct 2016 15:50:29 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65218127078; Mon, 31 Oct 2016 15:50:26 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VMoI1L018569; Mon, 31 Oct 2016 22:50:18 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9VMoHit018560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2016 22:50:17 GMT From: "Adrian Farrel" To: "'Linda Dunbar'" , "'opsawg@ietf.org'" References: <010801d2336f$4ee0d6b0$eca28410$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F657F64353@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F64353@dfweml501-mbb> Date: Mon, 31 Oct 2016 22:50:11 -0000 Message-ID: <009301d233c9$23f9eb30$6bedc190$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE2BKSlTaj5rRbSLIpZwwM9zdDNfgHenr7qoeyRtVA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22672.003 X-TM-AS-Result: No--2.332-10.0-31-10 X-imss-scan-details: No--2.332-10.0-31-10 X-TMASE-MatchedRID: fgYTp5XatxY4HKI/yaqRm5mug812qIbzbd6rGhWOAwTjsTquy0JRi9sk 0/YgqT9Hed1N9nZ/22uUXobAVGL7/NBefqsuc8HMcFEiuPxHjsVQCOsAlaxN7wpcq1+LTpsUo8W MkQWv6iV95l0nVeyiuDrm2CwlZwVRJ0RPnyOnrZKE8CebufNFW1UJoRLLUVKEWNwrJb5RWWbIxh UoYrjELK4xZn7wURk7SnBQbSnRzIUO9q6rExZiLgFvjf4mUxyu6QKOmoTfdfLoer1EJMvG+yy0e Zxd5bV4FVIZbguNbjQVic9Khd8bxySFgdUD+vyT Archived-At: Cc: draft-wu-opsawg-service-model-explained@ietf.org Subject: Re: [OPSAWG] Soliciting thoughts on draft-wu-opsawg-service-model-explained X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 22:50:32 -0000 Hi Linda, > Does your draft intend to cover model for all possible services? Such as Private > Line service? > Simple vanilla IP Internet access services, SD-WAN services, or others? > > As of now, the draft is primarily on L3VPN services. Is it intended? Or to be > expanded to more? Are we reading the same draft? :-) I think we do give L3VPN customer service model as an example in section 6.3 where we also discuss the L2VPN customer service model work. We used these two examples because the L3SM draft is completing IESG review, and the L2SM working group is just being formed. But of course other examples exist. it is not our intention to try to catalogue all possible examples. Rather, we intend to stablish the terminology and then other work has a reference point on which to stand. So, if you are doing work on, say, IP-as-a-service, you might be able to look at this document and select appropriate terms to use in your work. So the question back to you is "Do the terms and figures set out in this document fit with the work you are doing?" Thanks, Adrian