Re: [TICTOC] Ben Campbell's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)

Jiangyuanlong <jiangyuanlong@huawei.com> Thu, 11 October 2018 09:16 UTC

Return-Path: <jiangyuanlong@huawei.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FB6130DC1; Thu, 11 Oct 2018 02:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y4PxKN_1DssC; Thu, 11 Oct 2018 02:16:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F77129BBF; Thu, 11 Oct 2018 02:16:13 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DF1A6D6588ECE; Thu, 11 Oct 2018 10:16:09 +0100 (IST)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 11 Oct 2018 10:16:10 +0100
Received: from DGGEML532-MBS.china.huawei.com ([169.254.7.198]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0399.000; Thu, 11 Oct 2018 17:16:00 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tictoc-1588v2-yang@ietf.org" <draft-ietf-tictoc-1588v2-yang@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>, "tictoc-chairs@ietf.org" <tictoc-chairs@ietf.org>, "odonoghue@isoc.org" <odonoghue@isoc.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: Ben Campbell's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)
Thread-Index: AQHUYNn7zHqBePLc4kOfj39wcbPuPaUZtwUQ
Date: Thu, 11 Oct 2018 09:16:00 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBC218204@dggeml532-mbs.china.huawei.com>
References: <153920423392.5904.16209504345160495561.idtracker@ietfa.amsl.com>
In-Reply-To: <153920423392.5904.16209504345160495561.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.171.86]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/cRQc4a8KCGlks-x-Lz4CcyauaJA>
Subject: Re: [TICTOC] Ben Campbell's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2018 09:16:18 -0000

Ben, 

Thanks much for the review and the opinions, please see my replies prefixed with [JY].

Regards,
Yuanlong

> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, October 11, 2018 4:44 AM
> To: The IESG
> Cc: draft-ietf-tictoc-1588v2-yang@ietf.org; Karen O'Donoghue;
> tictoc-chairs@ietf.org; odonoghue@isoc.org; tictoc@ietf.org
> Subject: Ben Campbell's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with
> DISCUSS and COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-tictoc-1588v2-yang-10: Discuss
> 
> 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.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is a process discuss, or maybe a discuss discuss. I expect to clear it
> once a discussion has occurred regardless of the outcome, but I want to
> make
> sure the discussion happens.
> 
> §2 contains the following paragraph:
> 
> "  The readers are assumed to be familiar with IEEE 1588-2008. As all
>    PTP terminologies and PTP data set attributes are described in
>    details in IEEE 1588-2008 [IEEE1588], this document only outlines
>    each of them in the YANG module."
> 
> If I understand correctly, IEEE 1588-2008 is not available without payment. If
> so, then I don't see how we can assume that reviewers of this draft are
> actually familiar with IEEE 1588-2008. It seems like that makes it hard for the
> draft to get sufficient review to be considered a standards-track IETF
> consensus document. I recognize that we do not have a policy against
> normative
> references to paywalled sources, but I read the disclaimer to make the IEEE
> document more foundational than just any normative reference.
> 
>
[YJ] I realized that most IEEE standards needs to be bought or accessed via subscription (such as 802.1, 802.3 and etc). Most SDOs will keep their documents in development only internally available. In such a case, one typical cooperation mechanism between SDOs is via official liaisons, for example, a document from a SDO (whether it is published or not) can be liaised to another SDO for reviews. Maybe we can establish such a relationship at an early stage next time so that IETF reviews can be more smooth.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> §1, 2nd bullet: "The YANG module of this document MAY be revised..."
> That seems more a statement of fact than permission.
> 
[YJ] agreed, to align with these bullets, "MAY" will change to "may", and "can" in bullet 4 will also change to "may" for consistency. 

> §2.2, definition of "static": If it "typically" doesn't change, does that mean
> it sometimes does change? -- 5th paragraph: "In such a case, an
> implementation
> MAY choose to return a warning upon writing to a read-only member" MAY
> seems
> week here; does it ever make sense to silently write to a read-only member?
> 
[YJ] "MAY" will change to "SHOULD".

> Appendix A: The appendix seems more like a liaison statement than
> something
> that belongs in an RFC defining a data model. Won't this become outdated
> whenever the change of control is (or is not) made? If it does need to go in an
> RFC, have people considered publishing it separately from the model?
> 
[YJ] My opinion is: the appendix can be published alone, similar to RFC 4663. But I'd like to hear more opinion from my coauthor Rodney on this issue, as he contributed most materials in this appendix.