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

[Stig Venaas <[e-mail]>]

Hi

On 6/26/2014 2:33 AM, Thomas C. Schmidt wrote:
> Hi all,
>
> as no more comments arrived, we have just updated the draft with the
> proposed text.

Great. I'll request publishing of this then. I'll try to get this
done early next week. Please everyone, have a look at the latest
document and let us know if any concerns. If you read the previous
versions the couple of latest diffs would be of help. See
http://tools.ietf.org/wg/multimob/draft-ietf-multimob-fmipv6-pfmipv6-multicast/
for the different versions and diffs.

Stig

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