Hal Murray <hmur...@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.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
