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

[tom petch <[e-mail]>]

-10 looks good.

In passing, I think that your logic for using YANG enum instead of
identity is fine.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" <[e-mail]>
Sent: Monday, September 10, 2018 4:45 AM

Hi all,

A New version of the Internet-Draft is available at:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-10
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588v2-yang-10

The "Security Considerations" section in the draft is revised to align
with the latest template (see
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as
indicated in draft-ietf-netmod-rfc6087bis-20).
BTW, RFC5246 in the template is obsoleted by RFC8446, thus I updated it
accordingly.
The appendix A.2 and description texts of default-ds and current-ds are
also updated as discussed in previous emails in the list.

Thanks,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:[e-mail]] On Behalf Of Jiangyuanlong
Sent: Monday, September 10, 2018 10:04 AM
To: tom petch <[e-mail]>; Rodney Cummings
<[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: [TICTOC] Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt>
(YANG Data Model for IEEE 1588-2008) to Proposed Standard

Tom,

Thanks much for your comments.
We will update the draft shortly with your suggested texts.

Regards,
Yuanlong

-----Original Message-----
From: tom petch [mailto:[e-mail]]
Sent: Friday, September 07, 2018 7:45 PM
To: Rodney Cummings <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: Last Call: <draft-ietf-tictoc-1588v2-yang-09.txt> (YANG
Data Model for IEEE 1588-2008) to Proposed Standard

<inline>

----- Original Message -----
From: "Rodney Cummings" <[e-mail]>
Sent: Friday, August 31, 2018 4:14 PM

> 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

The obvious place, to me, to keep such an item would be IASA and I have
e-mailed them but have yet to get a response. I expect that their
response will be that they are not interested.  The IETF cares that it
has the IPR necessary to do its current and future work and that grant
of IPR allows the authors to grant further IPR to other parties as long
as that does not restrict the rights granted to the IETF, as RFC5378
describes, so while I would like to be able to see the grants that you
have made without having to ask the IEEE, I suspect that that view will
not be shared.  So ignore my suggestion about the IETF having a copy.

Just to state the obvious, I do think that Appendix A is a useful and
valuable piece of work.

Tom Petch

> Rodney
>
>
> > -----Original Message-----
> > From: tom petch <[e-mail]>
> > Sent: Friday, August 31, 2018 5:39 AM
> > To: Rodney Cummings <[e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > 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" <[e-mail]>
> > 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 <[e-mail]>
> > > > Sent: Wednesday, August 29, 2018 5:32 AM
> > > > To: [e-mail]
> > > > Cc: [e-mail];
[e-mail];
> > > > [e-mail]; [e-mail]
> > > > 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" <[e-mail]>
> > > > To: "IETF-Announce" <[e-mail]>
> > > > Cc: <[e-mail]>;
> > <[e-mail]>;
> > > > <[e-mail]>; <[e-mail]>
> > > > 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
> > > > > [e-mail] mailing lists by 2018-09-07. Exceptionally,
comments
> > may
> > > > be
> > > > > sent to [e-mail] 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.
> > >
> > >
>
>

_______________________________________________
TICTOC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tictoc