nts_lib

Eric S. Raymond esr at thyrsus.com
Thu Feb 7 15:34:42 UTC 2019


Hal Murray <hmurray at megapathdsl.net>:
> I'd probably put an NTS_KE_ in front of all the record_types, IANA_ on the 
> crypto list, and NTP_EX_ on the NTP extension types.

No objection from here.

> Maybe:
>   ntp_append_record(&buffer-blk, type, length, &data, pad)
> It would byte-swap and append the type and length, copy the data, and maybe 
> pad.
> It would silently truncate if it didn't fit.
> The caller could check for nothing left after putting everything in to see if 
> it overflowed.
> 
> On receive, I think I want a ntp_next_record that would return the type, store 
> the length iand pointer to data in arguments, and bump the pointer to the next 
> record.  It can't copy the data anyplace because I don't know where I want to 
> put it until I dispatch on the type.
> 
> We probably want special routines that handle the data being a 2 byte int.

Do you want me to write those?

> Eric:
> 
>   I'm still not happy with your nts_decorate and nts_validate.  We can sort 
> that out later.

Suggestions cheerfully accepted.  I did the simplest thing I could think of to
isolate the NTS code from the protcol machine.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.




More information about the devel mailing list