Re: comments on draft-ietf-itrace-03

I'm sorry -- I should have responded to the original note.  Most of my responses 
would have been: "Agreed.  I'll make the necessary changes."

I'm glad the second timestamp issue has been brought out.  I am the one who made the 
change on my own initiative, because I foresaw the possibility of a significant time 
lapse between when the traced packet was captured and when the the trace packet was 
formatted and sent out (e.g. if the traced packets got sent to an off-board computer 
for processing).  I pointed out this change to Marcus and Steve at the time, but I 
should have sent a note to the general list.  If people don't think this is needed, 
I'll take it out again.

Mikael Olsson wrote:
> This is basically a "me too" post, but given the utter lack
> of responses, I guess any response is better than none.
> 
> Pekka Savola wrote:
> 
>>   2.5 Traced packet (TAG=0x09)
>>
>>      This element provides the contents of the traced packet, as much as
>>      can reasonably fit, subject to link and router resource constraints.
>>      This element MUST be present at the top level within the TRACEBACK
>>      message, and MUST contain at least the IP header and the first 64
>>      bits of the body of the traced packet.
>>
>>==> [send more]
> 
> 
> Agree. I think the spec should say "include as much as possible
> up to the max ICMP data length".
> 
> 
> 
>>   2.8 Authentication data
>>
>>==> this section does not seem to take a stance whether this
>>MAY/SHOULD/... be included.
>>
>>           * timestamp of the time at which the hash was taken, NTP
>>              format (eight octets)
>>
>>==> [why _two_ timestamps?]
> 
> 
> I was wondering about this, too.  Would someone care to shed some 
> light on the design decision here?
> 
> 
> 
>>     The public-key information element can be used to discover the
>>      appropriate public keys, and other related information.
>>      This element contains a URL, pointing to an XML page that contains
>>      the public key used to sign key-disclosure elements.
>>
>>==> is this kind of XML referral commonplace in security architectures?
>>I've never come across that myself..
> 
> 
> I also fail to see the point of adding XML to the mix.
> Why not just state that the URL should point to an X.509 cert?
> 
> Plain X.509 certs _are_ after all a proposed internet standard
> (RFC 2459/3280), and there are (proposed) standardized ways of
> obtaining X.509 certs via HTTP, FTP and LDAP; see RFC 2585 
> (HTTP+FTP) and RFC 2587 (LDAP).  They do not include XML.
> 
> Is there an additional reason for using XML that I am 
> not aware of?
> 
> Oh, wait, here's an interesting point: certs have "acceptable
> use" parameters, e.g. "may be used for email", "may be used
> for web servers".  I believe (but am not certain) that these
> fields are easily extended.  Should we register a "may be
> used for itrace" acceptable use field?
> (Any PKI wizards around that can comment on this?)
> 
> 
> 
>>==> I've always seen [TLV] spelled out Type-Length-Value, but I guess 
>>[tag-length-value] is ok too..
> 
> 
> Same here. Or even "Type-Length-Value tags".
> 
>