Re: DMM framework vs architecture

As I said for the time being we'd like the WG to focus on completing
the existing deliverables.

Thank you.

On Wed, Apr 3, 2013 at 7:44 AM, Marco Liebsch <[email protected]> wrote:
> Julien,
> not sure what you mean with moot. We are aware that a framework is not yet
> considered by the charter. And I agree that the WG's focus should be on the
> current charter items. However, the group is discussing requirements now for
> 1.5 years.. Looking ahead now and providing input that can help the WG to
> progress does not seem to be a bad idea, IMHO. And there was some support
> from the WG for having a framework.
>
> marco
>
>
>
>
>>-----Original Message-----
>>From: Julien Laganier [mailto:[email protected]]
>>Sent: Freitag, 29. März 2013 18:17
>>To: Behcet Sarikaya
>>Cc: Marco Liebsch; [email protected]
>>Subject: 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
>>>