Hi Eric, I'd like to follow up on Yuanlong's last response below.
The fundamental answer to your question is that each of the co-authors signed a legal form provided by the IEEE Standards Association's department of Risk Management and Licensing. That form is effectively the same form that was used in the past for RFC 4663 (Bridge MIB). The signatures are relevant because IETF license is held by co-authors, whereas IEEE license is held by IEEE. If for some reason an IETF co-author refused to assign licensing to IEEE in the future, the work could never be transferred to IEEE. I'm also not a lawyer, but my understanding is that the form essentially says "I promise to assign my license for this content to IEEE 1588 in the future." In other words, this particular legal issue is mostly relevant to the IEEE side, and not the IETF side. To echo Karen O'Donoghue's point, this I-D was developed as a cooperative effort between the IETF TICTOC WG and IEEE 1588 WG. Members of the IEEE 1588 WG didn't have the charter (i.e. IEEE PAR) or arguably the history/expertise to develop an initial YANG module, so it was felt that IETF would be a great place to perform the initial YANG standardization (similar to MIB for IEEE 802.1). Although I agree that the YANG descriptions need to be technically correct and targeted to a non-implementer, I don't think that we should go so far as to repeat the entire specification from the IEEE 1588 document. I realize it is a bit strange that the YANG is modeling information that is specified as a protocol in another document, but that sort of thing is somewhat fundamental to this sort of cooperation. Nevertheless, I'm confident that users of IEEE 1588 products have a fundamental understanding of how these leaves work, so I tend to think that one or sentences in the YANG is sufficient. Rodney Cummings > -----Original Message----- > From: Jiangyuanlong <[email protected]> > Sent: Thursday, October 11, 2018 4:42 AM > To: Eric Rescorla <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; Karen O'Donoghue <[email protected]> > Subject: RE: Eric Rescorla's No Objection on draft-ietf-tictoc-1588v2- > yang-10: (with COMMENT) > > Hi Eric, > > Thanks for your review and comments, please see my replies prefixed with > [YJ]. > > Regards, > Yuanlong > > > -----Original Message----- > > From: Eric Rescorla [mailto:[email protected]] > > Sent: Thursday, October 11, 2018 8:07 AM > > To: The IESG > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; Karen O'Donoghue > > Subject: Eric Rescorla's No Objection on draft-ietf-tictoc-1588v2-yang- > 10: > > (with COMMENT) > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-tictoc-1588v2-yang-10: No Objection > > > > 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://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_iesg_statement_discuss- > 2Dcriteria.html&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=W > A71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=ot9cnwHATMvYzOPeiPTZi_d0Fb0_N > MA-hF-9PGRUYts&s=Qmx65ur089HICdPd-k9cOUVwuPrOaRdKIRHxxCuKTXM&e= > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2D1588v2- > 2Dyang_&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7 > Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=ot9cnwHATMvYzOPeiPTZi_d0Fb0_NMA-hF- > 9PGRUYts&s=pySceSxN6jhyt4fjdHVGBrGmfE968qGVS4fiv8W_wSU&e= > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mozphab- > 2Dietf.devsvcdev.mozaws.net_D3264&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1j > jZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=ot9cnwHATMv > YzOPeiPTZi_d0Fb0_NMA-hF- > 9PGRUYts&s=D1tnltVhXPJToHaCaQJEMt3giSidkaGj6BWrEJAloiE&e= > > > > > > I concur with Ben Campbell's DISCUSS. > > > > COMMENTS > > S 1. > > > 2008. > > > > > > o When the IEEE 1588 standard is revised (e.g. the IEEE 1588 > > > revision in progress at the time of writing this document), it > will > > > add some new optional features to its data sets. The YANG module > > > of this document MAY be revised and extended to support these new > > > > Nit: this looks like it's more a statement of fact than normative > > langauge. > > > [YJ] For consistency, "MAY" in this bullet will change to "may", and "can" > in bullet 4 will also change to "may". > > > > > S 1. > > > dedicated YANG module for its profile. The profile's YANG module > > > SHOULD use YANG "import" to import the IEEE 1588-2008 YANG > > module > > > as its foundation. Then the profile's YANG module SHOULD use > > YANG > > > "augment" to add any profile-specific enhancements. > > > > > > o A product that conforms to a profile standard can also create > > > > Is the "can" in this statement different from the "may" in the > > previous bullet. > > > [YJ] resolved as above. > > > > S 7. > > > create derivative works from this document. Those IEEE forms and > > > mechanisms will be updated as needed for any future IETF YANG > > > modules for IEEE 1588 (The signed forms are held by the IEEE > > > Standards Association department of Risk Management and > > Licensing.). > > > This will help to make the future transfer of work from IETF to > > > IEEE occur as smoothly as possible. > > > > I don't mean to be overly legal, but why is it that you think that the > > named authors consent is what's relevant here as opposed to the IETF, > > or everyone who has submitted text? > > > [YJ] None of the authors are legal experts;) but during the development of > this appendix, we did diligently solicit the guidance from quite a few ADs > (such as Suresh), and the texts reflect exactly the legal advices we got > from the IETF legal counsel for IPR matters and the IEEE Standards > Association Manager of Standards Intellectual Property. Please also refer > to RFC 4663 for the similar procedural texts. _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
