Re: [core] Comments on proposed changes to draft-ietf-core-http-mapping

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 20 April 2016 15:42 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA22512DA61 for <core@ietfa.amsl.com>; Wed, 20 Apr 2016 08:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.596
X-Spam-Level:
X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, WEIRD_PORT=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 uMf9QSEUO1BS for <core@ietfa.amsl.com>; Wed, 20 Apr 2016 08:42:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981B812E628 for <core@ietf.org>; Wed, 20 Apr 2016 08:39:54 -0700 (PDT)
Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUkxk-1bG4Ko2f3k-00YDWI; Wed, 20 Apr 2016 17:39:34 +0200
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, Carsten Bormann <cabo@tzi.org>, "core@ietf.org WG" <core@ietf.org>
References: <36F5869FE31AB24485E5E3222C288E1F5BAA8E0E@NABESITE.InterDigital.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5717A2BA.3020404@gmx.net>
Date: Wed, 20 Apr 2016 17:39:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BAA8E0E@NABESITE.InterDigital.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qqg9q0L3oTnBka06gCHhS5IWHAXBpwRuv"
X-Provags-ID: V03:K0:u2+f7c0uvH9IsTn7X0eIUSbpYHVNaVJEnvnyqeYyiu7V6DAck2o /Hcs1bxM/h8UShuWtE3Ue8Xn/dInFAnoBAj58SfSJWtnWeir8p/kC4oV78/qyfCEkgDiuBs uY78eOwU9wl96VLpYL+gy2KCj4gWYi8MRFZmzvMypAaXkjLz85x1jyUTSFiiktFg+uAF6fs 7PAM0vhyAv59Ttqj2GICQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:BiCRVasECZo=:8RHWIw5qaVsd5HqlLg7sDR CkdggThD2WdH9eE3x2O3waO4XJujmEBuaEiMYeopHkIF3e0RdsnP+unp0Sqbkj+ECBuqE+CiH Hw43l1iqkj9L4YLsPWKO8AVHatjgmkolmO4x4OyvmHCgQ4JENto99ZzqipW4KfxszYwwBDpDu 5k1jOe8FKtkSUXdHXMo0QzT4yAspgXGHPhLR/NzIspIwVULMBj6oPDlwFmcKj+3XYeMt+0XpW ORY53PDq6jWY5MXX1LxUReVecwfcck+REw7Iilj3B/rH4NX7swWCgvwfyXf9fIHw5QaAB33Z0 v4WTmNtjDvZmNsm1fEVBwppkrsZUB1afgH74T54RT8jtC8yt2V/uLTix0xTtVms9NqWmueW4C WnZceaczPAGcL2Z9oH6p9LJUz4spnChd7YdHU2L2Z7aE6O+8oaS+lcpkBLK8mqIIPHMX0G3oG 3guVIgBpxedrJYWnr9NQeL8ZUGN4JZ8Tondz3VjOKgKZfzMSLVQ4EEKJGCPr9vtCJynd/iM+X PNLY89FUrXta9xgXXiPsvClqoH/4EeIggGgxRWqqxoazBP/eQlaZp91YK9RXZ1hAyndcehhAS Yu5TLU6F7n6PnylBlaBChWpLBm2W4lJz64K9zoSxHBhfzXdjmajfQDKS9lLnkxGJuBcg7dG7b rFRxsQDc4pKdxIo/0dSJ8bAuXekuX1NxrxY3I8+jaYmvXBdj6FeGZ0ChzjQMNczjMeT0g1T9u 2ybHPs2JMh6DVhilaSVcgGJJNIBaKDG5ucjiJFsfrFuvD4PdEbnApkdx8AI=
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/9zJujbjJX9nB2hvs18YhHG6GP98>
Subject: Re: [core] Comments on proposed changes to draft-ietf-core-http-mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2016 15:42:46 -0000

Hi Akbar,

changing the scope of the document to include forward and reverse proxy
functionality, as discussed in BA, is fine for me.

Ciao
Hannes


