Re: DMM framework vs architecture
Marco Liebsch <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <69756203DDDDE64E987BC4F70B71A26D55213FA7__29070.0900521644$1365000351$gmane$org@DAPHNIS.office.hd> |
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 >>