Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05

["Thomas C. Schmidt" <[e-mail]>]

Hi Stig,

sorry, we've been busy otherwise.

We'll try to update asap.

Cheers,

Thomas

On 22.04.2014 19:29, Stig Venaas wrote:
> Thomas/authors, I think we're just waiting for 06 with these minor
> changes and we can request publication.
>
> Stig
>
> On 4/3/2014 2:15 PM, Stig Venaas wrote:
>> Hi
>>
>> On 3/31/2014 2:57 PM, Thomas C. Schmidt wrote:
>>> Hi Dirk,
>>>
>>> many thanks for carefully looking through the draft. Please see comments
>>> inline.
>>>
>>> On 27.03.2014 16:30, [e-mail] wrote:
>>>
>>>> Sorry that I missed the preceding WGLC - I do think that this document
>>>> is ready for publication. It has greatly improved since version 00 ;-)
>>>>
>>>> Though some (minor) nits came to my mind after re-reading:
>>>>
>>>> p.1.
>>>> Updates: 5568 (if approved) => shouldn't be added 5949 since it does
>>>> also update PFMIPv6?
>>>>
>>>
>>> I don't think so. The update of 5568 is with the PrRtAdv-Messages. 5949
>>> does not contain such things, as there is no explicit messaging between
>>> MAGs and the MN. Mobility Options are explicitly under the control of
>>> IANA.
>>>
>>>> As mentioned by others for prior versions there is still mixed usage
>>>> of FBack, Hack, ... and FBACK, HACK, ...
>>>> Same for PMAG/NMAG and pMAG/nMAG.
>>>>
>>>
>>> Oh yes, that was in the figures ...
>>>
>>>> p.10ff
>>>> "Section 3.3.  Protocol Operations Specific to PFMIPv6" and Figs. 4/5
>>>> do include "PMAG (PAR)" and "NMAG (NAR)" - isn't it all about PMIP -
>>>> so no relevance for AR? Otherwise I would expect a statement like that
>>>> also a mixed scenario MIP/PMIP is in focus here ...
>>>> I tried to find out whether this was explained in prior posts but
>>>> didn't catch any ... sorry if I missed it!
>>>>
>>>
>>> Actually the terms PAR and NAR in parenthesis are used to indicate the
>>> correspondence with FMIP ... it does not consider mixed terms, but
>>> should help the reader to see that this is all about the same "abstract
>>> entities" here.
>>>
>>>> p.15
>>>> sect. 4.1.3 is on NAR, so I guess:
>>>> of the PAR => of the NAR
>>>>
>>>
>>> Yes, thanks.
>>>
>>>> the NAR joins the groups subscribed
>>>>     for forwarding on the tunnel link. < sounds puzzling to me
>>>> => the NAR joins the groups the MN has subscribed
>>>>     for (which are then forwarded by PAR) via the tunnel link. < is it
>>>> that what is meant?
>>>>
>>>
>>> Yes, thanks. This is better.
>>>
>>>> p.21
>>>> number of muticast records => number of multicast records
>>>>
>>>
>>> Thanks, fixed.
>>>
>>>> or Section 4.2 of [RFC3376]) for the => or Section 4.2 of [RFC3376]
>>>> for the
>>>>
>>>
>>> Thanks, fixed.
>>>
>>>> p.23
>>>> 5.5.  Length Considerations: Number of Records and Addresses
>>>> I understand why the maximum number of multicast address records is 72
>>>> or sources for MLDv2 is 89 (also given in
>>>> http://tools.ietf.org/html/rfc3810#section-5.1.10), but I miss a
>>>> consideration of specific limitation due to 8-bit Length format in new
>>>> Mobility Header Multicast Option (Fig.7).
>>>> Have I misunderstood something or isn't there a much stricter limit
>>>> for multicast address records to (512-2-4)/(4+16) < 26 (w/o source
>>>> addresses) ??
>>>>
>>>
>>> I guess you hit a point: By bringing back length formatting to standard
>>> mobility options recently, we missed that this will not fill an Ethernet
>>> packet. I don't think this matters much, but we definitely should adjust
>>> the section on length considerations.
>>>
>>>> for that multicast address to their MLDv2 (IGMPv2) equivalents
>>>> => for that multicast address to their MLDv2 (IGMPv3) equivalents
>>>>
>>>
>>> Thanks, fixed.
>>>
>>>> Hope this helps
>>>
>>> Yes, it definitely does.
>>>
>>> We will wait for the next days to pass the call deadline and resubmit
>>> then.
>>
>> Thanks. Looks like these are the only outstanding issues. Thanks for
>> having a careful look Dirk.
>>
>> Once you submit the new version I'll allow a couple of days for myself
>> and others to review changes. If they look good I'll request publishing.
>>
>> If others have any issues, please let us know, even if passed the WGLC
>> deadline.
>>
>> Stig
>>
>>> Thanks again & best regards,
>>>
>>> Thomas
>>>
>>>
>>>>   -----Original Message-----
>>>> From: multimob [mailto:[e-mail]] On Behalf Of Stig
>>>> Venaas
>>>> Sent: Montag, 24. März 2014 21:30
>>>> To: [e-mail]
>>>> Subject: [multimob] Working group last call for
>>>> draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
>>>>
>>>> This is a working group last call for
>>>> draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
>>>>
>>>> Please state whether you think it is ready for publishing or if you
>>>> believe there are issues with the document or that it is not ready for
>>>> other reasons.
>>>>
>>>> The document has already been reviewed by several people, but it is
>>>> still good to hear from the working group what you think.
>>>>
>>>> The last call ends one week from now on Monday March 31st.
>>>>
>>>> The draft is available at
>>>> http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
>>>>
>>>>
>>>>
>>>>
>>>> Stig
>>>>
>>>> _______________________________________________
>>>> multimob mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/multimob
>>>>
>>>> _______________________________________________
>>>> multimob mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/multimob
>>>>
>>>
>>
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °