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@xxxxxxxxxxxxx> > Sent: Friday, August 31, 2018 5:39 AM > To: Rodney Cummings <rodney.cummings@xxxxxx>; ietf@xxxxxxxx > Cc: tictoc-chairs@xxxxxxxx; draft-ietf-tictoc-1588v2-yang@xxxxxxxx; > tictoc@xxxxxxxx; suresh@xxxxxxxxxx > 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@xxxxxx> > 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@xxxxxxxxxxxxx> > > > Sent: Wednesday, August 29, 2018 5:32 AM > > > To: ietf@xxxxxxxx > > > Cc: tictoc-chairs@xxxxxxxx; draft-ietf-tictoc-1588v2-yang@xxxxxxxx; > > > tictoc@xxxxxxxx; suresh@xxxxxxxxxx > > > 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@xxxxxxxx> > > > To: "IETF-Announce" <ietf-announce@xxxxxxxx> > > > Cc: <tictoc-chairs@xxxxxxxx>; > <draft-ietf-tictoc-1588v2-yang@xxxxxxxx>; > > > <tictoc@xxxxxxxx>; <suresh@xxxxxxxxxx> > > > 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@xxxxxxxx mailing lists by 2018-09-07. Exceptionally, comments > may > > > be > > > > sent to iesg@xxxxxxxx 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. > > > >
