Re: draft charter text updates in github..

Right, RFC5555 should be there.

- Jouni

6/10/2014 3:56 PM, [email protected] kirjoitti:
> 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.
>