Re: [manet] DLEP-17: duplicate functions - Options & extensions negotiations

[Rick Taylor <[e-mail]>]

On 10/12/15 14:39, Wiggins, David - 0665 - MITLL wrote:
> Extensions can add status codes too.
>
> I can see a use for an extension that does not add any signals/messages,
> data items, or status codes; it just adds behavior.  In particular, it
> allows new combinations of the protocol elements that were previously
> disallowed.  For example, an extension could allow an existing data item
> on an existing signal.  dlep-17 appears to allow this, section 6 paragraph
> 1: 
>
>     Such extensions are defined as *additional rules of behaviour,*
>     messages, data items and/or status codes that are not defined in this
>     document.
>
>
> I've been thinking about this because of the discussion about which data
> items (if any) should be allowed to appear on a Destination Up coming from
> the router.  Let's say the result of that discussion is that we clamp down
> hard and don't allow any data items other than the MAC address, and that
> MAC address MUST represent a multicast address.  However, someone :) would
> like the router to be able to advertise IP addresses and subnets that it
> provides access to so that the modem can propagate this to the other side
> (using a non-DLEP protocol).  So, we could add an extension that relaxes
> Destination Up and Update to allow 1) unicast MAC addresses coming from
> the router (the router would put its own MAC address), and 2) IP address
> and IP subnet data items.  The extension would of course define what this
> new combination means.  It adds no new messages or data items, but it's a
> useful extension (to us).
>
> You could certainly do this with a new message too, but a small tweak to
> the allowed data items seems cleaner and easier to deal with to me.

I completely agree here.  This is exactly how I see extensions being used.
>
> David
>
> On 12/10/15, 8:15 AM, "manet on behalf of Dearlove, Christopher (UK)"
> <[e-mail] on behalf of [e-mail]> wrote:
>
>> I'm not convinced by that example. Two extensions operating the way you
>> describe is a potential interoperability nightmare. Different algorithms
>> for calculating the flow control is already an issue - but is the same
>> extension.
>>
>> -----Original Message-----
>> From: Henning Rogge [mailto:[e-mail]]
>> Sent: 10 December 2015 12:39
>> To: Dearlove, Christopher (UK)
>> Cc: Lou Berger; [e-mail]; MANET IETF
>> Subject: Re: [manet] DLEP-17: duplicate functions - Options & extensions
>> negotiations
>>
>> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partner
>> or from the internet.
>> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for instructions
>> on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>> On Thu, Dec 10, 2015 at 1:33 PM, Dearlove, Christopher (UK)
>> <[e-mail]> wrote:
>>> I think it's worth just thinking about this. Can you suggest a
>>> plausible example where you need more information than just new
>>> message and data item types? It can be an alien space bats example ;)
>>>
>>> (Of course there's more needed implicitly - such as what to do with a
>>> new message type. But the required information can be carried by just
>>> the new message type number.)
>> We might have different kinds of "flow control" extensions using the same
>> kind of message.
>>
>> Someone write "Flow Control Extension A"... and from the experiments we
>> learned that we can do a bit better than it, but its still a mutual
>> exclusive choice. So the author writes "Flow Control Extension B"
>> which reuse the messages he designed for A.
>>
>> Henning Rogge
>> ********************************************************************
>> This email and any attachments are confidential to the intended
>> recipient and may also be privileged. If you are not the intended
>> recipient please delete it from your system and notify the sender.
>> You should not copy it or use it for any purpose nor disclose or
>> distribute its contents to any other person.
>> ********************************************************************
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet