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

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

Hi all,

as no more comments arrived, we have just updated the draft with the 
proposed text.

Best,

Thomas

On 16.06.2014 14:35, Brian Haberman wrote:
> You could always borrow legacy text from RFC 791...
>
> "Internet Header Length is the length of the internet header in 32 bit
> words"
>
> Regards,
> Brian
>
> On 6/16/14 6:25 AM, Thomas C. Schmidt wrote:
>> Hi Dirk,
>>
>> many thanks for you continued effort!
>>
>> Making the bit counting more apparent, should not be a problem. I agree
>> that this is a somewhat uncommon way of counting, but prevents us from
>> changing the encoding structure of the mobility options, which I believe
>> is the more relevant part.
>>
>> What is your opinion, Stig?
>>
>> Best regards,
>>
>> Thomas
>>
>> On 16.06.2014 12:00, [e-mail] wrote:
>>> Hi all,
>>> I also had a look at the latest version -06 and it seems for me to be
>>> ok now.
>>> The only minor concern might be whether the expression "length in four
>>> octets" is familiar enough (I didn't find this in any other draft) or
>>> should be mentioned especially in terms of a warning "caution!" or
>>> explicit (e.g. "i.e. 32 bit") or similar?
>>> Otherwise I am fine with it ...
>>> Thanks!
>>> Best regards
>>> Dirk
>>>
>>> -----Original Message-----
>>> From: Stig Venaas [mailto:[e-mail]]
>>> Sent: Donnerstag, 29. Mai 2014 00:28
>>> To: Thomas C. Schmidt; von Hugo, Dirk; [e-mail]
>>> Subject: Re: [multimob] Working group last call for
>>> draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
>>>
>>> Hi
>>>
>>> On 5/22/2014 4:29 AM, Thomas C. Schmidt wrote:
>>>> Hi Stig, Dirk,
>>>>
>>>> we just updated the document - sorry for me being slow.
>>>>
>>>> We have fixed all nits that you pointed at.
>>>>
>>>> In particular, the length counter issue should be resolved now: As
>>>> this inherited 8 bit length counter is not long enough to count bytes
>>>> of MLD state records, we propose to count four octets. This complies
>>>> to the alignment and should not be a problem. However, it leads to a
>>>> feasible number of MLD records in the payload which at least comes
>>>> close to common packet lengths.
>>>
>>> Thanks. I'll have a look at this shortly. Great if others can help
>>> verify that this change is OK as well.
>>>
>>> Stig
>>>
>>>> Best,
>>>>
>>>> Thomas
>>>>
>>>>
>>>> On 19.05.2014 22:00, Stig Venaas wrote:
>>>>> 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-mu
>>>>>>>>>> lticast-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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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] °