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

[Stig Venaas <[e-mail]>]

Hi

On 4/22/2014 11:13 AM, Thomas C. Schmidt wrote:
> Hi Stig,
>
> sorry, we've been busy otherwise.
>
> We'll try to update asap.

How is this going? Looks like we're still waiting.

Stig

> 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
>>>>>
>>>>
>>>
>>
>