Re: [6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-paging-dispatch-04: (with COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 30 September 2016 15:34 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3924712B31C; Fri, 30 Sep 2016 08:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.836
X-Spam-Level:
X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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
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 g3Y26JlpW44t; Fri, 30 Sep 2016 08:34:15 -0700 (PDT)
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 8447F12B0CB; Fri, 30 Sep 2016 08:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17488; q=dns/txt; s=iport; t=1475249653; x=1476459253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NkdM43EnpQ/h1591z11JfHMwKBfBETs+Pfj+w3cwtSQ=; b=BS7uO0gqRXtzK0tiAkiJ4qQG+FhuiMU9B38HChdeaTdZ9Z9XZNmX09Vy GF1OtkOv0nR7L3ozQ6nqH58gRj1G6HyZCaBy8XOcHWLGleepHbilNK6dh HKeeKdPuVE0CEJq5c3IOoaWFdG1kgkctetxi2HFRibwwJJ3zTCmAwLO86 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CvAQCEhe5X/49dJa1dGgEBAQECAQEBAQgBAQEBgwk2AQEBAQEeV3wHjSuWf48RgwOCD4IGhh4CHIFBOBQBAgEBAQEBAQFeJ4RhAQEBBCMKTBACAQgRBAEBKAMCAgIwFAkIAgQOBQiIRbAzjGcBAQEBAQEBAQEBAQEBAQEBAQEBAQEchjiEVYQWEQFSgk6CWgWIN4tphVgBj2mBdYRmiR6HC4Vjg30BHjaDHxwYgThyhUaBIIEAAQEB
X-IronPort-AV: E=Sophos;i="5.31,273,1473120000"; d="scan'208,217";a="157045087"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2016 15:33:55 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u8UFXtde017538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Sep 2016 15:33:55 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Sep 2016 10:33:54 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 30 Sep 2016 10:33:54 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Thread-Topic: [6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-paging-dispatch-04: (with COMMENT)
Thread-Index: AQHSGy3TAInNtwhPY0umLfAn0klNPKCSKLOA
Date: Fri, 30 Sep 2016 15:33:49 +0000
Deferred-Delivery: Fri, 30 Sep 2016 15:33:11 +0000
Message-ID: <001ce350488e455ba6bc95968dad2b59@XCH-RCD-001.cisco.com>
References: <147499880172.4456.2629427757724393939.idtracker@ietfa.amsl.com> <db38631ac32e4bb482fed4ee6dd31566@XCH-RCD-001.cisco.com> <CAKKJt-eujhehXNGuYV=Oka2cqQ1uOaJT_CvW-MczsqGvEohG0g@mail.gmail.com>
In-Reply-To: <CAKKJt-eujhehXNGuYV=Oka2cqQ1uOaJT_CvW-MczsqGvEohG0g@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.5]
Content-Type: multipart/alternative; boundary="_000_001ce350488e455ba6bc95968dad2b59XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/O-_Rr5CDDGL2yzPPHO-SKjUo0Ng>
Cc: "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "draft-ietf-6lo-paging-dispatch@ietf.org" <draft-ietf-6lo-paging-dispatch@ietf.org>, "jhw@nestlabs.com" <jhw@nestlabs.com>, The IESG <iesg@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>
Subject: Re: [6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-paging-dispatch-04: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 15:34:18 -0000

Thanks a bunch, Spencer !

I’ll publish an update, and will see what the WG and the IESG say about reserving a page for experimentations;

Take care,

Pascal

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: vendredi 30 septembre 2016 17:18
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: 6lo-chairs@ietf.org; draft-ietf-6lo-paging-dispatch@ietf.org; jhw@nestlabs.com; The IESG <iesg@ietf.org>; 6lo@ietf.org; Alvaro Retana (aretana) <aretana@cisco.com>
Subject: Re: [6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-paging-dispatch-04: (with COMMENT)

Hi, Pascal,

On Fri, Sep 30, 2016 at 4:36 AM, Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
Hello Spencer;

Thanks a bunch for your review. Please see in line;

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.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I found this text

   A Page (say Page N) is said to be active once the Page N Paging
   Dispatch is parsed, and as long as no other Paging Dispatch is
   parsed.

somewhat unclear. Is it saying

   A Page (say Page N) is said to be active once the Page N Paging
   Dispatch is parsed, and remains active until another Paging
   Dispatch is parsed.

?

[Pascal Thubert (pthubert)] Yes, and I like your sentence above better than the original. The temporal aspect (your "until") still remains to be clarified, as meaning "as the packet headers are being processed from the first to the last octet. Do we need to indicated that or is the implicit good enough?

It's good enough for me :-)

I wasn't quite sure what "so far" meant in this text (and temporal references in RFCs that live forever are somewhat confusing, anyway).

      As a result, there is no need so far for restoring the Page 0
      parsing context after a context was switched to Page 1, so the
      value for the Page 0 Paging Dispatch of 11110000 may not actually
      occur in those packets that adhere to 6LoWPAN specifications
      available at the time of writing this specification.

Would this be just as correct with "so far" deleted, or am I not understanding the point you're making?

[Pascal Thubert (pthubert)] I meant at the time of this publication, there is no known standard that has a case where page 0 would need to be restored after switching to page one. Does removing the so far express that correctly?

I think so.

Thanks for explaining why you're choosing "Specification Required" as your IANA policy.

[Pascal Thubert (pthubert)] The bottom line is that for most of these 6Lo networks, there is no equivalent to ethertype. We were already cornered with the ITU that started using some escape codes without IETF agreement. Now we are opening a very large namespace, we want it to be used by many communities beyond IETF, but we also indicate that we wish the IANA to manage that namespace like the IEEE does for ethertypes; and we wish that non experimental values are registered based on some standard action not just anyone asking for one. Now, this question leads to another. Should we reserve one page, say page 15, for experimentations?

That sounds reasonable to this outsider.

Do the right thing, of course :-)

Spencer