Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 25 September 2018 09:40 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F12713127B for <netmod@ietfa.amsl.com>; Tue, 25 Sep 2018 02:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68ZHzkgTH4iJ for <netmod@ietfa.amsl.com>; Tue, 25 Sep 2018 02:40:14 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63DD131274 for <netmod@ietf.org>; Tue, 25 Sep 2018 02:40:13 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Y6E/BajCw2c2KDIyUMu6GncPN6McKsi7ixEheGpKrY3ENzImrG84nShR0TAzktOQbZN+5WHWforlMyEjWSKD9f3fDeKOoGMQDv0RuIhohDrzMv74CRVy5bgZzxWWuMxWorHf1qjUSBKD3pVzm1qqJqdNId74AUxEqyiK223iZd8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 10629 invoked from network); 25 Sep 2018 11:32:30 +0200
Received: from mue-88-130-61-126.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.126) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Sep 2018 11:32:30 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <E957D368-88BA-442F-AB7F-F8464847C719@gmail.com>
Date: Tue, 25 Sep 2018 11:32:28 +0200
Cc: netmod-chairs@ietf.org, Kent Watsen <kwatsen@juniper.net>, The IESG <iesg@ietf.org>, netmod@ietf.org, draft-ietf-netmod-acl-model@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <53A51142-7568-473D-B309-E3A86459B5F9@kuehlewind.net>
References: <153753763758.7269.9597830616255329217.idtracker@ietfa.amsl.com> <E957D368-88BA-442F-AB7F-F8464847C719@gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180925093230.10620.83959@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/m6YDrOnzcVBC1-rotiRilvP5m34>
Subject: Re: [netmod] Mirja Kühlewind's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Sep 2018 09:40:16 -0000

Hi Mahesh,

please see below.

> Am 25.09.2018 um 00:56 schrieb Mahesh Jethanandani <mjethanandani@gmail.com>:
> 
> 
> 
>> On Sep 21, 2018, at 6:47 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> 1) The tcp options element is type uint32, however, the option field in the TCP
>> header can be up to 40 bytes.
> 
> You are right that the options field can be up to 40 bytes long.
> 
> To the WG - We have two options in front of us. Take the field out completely or change the type to binary, and add a ‘length’ restriction of 40. Unless there is a objection, we will go with the latter option.

Not sure what exactly you mean but change the type to binary and add a length restriction but I’ll leave it to you to have the appropriate change.

> 
>> 
>> 2) Why are only TCP and UDP supported? What's about SCTP and DCCP?
> 
> There has been no requirement to support either of those protocols. Support for those protocols can be added as augmentations to the base model in the future if such a need arises.

That’s do bad. However, the document must at least say that it’s scope is restricted to TCP and UDP only and it would also be nice to reason why that restriction is and what would need to be done to extend it in future.

> 
>> 
>> 3) The icmp rest-of-header can also be larger than 4 bytes but the type is
>> uint32 again.
> 
> You are right that the rest-of-header can be more than 4 bytes, but in reality we have not had a requirement to support more than 4 bytes. 
> 
> To the WG - We will give it the same treatment as above - two options. Take it out completely, or change this to binary also. The only difference is that there does not seem to be a length restriction on the size of the field, so the field will be left unbounded. Unless there is a objection, we will go with the conversion to binary option.

Again, leaving it to you to apply the appropriate fix.

Mirja



> 
> Cheers.
> 
>> 
>> 
>> 
>> 
>