Re: [Softwires] Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 10 January 2019 19:07 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE34130F81; Thu, 10 Jan 2019 11:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu
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 DCpUuK1jnqOg; Thu, 10 Jan 2019 11:07:21 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72504130F2D; Thu, 10 Jan 2019 11:07:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s17M/4tHHWIQowK6U1XtGvSXDdX5YGvmhXOJMSCrYJc=; b=i+APD2g2/aBli4Wnj/VqNl7CZxueNCtECjAEx+gjvsQw/7oYrjVFexXqlyS9sGZcywebHWNOSVCcEoXxDg8MADaD28lHhXBGYoGU1mrfnxbx0b3mjRFiyPPT6x90ufs04CEC5LZLeOxdMwicdxuveSTsBZYyFg3PfXNd6QTGuck=
Received: from DM5PR0101CA0003.prod.exchangelabs.com (2603:10b6:4:28::16) by CY1PR01MB2028.prod.exchangelabs.com (2a01:111:e400:c60e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.7; Thu, 10 Jan 2019 19:07:19 +0000
Received: from DM3NAM03FT029.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::202) by DM5PR0101CA0003.outlook.office365.com (2603:10b6:4:28::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.16 via Frontend Transport; Thu, 10 Jan 2019 19:07:19 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT029.mail.protection.outlook.com (10.152.82.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Thu, 10 Jan 2019 19:07:19 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0AJ7EGA024447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jan 2019 14:07:16 -0500
Date: Thu, 10 Jan 2019 13:07:14 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: mohamed.boucadair@orange.com
CC: The IESG <iesg@ietf.org>, "draft-ietf-softwire-yang@ietf.org" <draft-ietf-softwire-yang@ietf.org>, Sheng Jiang <jiangsheng@huawei.com>, "softwire-chairs@ietf.org" <softwire-chairs@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
Message-ID: <20190110190714.GP28515@kduck.mit.edu>
References: <154697630513.25490.16268435481165618838.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E0642E0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E0642E0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(346002)(39860400002)(376002)(396003)(2980300002)(189003)(199004)(55784004)(51914003)(72854002)(7696005)(4326008)(23756003)(356004)(305945005)(86362001)(76176011)(11346002)(229853002)(446003)(6246003)(6916009)(33656002)(345774005)(186003)(567974002)(126002)(75432002)(2906002)(1076003)(50466002)(246002)(966005)(8676002)(47776003)(336012)(58126008)(54906003)(478600001)(106466001)(5660300001)(14444005)(486006)(786003)(8936002)(26005)(6306002)(55016002)(956004)(2870700001)(26826003)(2351001)(36906005)(316002)(476003)(88552002)(104016004)(426003)(53416004)(106002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR01MB2028; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT029; 1:bOLAXnNiWdwa4p+1aMA7EHYs/nArG4fASWq/Qm+RpaTz6qqrOCIDGyMr7VzC3y0VHlEsktUGW98k+kEW09LIbOM2uHnen4WaBnnyA8kursPz7gOVRxx0hNCt24KhzUSL
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 105609bb-593c-4620-d498-08d6772ed7fe
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:CY1PR01MB2028;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2028; 3:LPME2843epWY2rK7UmcfHUewXwCQmPrQDPYAL7F28WeT94X0YI9FJDgmQ7gmnYOwYdY9LKpYs2wRMimvDaIBk1DvHkHv6O7TFg3J0Gu7zRFHAn1In3Xy55FmeHQ3toAL9JC8C+nyzp6HHMvTUfQBoXJyhog1yEx2NeF6ZATNrkK8OAdQ9kmWeYJnnFdlIoHruFNykEWRiHR83XWRVurQ/WdyL+qHOMFpx+pptE8UllF8g2hMWJZAXxIqiCDmLia/sW3T3FJc+6X+c6VThzmOc+sENaSIA8g+sLsONlpZjsy3yWre7kIlnQ11noJejQJuxK/6rhNVxAtBouL5Z9vzzRswTCSjeOk2QxUXkASPx8RRHqz0VmIYB7jlVojif4Si; 25:LQPAzEbb0ghQUqQ2Z18243nLz16tjIW8EETnburWI9rQgF6zWM/TMPCitHyEaYhQoJgt3EveVXFKIFwmPlXDpEhiCJjmo8dsg4S7m2jAhueuEgU3WEpMJWJYbu0bqehiEX7DMu+8A0PPSuIH8Hvhel0ghULhjxqYzl1eZKxiPjexdAd+WvtzweNb9yNGqJpXaU8ZvXcIbDnoF++gVhR/SHqM6YRNw4TdhhbOGBJ4cNoF8cJ3YM33tafIzVBAU0CfXgyyWlTe5jqUxiFcGErClaitCV6SDuVFKvPYMCxMlgRG9W5kbkDKqbr4B3s+YFbBwLAT8EDPpzSVHcpLnrfP8g==
X-MS-TrafficTypeDiagnostic: CY1PR01MB2028:
X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2028; 31:rrn6p4xLcnsZk7k2R78i5+dpO+yf2qVo/cSllCRSzmIj5zRqdNRByJlqGswtqXYdfTv+LRX+5SS6gkm93b7FD6sG3ttuNWvfoaJJhDkvQ/sG5l6bn+R7BqfyzPha/ZOgQDQP/2YGb1sPgraCdzz3Dn5L6Msv2Gxkd+vTYzuFtbvapSc/woPR6WiFttKilWSW3z8m53tdkv0J7nyYUVIR4PDfhxhhfRXybBdpWenLSnQ=; 20:nPHvTeedAjclRLs+9qWu5N5yQp3OB519f/63c+tmpqpsRRhJsPWj6BOASUqw+eKsQpCM78cOiYlzYzFdxqbTeT5bIBqlEPkWJIMEZG9NZeWEwaPN7dLRCHw4u6IDIiEAnr2ZEcHsPgu7CNaO6TyS0CrWtOCbhK065FwKCYxPFX3aMjBRz1yEy/ydPIrMmwN/5x8RBzAyoVJPaaGgMTwdV0/jFM/iqrKCyHUZcOSScL7tC4gNAhn6IduRP0F3LECZ0Fc9Qxxz3hP1TfTqA4b3tzJsCCMFk3r9FMXkeP6mZg0K3D7twgWa/JCjE8M8X0ibdgLRplvkavEPKs1w5h0bye3LH5jYAad2WHR+kTiqCqsLbEOT0CB084wgnnKF+HaAmXh5MC6w61JrF1e3c04Il+6kbATanV0zJm/67a4aQFQUSKqVhIMAXr936KCKXYWgXQmG1fRaFVAGq0DcMwscVdOQarjjeajW4iNsRY5M12emuPeTS6pteO20ujOZRH0l
X-Microsoft-Antispam-PRVS: <CY1PR01MB2028A0000CA0CC557BFE96D0A0840@CY1PR01MB2028.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2028; 4:S6NSCqVnT4jhtOUndbXjnUMa62yTQzIZb4Uv8/54xO8NZyvNm4QiK3AzHPYGxhn4vtFMJ70MA9xSH4jOACWua2O1Ao7Xb9rFgFmVldnU3VwzgycPgbzy/r5PxcmrQrT+ETnAD5ikqMZxp4Cs61hllwmxy4xuAGHkIy/k/FCaoLpr8JtBOfA9oyvChPgPD3LA+eOmuWRzUKF3TsGbpykhCovS0sIvv/vq6N2HmCcBqs9vGX2+YdrXACZIX0LyAn4PBjSn0mj9Oh5I0fTvhtRHiyWRMbIq3/QD9x5FOegOINtS1475sFgbxnKp6f+q9rQn
X-Forefront-PRVS: 0913EA1D60
X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2028; 23:eROXZKhwPOTJYBdqGehOith3ekydXiOXjMvF3XGBok6pS39IcsO/9U08jt+5qoiaBqZaJ4dHvKDtcblTQ7ZXBzxdropU03zORk2XnL1bGHfEiPeLz91JdQ8mPO3CklR7DN2IjvoNgEzOT82W0qbNC9+PNrlsNzMIPYAMTb7HJhZg2GiOFV6JoTeHyAN9Qd9yPI94+s6lNd+KBCgZ1la+5ZWZGmviY+6kwodgWWzmI/6yil1tV/+gNluBZbLpg/qp98XUk3KHdr7r10OIf+v6ddAlTi7j/oLolI7zlW74Ju/RrHVk3x0INtoMLkGA4JKMi+3Baia/7F3oExoqY0YEIPIfHoYT5pgVFsJhdtKCiFq+CWkzlKojDgobDz03v9Hg7aihkvANufb1k+x9/ccqJnFu7+rolR8TUDAOHazzCd6lsQJ8ywSUYrBt6H8mIzoJYDBXhOZyxx7d13rfIsWIOMJ7eEs3hncGD025vxBXwlBeEVun5Qd5ySH9N7YwNFNFDGE3HhSwsS4SiLcJULQvGJY0PCOZ5194QIReFicV7WdUcCytf0fg5B+EnaFOWh4zG0kSkOGs+42C/ARbbkuMrhZtjTZO9Eb9ZiZU6tclFiziOgPXMxr+Ll4zh6KsBtb4cNbvp7R2si+4ICKvGyniyg4KU86o4e1OvFTmHU10qxWR/m15HbkjjwgDIFb5kVNzYNwVcZnDoZxPh+tP4Zc2pFeARe07qDBhnPXgILJFw18dRbJHA5VeqRdbjODpTfCkf9uEK2iibUhnFWcqkJkCR254LqUg5savIiaxn+GR6iFlPRuX39mafkqU6aIagFoAnygiZdF96j3I36zLKR022iTA3PSo/vCnFLbm3TuLC13LYMVyDMuujVJBPXs+1EsVOXxSvSbTWQIsS3vb1mGys/UJZHhPV5qW71oBjflw+oN8LiAWs6tOLGRfqsBH0Q8EbOGElP7fc5ltFjaHe9Ajv9fKK7AaX7+VlQ4jFtfZ6HL1HfvGqr9nIxcXU0ufzBmY0tEYltH3Q31qN3+1phaW8uqjpbhNLX7URn1aKemt11KC72mQGxJ7SzGpmFxyLelLQ2KcJRW1QPnBsIAj5tIatdFM0b/3PEsGDO5SLN6eCOsLkD2Gk/plIqyXHg/cWcJIaLz5/L0WdqhmgmoURZUgW1n17Z4OZ8A9Gk68K/L6ruwV9iVR8kSLUoSEOzQnOSOASPxyxyB9lq93dZW6rSWi3gVa+xbWaT8L3qQtHD5lLIup9ozBFtlN7o4EMzaJHkDZ8Qrxqsy23kv9ndF/9K8GHFqgEK0/RfDRzNU1/me01A86rgAHufTpqnPXRK77zh4B+xjz0jU35tRuUMM8IlZPKA==
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: FOJxCljPA2/4aTI2jXY99E2oUdVcEE5zYdZ/j/04/ojD9VsDI6/9CukL+bxjodzha7M2i6S2BOf5R5dbQN7lHLzPxWTj3/Fx1ctHJU+HVuq5sZyuf45TTDcJvg3Sv0L3Ptguxf270j5DdW4q5ZrpL9BTRFgqmT704H5sbbAtP/Yr05q93mDGoAz1SzG76+xJZavPWw4ADvKgTknGRPfxl5vVDiwh2hcK0FNrZZd6PB5+1jJnU9iZAxtQedJQqpxxKh2FG+Y0BimlBhK+7NXsF2X5rCD9xbq0F+QLWd/qGQ2l9EQr8GUmf9qqr47PC7EZ
X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2028; 6:d/Q9GnCjzbivRX95+xa6J8ktS8fr8imWgejGAUVKCbUQ9SIVmdlctstkqEUksTLA/HDfPJuFglSzUy6QUhkSWRu8TNdsAeYwIe/pDstiqZiADCVdXSZ9VqIonisNFjobHgRZ9Ru5js8AlXNrRCIHCgS9suLILMBfitvqeCAka7t9jjq9bKo2G+gl4PXWd01mYgmOpQHNPHzvZlnxtNjCAh6V4f1smXfGvx7NzkcMOM04gs2+uDlnldCqrX+v1hmFZvdTNBFpdGNhYAjYpNAzZiTRULd2LG3PNtflP6eEiBImWkBjrgsfkUWdRVYRrYKs4Cukaj1499U4lFl8blxtYh3pQV9DZ2lrDng1ZF3pB4NDHIKK2LpdOesPreCumbQlnZr9MTzyt5W6WX4UHha5vrJZ1cpyN0yQBO9PEFwahtrjVfxMr+ep4ZGakhGfkTtzcwTwGY2DsLCSKBsUUPJAOQ==; 5:MtnKcv4aWY4lStShesdCtx/oPh28jh/LWs6iRt5wVUJ36z4M5ggJ0ooHOyuPhWAozuOok0SyrTA/u/prI9vLqHyHjr9rdV57YWELd9AFb5beWgcuXgZOLVmml1lnNVs1TTxPXcV5FrNfny2/ID86G7H9tURLwWzph9UqzxvFzLPzXCJSlySahWMIH8YbmKPYX9Mhy4SaJirr0MUK/w0PEA==; 7:cB8IYWAdHRq2WPy9BY4W3t1uzERKeIK2qQ/Hmi2+zXiz8WI4+qZSLSOGmGHsmI06cbgiWMtjGtk7LxiZ16q+Arw25TTG/lxU+L4E2yAwbStrnq9/1Lk6MpYqAcY/UL26QCNxwtmqpq93dldTHvG02g==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2019 19:07:19.0037 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 105609bb-593c-4620-d498-08d6772ed7fe
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR01MB2028
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/JeN7tNC4OHTRZL0zasoIc5wANBU>
Subject: Re: [Softwires] Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 19:07:24 -0000

Hi Med,

On Thu, Jan 10, 2019 at 02:08:02PM +0000, mohamed.boucadair@orange.com wrote:
> Hi Benjamin, 
> 
> Thank you for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> > Envoyé : mardi 8 janvier 2019 20:38
> > À : The IESG
> > Cc : draft-ietf-softwire-yang@ietf.org; Sheng Jiang; softwire-
> > chairs@ietf.org; jiangsheng@huawei.com; softwires@ietf.org
> > Objet : Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with
> > DISCUSS and COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-softwire-yang-14: 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-softwire-yang/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > This document has 7 listed authors/editors.  Since, per RFC 7322, documents
> > listing more than five authors are unusaul, and seven is greater than five,
> > let's talk about the author count.
> > 
> 
> [Med] Will leave this one to our AD. 

And he has done a fine job with it!

> 
> > The binding-table-versioning container's "version" leaf is of type uint64
> > but the in-module description indicates that it is a timestamp.  If it is
> > actually supposed to be a timestamp, then the units and zero time need to
> > be specified, but it seems more likely that this should just be described
> > as an abstract version number, if I understand the prose text about this
> > container correctly.
> > 
> 
> [Med] Thank you for catching this one. 
> 
> There is a copy/paste bug: 
> 
> OLD: 
> 
>             container binding-table-versioning {
>               description
>                 "binding table's version";
>               leaf version {
>                 type uint64;
>                 description
>                   "Timestamp when the binding table was activated.
> 
>                    A binding instance may be provided with binding
>                    entries that may change in time (e.g., increase
>                    the size of the port set). When an abuse party
>                    presents an external IP address/port, the version
>                    of the binding table is important because, depending
>                    on the version, a distinct customer may be
>                    identified.
> 
>                    The timestamp is used as a key to find the
>                    appropriate binding table that was put into effect
>                    when an abuse occurred. ";
>               }
>               leaf date {
>                 type yang:date-and-time;
>                 description
>                   "Timestamp of the binding table";
>                 reference
>                   "RFC7422: Deterministic Address Mapping to Reduce
>                             Logging in Carrier-Grade NAT Deployments";
>               }
>             }
> 
> 
> NEW:
> 
>             container binding-table-versioning {
>               description
>                 "binding table's version";
>               leaf version {
>                 type uint64;
>                 description
>                   "A version number for the binding table.";
>               }
>               leaf date {
>                 type yang:date-and-time;
>                 description
>                   "Timestamp when the binding table was activated.
> 
>                    A binding instance may be provided with binding
>                    entries that may change in time (e.g., increase
>                    the size of the port set). When an abuse party
>                    presents an external IP address/port, the version
>                    of the binding table is important because, depending
>                    on the version, a distinct customer may be
>                    identified.
> 
>                    The timestamp is used as a key to find the
>                    appropriate binding table that was put into effect
>                    when an abuse occurred. ";
>                 reference
>                   "RFC7422: Deterministic Address Mapping to Reduce
>                             Logging in Carrier-Grade NAT Deployments";
>               }
>             }

Ah, a very easy resolution -- sorry for missing that it was just a
copy/paste issue.

> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Please expand CE on first usage.
> > 
> > Section 4.1
> > 
> > It feels a little strange to put something as generic as
> > /if:interfaces/if:interface/if:statistics:sent-ipv4-packets in the
> > ietf-softwire-ce module.  Are these counters likely to be useful for other
> > (non-softwire?) tunneling techniques?
> 
> [Med] Some of these counters may be applicable to some other tunneling techniques, but not all of them. As such, these counters cannot be considered as generic. 
> 
> If in the future, a YANG module is to be defined for some tunneling technique and similar counters are also applicable fro that technique, that module can use the traffic-stat grouping defined in draft-ietf-softwire-yang. 

Ok.

> > 
> > Section 5.2
> > 
> >    o  softwire-num-max: used to set the maximum number of softwire
> >       binding rules that can be created on the lw4o6 element
> >       simultaneously.  This paramter must not be set to zero because
> >       this is equivalent to disabling the BR instance.
> > 
> > This seems to leave it ambiguous whether a server should reject an attempt
> > to set it to zero, or accept it but diable the BR instance.
> 
> [Med] The text is clear, IMO. Furthermore, the range of allowed values is called out explicitly in the module: 
> 
>             leaf softwire-num-max {
>               type uint32 {
>                 range "1..max";
>               }

My apologies, I must have found the wrong place in the module -- I thought
there was not a range specified.

> 
> > 
> > Section 7
> > 
> >             leaf enable-hairpinning {
> >               type boolean;
> >               default "true";
> >               description
> >                 "Enables/disables support for locally forwarding
> >                  (hairpinning) traffic between two CEs.";
> >               reference "Section 6.2 of RFC7596";
> > 
> > Is a global toggle sufficient or would there be cases where more
> > fine-grained control would be needed?
> > 
> 
> [Med] A+P is designed to reduce as much as possible the per-subscriber state at the network/BR. Requiring fine-grained control would require some extra state to be maintained, which is not desired. Having the general parameter is sufficient.

Okay, thanks for the explanation (and no need to cover it in the document
itself).

> > Section 8
> > 
> >     container algo-versioning {
> > [...]
> >       leaf date {
> > 
> >         type yang:date-and-time;
> >         description
> >           "Timestamp when the algorithm instance was activated.
> > 
> >            An algorithm instance may be provided with mapping
> >            rules that may change in time (for example, increase
> >            the size of the port set). When an abuse party
> >            presents an external IP address/port, the version
> >            of the algorithm is important because depending on
> >            the version, a distinct customer may be identified.
> > 
> > nit: "abuse party" is probably not a term that everyone is familiar with.
> > (similarly in br-instances)
> 
> [Med] We used "abuse" in reference to what is discussed in RFC6269 : https://tools.ietf.org/html/rfc6269#section-13.1. We may add a pointer to that section if you think this is useful. 

I think "abuse" is fine, it's just the combination "abuse party" that is
unexpected.  If we want to indicate "the party responsible for abuse", it
may be easiest to just use that descriptive phrase rather than trying to
coin a compound noun.

> > 
> > Section 9
> > 
> > Is there any possibility of a situation where the
> > invalid-/added/modified-entry notifications cause a substantial amount of
> > notification traffic (i.e., a DoS level of traffic)?
> > 
> 
> [Med] This is in theory possible if the BR is under the control of a non-authorized/misbehaving entity. The DDoS can be softened by defining a notification interval, but given that this interval parameter can be disabled or set to a low value by the misbehaving entity, the same problem will be observed.  

Probably worth a mention, then.

Thanks (and I'll go clear my Discuss now),

Benjamin