From nobody Mon Jun 16 03:01:14 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7952E1B2B54 for ; Mon, 16 Jun 2014 03:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pY5tCnCYwHL for ; Mon, 16 Jun 2014 03:01:09 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F281B2B4F for ; Mon, 16 Jun 2014 03:01:08 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 16 Jun 2014 12:01:01 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 16 Jun 2014 12:01:00 +0200 From: To: , , Date: Mon, 16 Jun 2014 12:00:58 +0200 Thread-Topic: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Thread-Index: Ac96xAdpRmLwNK4iSU6mm8fqa1Dz4AOg4nNw Message-ID: <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> In-Reply-To: <538662D3.6050708@venaas.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/pAcGo_2oYYNkSgNyP0Gbxl5DQ8I Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 10:01:12 -0000 Hi all, I also had a look at the latest version -06 and it seems for me to be ok no= w.=20 The only minor concern might be whether the expression "length in four octe= ts" 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:stig@venaas.com]=20 Sent: Donnerstag, 29. Mai 2014 00:28 To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmi= pv6-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=20 > this inherited 8 bit length counter is not long enough to count bytes=20 > of MLD state records, we propose to count four octets. This complies=20 > to the alignment and should not be a problem. However, it leads to a=20 > feasible number of MLD records in the payload which at least comes=20 > close to common packet lengths. Thanks. I'll have a look at this shortly. Great if others can help verify t= hat 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=20 >>>> 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=20 >>>>>> comments inline. >>>>>> >>>>>> On 27.03.2014 16:30, Dirk.von-Hugo@telekom.de wrote: >>>>>> >>>>>>> Sorry that I missed the preceding WGLC - I do think that this=20 >>>>>>> document is ready for publication. It has greatly improved since=20 >>>>>>> version 00 >>>>>>> ;-) >>>>>>> >>>>>>> Though some (minor) nits came to my mind after re-reading: >>>>>>> >>>>>>> p.1. >>>>>>> Updates: 5568 (if approved) =3D> shouldn't be added 5949 since it=20 >>>>>>> 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=20 >>>>>> between MAGs and the MN. Mobility Options are explicitly under=20 >>>>>> the control of IANA. >>>>>> >>>>>>> As mentioned by others for prior versions there is still mixed=20 >>>>>>> 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=20 >>>>>>> PMIP - so no relevance for AR? Otherwise I would expect a=20 >>>>>>> statement like that also a mixed scenario MIP/PMIP is in focus=20 >>>>>>> here ... >>>>>>> I tried to find out whether this was explained in prior posts=20 >>>>>>> but didn't catch any ... sorry if I missed it! >>>>>>> >>>>>> >>>>>> Actually the terms PAR and NAR in parenthesis are used to=20 >>>>>> indicate the correspondence with FMIP ... it does not consider=20 >>>>>> mixed terms, but should help the reader to see that this is all=20 >>>>>> about the same "abstract entities" here. >>>>>> >>>>>>> p.15 >>>>>>> sect. 4.1.3 is on NAR, so I guess: >>>>>>> of the PAR =3D> of the NAR >>>>>>> >>>>>> >>>>>> Yes, thanks. >>>>>> >>>>>>> the NAR joins the groups subscribed >>>>>>> for forwarding on the tunnel link. < sounds puzzling to me=20 >>>>>>> =3D> the NAR joins the groups the MN has subscribed >>>>>>> for (which are then forwarded by PAR) via the tunnel link. <=20 >>>>>>> is it that what is meant? >>>>>>> >>>>>> >>>>>> Yes, thanks. This is better. >>>>>> >>>>>>> p.21 >>>>>>> number of muticast records =3D> number of multicast records >>>>>>> >>>>>> >>>>>> Thanks, fixed. >>>>>> >>>>>>> or Section 4.2 of [RFC3376]) for the =3D> or Section 4.2 of=20 >>>>>>> [RFC3376] for the >>>>>>> >>>>>> >>>>>> Thanks, fixed. >>>>>> >>>>>>> p.23 >>>>>>> 5.5. Length Considerations: Number of Records and Addresses I=20 >>>>>>> understand why the maximum number of multicast address records=20 >>>>>>> is 72 or sources for MLDv2 is 89 (also given in=20 >>>>>>> http://tools.ietf.org/html/rfc3810#section-5.1.10), but I miss a=20 >>>>>>> consideration of specific limitation due to 8-bit Length format=20 >>>>>>> in new Mobility Header Multicast Option (Fig.7). >>>>>>> Have I misunderstood something or isn't there a much stricter=20 >>>>>>> limit for multicast address records to (512-2-4)/(4+16) < 26=20 >>>>>>> (w/o source >>>>>>> addresses) ?? >>>>>>> >>>>>> >>>>>> I guess you hit a point: By bringing back length formatting to=20 >>>>>> standard mobility options recently, we missed that this will not=20 >>>>>> fill an Ethernet packet. I don't think this matters much, but we=20 >>>>>> definitely should adjust the section on length considerations. >>>>>> >>>>>>> for that multicast address to their MLDv2 (IGMPv2) equivalents=20 >>>>>>> =3D> for that multicast address to their MLDv2 (IGMPv3)=20 >>>>>>> equivalents >>>>>>> >>>>>> >>>>>> Thanks, fixed. >>>>>> >>>>>>> Hope this helps >>>>>> >>>>>> Yes, it definitely does. >>>>>> >>>>>> We will wait for the next days to pass the call deadline and=20 >>>>>> resubmit then. >>>>> >>>>> Thanks. Looks like these are the only outstanding issues. Thanks=20 >>>>> for having a careful look Dirk. >>>>> >>>>> Once you submit the new version I'll allow a couple of days for=20 >>>>> myself and others to review changes. If they look good I'll=20 >>>>> request publishing. >>>>> >>>>> If others have any issues, please let us know, even if passed the=20 >>>>> WGLC deadline. >>>>> >>>>> Stig >>>>> >>>>>> Thanks again & best regards, >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: multimob [mailto:multimob-bounces@ietf.org] On Behalf Of=20 >>>>>>> Stig Venaas >>>>>>> Sent: Montag, 24. M=E4rz 2014 21:30 >>>>>>> To: multimob@ietf.org >>>>>>> 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=20 >>>>>>> you believe there are issues with the document or that it is not=20 >>>>>>> ready for other reasons. >>>>>>> >>>>>>> The document has already been reviewed by several people, but it=20 >>>>>>> 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 >>>>>>> multimob@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>> >>>>>>> _______________________________________________ >>>>>>> multimob mailing list >>>>>>> multimob@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nobody Mon Jun 16 03:26:07 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98BC1B2B9F for ; Mon, 16 Jun 2014 03:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Eq0QU7uYc90 for ; Mon, 16 Jun 2014 03:26:02 -0700 (PDT) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262A31B2B54 for ; Mon, 16 Jun 2014 03:26:01 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231109020.adsl.alicedsl.de ([92.231.109.20] helo=[192.168.178.49]) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WwU6x-000HlB-Ch for multimob@ietf.org; Mon, 16 Jun 2014 12:25:59 +0200 Message-ID: <539EC636.2060303@informatik.haw-hamburg.de> Date: Mon, 16 Jun 2014 12:25:58 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/g4cTzoYcTsmkXEJ4B2mdKICh_Zw Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 10:26:05 -0000 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, Dirk.von-Hugo@telekom.de 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:stig@venaas.com] > Sent: Donnerstag, 29. Mai 2014 00:28 > To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org > 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, Dirk.von-Hugo@telekom.de 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:multimob-bounces@ietf.org] On Behalf Of >>>>>>>> Stig Venaas >>>>>>>> Sent: Montag, 24. März 2014 21:30 >>>>>>>> To: multimob@ietf.org >>>>>>>> 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 >>>>>>>> multimob@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> multimob mailing list >>>>>>>> multimob@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > multimob mailing list > multimob@ietf.org > 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: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Mon Jun 16 05:35:36 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FBB1A000F for ; Mon, 16 Jun 2014 05:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdw3Ft43WCvN for ; Mon, 16 Jun 2014 05:35:31 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A059F1A0005 for ; Mon, 16 Jun 2014 05:35:31 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 853D7880E2 for ; Mon, 16 Jun 2014 05:35:31 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3BE3171C0002 for ; Mon, 16 Jun 2014 05:35:31 -0700 (PDT) Message-ID: <539EE499.7010702@innovationslab.net> Date: Mon, 16 Jun 2014 08:35:37 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> <539EC636.2060303@informatik.haw-hamburg.de> In-Reply-To: <539EC636.2060303@informatik.haw-hamburg.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A0sKNHXFRI7f9lnc85gJvPL3FAwMcMq8s" Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/lzHUyczqR42VaGROb1vN80Fwd0A Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 12:35:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A0sKNHXFRI7f9lnc85gJvPL3FAwMcMq8s Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, >=20 > many thanks for you continued effort! >=20 > 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 believ= e > is the more relevant part. >=20 > What is your opinion, Stig? >=20 > Best regards, >=20 > Thomas >=20 > On 16.06.2014 12:00, Dirk.von-Hugo@telekom.de 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:stig@venaas.com] >> Sent: Donnerstag, 29. Mai 2014 00:28 >> To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org >> 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, Dirk.von-Hugo@telekom.de wrote: >>>>>>>> >>>>>>>>> Sorry that I missed the preceding WGLC - I do think that this >>>>>>>>> document is ready for publication. It has greatly improved sinc= e >>>>>>>>> version 00 >>>>>>>>> ;-) >>>>>>>>> >>>>>>>>> Though some (minor) nits came to my mind after re-reading: >>>>>>>>> >>>>>>>>> p.1. >>>>>>>>> Updates: 5568 (if approved) =3D> shouldn't be added 5949 since = it >>>>>>>>> does also update PFMIPv6? >>>>>>>>> >>>>>>>> >>>>>>>> I don't think so. The update of 5568 is with the PrRtAdv-Message= s. >>>>>>>> 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 Fig= s. >>>>>>>>> 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 =3D> of the NAR >>>>>>>>> >>>>>>>> >>>>>>>> Yes, thanks. >>>>>>>> >>>>>>>>> the NAR joins the groups subscribed >>>>>>>>> for forwarding on the tunnel link. < sounds puzzling to me= >>>>>>>>> =3D> 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 =3D> number of multicast records >>>>>>>>> >>>>>>>> >>>>>>>> Thanks, fixed. >>>>>>>> >>>>>>>>> or Section 4.2 of [RFC3376]) for the =3D> 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 >>>>>>>>> =3D> 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:multimob-bounces@ietf.org] On Behalf Of >>>>>>>>> Stig Venaas >>>>>>>>> Sent: Montag, 24. M=E4rz 2014 21:30 >>>>>>>>> To: multimob@ietf.org >>>>>>>>> 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 no= t >>>>>>>>> ready for other reasons. >>>>>>>>> >>>>>>>>> The document has already been reviewed by several people, but i= t >>>>>>>>> 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-m= u >>>>>>>>> lticast-05 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Stig >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> multimob mailing list >>>>>>>>> multimob@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> multimob mailing list >>>>>>>>> multimob@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >=20 --A0sKNHXFRI7f9lnc85gJvPL3FAwMcMq8s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTnuSZAAoJEBOZRqCi7goqJeUIAKlOuksf+JjOGyOLafg8wRoA Leut4iuyhlbOaJ806nk96vRJde3y0xk8vOQW6awRtLPDJY+m7ZfU6lMq9YsCm05C wvA2/x99Tce1yS0q/AWsmHx9NkBrUw/0yz+U4MWxgK9i6WA6TgS2PuNAyh7cbjsD 48sNmuRoyS1wzdKbY5mLMyA3lSFG7RgvUqziutM6yGvDrAmg5yRYEgbdVhUnKZnc wjP8xveDXOMiphPj0xPi4wJUc4P9z0dqzT5Nqsb4tSqe5wd8GNCLBaHOHSzNkTa0 HlNVteb2cv/0pTKwDIaeSbqKEaKLFBE2uiwcrwKlWx3nSwOWQx0nMYpRMpWat3Q= =6R1b -----END PGP SIGNATURE----- --A0sKNHXFRI7f9lnc85gJvPL3FAwMcMq8s-- From nobody Mon Jun 16 13:23:56 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2178D1A01DC for ; Mon, 16 Jun 2014 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EKip-8zxAIm for ; Mon, 16 Jun 2014 13:23:48 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2::152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D71A01C8 for ; Mon, 16 Jun 2014 13:23:48 -0700 (PDT) Received: from [10.154.210.61] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D75AD83BC; Mon, 16 Jun 2014 22:23:43 +0200 (CEST) Message-ID: <539F524B.70301@venaas.com> Date: Mon, 16 Jun 2014 13:23:39 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Haberman , multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> <539EC636.2060303@informatik.haw-hamburg.de> <539EE499.7010702@innovationslab.net> In-Reply-To: <539EE499.7010702@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/2XtXAIggDkMCJbosiM_Lv9q9vK0 Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:23:52 -0000 On 6/16/2014 5:35 AM, 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" This does sound better. Less risk of anyone getting it wrong. You could consider a small example. Just a sentence saying i.e. if the length is 8 octets the length field would be set to 2 or something. Stig > 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, Dirk.von-Hugo@telekom.de 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:stig@venaas.com] >>> Sent: Donnerstag, 29. Mai 2014 00:28 >>> To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org >>> 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, Dirk.von-Hugo@telekom.de 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:multimob-bounces@ietf.org] On Behalf Of >>>>>>>>>> Stig Venaas >>>>>>>>>> Sent: Montag, 24. März 2014 21:30 >>>>>>>>>> To: multimob@ietf.org >>>>>>>>>> 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 >>>>>>>>>> multimob@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> multimob mailing list >>>>>>>>>> multimob@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >>> >> > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From nobody Tue Jun 24 16:48:06 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7311B29E7; Tue, 24 Jun 2014 16:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGM4asXTsprN; Tue, 24 Jun 2014 16:47:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 452F91B29E8; Tue, 24 Jun 2014 16:47:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 468101801C2; Tue, 24 Jun 2014 16:46:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140624234607.468101801C2@rfc-editor.org> Date: Tue, 24 Jun 2014 16:46:07 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/sEsvcgid4b2d9Ut-Cqos4AMnrp4 Cc: drafts-update-ref@iana.org, multimob@ietf.org, rfc-editor@rfc-editor.org Subject: [multimob] RFC 7287 on Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 23:47:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7287 Title: Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Author: T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch Status: Experimental Stream: IETF Date: June 2014 Mailbox: Schmidt@informatik.haw-hamburg.de, shgao@bjtu.edu.cn, hkzhang@bjtu.edu.cn, mw@link-lab.net Pages: 28 Characters: 66766 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-multimob-pmipv6-source-09.txt URL: http://www.rfc-editor.org/rfc/rfc7287.txt Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. This document is a product of the Multicast Mobility Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 26 02:31:38 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12931B2F75; Thu, 26 Jun 2014 02:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdP55YYAnobN; Thu, 26 Jun 2014 02:31:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 139A01B2B21; Thu, 26 Jun 2014 02:31:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626093132.5968.62229.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 02:31:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/PR3CQ0fDXp7mELqLTQXgBgmqHoc Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-07.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 09:31:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers Authors : Thomas C. Schmidt Matthias Waehlisch Rajeev Koodli Godred Fairhurst Dapeng Liu Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-07.txt Pages : 28 Date : 2014-06-26 Abstract: Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay- sensitive real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 26 02:33:11 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C351B2F65 for ; Thu, 26 Jun 2014 02:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jwDO6PNSiw8 for ; Thu, 26 Jun 2014 02:33:06 -0700 (PDT) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3A71B2B21 for ; Thu, 26 Jun 2014 02:33:06 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.22.28.186] by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X063E-000BFP-F9 for multimob@ietf.org; Thu, 26 Jun 2014 11:33:04 +0200 Message-ID: <53ABE8CD.2030509@informatik.haw-hamburg.de> Date: Thu, 26 Jun 2014 11:33:01 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> <539EC636.2060303@informatik.haw-hamburg.de> <539EE499.7010702@innovationslab.net> In-Reply-To: <539EE499.7010702@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/QOOGYwTMUKvCWNkxuptSpa-CteI Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 09:33:09 -0000 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, Dirk.von-Hugo@telekom.de 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:stig@venaas.com] >>> Sent: Donnerstag, 29. Mai 2014 00:28 >>> To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org >>> 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, Dirk.von-Hugo@telekom.de 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:multimob-bounces@ietf.org] On Behalf Of >>>>>>>>>> Stig Venaas >>>>>>>>>> Sent: Montag, 24. März 2014 21:30 >>>>>>>>>> To: multimob@ietf.org >>>>>>>>>> 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 >>>>>>>>>> multimob@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> multimob mailing list >>>>>>>>>> multimob@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> multimob mailing list >>> multimob@ietf.org >>> https://www.ietf.org/mailman/listinfo/multimob >>> >> > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > 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: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Jun 26 10:25:01 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5E1B2B83 for ; Thu, 26 Jun 2014 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u12_tBHE3hI for ; Thu, 26 Jun 2014 10:24:55 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2::152:127]) by ietfa.amsl.com (Postfix) with ESMTP id C464E1B2B8E for ; Thu, 26 Jun 2014 10:24:48 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:1530:ce47:ecb5:8e4f] (unknown [IPv6:2001:420:301:1004:1530:ce47:ecb5:8e4f]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2634C848F for ; Thu, 26 Jun 2014 19:24:46 +0200 (CEST) Message-ID: <53AC5758.1020107@venaas.com> Date: Thu, 26 Jun 2014 10:24:40 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> <539EC636.2060303@informatik.haw-hamburg.de> <539EE499.7010702@innovationslab.net> <53ABE8CD.2030509@informatik.haw-hamburg.de> In-Reply-To: <53ABE8CD.2030509@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/2FaivUxm5Rf0T1JFbw37FVnMQDw Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:24:59 -0000 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, Dirk.von-Hugo@telekom.de 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:stig@venaas.com] >>>> Sent: Donnerstag, 29. Mai 2014 00:28 >>>> To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org >>>> 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, Dirk.von-Hugo@telekom.de 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:multimob-bounces@ietf.org] On Behalf Of >>>>>>>>>>> Stig Venaas >>>>>>>>>>> Sent: Montag, 24. März 2014 21:30 >>>>>>>>>>> To: multimob@ietf.org >>>>>>>>>>> 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 >>>>>>>>>>> multimob@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> multimob mailing list >>>>>>>>>>> multimob@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/multimob >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> multimob mailing list >>>> multimob@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multimob >>>> >>> >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> > From nobody Mon Jun 30 11:01:44 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C84F1A03A5 for ; Mon, 30 Jun 2014 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4Dl5mnin1v8 for ; Mon, 30 Jun 2014 11:01:40 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2::152:127]) by ietfa.amsl.com (Postfix) with ESMTP id 527F81A03A9 for ; Mon, 30 Jun 2014 11:01:34 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:b057:942f:9ebc:f04f] (unknown [IPv6:2001:420:301:1004:b057:942f:9ebc:f04f]) by ufisa.uninett.no (Postfix) with ESMTPSA id A49188324 for ; Mon, 30 Jun 2014 20:01:32 +0200 (CEST) Message-ID: <53B1A5FA.7020108@venaas.com> Date: Mon, 30 Jun 2014 11:01:30 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> <539EC636.2060303@informatik.haw-hamburg.de> <539EE499.7010702@innovationslab.net> <53ABE8CD.2030509@informatik.haw-hamburg.de> <53AC5758.1020107@venaas.com> In-Reply-To: <53AC5758.1020107@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/7gaWd428IYYMSPifEQRYwAmAfso Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:01:42 -0000 Hi I've now requested publication of this document. You can find the writeup and other details in the tracker at https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast/ Stig