On 27/03/2013 21:41, Martin Thomson wrote:
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?
That is surely an application issue.
The TX advertizes a parameter, and says how long it assumes it to be valid.
What the application does with it is up to the application.
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?
.
A case where data might not be replaced would be a case where it was logged.
For example I might report the temperature of my optical interface and
want a small history, or I might want a small history of alarm events.
Alternatively if the event rate was too fast for the RX process some
types might be fifoed.
Our point was to specify the normal behaviour, but permit an application
to request a variation. Given that this is an advertisment protocol,
the normative behaviour is the TX side and the RX side is largely
illustrative,
because what the RX does with any of this is optional, so I do not think
there
is an issue here.
- Stewart
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
