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

["Wiggins, David - 0665 - MITLL" <[e-mail]>]

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.

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