Hi Stewart, Looks like you have most of this in hand. A few comments.
On 27 March 2013 13:11, Stewart Bryant <[email protected]> wrote: >>> In Section 4.4, how does the duration interact with the lifetime? >>> What happens when the duration is longer than lifetime such that the >>> TLV is expunged before the duration is up? > > Well that would normally be a silly thing to do, but we do not propose to > stop > it lest it be something an application actually wants. > > This would be functionally equivalent to issuing a short term note > that was only transiently valid, or issuing some sort of synchronization > message. I can't think why you would want to do it, but why would we > stop it? There was an implicit question here. Namely: Do you want to codify anything regarding expectations on this? Can I rely on an attribute/action with a long duration after the retention interval has expired? >>> Section 5.2 states: >>> [...] If one >>> of the received TLV objects has the same Type as a previously >>> received TLV then the data from the new object SHALL replace the data >>> associated with that Type unless the X specification dictates a >>> different behavior. >>> >>> This leads to different retention characteristics depending on some >>> arbitrary application-specific requirements. It also complicates >>> implementations. Is there a strong motivation for the "unless the X >>> specification dictates a different behavior" part of this statement? > > Yes, on the one hand we do not wish to constrain the applications, and > on the other we trust the application developers and the IETF review > process (required for a code point) to stop silly behaviour. I don't find that answer particularly satisfactory. If I were to build a generic implementation of this, I wouldn't want to allow for this feature because it's a fairly large complication. That's what I'm trying to get to: what motivation can you provide to an implementer to support this feature? And in case I'm not being clear, what would you want to put in the draft? _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
