Re: DMM framework vs architecture

Hi Julien, Hi Behcet,



Please note that in our opinion the goal of the DMM framework draft is not to define the DMM architecture, but to mainly support (1) the specification and design process of the DMM solutions and (2) the gap analysis within and beyond the mobility protocol space.

As already Marco merntioned, in order to support this process we identify functional entities and possible dependencies between these functions. Of course the type of these functional entities and dependencies can change according to what the DMM wg would want to see.

We think indeed that such a DMM framework is needed before starting to work on DMM solutions.



Also other WGs used this approach, for example, this has been done in the NSIS WG, see below:



http://www.rfc-editor.org/rfc/rfc4080.txt



Best regards,

Georgios



________________________________
Van: [email protected] [[email protected]] namens Julien Laganier [[email protected]]
Verzonden: vrijdag 29 maart 2013 18:16
To: Behcet Sarikaya
Cc: [email protected]
Onderwerp: Re: [DMM] DMM framework vs architecture

Hi Marco,

I guess the point I made you are referring to is moot, given the
timeline for the DMM work. At this stage we are looking at completing
the gap analysis as soon as possible and we would like all the group's
energy to focus on that critical step.

Best,

--julien

On Fri, Mar 29, 2013 at 9:49 AM, Behcet Sarikaya <[email protected]> wrote:
> Hi Marco,
>
> Sorry to interfere as this mail was not addressed to me.
>
> On Mon, Mar 18, 2013 at 5:45 AM, Marco Liebsch <[email protected]>
> wrote:
>>
>> Julien, all,
>>
>> let me comment to your statement in Orlando about the DMM framework
>> draft-liebsch-dmm-framework-analysis:
>>
>> You commented that the framework assumes an architecture. Well, yes, a
>> 'functional' architecture as it's always done by a functional framework.
>> We identify functional entities and dependencies between these functions.
>> Dependencies are coordinated via reference points/interfaces between
>> these functions. Functions can be co-located to a single protocol
>> architecture
>> component or distributed. Functions and reference points may apply to a
>> solution
>> or may not, dependent on the targeted protocol support and requirements.
>> So, the draft does not go beyond what a framework should do.
>> It simply supports building any protocol solution without being dependent
>> on the underlaying protocols.
>>
>> Please see e.g. RFC 3154, which did the same for Dormant Mode Host
>> Alerting.
>> The approach applies to many other frameworks.
>>
>
> I am one of the co-authors of RFC 3154.
> It was nostalgic for me to see your reference to this work. I believe that
> IETF missed a good opportunity to make some difference in mobile networks by
> staying out of developing an IP based paging protocol.
>
> I think you are referring to Section 5 in this document.
> The functional architecture in Section 5 was an obvious one, it was built on
> widely agreed components and their connections.
>
> I can not see how you are going to project it to the DMM case? In dmm we do
> not yet have the same consensus on the architectural entities. Until then it
> is good to keep different choices up and help build consensus on one such
> thing whatever it is.
>
> Behcet
>>
>> Hope you can agree to this approach.
>>
>> marco
>>
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm