Subject: Re: [ntpwg] NTPStamp - A new addition to the kit...

From: Danny Mayer <[email-masked]>
Date: Sun, 08 Nov 2009 00:04:40 -0500

Todd Glassey wrote:
> I am submitting a new utility proposal to the WG for consideration. I 
> will not submit the draft contents to this WG until it agrees that it 
> will allow this new proposed material to the official reference port 
> definitions.

The working group has nothing to do with the reference implementation.
The WG does not write or approve code.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Sun, 08 Nov 2009 00:56:46 -0500

Dave,

I think that you are thinking of the md5 issue. There was a bug in the
NTP reference implementation. It has nothing to do with autokey.

Danny

David Mills wrote:
> Danny,.
> 
> Were you the one who told me there was another implementation or was it
> Dave Hart? I know that implementation exposed a problem which we fixed.
> 
> Brian,
> 
> The culturally correct way to proceed is to continue on the
> Informational Track and strike up a new WG with the mission of studying
> NTP security issues and proposing Autokey as a work item. Ordinarily, I
> would be the first to beat that drum, but my faculties and vision have
> deteriorated (but not my mind!), so travel is difficult. However, there
> might be other drummers, possibly including Danny and/or Dave Hart, two
> of the most intrepid warriors in the NTP tribe.
> 
> If there is a shorter path to Standards Track, lets take it; however, an
> NTP security WG would still be a good idea.
> 
> Dave
> 
> Brian Haberman wrote:
> 
>> The publication status of Autokey was decided when the working group
>> was first started.  The Area Directors at the time thought that
>> Informational was appropriate given there was a single implementation
>> and there was some concerns within the Security Area of the IETF on
>> the actual security model used for Autokey. Now, it has been a long
>> enough process that we have almost completely changed over the
>> membership of the IESG, hence the information loss on the publication
>> status.
>>
>> If the working group wants to revisit the publication status of
>> Autokey, we can do that.  I will note that changing the status to
>> Proposed Standard will hold it to a higher level of review.
>>
>> Regards,
>> Brian
>>
>> Danny Mayer wrote:
>>
>>> Dave,
>>>
>>> My understanding of this was that the editors and/or chairs felt it
>>> would be too difficult, given the security questions, to get it through
>>> on standards track. I too would prefer standards track.
>>>
>>> I haven't heard of another implementation of autokey. Pray tell us more
>>> as this could give an impetus to this document.
>>>
>>> Danny
>>>
>>> David Mills wrote:
>>>
>>>> Danny,
>>>>
>>>> I have had several jousts with the IESG reviewers, one of which
>>>> asked me why the document was not on the standards track, especially
>>>> since all but one reference to the reference implementation was
>>>> removed by request. I told them my personal preference was that it
>>>> be on the standards track, especially since there apparently is now
>>>> another implementation. The opinion of the WG as a group might be
>>>> different, in which case the IESG should be so advised.
>>>>
>>>> Dave
>>>>
>>>> Danny Mayer wrote:
>>>>
>>>>> Todd Glassey wrote:
>>>>>  
>>>>>
>>>>>> Danny Mayer wrote:
>>>>>>  
>>>>>>> Todd Glassey wrote:
>>>>>>>
>>>>>>>    
>>>>>>>> In regard to this I-D, its according to the filing obsoletes the
>>>>>>>> RFC1305 document which doesnt seem possible since it is not a RFC,
>>>>>>>> and thoughts?
>>>>>>>>
>>>>>>>> Todd
>>>>>>>>          
>>>>>>>
>>>>>>> Obsoleting an RFC can only happen when the draft becomes an RFC.
>>>>>>> When
>>>>>>> issuing a draft you need to state any RFC that will be obsoleted
>>>>>>> by the
>>>>>>> adoption of the draft. That has nothing to do with Dave, it's
>>>>>>> standard
>>>>>>> IETF process.
>>>>>>>
>>>>>>>  
>>>>>>>     
>>>>>>
>>>>>> Danny my concern was that this document is filed for informational
>>>>>> purposes and I am getting underwriting for NTP and the bonding house
>>>>>> wants that in place.  So I want to make sure NTPv4 RFC happens as
>>>>>> soon
>>>>>> as possible since its already in use.
>>>>>> Todd
>>>>>>   
>>>>>
>>>>> The draft is informational so the bonding house will probably be
>>>>> disappointed that it's not a proposed standard. That of course has
>>>>> nothing to do with the NTPv4 draft RFC.
>>>>>
>>>>> Danny
>>>>>
>>>>>  
>>>>>

---

From: Todd Glassey <[email-masked]>
Date: Sun, 08 Nov 2009 12:03:22 -0800

> The WG does not write or approve code.
Uhh gee Danny yes it does as does the NTP Questions ML. Sorry but they 
are all derivatives of the IETF NTP Initiative and are all tied to the 
IETF's use license. Sorry but that's the way it is.

Todd
> Danny
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.425 / Virus Database: 270.14.54/2488 - Release Date: 11/07/09 23:52:00
>
>

---

From: David Mills <[email-masked]>
Date: Mon, 09 Nov 2009 03:52:23 +0000

Todd,

Wrong yourself. The IETF does not approve or disapprove implementations. 
I have been repeatedly reminded by the IETF and IESG that the reference 
implementation has no place in the standard and, in fact, I have removed 
all references to it other than to point out the specification has been 
implemented, tested and now in regular operation.

Dave

---

From: Todd Glassey <[email-masked]>
Date: Thu, 12 Nov 2009 12:29:53 -0800

David Mills wrote:
> Todd,
>
> Wrong yourself. The IETF does not approve or disapprove 
> implementations. I have been repeatedly reminded by the IETF and IESG 
> that the referrence implementation has no place in the standard and, 
> in fact, I have removed all references to it other than to point out 
> the specification has been implemented, tested and now in regular 
> operation.
No David - that's where the disconnect is. The IETF approves protocols 
for network functionality and that is it. So they can approve the NTP 
protocol and nothing more.

That however means according to their process-protocol approval process 
and standards development practices that there will be at least two (2) 
interoperable implementations of the code that supports that standard 
candidate. The NTP.ORG Reference Implementation  is one of those two 
instances and since it is used as the proof of the protocols 
functionality it also is controlled under their license.

So, I understand why you might want me to be wrong but if you have an 
attorney read the current BCP's for participation and the historical 
documents you will find I am right - since that's what I in fact did.

Anyway - hope all is well with you sir!

Todd Glassey
>
> Dave
>
> Todd Glassey wrote:
>
>> Danny Mayer wrote:
>>
>>> Todd Glassey wrote:
>>>  
>>>
>>>> I am submitting a new utility proposal to the WG for consideration. 
>>>> I will not submit the draft contents to this WG until it agrees 
>>>> that it will allow this new proposed material to the official 
>>>> reference port definitions.
>>>>   
>> Uhh gee Danny yes it does as does the NTP Questions ML. Sorry but 
>> they are all derivatives of the IETF NTP Initiative and are all tied 
>> to the IETF's use license. Sorry but that's the way it is.
>>
>> Todd
>>
>>> Danny
>>>
>>>  
>>> Checked by AVG - www.avg.com Version: 8.5.425 / Virus Database: 
>>> 270.14.54/2488 - Release Date: 11/07/09 23:52:00
>>>
>>>  
>>>
>>
> Version: 8.5.425 / Virus Database: 270.14.55/2490 - Release Date: 11/08/09 19:39:00
>
>

---

From: Danny Mayer <[email-masked]>
Date: Thu, 26 Nov 2009 18:25:32 -0500

> documents you will find I am right - since that's what I in fact did.

Nope. IETF doesn't own or license any reference implementations for any
purpose including interoperability requirements.

Note that BCP's are in any case not a requirement for anything, they are
just best practice documents.

Danny

---

From: Todd Glassey <[email-masked]>
Date: Sun, 29 Nov 2009 09:49:53 -0800

Danny Mayer wrote:
>
> You seem to be determined to make yourself look foolish. The reference
> implementation is not owned by IETF and even the protocol is not owned
> by the IETF. Quoting directly from RFC2026 (BCP9) Section 10.3.1 Item 1:
>   
No Danny just point out how little you know about law.
>      "However, to the extent that the submission is or may
>       be subject to copyright, the contributor, the organization he
>       represents (if any) and the owners of any proprietary rights in
>       the contribution, grant an unlimited perpetual, non-exclusive,
>       royalty-free, world-wide right and license to the ISOC and the
>       IETF under any copyrights in the contribution.  
Uh Danny ask any of the commercial entities here or the University IP 
Acquisition houses whether they would rely on this assignment??? If you 
get a YES then let me ask - who is the company and are they profitable 
because no one in their right mind would accept IP under these terms.

Let me also ask how many really bad contracts sloppy technical people 
have put in place exist? - let me tell you the number is HUGE.
> This license
>       includes the right to copy, publish and distribute the
>       contribution in any way, and to prepare derivative works that are
>       based on or incorporate all or part of the contribution, the
>       license to such derivative works to be of the same scope as the
>       license of the original contribution."
>
> This does *NOT* say that IETF owns the copyright and in fact is says the
> opposite. 
Yes it does now but it didn't back when NTP was originally submitted... 
and that's the point.
> This is laid out in more detail and/or clarification in
> RFC3978 (BCP78) which basically says the same thing. None of the
> documents (including BCP79 - RFC3979) make any ownership claim by the
> IETF over either the protocol or the implementation. 
Sure they do - they make direct publication claims which impact patent 
filing by the rightful IP owners...
> The IETF only gets
> a perpetual license and copyright is retained by the submitter/author or
> organization claiming copyright.
>   
yeah this is one of the other misnomers - its not a perpetual its a 
"Shared Exclusive Right" to ... and that is the key issue here. 
Contracts which fabricate relationships which cannot exist in law are 
void so I suggest that you get the lawyers to really look over that 
contract and the IETF operations documents because its way too late to 
change anything now.
>  Yes
>   
>> the IETF has changed these rules through BCP78 and 79 and the later docs
>> but the earlier versions of the NTP package are totally tied to those
>> previous licenses. Something the IETF has not thought too much about but
>> those licenses cannot be changed ever because of how they were written.
>> So the code used to verify the IETF's Standard's Operation - something
>> that NTP *** MUST *** have to be a standard belongs to the IETF under
>> the earlier rules.
>>     
>
> No. See BCP 9. BCP 78 and BCP 79 both update BCP 9 and there is nothing
> to prevent IETF from updating or obsoleting these documents.
>   
Yes but BCP78/79 process is a revision to a contract which is 
unenforceable after being published on the earlier licensing agreements 
- check with any attorney you want who specializes in IP Licensing.... 
But it gets even funnier - when you read the HEADER of the filing 
itself. The HEADER says

Network 
Working                                                             S. 
Bradner, Ed.
Request for Comments: 3979                                            
Harvard University
BCP: 79 March 2005 Obsoletes: 3668
Updates: 2028, 2026 Category: Best Current Practice

So we read that this DOCUMENT UPDATES RFC2026 meaning that RFC2026 is 
still in effect. Also then it is two fold (1) up to the RELYING PARTY as 
to what they 'Understood" at the time they entered into this agreement.

But you may also want to look at sections 4a and 4.1 on that document 
since there is collateral legal impact of the language of those 
including that ANY WG WHO BLOCKS publication of anyone's submission 
would be in breach of their IETF Responsibilities as a List Operator...
> BCP 9 does not require *any* implementation to exist before becoming a
> Proposed Standard. 
I suggest you ask ISC lawyers about the derivative changes to the IETF's 
process agreements and what the evolution of them means.

 You seem to have the idea that what today's licensing documents say is 
the way it is - except that those previous filings under those previous 
rules makes NTP forever impossible to control - and YES if Dave wants me 
to point out how stupid and incompetent the legal counsel here has been 
because they DIDN'T READ the earlier IETF documents.

Your screwup here Danny is that the IETF "Contract for Performance of 
its Standards Process Practices" is split across a number of documents 
and has been for a while but the terms of the participation of the 
process is set at its original filing and since there is NOTHING in any 
BCP which specifies the IETF has the right to change those terms and 
conditions at any time, any effort originally filed under those terms is 
set for life. Sorry...

So Danny the problem is that the contract between the NTP.ORG entity or 
Dave Mills started back when the IETF published IP 'for any and all 
uses' meaning that code could be built from it. The original intent was 
to make it globally impossible to protect IP and if people would like to 
see photos of when that meeting took place I can arrange it. You will 
see some of the most influential faces in Internet History there and 
they all agreed at the time... And unless there is specific changes to 
that agreement between Dave Mills and the IETF and the IETF can formally 
notify all of the relying parties of those changes - the changes are 
most likely unenforceable in my opinion.

> See Section 4.1.1 of BCP 9. Since NTPv4 was submitted
> on the standards track, it would initially become a proposed standard.
Yes but the submission of the proposed standard took place when the 
original NTP filing was first done with the IETF years ago not when the 
IETF acted on it. The proposed NTP Standard Number has been hanging in 
limbo for a decade that I know of... meaning that that it is controlled 
by the standard process in place at the time it was submitted originally 
- the status of the documents inside the IETF is flawed such that ANYONE 
filing anything with them can demand that all filings take place under 
the terms and conditions in place at the time of the original filing 
because that process "document set" forms a full contract and set 
specific expectations. If you don't believe that check into legal 
precedents where the contracts evolve and change requirements on the fly 
and how enforceable they are without specific agreement by the 
SPONSORING PARTY under the US Copyrights Work for Hire Doctrine.

Todd Glassey