On 04/11/2016 10:27 PM, Rahman, Akbar wrote:
> Hi All,
> 
> 
> At IETF-95 (Buenos Aires) we discussed modifying draft-ietf-core-http-mapping to:
> 
>        Clarify that the scope of draft is primarily Reverse HC Proxy but that it also covers generic protocol translation aspects that apply as well to Forward and Interception HC Proxy
>                ■ e.g. Response status mapping & content format mapping apply to all types of proxies
> 
> 
> Specifically see pg. 70-71 of the F2F presentation slides that presents the details of the proposed changes:
> 
> https://www.ietf.org/proceedings/95/slides/slides-95-core-0.pdf
> 
> 
> We had good support during the F2F meeting to make these changes.  Does anyone have any issues with this approach?  If you do please write back to the list.  If we have not received any comments by April 22 we will assume that this decision is supported by the WG and will proceed to make the changes so that we can start the new WGLC.
> 
> 
> 
> Thanks,
> 
> 
> Akbar
> 
> 
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: Saturday, April 09, 2016 10:00 AM
> To: core@ietf.org WG <core@ietf.org>;
> Subject: [core] Summary of second meeting at IETF95
> 
> ... and here is my summary of the Friday results.
> 
> Again, please send in fixes and additions; the raw details are still at the same site: http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core
> Big thanks to the note takers!
> 
> On Friday:
> 
> * Handoff of the Baton: Barry Leiba gave his farewall as CoRE's
>  responsible AD; great applause of the WG.
> * For the resource directory (RD) and related documents, we are aiming
>  at WGLC before July 1st so we can discuss the outcome in Berlin and
>  ship soon after.  There are quite a few things to do, many of which
>  are on the editorial level (see slides, but also Akbar's "advanced
>  RD" document; we will not try to put mirror server/pubsub support in
>  the RD document now, though). The issues will managed on the WG
>  tracker.
> * There was in-room consensus to adopt draft-vanderstok-core-etch-00
>  as a WG document.  This is needed to keep PATCH in the RD, but also
>  for the management work (below).  To be verified on the mailing
>  list.
> * core-links-json also is in the same cluster (WGLC before July 1st).
>  Hannes would like to see the RFC7390 parts separated out from the
>  RFC6690 part that we are about for RD.  The TODOs in the document
>  need to be ticked off/trackerized.
> * There will be a 2nd WGLC for core-http-mapping after the comments
>  are incorporated (-10).
> * core-interfaces may have been adopted too early and requires a major
>  overhaul, separating out the more speculative material (some of
>  which is T2TRG material).  It should be made very clear that this
>  describes one way of using CoAP (which has indeed been picked up in
>  various ways by other SDOs), not the prescribed way.  Matthias will
>  help Michael to do the separation.
> * The work on management of constrained devices has converged ("COMI
>  with COOL").  The yang-cbor draft is ready for an adoption call, but
>  not enough people had read it yet to do an in-room adoption check.
>  The other drafts will undergo merger/restructuring work based on
>  this week's discussions and should then become ready for adoption.
>  This work is explicitly covered by our charter (which also calls out
>  LWM2M management as a related approach that we will continue to
>  support as needed), and we will implicate NETMOD/NETCONF into every
>  step we are taking.  The author team invites the WG to its bi-weekly
>  phone meetings (to be announced on core mailing list).
> * The work on Object Security for COAP (OSCOAP) is progressing nicely.
>  A complete draft can be expected for Berlin.
> 
> 
> Grüße, Carsten
> 
> 
> Carsten Bormann wrote:
>> Here is my summary of what we did on Tuesday.
>> Fixes/additions welcome; details are in the draft minutes at
>> http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core
>>
>> On Tuesday:
>>
>> * Andrew indicated that he plans to step down as a WG chair and that
>>   the ADs are looking for a replacement.
>> * As periodically, the AD is changing; this time from a graybeard
>>   (Barry) to a blackbeard (Alexey).
>> * The chairs apologize for the infrequently updated milestones; fixing
>>   them is up next.
>> * draft-ietf-core-block–19 is in IESG Evaluation, telechat date is
>>   2016–04–21.
>> * heads-up for new individual drafts: draft-kivinen-802-15-ie and
>>   draft-bormann-6lo-coap-802-15-ie.
>> * CoAP over TCP received extensive discussion.  Results (all to be
>>   confirmed on the mailing list):
>>   * #396: We revert the decision in Yokohama and go with alternative
>>     L3.  Procedurally, the pain of this reversal is balanced by the
>>     reduced pain of not having to convince OCF to change their
>>     specification.  Technically, L3 is more open to evolving ideas about
>>     message sizes.  In any case, there is no intent to modify or
>>     revoke section 4.6 of RFC 7252 at this time.
>>   * We will need to examine the various proposals to add signaling to
>>     the TCP connection (settings, ping/pong, release/abort).
>>     Signaling messages (7.xx) is one possible mechanism for doing that.
>>   * #387 (ALPN): We really need to make a decision here.
>>   * Websockets: For merging the websockets draft into the TCP/TLS WG
>>     document (with the websockets specific parts going to an
>>     appendix), the authors of both drafts will discuss the merge.
>> * Multi-hop Security: Initial discussion of
>>   draft-hartke-core-e2e-security-reqs.
>>   * It is more well-defined what is being protected in a
>>     request-response that spans a proxy than with a pub-sub broker.
>>   * The current set of scenarios does not include the case that
>>     security services are being performed by the intermediary.
>>     Many such scenarios are conceivable; which ones have serious use
>>     cases?
>>   * Multicast (or, more generally, group communication) is not yet
>>     being considered.
>> * Data Formats: WG to adopt SenML (to be confirmed on the mailing
>>   list).  After a bit of Brownian motion, the WG is now happy with the
>>   way the data is formatted in -06 (base record with data, zero or
>>   more records with more data).  The addition of links in the data is
>>   to be done by registering a senml label in core-links-json
>>   ("reversing the arrow of dependency").
>>
>> Friday meeting upcoming.
>>
>> Grüße, Carsten
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>>
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>