Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

[Brian Haberman <[e-mail]>]

Carlos is correct, these type of acknowledgements are acceptable.  They
have been in several RFCs published with similar statements.

Brian

On 7/2/14 9:51 AM, Carlos Jesús Bernardos Cano wrote:
> Hi Pierrick,
> 
> This should be fine. I've put similar statements in previous documents
> and I haven't had any problems so far. The statement just refers to my
> work (e.g., supporting travels, etc).
> 
> Carlos
> 
> On Wed, 2014-07-02 at 13:37 +0000, [e-mail] wrote:
>> Hi,
>>
>> Just a minor comment:
>>
>> The acknowledgement section states that this work has been partially funded by the European Community via a research project. Is such statement acceptable for an IETF document? Shoudn't we remove this ack?
>>
>> Pierrick
>>
>>> -----Message d'origine-----
>>> De : Carlos Jesús Bernardos Cano [mailto:[e-mail]]
>>> Envoyé : mercredi 2 juillet 2014 02:38
>>> À : Hidetoshi Yokota
>>> Cc : Sri Gundavelli; SEITE Pierrick IMT/OLN; [e-mail]
>>> Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-
>>> 09.txt]
>>>
>>> Hi Hidetoshi,
>>>
>>> Thanks again for your comments. Please see inline below some
>>> comments/replies from my side:
>>>
>>> On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote:
>>>> Hi Carlos,
>>>>
>>>> I briefly reviewed the updated draft and have a couple of comments.
>>>>
>>>> o The messages named as FMI/FMA in this document are actually
>>> UPN/UPA,
>>>> so the description is confusing since it looks as if new messages were
>>>> defined. I would propose a new flag or notification reason/status code
>>>> to indicate that UPN/UPA are used for flow mobility.
>>>
>>> The use of FMI/FMA is simply to make clearer that these UPN/UPA messages
>>> are for flow mobility purposes. New notification reason codes are actually
>>> defined in the document for this purpose.
>>>
>>>>
>>>> o In the previous version, FMI could convey the Flow ID mobility
>>>> option, but the latest version can convey only HNPs. This looks like a
>>>> degradation and I'm not sure how both LMA and MAG can share the same
>>>> flow mobility cache.
>>>
>>> With the UPN/UPA signaling option, the document has never supported
>>> conveying the Flow ID mobility option. Ensuring that both the LMA and MAG
>>> keep the same flow mobility cache was out of the scope of the document. If
>>> the WG agrees, we could add the possibility of supporting UPN/UPA
>>> (FMI/FMA) optionally conveying the Flow ID mobility option. What do other
>>> people think?
>>>
>>>>
>>>> o The flow mobility operation such as "add" or "remove" should be able
>>>> to specify the targeted flow. To this end, the Flow ID mobility option
>>>> in RFC6089 should be used. The flow binding action sub-option defined
>>>> in
>>>> RFC7109 can be used for the flow mobility operation.
>>>
>>> In the current version "add" and "remove" are performed with prefix
>>> granularity (as I mentioned in a previous e-mail, this was the consensus
>>> reached some time ago, but we can revisit this if the WG wants to do so).
>>>
>>> Thanks!
>>>
>>> Carlos
>>>
>>>>
>>>> Please take these points into consideration.
>>>>
>>>> Regards,
>>>> --
>>>> Hidetoshi
>>>>
>>>> (2014/06/26 7:05), Carlos Jesús Bernardos Cano wrote:
>>>>> Hi,
>>>>>
>>>>> I've just posted -10, now including only one single signaling
>>>>> mechanisms, as discussed on the ML.
>>>>>
>>>>> I think this version is ready for WGLC.
>>>>>
>>>>> Carlos
>>>>>
>>>>> On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote:
>>>>>> Hi Carlos/All,
>>>>>>
>>>>>>
>>>>>> Can we plan to close this work in the next few days. AFAIK, this
>>>>>> FMI/FMA issue is now resolved. If you still doubt the consensus on
>>>>>> this issue, we can wait for 2 days for any comments and post the
>>>>>> next rev.
>>>>>>
>>>>>>
>>>>>> I'm hoping we will close this work this week and go LC on Monday
>>>>>> (if chairs agree). Waiting for Toronto meeting can delay the work
>>>>>> by another few months.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>> From: Sri Gundavelli <[e-mail]>
>>>>>> Date: Thursday, June 19, 2014 6:46 AM
>>>>>> To: "[e-mail]" <[e-mail]>,
>>>>>> Hidetoshi Yokota <[e-mail]>, "[e-mail]"
>>>>>> <[e-mail]>
>>>>>> Subject: Re: [netext] [Fwd: I-D Action:
>>>>>> draft-ietf-netext-pmipv6-flowmob-09.txt]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Pierrick,
>>>>>>
>>>>>>
>>>>>> After the NETEXT meeting in London, we had some offline discussions
>>>>>> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN)
>>>>>> messaging format for FMI/FMA. So, the Flow Mobility spec may refer
>>>>>> to this message as FMI/FMA, but the underneath messaging format
>>>>>> will confirm to RFC-7077 format and will have references to
>>>>>> RFC-7077. We are not going to define a new MH message. This closes
>>>>>> the key issue of using two notification approaches in the same
>>>>>> spec. AFAIK, no one has any objection to this. If any does, its now
>>>>>> time to speak up :)
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Sri
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: "[e-mail]" <[e-mail]>
>>>>>> Date: Thursday, June 19, 2014 1:32 AM
>>>>>> To: Hidetoshi Yokota <[e-mail]>, "[e-mail]"
>>>>>> <[e-mail]>
>>>>>> Subject: Re: [netext] [Fwd: I-D Action:
>>>>>> draft-ietf-netext-pmipv6-flowmob-09.txt]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Hidetoshi/all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in
>>>>>> London, we have decided (group consensus) to reintroduce FMI/FMA to
>>>>>> avoid dependency between RFC. Now, it’s true that introducing 2
>>>>>> options for message format makes the solution more complex for
>>>>>> little added-value (no major differences between messages)… So,
>>>>>> maybe the question is “is it good or bad to have RFC dependency?”
>>>>>> then update the draft according the answer...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pierrick
>>>>>>
>>>>>>
>>>>>>
>>>>>> De : netext [mailto:[e-mail]] De la part de
>>>>>> Hidetoshi Yokota Envoyé : jeudi 19 juin 2014 06:41 À :
>>>>>> [e-mail] Objet : Re: [netext] [Fwd: I-D Action:
>>>>>> draft-ietf-netext-pmipv6-flowmob-09.txt]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello Carlos,
>>>>>>
>>>>>> Thanks for updating the draft.
>>>>>> I have a couple of questions and comments:
>>>>>>
>>>>>> o In Section 3.2.1, which is the shared prefix case, there is no
>>>>>> message exchange between the LMA and MAG, so there is no flow
>>>>>> information on the MAG side. It should work in the sense of
>>>>>> routing, but if, for example, each flow has a specific QoS, the MAG
>>>>>> should also need to know which flow should go on which QoS path
>>>>>> especially for upstream traffic towards the LMA. Or, the MAG may
>>>>>> want to send a trigger for flow mobility to the MN (the exact
>>>>>> mechanism is out of scope).  Some mobility signaling should be there,
>>> too.
>>>>>>
>>>>>> o In Section 3.3, FMI/FMA are revived considering the case where
>>>>>> UPN is not supported, but they convey very little information.
>>>>>> There is no special information that cannot be conveyed by the existing
>>> messages.
>>>>>> Since RFC7077 is now a proposed standard, I cannot think of a
>>>>>> situation where the UPN/UPA are not supported, nevertheless
>>> FMI/FMA
>>>>>> are supported. It rather seems more natural to mandate the support
>>>>>> of
>>>>>> RFC7077 or to mandate FMI/FMA for all flow mobility operations.
>>>>>> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
>>>>>> convey different set of parameters in Figure 7. Could you clarify
>>>>>> it a little bit more please?
>>>>>>
>>>>>> o In Section 3.3, just above Figure 7, there is a description:
>>>>>> "..., and the type of flow mobility operation (add flow)", but does
>>>>>> RFC6089 define such an operation code? This kind of operation
>>>>>> should also be defined in the draft.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Hidetoshi Yokota
>>>>>>
>>>>>> KDDI R&D Laboratories, Inc.
>>>>>> e-mail:[e-mail]
>>>>>>
>>>>>>
>>>>>>
>>>>>> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:
>>>>>>
>>>>>>
>>>>>>          Hi,
>>>>>>
>>>>>>          As agreed in London, I've updated the flow mobility draft to include
>>>>>>          also the FMI/FMA signaling option (in addition to the use of Update
>>>>>>          Notifications). The draft also includes a mechanism to allow selecting
>>>>>>          which one of the two signaling mechanisms to use.
>>>>>>
>>>>>>          In my personal opinion, it'd be much cleaner and simpler to just
>>> specify
>>>>>>          one signaling mechanism, but this is up to the WG to decide.
>>>>>>
>>>>>>          Comments, reviews and discussion on this new revision would be
>>> welcome.
>>>>>>          Hopefully we could get at least a new revision before Toronto.
>>>>>>
>>>>>>          Thanks,
>>>>>>
>>>>>>          Carlos
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>          _______________________________________________
>>>>>>          netext mailing list
>>>>>>          [e-mail]
>>>>>>          https://www.ietf.org/mailman/listinfo/netext
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> ___________________________________________________________
>>> ________
>>>>>> ______________________________________________________
>>>>>>
>>>>>> 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.
>>>>>> _______________________________________________
>>>>>> netext mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
> 
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext
>