>  A
> Draft Standard wants at least two independent implementations of the
> protocol to move the protocol to draft standard status. See Section
> 4.1.2. Note that none of this requires that IETF owns either the
> protocol or the implementations and in fact IETF does not make such a
> claim. See above.
>   
Not now but the code to support the filing WAS NECESSARY and the instant 
that SOURCE CODE was filed to document the reference port it became the 
property of the IETF... poof all done - and not arguable either. Sorry - 
just because todays document's say the IETF may only own the publication 
rights they didn't used to and since all of the contributed engineering 
(the Vetting) done on NTP in the NTPWG and other places, this makes that 
code also the property of the IETF.

But hey... let me ask a totally unrelated question - I heard that the 
old ISC was nailed for an antitrust matter in something called the  MAPS 
Blacklisting Fiasco- is this true? 

I bring this up because of a Post Dean Anderson made on one of the other 
IETF Lists. Again - is this true or not?

Todd Glassey
> Version: 8.5.426 / Virus Database: 270.14.87/2534 - Release Date: 11/29/09 07:49:00
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Nov 2009 13:52:22 +0000

Todd

Please remind us all (in just a tiny number of words) what you are 
trying to achieve?

- Stewart

---

From: David Mills <[email-masked]>
Date: Mon, 30 Nov 2009 16:41:47 +0000

Guys,

The original submission of rfc1305 was in March of 1992 in PostScript 
and document sources, which conformed to the rules at the time. I got a 
lot of lip at the time because it wasn't in ASCII. So far as I know, the 
specification was never advanced past the draft standard status, which 
was quite informal at the time. I have not then and not now any 
contractural agreement with anybody except the law firmsthat are my 
consulting clients. There is no representation, legal or otherwise, for 
ntp.org other than the kind assisstance of our Intellectual Property 
Attorneys. Neither NTP nor rfc1305 is listed at the IANA, so in a very 
real sense, NTP does not exist.

Publication of the NTPv4 document and  the Autokey document has been 
held up for years. So, in a very real sense, NTP may not exist in future.

Dave

---

From: Todd Glassey <[email-masked]>
Date: Mon, 30 Nov 2009 10:17:49 -0800

> Please remind us all (in just a tiny number of words) what you are 
I am building a set of tools for using the time-source that the TOD in 
host systems for the creation of time-stamps against content - because 
its key that the source of time in the timestamps be the same one 
attesting to the other events in the logging system of that host 
environment. This about building reliable digital evidence.

NTPStamp uses the NTPDate framework and my second generation 
timestamping services (the first was that system originally built by 
Datum and later nCipher) which are built for evidence generation.

It (my new version of NTPDate) comes with a practice use model which 
will reduce the Financial Organization Costs regarding all the headcount 
they created to better isolate their controls in the process workflows. 
The NTPDate functionality also opens the door to my next generation of 
NTP which uses a TCP/SSL tunnel to setup, negotiate, and authorize 
entitlement, and then the existing NTP/UPD transport model to actually 
deploy the time data as a hybrid. NTPDate only uses the TCP/SSl 
interface of Open Connect NTP (what I call the Hybrid Model).

My model creates a local timestamp for every key evidentiary event 
including the stages. The evidence model is something that most NTP 
hacks would choke on since it seems contra-indicated from first topical 
view but when you get into the proof models it all makes sense. 20 years 
ago when Dave and the team invented NTP it was all about reliable 
synchronization. Now that is only a small part of the bigger picture 
since the rampant availability of GPS and other 1PPS sources has made 
precision timekeeping at the PC/Client level possible. Today its all 
about evidence - and end-to-end evidence at that... something about 
'provable chain of custody' and all that.

Todd

> Version: 8.5.426 / Virus Database: 270.14.87/2535 - Release Date: 11/29/09 19:31:00
>
>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 30 Nov 2009 15:24:43 -0500

> No Danny just point out how little you know about law.

The fact is, as you constantly prove, you not only no nothing about law
but you cannot even read and understand correctly what is written.

> because no one in their right mind would accept IP under these terms.

Who cares? Those are the terms, accept them or leave them.

> have put in place exist? - let me tell you the number is HUGE.

Again who cares? It has nothing to do with the IETF rules and agreements.

> Yes it does now but it didn't back when NTP was originally submitted...

Huh?

> "Shared Exclusive Right" to ... and that is the key issue here.

Well since the word "shared", never mind "shared exclusive right" does
not appear anywhere in RFC2026, RFC3978 OR RFC3979 this is not relevant.

> contract and the IETF operations documents because its way too late to

Well at least contract lawyers don't rely on your opinion since it's
wrong every time. A contract *defines* a relationship between two or
more parties so what is there to fabricate? You really need to talk to
someone who knows something about law rather than making it up.

Dave has asked you for your phone number so that he can have the IP
lawyers at UDel talk to you. Have you done that?

Danny