Re: [Gen-art] Gen-ART review of draft-ietf-mpls-gach-adv-06

[Martin Thomson <[e-mail]>]

Hi Stewart,

Looks like you have most of this in hand.  A few comments.

On 27 March 2013 13:11, Stewart Bryant <[e-mail]> 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?