Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Fri, 20 December 2019 17:18 UTC

Return-Path: <pkampana@cisco.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EF2120875; Fri, 20 Dec 2019 09:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KlP5YQDY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=k8rUeJFg
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 ZFyClXDemLqg; Fri, 20 Dec 2019 09:18:45 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CF8120882; Fri, 20 Dec 2019 09:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4594; q=dns/txt; s=iport; t=1576862325; x=1578071925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=expOafzG4ySvb8SnnC3y8kh5Rt+bK6ZrnTkl7O2Iv88=; b=KlP5YQDY//TD5RhfoisPS1aFJtfrGU98515cBLMq8tMSghBVh0ZAS+VN rXX1zY4F6gR8gxs2AnYfRY5n5lHosedKCZpO9DyVyShm9cpIueVFQBE7w DGrIIZnQouzcD98HNb4f8D6LInqLXoHGIzvC0Sm33UaCLjo8iohLcCt7i Y=;
IronPort-PHdr: 9a23:RZKkdR3arZsDrax5smDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQEU7yKebjaSUSF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DdAQCeAf1d/5hdJa1lGwEBAQEBAQEFAQEBEQEBAwMBAQGBfIFNJCwFgUQgBAsqCoN9g0YDinOCX5gIglIDVAkBAQEMAQEtAgEBhEACF4IFJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDEhERDAEBNwELAgICAQgRBAEBAQICIwMCAgIZFxQBCAgCBAENBQgahUcDLgECoHcCgTiIYXWBMoJ+AQEFhRsYggwJBYEJKIwZGoFBP4ERR4JMPoQzGBWCeTKCLI1HgnGeWQqCNJYzmlWOUZpUAgQCBAUCDgEBBYFpIiqBLnAVgydQGA2NEjiDO4pTdIEokSoBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.69,336,1571702400"; d="scan'208";a="674427903"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Dec 2019 17:18:44 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xBKHIifg019585 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Dec 2019 17:18:44 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Dec 2019 11:18:43 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 20 Dec 2019 12:18:42 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 20 Dec 2019 12:18:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T3RRziGa1z6z0cUrRHRe3apHKgx0QCkmsUSgBW9RVApWYmunBGI2wZJm4nXPa5Ha258NCCDmUaisjEPjZsDJrZBXX/QVcW7SnFjBbRLXl+m+qEXPbm2iMOo5WI5rBo7B5oqfQS9WLJxU+ptRZ0Nt2x4dKe81kBcmSfIHjgOnIObu/P700QfEOVCrZQx75xijod9etPwUTcin4JlkDEDavx7HnMkhdSWUiNtvINYjqDsuKXMAAt0BOS+9fn6Des8jwgmHYTos+dTpK5qEi6BP9vVFstP31/KQrco3ocrnJmckH3Vd+UaF+PdxoP4+H4L9BU+Kre+ezZxJI4seDUbvqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=expOafzG4ySvb8SnnC3y8kh5Rt+bK6ZrnTkl7O2Iv88=; b=KNSts9ESRfn/FFbK/z2R2tjQb+F1+QTFGw63tuEnQUdT1dNmSNFH12+zAyXqvaXkBDNpcHzhrEJc0hWSaqdmj83GR63zMN/ggoM5U2bfHqvuu8U6aYZkkMDzFjRelQg92GtN0fI5M/4X7ozwyF/P7z6zhm567pnKxFhlwu1efm79E7z2f69NTZJ2DXmHjeL+ulBl8gd8+o+e8aC7MlA2HSqdUIWCCyQO3yK2NojySbCZaQWtjYDgHdxfcpO7QehRe8hEaZBSRC2Dh0bJAVEVhFpgm9wM1ugVRVjX1PjhKCtegZ/DCkcX99RtkLmoHs9Ysk5y5YliKy1nu7fcwOSanw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=expOafzG4ySvb8SnnC3y8kh5Rt+bK6ZrnTkl7O2Iv88=; b=k8rUeJFgkqtWk+ocrYnuVKc/XTfAt5T4bqmkr3c+sbFtO/RvVXIGOVR1SXsC8zTFPFRfyf3vp2uLNj/dzpb/cRa1+emWr8UnA6xANFahdS7QXTK/rvN+k4+s1nYa0qIEx+jCXZvs+wCAhUL86Xt6lWZbXNkMI39J0qc/nBW20e4=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2689.namprd11.prod.outlook.com (52.135.245.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.15; Fri, 20 Dec 2019 17:18:42 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2559.016; Fri, 20 Dec 2019 17:18:41 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-ace-coap-est@ietf.org" <draft-ietf-ace-coap-est@ietf.org>, "ietf@augustcellars.com" <ietf@augustcellars.com>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)
Thread-Index: AQHVtmteNYW1qV2WE0en9EAnACcqDKfCd2YggABM1wCAAHy84A==
Date: Fri, 20 Dec 2019 17:18:41 +0000
Message-ID: <BN7PR11MB2547F0C75AACAC52A120933EC92D0@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <157676001842.27446.17022734601869062681.idtracker@ietfa.amsl.com> <BN7PR11MB254701AF4493E907FAE9D156C92D0@BN7PR11MB2547.namprd11.prod.outlook.com> <b8767fda3c19cf7fb00e74e3c7840faf51fe38e3.camel@ericsson.com>
In-Reply-To: <b8767fda3c19cf7fb00e74e3c7840faf51fe38e3.camel@ericsson.com>
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=pkampana@cisco.com;
x-originating-ip: [173.38.117.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3157bd1a-80f4-44ef-6a08-08d78570a950
x-ms-traffictypediagnostic: BN7PR11MB2689:
x-microsoft-antispam-prvs: <BN7PR11MB268980F15CFB2BBB9C88CFBAC92D0@BN7PR11MB2689.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 025796F161
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(346002)(39860400002)(396003)(189003)(199004)(13464003)(2906002)(53546011)(5660300002)(7696005)(186003)(4001150100001)(26005)(9686003)(110136005)(81156014)(33656002)(81166006)(55016002)(316002)(66946007)(64756008)(478600001)(71200400001)(66556008)(66446008)(66476007)(4326008)(8676002)(86362001)(76116006)(54906003)(8936002)(6506007)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2689; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 9+pvWZAYMB5Vl5UGemq4r5GEExMxSrhe6EbUUae9BhuBx6xcROO+fmE68oQ5qXGOQRutVnxYb29D7bNPJhNypsubkO99Nl0vFutYQjarWWKN7Kfd5CrtiAje8XQ6weBTEhK/jwdNE9x7O9CMhIOLQsZ6lBMYs0AM4cl90rZzVhRxOuNhmTOfRt3gslSGHvHb30nP/iLQZFSnaQQNf0ykJ2D5Njjxcs837Y1jB2adDZaskzWoFsv8PXQSzekXVOA+hh11qr/hWYTQVMIyoGvesiVdfpWvzbVIsu+YxgCxMs48B4CVL+jJhTmErp3BfsOxsQsFpB2p0q2scy+tw9tWgXhYZ/xiLJsen6NPuWpxxRSvhZLbHR1RWbIpEbf7byajb7dk0Dg6IQkJbQrOoTkQANEA1gjn9QjQgXC3I14JeBXVqnl8YGS5HYyUyLI8wtT2IA9PLEb7Emdjp5MrXEM/MOehogP3GyIsSAd1kcvD25A0GIwlEuswF0J/YqXbU528
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3157bd1a-80f4-44ef-6a08-08d78570a950
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2019 17:18:41.8086 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OsYZcTqgFFLyeabPDPv0BpvbLwKJ5xuF9uCu+4brM31fZO3GvEvgJsSkzrdX5SeJ+/fUzbB62imPdGXJTdxz3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2689
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/we5kmGAbfTjgcvByH00fAWiz2bE>
Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2019 17:18:49 -0000

Hi Magnus,

I see your point about the confusion the word "support" could cause. Our intention was to make Block1 and Block2 MTI for the server, Block2 MTI for the client and Block1 optional to implement for the client only if it needs it. RFC7959 says " Implementation of either Block option is intended to be optional. ". So, I think it makes more sense to replicate this language instead of support. We will use "implement" in place of "support" in our draft.

Regarding what happens if a client wants to send a large request and it has not implemented Block 1, I don't think we should define that in our draft. RFC7959 says when you see a Block message you MUST process it or reject the message. It does not mandate what the sender application does if it has a large message and does not have COAP Blocks implemented. The right behavior in this case is to depend on the lower layer protocol. So if COAP does not support it, then IP. I do not think we should interfere with that in our draft, it falls in general TCP/IP layering.

Does the above sound reasonable?

Panos


-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of Magnus Westerlund
Sent: Friday, December 20, 2019 4:34 AM
To: iesg@ietf.org; Panos Kampanakis (pkampana) <pkampana@cisco.com>
Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org
Subject: Re: [Ace] Magnus Westerlund's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS)

Hi,


On Fri, 2019-12-20 at 05:01 +0000, Panos Kampanakis (pkampana) wrote:
> Thanks Magnus.
>
> > The EST-coaps client MUST support
> > Block1 only if it sends EST-coaps requests with an IP packet size
> > that exceeds the Path MTU.
> >
> > I think the requirement for when Block1 is required to be supported
> > in the above sentence is unclear. Is the intention to say: An
> > EST-coaps MUST support
> > block1 to be capable to send requests that would otherwise result in
> > the reliance on IP level fragmentation?
>
> Yes, that was the intention. We will rephrase it to say
>
>    [...] The EST-coaps client MUST support
>    Block1 only if it sends large EST-coaps requests that would
>    otherwise result to IP layer fragmentation.
>

Is it support or use block1 when the request is to big? I think the combination of support and only results in uncertainty towards what the implementor. Based on this reformulation I have the impression you want to make the implementation optional if the expected EST-coaps request size is less than what the IP MTU can send without fragmentation. However, that leads me to ask what is the behavior of a node that suddenly are faced with a request that is larger. Refuse to send it with an error or still rely on IP fragmentation? There is always the potential for a request being to large unless implementation support of block1 is mandated.


Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------