Re: [TICTOC] Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt> (YANG Data Model for IEEE 1588-2008) to Proposed Standard

Rodney Cummings <rodney.cummings@ni.com> Fri, 31 August 2018 15:15 UTC

Return-Path: <prvs=878170339f=rodney.cummings@ni.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 1CEDB130DD1; Fri, 31 Aug 2018 08:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.onmicrosoft.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 XEqPdk8DjZns; Fri, 31 Aug 2018 08:14:58 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0b-00010702.pphosted.com [148.163.158.57]) (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 BF1751292F1; Fri, 31 Aug 2018 08:14:57 -0700 (PDT)
Received: from pps.filterd (m0098778.ppops.net [127.0.0.1]) by mx0b-00010702.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7VFCePg015514; Fri, 31 Aug 2018 10:14:53 -0500
Authentication-Results: ppops.net; dkim=pass header.d=nio365.onmicrosoft.com header.s=selector1-ni-com
Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0119.outbound.protection.outlook.com [216.32.181.119]) by mx0b-00010702.pphosted.com with ESMTP id 2m5x29e4k8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 10:14:53 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=prKqkihckuSNldvkq7/ahJKQXbaVAKUfgTJGqZ0qVf8=; b=eRkpw/P9p44ulyfN2LWN4jRsGuwjFV222vfUD2kOUCT/zJ7+YZDAaQD7qBilb1oFwbOomBgJfh74MiXdMxTrXqbor6PFcRKWDAfB4GcB4871OqFhK8VDFIwcNAPK2Utw8+RRZkdHUpYccS7W9kESqsoiY8bYlv7jQj+O82FCnnA=
Received: from MWHPR04MB1134.namprd04.prod.outlook.com (10.173.51.135) by MWHPR04MB0784.namprd04.prod.outlook.com (10.172.168.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.15; Fri, 31 Aug 2018 15:14:50 +0000
Received: from MWHPR04MB1134.namprd04.prod.outlook.com ([fe80::2864:4db9:b869:a41b]) by MWHPR04MB1134.namprd04.prod.outlook.com ([fe80::2864:4db9:b869:a41b%6]) with mapi id 15.20.1080.015; Fri, 31 Aug 2018 15:14:50 +0000
From: Rodney Cummings <rodney.cummings@ni.com>
To: tom petch <daedulus@btconnect.com>, "ietf@ietf.org" <ietf@ietf.org>
CC: "tictoc-chairs@ietf.org" <tictoc-chairs@ietf.org>, "draft-ietf-tictoc-1588v2-yang@ietf.org" <draft-ietf-tictoc-1588v2-yang@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>, "suresh@kaloom.com" <suresh@kaloom.com>
Thread-Topic: Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt> (YANG Data Model for IEEE 1588-2008) to Proposed Standard
Thread-Index: AQHUO8V5sbojyeAsm0+ZkurtbCnfMaTZ/qLA
Date: Fri, 31 Aug 2018 15:14:49 +0000
Message-ID: <MWHPR04MB113402D1C085B1BBC5CD2206920F0@MWHPR04MB1134.namprd04.prod.outlook.com>
References: <153512723932.23011.7549399576500419871.idtracker@ietfa.amsl.com> <02f801d43f83$85b22fa0$4001a8c0@gateway.2wire.net> <MWHPR04MB1134E8843A8D12645667D61E92090@MWHPR04MB1134.namprd04.prod.outlook.com> <032401d44116$c36be0e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <032401d44116$c36be0e0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.164.62.219]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR04MB0784; 6:F53sU7MFxJ4jUO5LSaiBOXxzj9Vt87XDB0dNR9zV+FCuffgLPPGqgsuOU/rBSgeqviZ9AgoDBytViwOffUds1cBeI4GiQzDfACVoXnhyQHVOMtlFsIaD+d2Z29kcljNgix00+eeDCzXVzvRVVvdodwZA5ZNve6tSGvEPvkbHRQZZIADXCMyDWacCHyW16yIws0JNX5eAQwJ/X116gkOKaSO42j43LZ9xQ4DSWjsAnAmj3OQpKxYPY4zpU3vWxzW0Mur/cXuZzq2fsur1RD0iX2SfJx/EXCVoCJnhj/brMU58ITHYgQCsY8eFN9Vya3uugvLb4Kb26ZS+UOjmG45Z4j6SUxzkLdq0u0OxROyuhFDNPevmeHDDfaRIjbF9ajNYKPUUveWOCR85ZurdrbECLk8keHeP33K5Cttw44kvOCMfvSkkKoUiuJO/ORQuNysdZ0ewM8DEdKRcD/ByIj74Ig==; 5:lBw+Ty/PWUs6hKZjy9KVrdE9Qc6nrFXzZlCE0UFy4PPDpcwvWZSEG9F2pco11gHJyNaYMuzBiL7h4d7EWv+r90ZTd1cS4mGenKwxRYRxpehdCA/bll8si+AvHmPdDYGrs7dY10ve2Hx2t9REHq+QjrEE6a2wmH0You+4db0tu7k=; 7:sljEf8PfSQpu+XcbP1yir7WWS9RbcV2Jf46PZ5Sv51gk8SesTtumw1xsoh3Fhy6q6J56oLZFHFJWJxhVPsN6iF7SXT/NjkgGIlu3AxH7qyFbdiKlFZKFB4VQYIMQGHLbZiD0B6k6WWfpO5zfxJGw/r9X8CqIB0tPk94ezc/5+QKFXWA24gw/XFXjP/on/ynKQ0f6o2/Hpw4DmxFM/ZgRThHeYn27U7FcJrpvQl1qPlrqCQ+jhVg9yooy76n9mghs
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b646af72-1d56-4175-9f9b-08d60f547ee6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR04MB0784;
x-ms-traffictypediagnostic: MWHPR04MB0784:
x-microsoft-antispam-prvs: <MWHPR04MB07845AAE00CD6EB79B20E6B0920F0@MWHPR04MB0784.namprd04.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(60795455431006)(178726229863574)(10436049006162)(192374486261705)(219612443155931)(145744241990776);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699016); SRVR:MWHPR04MB0784; BCL:0; PCL:0; RULEID:; SRVR:MWHPR04MB0784;
x-forefront-prvs: 07817FCC2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(396003)(346002)(366004)(189003)(13464003)(199004)(7696005)(5660300001)(68736007)(446003)(81156014)(81166006)(476003)(44832011)(486006)(11346002)(26005)(186003)(8936002)(2906002)(8676002)(99286004)(54906003)(66066001)(86362001)(575784001)(296002)(316002)(6506007)(102836004)(53546011)(76176011)(2900100001)(110136005)(256004)(14444005)(97736004)(2501003)(5250100002)(305945005)(25786009)(53936002)(106356001)(74316002)(105586002)(4326008)(6306002)(9686003)(3846002)(93886005)(6116002)(7736002)(6436002)(229853002)(55016002)(33656002)(6246003)(966005)(478600001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR04MB0784; H:MWHPR04MB1134.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: SB4XfoIdwzzE6cCLWZzD6VQgSsyOfFLE+Yuo641y0/cIspWBz9Xq6zPKJH2PPSWFIe0vfBRaLickn1YvL3cDU/uQ+H4JVO6JOYVTXR8FgTK7BsEMFpGnY2LCBKyDo509r8GZaWc7KqC/EK29D1oVENs/YULLe2JHgzcu0lA3j76mvrLX6eWGqtiwwRfw1BOe7wUQKC8hDm4GF7v5iPwmM3oEH7DRGlfgbejb7vnXZ7GHIo/tjqt502zsoZbVdFY0uDR5l3knNel0REG1d+qxE+005DK/zc32m2Oq/KhKCbI7LsIXaiyiUaXbzkDgeoBjyxXBgJWMgRMbE4Os0kRaOnvhyFZQQ7wWtJvOTrAFuvs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b646af72-1d56-4175-9f9b-08d60f547ee6
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2018 15:14:49.9406 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB0784
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-31_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_policy_notspam policy=inbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808310159
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/pIn7KmBLAVe8murdns623rjTS3o>
Subject: Re: [TICTOC] Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt> (YANG Data Model for IEEE 1588-2008) to Proposed Standard
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 31 Aug 2018 15:15:01 -0000

Thanks Tom,

I agree with your NEW text.

When I saw your email on this, I considered just forwarding my signed PDF of the form, but I noticed that it has "Copyright 2016 IEEE" at the bottom. Lawyers will be lawyers.

> "  The signed forms are held by the IEEE Standards Association
> department of Risk Management and Licensing."
> (hoping that that is true for the IEEE).

Sounds good, and that is the correct name from the form.

> I think it worth clarifying a little more since the situation may recur
> with a different piece of IETF work, perhaps with a different SDO (and I
> recall the effort needed for the MIB).

Agreed. We pretty much copied this process from what was described for the Bridge MIB transfer to IEEE 802.1.

> And finally, curiosity, does the IETF/IASA keep a copy?  If so, I would
> say so, so that a future interested party can have what I would expect
> an easier option of accessing the IETF support functions rather than
> those of another SDO.  If the IETF etc. do not have a copy, then say no
> more i.e. I would not say that we do not have a copy!.

As of now only IEEE-SA Risk Management and Licensing has a copy of all co-authors' signed forms.
As I understand it, IETF policy is that the authors have ownership rights for the content of an RFC.
For IEEE standards, IEEE has the ownership rights. Therefore, if content of an RFC is to be transferred
to IEEE in the future, IEEE wants those RFC authors to grant a license to IEEE. Since each form is
exclusively an agreement between one author and IEEE, I assume it wouldn't be very useful for future
IETF projects.

That being said, if IETF would like to retain copies, it certainly wouldn't hurt to ask
IEEE-SA Risk Management and Licensing. I'd recommend that we do that for the new set of
forms that are signed with the updated RFC number. If we want to do that please let me
know the contact info for where IEEE should send the copies.

Rodney


> -----Original Message-----
> From: tom petch <daedulus@btconnect.com>
> Sent: Friday, August 31, 2018 5:39 AM
> To: Rodney Cummings <rodney.cummings@ni.com>; ietf@ietf.org
> Cc: tictoc-chairs@ietf.org; draft-ietf-tictoc-1588v2-yang@ietf.org;
> tictoc@ietf.org; suresh@kaloom.com
> Subject: Re: Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt> (YANG Data
> Model for IEEE 1588-2008) to Proposed Standard
> 
> ----- Original Message -----
> From: "Rodney Cummings" <rodney.cummings@ni.com>
> Sent: Wednesday, August 29, 2018 3:22 PM
> 
> > > "Those IEEE forms and
> > >    mechanisms will be updated as needed during the development of
> this
> > >    document ..."
> >
> > Thanks for catching that. I wrote that text originally, but I agree
> that
> > we need to change it.
> >
> > When we started the drafts, I coordinated with IEEE's legal team to
> determine
> > what IEEE would require in order for the work in this draft to
> transfer in the
> > future to the IEEE 1588 Working Group. In response, IEEE legal created
> a simple
> > one-page form for each I-D co-author to sign, which we did.
> >
> > The current form grants a license for the "1588 YANG Model and Module"
> to
> > "IEEE 1588, IEEE Standard for a Precision Clock Synchronization
> Protocol
> > for Networked Measurement and Control Systems".
> >
> > The forms have standing as is, but IEEE's lawyer asked that if/when
> the I-D
> > is published as RFC, the co-authors sign the forms again with
> > "1588 YANG Model and Module" replaced with the RFC number/name. That
> is
> > the only action item from the IEEE side.
> >
> > We could edit the draft to either:
> > 1. Remove this sentence and related text, under the assumption that it
> isn't
> > essential for the document.
> > 2. Change the sentence to say "Those IEEE forms will be updated with
> the RFC
> > number and name after this document is published." (or similar).
> >
> > We'd appreciate your advice.
> 
> Rodney et al.,
> 
> A disclaimer; I do not have any specific skills in this area (IPR, IEEE,
> legal documents,...) so weigh my comments accordingly.
> 
> I think it worth clarifying a little more since the situation may recur
> with a different piece of IETF work, perhaps with a different SDO (and I
> recall the effort needed for the MIB).
> 
> So I suggest
> OLD
> "Those IEEE forms and
>    mechanisms will be updated as needed during the development of this
>    document (Note: i.e., RFC XXXX, update it to the actual RFC if
>    published) and any future IETF YANG modules for IEEE 1588. "
> NEW
> "Those IEEE forms and
>    mechanisms will be updated as needed
> for
> any future IETF YANG modules for IEEE 1588. "
> 
> And I would like a reference to where the forms are kept.  I would
> expect that to be the IEEE's task so perhaps add
> "  The signed forms are held by the IEEE Standards Association
> department of Risk Management and Licensing."
> (hoping that that is true for the IEEE).
> 
> And finally, curiosity, does the IETF/IASA keep a copy?  If so, I would
> say so, so that a future interested party can have what I would expect
> an easier option of accessing the IETF support functions rather than
> those of another SDO.  If the IETF etc. do not have a copy, then say no
> more i.e. I would not say that we do not have a copy!.
> 
> Tom Petch
> 
> > Rodney
> >
> > > -----Original Message-----
> > > From: tom petch <daedulus@btconnect.com>
> > > Sent: Wednesday, August 29, 2018 5:32 AM
> > > To: ietf@ietf.org
> > > Cc: tictoc-chairs@ietf.org; draft-ietf-tictoc-1588v2-yang@ietf.org;
> > > tictoc@ietf.org; suresh@kaloom.com
> > > Subject: Re: Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt> (YANG
> Data
> > > Model for IEEE 1588-2008) to Proposed Standard
> > >
> > > Looks good; I commented on an earlier version of this document and
> my
> > > comments have been addressed.
> > >
> > > Two further thoughts at this time.
> > >
> > > The Security Considerations makes no mention of  RESTCONF, which
> makes
> > > me think that this is not the usual template for this section.
> > >
> > > And I am curious as to what the final wording of A.2 will be.
> > > Currently, it says
> > > "Those IEEE forms and
> > >    mechanisms will be updated as needed during the development of
> this
> > >    document ..."
> > > so that the IEEE has the IPR to use this RFC as a basis for future
> work.
> > > The development of this document is nearly, but not quite, complete
> so
> > > have the forms been produced and signed or when will they be, should
> the
> > > RFC reference the forms and what form of words will this paragraph
> use
> > > in the RFC as published? It is a bit like IANA Considerations where
> the
> > > I-D is proposing an action but the RFC says it has been done.  As I
> say,
> > > I am curious to see how this is handled.
> > >
> > > Tom Petch
> > >
> > > ----- Original Message -----
> > > From: "The IESG" <iesg-secretary@ietf.org>
> > > To: "IETF-Announce" <ietf-announce@ietf.org>
> > > Cc: <tictoc-chairs@ietf.org>;
> <draft-ietf-tictoc-1588v2-yang@ietf.org>;
> > > <tictoc@ietf.org>; <suresh@kaloom.com>
> > > Sent: Friday, August 24, 2018 5:13 PM
> > >
> > > > The IESG has received a request from the Timing over IP Connection
> and
> > > > Transfer of Clock WG (tictoc) to consider the following
> document: -
> > > 'YANG
> > > > Data Model for IEEE 1588-2008'
> > > >   <draft-ietf-tictoc-1588v2-yang-09.txt> as Proposed Standard
> > > >
> > > > The IESG plans to make a decision in the next few weeks, and
> solicits
> > > final
> > > > comments on this action. Please send substantive comments to the
> > > > ietf@ietf.org mailing lists by 2018-09-07. Exceptionally, comments
> may
> > > be
> > > > sent to iesg@ietf.org instead. In either case, please retain the
> > > beginning of
> > > > the Subject line to allow automated sorting.
> > > >
> > > > Abstract
> > > >
> > > >    This document defines a YANG data model for the configuration
> of
> > > >    IEEE 1588-2008 devices and clocks, and also retrieval of the
> > > >    configuration information, data set and running states of IEEE
> > > >    1588-2008 clocks. The YANG module in this document conforms to
> the
> > > >    Network Management Datastore Architecture (NMDA).
> > > >
> > > > The file can be obtained via
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-
> > >
> 2Dyang_&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2
> o7
> > >
> Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=NFxKcqZGoBTp9Cb3kYMictVY92Qg3RRqRTj
> j-
> > > ai4dZc&s=Cqj4S_Yu69jW5EMhJTnE6-TGiWjtglJFLYzgwJON4nU&e=
> > > >
> > > > IESG discussion can be tracked via
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-
> > >
> 2Dyang_ballot_&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=
> WA
> > >
> 71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=NFxKcqZGoBTp9Cb3kYMictVY92Qg
> 3R
> > > RqRTjj-ai4dZc&s=SO_y6eZSeTvPjb0MjBruqASMEZ-nOlVPnnnyxydZRAo&e=
> > > >
> > > > No IPR declarations have been submitted directly on this I-D.
> >
> >