[Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
Pete Resnick <presnick@qti.qualcomm.com> Tue, 06 September 2016 16:05 UTC
Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE8012B52A; Tue, 6 Sep 2016 09:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.528
X-Spam-Level:
X-Spam-Status: No, score=-8.528 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=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 SfAkF6kwCn2e; Tue, 6 Sep 2016 09:05:09 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E8912B5CE; Tue, 6 Sep 2016 08:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1473177328; x=1504713328; h=from:to:cc:subject:date:message-id:mime-version; bh=TgC/aIOmQ5O2A93ANdZcH+bvzFLjAn2djNsfwehZObk=; b=p5HxI5a0+X0rVPhWaIlhYU+xHVferRq+9stCZeuyyJLzWv7MNpQmMBXd 5uUznA9M+i+acmnZZz/tf7dwJ1qJeUl5sVzpJAN1KyQ7qKVUBsTvmz/10 wDbXCdgTLzKUqxfUsFbwLs1sz051jPxWbDvV9MoBin1sLAqurEhZlHsse E=;
X-IronPort-AV: E=Sophos;i="5.30,292,1470726000"; d="scan'208,217";a="317405948"
Received: from unknown (HELO Ironmsg04-R.qualcomm.com) ([10.53.140.108]) by wolverine02.qualcomm.com with ESMTP; 06 Sep 2016 08:55:28 -0700
X-IronPort-AV: E=McAfee;i="5700,7163,8280"; a="1267038269"
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Sep 2016 08:55:27 -0700
Received: from [10.64.128.83] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 6 Sep 2016 08:55:26 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: IESG <iesg@ietf.org>
Date: Tue, 06 Sep 2016 10:55:25 -0500
Message-ID: <6ECD9A3A-0D63-421B-953D-A516D773CCBA@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_ACCA4C19-B7E7-44C8-9142-F06EB58A79A6_="
X-Mailer: MailMate (1.9.5r5260)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/MGACH2k9A1dzkeXATef6ymIrb-E>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-tram-turn-mobility.all@ietf.org, tram@ietf.org
Subject: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 16:05:15 -0000
Greetings, I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other participants comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-tram-turn-mobility-03 Reviewer: Pete Resnick Review Date: 2016-09-06 IESG Telechat date: 2016-09-01 Summary: This is an odd post-telechat review, but I think the draft has gone from "Ready" to "Ready with an issue" because of an IESG Eval change. Details: I did not get to my post-Last Call GenART review of draft-ietf-tram-turn-mobility until after the telechat. Had I done so, which would have been on version -05, I would have said "Looks fine to me". However, I happened to look at the latest version, figuring I would just confirm. I found that a change was made in response to an IESG Evaluation comment from Suresh <https://mailarchive.ietf.org/arch/msg/tram/SYVAXc1dF6xUcm0OQ9xyuaknJco>: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 3.2.1 > > The section on sending a Refresh when the IP address does not change > needs a little bit more tightening. Given that the server would reject > the request with a mobility ticket in this case, it would be good to > put > in an explicit restriction to not add the mobility ticket in the > following statement > > OLD: If a client wants to refresh an existing allocation and update > its > time-to-expiry or delete an existing allocation, it will send a > Refresh > Request as described in Section 7.1 of [RFC5766] > > NEW: > If a client wants to refresh an existing allocation and update its > time-to-expiry or delete an existing allocation, it MUST send a > Refresh > Request as described in Section 7.1 of [RFC5766] and MUST NOT include > a > MOBILITY-TICKET attribute. I'm not sure if the "MUST NOT" in the latter part of the sentence is correct: Since the server will reject it anyway, I don't see the harm in including the attribute that the "MUST NOT" implies, but perhaps this is belt-and-braces protocol description. On this point, I can't complain too much. However, I believe Suresh was incorrect in suggesting the first "MUST", and it should be removed. There is no harm being prevented here. "If a client wants X, it MUST send Y" is absolutely no different protocol-wise from "If a client wants X, it will send Y". The "MUST" is a misuse. I believe that this change should be undone before publication. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478
- [Gen-art] GenART post-telechat comment on draft-i… Pete Resnick
- Re: [Gen-art] GenART post-telechat comment on dra… Tirumaleswar Reddy (tireddy)
- Re: [Gen-art] GenART post-telechat comment on dra… Spencer Dawkins at IETF
- Re: [Gen-art] GenART post-telechat comment on dra… Suresh Krishnan
- Re: [Gen-art] GenART post-telechat comment on dra… Stephen Farrell
- Re: [Gen-art] GenART post-telechat comment on dra… Pete Resnick
- Re: [Gen-art] GenART post-telechat comment on dra… Pete Resnick
- Re: [Gen-art] GenART post-telechat comment on dra… Tirumaleswar Reddy (tireddy)
- Re: [Gen-art] GenART post-telechat comment on dra… Suresh Krishnan
- Re: [Gen-art] GenART post-telechat comment on dra… Pete Resnick
- Re: [Gen-art] [tram] GenART post-telechat comment… Jonathan Lennox
- Re: [Gen-art] GenART post-telechat comment on dra… Tirumaleswar Reddy (tireddy)
- Re: [Gen-art] [tram] GenART post-telechat comment… Tirumaleswar Reddy (tireddy)