[sipcore] Opsdir last call review of draft-ietf-sipcore-multiple-reasons-01

Tianran Zhou via Datatracker <noreply@ietf.org> Sat, 29 October 2022 02:05 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9FCC14F722; Fri, 28 Oct 2022 19:05:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tianran Zhou via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-sipcore-multiple-reasons.all@ietf.org, last-call@ietf.org, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.20.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166700910346.30158.7379036605313247313@ietfa.amsl.com>
Reply-To: Tianran Zhou <zhoutianran@huawei.com>
Date: Fri, 28 Oct 2022 19:05:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/F5mWz9bYvMsZW1za3nftz5PSWbc>
Subject: [sipcore] Opsdir last call review of draft-ietf-sipcore-multiple-reasons-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Oct 2022 02:05:03 -0000

Reviewer: Tianran Zhou
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Ready with nits.

>From the operational point of view, I am not sure how an exisitng/old
application will behave when it receive this message with multiple value. Yes,
RFC3326 has this text "An implementation is free to ignore Reason values that
it does not understand." However, there is "MUST" in the old text "all of them
MUST have different protocol values". I am not clear about existing
implemenations. But posibly an application may check this rule and return
error, since this is a "MUST". I am also interested why old text need a very
hard rule "all of them MUST have different protocol values", but now relex.

Cheers,
Tianran