I suggest the following for the protocol maintenance part:
-------- OLD TEXT ------------
The DMM working group will also work on maintenance-oriented and
incremental extensions to the Mobile IPv6 protocol, specified
in RFC 5213, RFC 5844, and RFC 6275.
-------- NEW TEXT -------------
The DMM working group will also work on maintenance-oriented and
incremental extensions to the IPv6 Mobility protocols, specified
in RFC 5213, RFC 5844, RFC 3963, RFC 5555 and RFC 6275.
>-----Message d'origine-----
>De : dmm [mailto:[email protected]] De la part de Jouni Korhonen
>Envoyé : lundi 9 juin 2014 15:52
>À : Alper Yegin
>Cc : [email protected]
>Objet : Re: [DMM] draft charter text updates in github..
>
>
>Alper,
>
>Hmm, I already read it in a way myself I said below but that seems to be only
>me. I'll try to reformulate the text..
>
>- Jouni
>
>6/9/2014 4:24 PM, Alper Yegin kirjoitti:
>> So, Jouni,
>>
>> Is this saying "Some solutions' applicability may be limited to
>> administrative
>domains (i.e., not Internet-wide)", and the point is "DMM WG can accept such
>solutions"?
>>
>> Whatever the point we are trying to make, we better spell it out.
>>
>> Alper
>>
>>
>>
>>
>> On Jun 9, 2014, at 9:35 AM, Jouni wrote:
>>
>>>
>>> On Jun 6, 2014, at 6:52 PM, Alper Yegin wrote:
>>>
>>>> Hi John,
>>>>
>>>> My reading of that sentence is different.
>>>>
>>>> To me it says "We cannot assume that the solutions we are developing
>would be available on all networks across the Internet".
>>>
>>> The highlighted text intend to say:
>>> unless the mobile node is made explicitly aware (by the network) of
>>> the fact that the prefix/address it got will guarantee IP session
>>> continuity, the mobile node cannot assume it to remain unchanged
>>> infinitely when doing handovers and such.. the prefix/address may
>>> remain unchanged e.g. within a limited are e.g. as long as the mobile
>>> node remains within one administrated network domain.
>>>
>>> - JOuni
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> While I'd agree with that statement, I don't know what it really means for
>our solution design.
>>>> Some of our solutions may not be present in a network, hence the MN
>cannot use them. OK.. and??
>>>>
>>>> In my reading, it does not say the following: "Network cannot always
>provide IP session continuity, hence we need to define solutions that can deal
>with this". (e.g., using MPTCP, or restarting flows, or some other magic,
>etc.).
>>>> I don't think the intent of that sentence is this. And therefore, I don't
>think that sentence is related to "anchor re-selection".
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 6, 2014, at 5:56 PM, John Kaippallimalil wrote:
>>>>
>>>>> Hi Alper, All:
>>>>>
>>>>> Towards the end of the charter, there is a paragraph that states:
>>>>> "Although the maintenance of stable home address(es) and/or
>prefix(es)
>>>>> and upper level sessions is a desirable goal when mobile
>hosts/routers
>>>>> change their point of attachment to the Internet, it is not a strict
>>>>> requirement. Mobile hosts/routers should not assume that IP
>>>>> addressing including home address(es) and/or home network
>prefix(es)
>>>>> remain the same throughout the entire upper level session lifetime,
>>>>> or that support for mobility functions is provided on the network
>>>>> side
>>>>> in all conditions, unless these properties are specifically
>>>>> indicated
>>>>> to the mobile node and its applications from the network."
>>>>>
>>>>>
>>>>> I suppose this clarifies that the "anchor re-selection" can apply to a
>single session also?
>>>>>
>>>>> BR,
>>>>> John
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin
>>>>>> Sent: Friday, June 06, 2014 9:38 AM
>>>>>> To: Jouni Korhonen
>>>>>> Cc: [email protected]
>>>>>> Subject: Re: [DMM] draft charter text updates in github..
>>>>>>
>>>>>> Hello Jouni, DMM folks,
>>>>>>
>>>>>> We better clarify what "anchor re-selection" stands for.
>>>>>> If it is about selecting different anchors for different IP flows,
>>>>>> that's one thing.
>>>>>> If it is about changing the IP anchor in the middle of an IP flow,
>>>>>> that's another thing. And that other thing needs to be scoped out.
>>>>>> A basic understanding of a use case would be appreciated (just an
>>>>>> explanation for discussion, I'm not asking for another I-D!), and
>>>>>> identification of various aspects of that scenario which translate to
>work items for DMM WG.
>>>>>>
>>>>>> I won't be in the call today. So, consider this for a discussion.
>>>>>> Follow up on the mailing list afterwards would be good.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Minor changes..
>>>>>>>
>>>>>>> https://github.com/jounikor/dmm-re-
>charter/blob/master/recharter_
>>>>>>> draft.txt
>>>>>>>
>>>>>>> IMHO..the charter as it is today, would allow pretty much any
>>>>>>> solution from
>>>>>> legacy anchoring to herd of pigeons carrying IP.. ;-)
>>>>>>>
>>>>>>> I have put in editorial changes of my own and clear text
>>>>>>> proposals received
>>>>>> from others.
>>>>>>>
>>>>>>> - Jouni
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
