Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)

"Songhaibin (A)" <haibin.song@huawei.com> Fri, 26 February 2016 01:21 UTC

Return-Path: <haibin.song@huawei.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0D1A1A38; Thu, 25 Feb 2016 17:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 lAjdGcfLvb_2; Thu, 25 Feb 2016 17:21:11 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA92B1A1A4D; Thu, 25 Feb 2016 17:21:09 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJE34310; Fri, 26 Feb 2016 01:21:07 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 26 Feb 2016 01:21:04 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 26 Feb 2016 09:20:57 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
Thread-Index: AQHRN7jZcW5g6EknVEW+vQa5IqGiDp7jRewwgC3qCQCAAAWVAIABZu+AgCniSUCAAFpUAIABHupw
Date: Fri, 26 Feb 2016 01:20:56 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F65DBE1E8@nkgeml513-mbx.china.huawei.com>
References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com> <E33E01DFD5BEA24B9F3F18671078951F65DAB4AF@nkgeml513-mbx.china.huawei.com> <D0BF613A-D35C-4BDF-8FD0-6BC8EB5B7E18@cooperw.in> <CALaySJ+QjHHfPxWFvG=8XvB9oz=1wpPQskw0-SwgVLt2uzUe3g@mail.gmail.com> <E3A881B6-BC75-4A9E-947F-13C490C9C59B@cooperw.in> <E33E01DFD5BEA24B9F3F18671078951F65DBDE51@nkgeml513-mbx.china.huawei.com> <D2F48D9A.112FDE%aretana@cisco.com>
In-Reply-To: <D2F48D9A.112FDE%aretana@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.145]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56CFA883.013C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 27ef7e6dff8ec0cfd0f8b69d31f84b64
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/nBxb1DCtrb6Wl9WRBQROxMMuhHY>
Cc: "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>, IESG <iesg@ietf.org>, Barry Leiba <barryleiba@computer.org>, "draft-ietf-p2psip-diagnostics@ietf.org" <draft-ietf-p2psip-diagnostics@ietf.org>
Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 01:21:14 -0000

Hi Alvaro,

Thanks. And agree with the suggested text and place for it.

Best Regards!
-Haibin

> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]
> Sent: Friday, February 26, 2016 12:12 AM
> To: Songhaibin (A); Alissa Cooper
> Cc: Roni Even; p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf.org;
> IESG; p2psip@ietf.org; Barry Leiba
> Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19:
> (with DISCUSS and COMMENT)
> 
> On 2/24/16, 10:10 PM, "iesg on behalf of Songhaibin (A)"
> <iesg-bounces@ietf.org on behalf of haibin.song@huawei.com> wrote:
> 
> Haibin:
> 
> 
> Hi!
> 
> >I did the editing job and have submitted a new version of the document
> >according to the comments received and the discussion in the list. I
> >also add some text in the change history appendix for it. Please check
> >if the updated version has addressed your comments.
> >
> >https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20
> 
> I think that the text added in 4.3 maybe needs a little word-smithing (see below
> for a suggestion), and I think it should be in a more prominent place (I suggest
> 4.1) because the issue is not specific to Path_Track.
> Otherwise I think it's ok.
> 
> >I keep the intended status of the document as it is. Alvaro thought
> >Experimental might be a better status, when I check the change history
> >in the document, as it is defined as a mandatory RELOAD extension, the
> >current intended status seems suitable. Otherwise we need go through
> >another WGLC to change the intended status.
> 
> I don't think a new WGLC would be needed (or IETF LC for that matter) since it
> was already approved at a "higher" maturity level.  I also don't think we need
> to belabor this point much longer.
> 
> I will clear my DISCUSS.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> Suggested text update:
> 
> OLD>
>    One important thing is that, this document does not guarantee what it
>    conveys must be the information that caused the previous failures,
>    but with the retrieved information from the previous traversed nodes
>    (with high probability they are, as it cannot guarantee the exact
>    same path), a user or machine can analyze and infer what is the
>    problem.  Symmetric routing is achieved by the Via List as defined in
>    [RFC6940] (whatever DHT routing algorithms are used), but response
>    message could go through not exactly the same path as there still can
>    be node failures during that very short period.  And there can also
>    be lack of accurate path informaiton of the previously failed
>    message.
> 
> 
> NEW>
>    It is important to note that the mechanisms described in this document
>    do not guarantee that the information collected is in fact related to
>    the previous failures.  However, using the information from previous
>    traversed nodes, the user (or management system) may be able to infer
>    the problem. Symmetric routing can be achieved by using the Via List
>    [RFC6940] (or an alternate DHT routing algorithm), but the response
>    path is not guaranteed to be the same.