Re: [Tsv-art] Tsvart last call review of draft-ietf-roll-useofrplinfo-25

Ines Robles <mariainesrobles@googlemail.com> Fri, 17 May 2019 09:34 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7E3120059; Fri, 17 May 2019 02:34:38 -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=googlemail.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 dlOlQYMYuSW5; Fri, 17 May 2019 02:34:36 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 CE5D212006A; Fri, 17 May 2019 02:34:36 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id e184so10964685ite.1; Fri, 17 May 2019 02:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UlkOzrRhQZDa9eJ21oFrioajvTWPHIKuWzKtIgCumzE=; b=EpXCb9avLapVOCDv5a3cKeZyi2YV8FgFKhcjjl2Sbzs3TxZMUpSND+Rqdbu17i0F4P 9LS7DZ9MzvrteO/Z8yHxH4vJNaTxtvAo5+vpu24U0JfVfiNbR7POXGDSL/YK/TqfpWLT hUBSrQeIfoLmsfbbWFvfS8QpHkoRvIUW3TZx97MTI3tkNYxOsk6ZzfQQz84j0/m06b1C 7EEpb3N/tjD64JOEse6gZy0ccGiM6jymKlCgQUKS9IvhD1K2Zdy9kHxqhqJCn4jIZUf+ 39wfSdbiRqU3PvxjK3vgTmcckER87ZbJHDrxQAGM+OgaYlmEXuek+YREsdvAVJJ5iCjZ obzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UlkOzrRhQZDa9eJ21oFrioajvTWPHIKuWzKtIgCumzE=; b=bV+zFKd93Zk1DzLFRB2oz53tpziTmEY4dq3Jvkv9d0pv60wAAFizYDye5pFQ2usyoT cFneGNdp3O7DYYsdHYAUtmPzuIf+5J3BzRSZOOUUrlf0HVvn8vUHaNhsky9GLj8rxFhw 6AkVbq3nfDko8SVEifUkvbB3OUGJI90yKzHAu6Lr6dxc6l5W/lmzfA7C3xY63pM0ICB0 df3UJqoaaGHf0tA8LjHefHNFE0BExfQIwfNjz3eAbrGwuo4dI8sAaBCntNycbGzI38c2 Bt1RnLFzIcpo4litPWJ5wMNd1u5LU9VWG+LwNeuXjTsGONiBiBw90F1r/N9CC8EYF8mb XSpw==
X-Gm-Message-State: APjAAAVeqEqOCMZdrZ4MIhRhkhdHalm6AcEq6r7MCugm22AYuxxT0ThO Kz9bItdjK6jvrAeyCuVDtanVwJpx9L876ZHzWp8y/KPT
X-Google-Smtp-Source: APXvYqwXmDXRYcug4jz7HADgGALmyYwxvdLFIz525Apd/52fpKhfImt7Fja/SLrktnog8bChpE+bbFQH6JVxttfegQo=
X-Received: by 2002:a24:bc02:: with SMTP id n2mr12184828ite.35.1558085676053; Fri, 17 May 2019 02:34:36 -0700 (PDT)
MIME-Version: 1.0
References: <155497956717.12785.2838340405405604916@ietfa.amsl.com>
In-Reply-To: <155497956717.12785.2838340405405604916@ietfa.amsl.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Fri, 17 May 2019 12:34:24 +0300
Message-ID: <CAP+sJUd1-WqgD7MUAwEnpA7gxH+Fi7QMjv0N_LjdoCCA_H1OFA@mail.gmail.com>
To: Colin Perkins <csp@csperkins.org>
Cc: tsv-art@ietf.org, roll <roll@ietf.org>, ietf <ietf@ietf.org>, draft-ietf-roll-useofrplinfo.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004038f005891217d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/FbleQSJZWRkeFn_WfwuCEOpxN-c>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-roll-useofrplinfo-25
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2019 09:34:39 -0000

Hi Colin,

Thank you for your review and comments. We have added a new paragraph which
addresses your concern.

New Text: "Since some of the uses cases here described, use IPv6-in-IPv6
encapsulation. It MUST take in consideration, when encapsulation is
applied, the RFC6040 [RFC6040], which defines how the explicit congestion
notification (ECN) field of the IP header should be constructed on entry to
and exit from any IPV6-in-IPV6 tunnel. Additionally, it is recommended the
reading of [I-D.ietf-intarea-tunnels]."

Best,

Ines

On Thu, Apr 11, 2019 at 1:46 PM Colin Perkins via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Colin Perkins
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> 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 and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> The draft updates RFC 6553 to use a different IPv6 hop-by-hop option type
> for
> RPL packets, to avoid some issues discovered through deployment experience.
> This looks to require a flag day cutover, and hence has some potential
> interoperability concerns, but introduces no transport concern. The draft
> also
> describes a number of clarifications around when to use the RPL hop-by-hop
> option header and when to use IP-in-IP tunnelling, described based on a
> set of
> use case examples.
>
> There do not look to be any new transport-related concerns with this draft.
>
> The draft does not mention ECN when using IPv6-in-IPv6 tunneling. It is
> perhaps
> implied, but a reference to RFC 6040 would be helpful to clarify how ECN
> bits
> are copied between inner and outer headers when encapsulating and
> decapsulating
> packets from an IPv6-in-IPv6 tunnel. ECN is seeing increasing use in
> transport
> protocols, so correctly propagating this information is important.
>
>
>