Document status is at http://datatracker.ietf.org/wg/behave/ Our preliminary agenda is at http://www.ietf.org/proceedings/80/agenda/behave.html If you want a slot, please email me. We have a 2.5 hour slot on Tuesday and a 2 hour slot on Friday. -d
Thank you Dave very much for your comments - we are already working on new revision. Some replies and clarifying questions inline: > -----Original Message----- > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf Of > ext Dave Thaler > Sent: 28. helmikuuta 2011 22:56 > To: behave <at> ietf.org > Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 > > I have reviewed the latest version and have two main technical comments. > I also have lots of editorial nits that I will send directly to the authors. > The main technical comments are summarized as follows. > > 1) There are three ways to implement the ENR. > a) at the API layer (works fine with DNSSEC) > b) as a recursive resolver on the same host as discussed in Appendix A > (I believe this has the same properties as DNS64 with respect to > DNSSEC impact) > c) in the network stack as shown in figure 2 (I think this breaks DNSSEC) > > Currently the document allows all three options, though seems to > treat (a) and (c) as equally recommended, and (b) is almost an > afterthought. Agree, the (a) comes from BIA and (c) from BIS, and this (b) is indeed newer thinking. Will look if this could be clarified. But I would not say (c) breaks DNSSEC more than network-based DNS64...(Continue reading)Works as long as host's resolver does not do its own validation. > I would prefer a stronger recommendation towards things that work
We have prepared this document to help sort out the multicast transition work in the BEHAVE and SOFTWIRES WGs. Please have a look at and comment on the conclusions. A new version of I-D, draft-tsou-multicast-transition-taxonomy-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-multicast-transition-taxonomy Revision: 00 Title: A Classification and Evaluation of Approaches to Transitional Multicast Creation_date: 2011-02-28 WG ID: Independent Submission Number_of_pages: 12 Abstract: A number of different contributions to the IETF make proposals in support of multicast during the transition from IPv4 to IPv6. This document provides a taxonomic framework to make it easier to see how the different proposals relate to each other. It analyzes the current work in progress in the light of this framework and draws a number of conclusions regarding how this work should move forward in the BEHAVE and SOFTWIRES Working Groups.
> -----Original Message----- > From: teemu.savolainen <at> nokia.com [mailto:teemu.savolainen <at> nokia.com] > Sent: Tuesday, March 01, 2011 7:49 AM > To: Dave Thaler; behave <at> ietf.org > Subject: RE: Comments on draft-ietf-behave-v4v6-bih-02 > > Thank you Dave very much for your comments - we are already working on > new revision. Some replies and clarifying questions inline: > > > -----Original Message----- > > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On > > Behalf Of ext Dave Thaler > > Sent: 28. helmikuuta 2011 22:56 > > To: behave <at> ietf.org > > Subject: [BEHAVE] Comments on draft-ietf-behave-v4v6-bih-02 > > > > I have reviewed the latest version and have two main technical comments. > > I also have lots of editorial nits that I will send directly to the authors. > > The main technical comments are summarized as follows. > > > > 1) There are three ways to implement the ENR. > > a) at the API layer (works fine with DNSSEC) > > b) as a recursive resolver on the same host as discussed in Appendix A > > (I believe this has the same properties as DNS64 with respect to > > DNSSEC impact) > > c) in the network stack as shown in figure 2 (I think this breaks > > DNSSEC) > > > > Currently the document allows all three options, though seems to > > treat (a) and (c) as equally recommended, and (b) is almost an(Continue reading)
> > The (a) is definitely the most powerful and works best with DNSSEC, but at > the > > same time I believe most difficult to implement. The (b) and (c) are > possible to > > have as plug-ins, which gives them some merit (especially for the time being > > when host based DNSSEC validation is quite rare). What if document would say > > (a) is MUST if it is feasible to implement (i.e. acknowledging sometimes the > > "MUST" may not hold)? > > "MUST if it is feasible to implement" means the same as "SHOULD", and the > latter is more concise. SHOULD then, for the next revision, perhaps: -- In order to properly support DNSSEC, the ENR SHOULD be implemented at the socket API level. If the socket API level implementation is not possible, DNSSEC support SHOULD be provided by other means. -- > My main point is that DNS is not the only protocol for off-link name > resolution, > and implementation option (a) is better than the others. Maybe: -- In the case of the socket API layer implementation option, when an IPv4 application tries to do a forward lookup to resolve names via the resolver library (e.g., gethostbyname()), BIH intercepts the function call and instead calls the IPv6 equivalent functions (e.g., getnameinfo()) that will resolve both A and AAAA records. This implementation option is name resolution(Continue reading)
On 3/1/2011 8:00 AM, Tom Taylor wrote: > We have prepared this document to help sort out the multicast transition > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and comment > on the conclusions. A good well written document :) I would not use the term Multicast Topology for ASM vs SSM. Topology is more used for network topology... ASM and SSM are generally I think, referred to as different multicast service models. I would suggest using that term. That is the only change I would suggest in the draft. Some comments regarding ID.venaas-mcast46 though. It can be used together with ID.boucadair-64-multicast-address-format, and I plan to update it with a reference to that. This is maybe obvious though. It is correct that it is from 2008. Although not relevant, I feel like pointing out that the draft is very close to draft-venaas-mboned-v4v6mcastgw-00.txt from 2003. Stig
> -----Original Message----- > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On > Behalf Of Stig Venaas > Sent: Wednesday, March 02, 2011 11:41 AM > To: Tom Taylor > Cc: behave <at> ietf.org > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-(Continue reading)tsou- > multicast-transition-taxonomy-00 > > On 3/1/2011 8:00 AM, Tom Taylor wrote: > > We have prepared this document to help sort out the multicast > > transition > > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and > > comment > > on the conclusions. > > A good well written document :) Agreed. > I would not use the term Multicast Topology for ASM vs SSM. Topology is > more used for network topology... ASM and SSM are generally I think, > referred to as different multicast service models. I would suggest > using > that term. > > That is the only change I would suggest in the draft. > > Some comments regarding ID.venaas-mcast46 though. It can be used > together with ID.boucadair-64-multicast-address-format, and I plan
Hi Dan, We have emailed all of the authors of the various drafts and ask them to review draft-tsou-multicast-transition-taxonomy. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf Of Dan Wing Sent: Wednesday, March 02, 2011 12:20 PM To: 'Stig Venaas'; 'Tom Taylor' Cc: behave <at> ietf.org Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-multicast-transition-taxonomy-00 > -----Original Message----- > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On > Behalf Of Stig Venaas > Sent: Wednesday, March 02, 2011 11:41 AM > To: Tom Taylor > Cc: behave <at> ietf.org > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-(Continue reading)tsou- > multicast-transition-taxonomy-00 > > On 3/1/2011 8:00 AM, Tom Taylor wrote: > > We have prepared this document to help sort out the multicast
> -----Original Message----- > From: Tina Tsou [mailto:tena <at> huawei.com] > Sent: Wednesday, March 02, 2011 1:33 PM > To: 'Dan Wing'; 'Stig Venaas'; 'Tom Taylor' > Cc: behave <at> ietf.org > Subject: RE: [BEHAVE] Fwd: New Version Notification for draft-(Continue reading)tsou- > multicast-transition-taxonomy-00 > > Hi Dan, > We have emailed all of the authors of the various drafts and ask them > to review draft-tsou-multicast-transition-taxonomy. Great. Thanks! -d > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On > Behalf Of > Dan Wing > Sent: Wednesday, March 02, 2011 12:20 PM > To: 'Stig Venaas'; 'Tom Taylor' > Cc: behave <at> ietf.org
Hi Dan,
We have emailed all of the authors of the various drafts and ask them to
review draft-tsou-multicast-transition-taxonomy.
We keep our promises with one another - no matter what!
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
-----Original Message-----
From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf Of
Dan Wing
Sent: Wednesday, March 02, 2011 12:20 PM
To: 'Stig Venaas'; 'Tom Taylor'
Cc: behave <at> ietf.org
Subject: Re: [BEHAVE] Fwd: New Version Notification for
draft-tsou-multicast-transition-taxonomy-00
> -----Original Message-----
> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
> Behalf Of Stig Venaas
> Sent: Wednesday, March 02, 2011 11:41 AM
> To: Tom Taylor
> Cc: behave <at> ietf.org
> Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-
> multicast-transition-taxonomy-00
>
> On 3/1/2011 8:00 AM, Tom Taylor wrote:
> > We have prepared this document to help sort out the multicast
> > transition
> > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and
> > comment
> > on the conclusions.
>
> A good well written document :)
Agreed.
> I would not use the term Multicast Topology for ASM vs SSM. Topology is
> more used for network topology... ASM and SSM are generally I think,
> referred to as different multicast service models. I would suggest
> using
> that term.
>
> That is the only change I would suggest in the draft.
>
> Some comments regarding ID.venaas-mcast46 though. It can be used
> together with ID.boucadair-64-multicast-address-format, and I plan
> to update it with a reference to that. This is maybe obvious though.
Tom, tt would be really valuable if you could email all of the
authors of the various drafts and ask them to review
draft-tsou-multicast-transition-taxonomy, to ensure their documents
are all accurately summarized.
-d
> It is correct that it is from 2008. Although not relevant, I feel like
> pointing out that the draft is very close to
> draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.
>
> Stig
>
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave
<div>Hi Tina,<br><br>Thanks for writing the document, please see below my comments.<br><br>For the discussions about draft-qin-softwire-dslite-multicast in Section 3,<br>Acctually, both ASM and SSM are covered everytime when some points are discussed, for example, Address mapping, mB4, mAFTR.<br> Particularly, the authors spent a lot of efforts on the ASM deployment issues encounterd in Section 7.<br>So, please update the text related, also that in the Table 1, thanks.<br><br><br>Cheers,<br>Jacni<br><br><br><div class="gmail_quote">On Thu, Mar 3, 2011 at 5:32 AM, Tina Tsou <span dir="ltr"><<a href="mailto:tena <at> huawei.com">tena <at> huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote"> Hi Dan,<br> We have emailed all of the authors of the various drafts and ask them to<br> review draft-tsou-multicast-transition-taxonomy.<br><br><br> We keep our promises with one another - no matter what!<br><br> Best Regards,<br>Tina TSOU<br><a href="http://tinatsou.weebly.com/contact.html" target="_blank">http://tinatsou.weebly.com/contact.html</a><br><div class="im"> <br><br> -----Original Message-----<br> From: <a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a> [mailto:<a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a>] On Behalf Of<br> </div> <div> <div></div> <div class="h5">Dan Wing<br> Sent: Wednesday, March 02, 2011 12:20 PM<br> To: 'Stig Venaas'; 'Tom Taylor'<br> Cc: <a href="mailto:behave <at> ietf.org">behave <at> ietf.org</a><br> Subject: Re: [BEHAVE] Fwd: New Version Notification for<br> draft-tsou-multicast-transition-taxonomy-00<br><br> > -----Original Message-----<br> > From: <a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a> [mailto:<a href="mailto:behave-bounces <at> ietf.org">behave-bounces <at> ietf.org</a>] On<br> > Behalf Of Stig Venaas<br> > Sent: Wednesday, March 02, 2011 11:41 AM<br> > To: Tom Taylor<br> > Cc: <a href="mailto:behave <at> ietf.org">behave <at> ietf.org</a><br> > Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-tsou-≤br> > multicast-transition-taxonomy-00<br> ><br> > On 3/1/2011 8:00 AM, Tom Taylor wrote:<br> > > We have prepared this document to help sort out the multicast<br> > > transition<br> > > work in the BEHAVE and SOFTWIRES WGs. Please have a look at and<br> > > comment<br> > > on the conclusions.<br> ><br> > A good well written document :)<br><br> Agreed.<br><br> > I would not use the term Multicast Topology for ASM vs SSM. Topology is<br> > more used for network topology... ASM and SSM are generally I think,<br> > referred to as different multicast service models. I would suggest<br> > using<br> > that term.<br> ><br> > That is the only change I would suggest in the draft.<br> ><br> > Some comments regarding ID.venaas-mcast46 though. It can be used<br> > together with ID.boucadair-64-multicast-address-format, and I plan<br> > to update it with a reference to that. This is maybe obvious though.<br><br> Tom, tt would be really valuable if you could email all of the<br> authors of the various drafts and ask them to review<br> draft-tsou-multicast-transition-taxonomy, to ensure their documents<br> are all accurately summarized.<br><br> -d<br><br> > It is correct that it is from 2008. Although not relevant, I feel like<br> > pointing out that the draft is very close to<br> > draft-venaas-mboned-v4v6mcastgw-00.txt from 2003.<br> ><br> > Stig<br> ><br> > _______________________________________________<br> > Behave mailing list<br> > <a href="mailto:Behave <at> ietf.org">Behave <at> ietf.org</a><br> > <a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><br> _______________________________________________<br> Behave mailing list<br><a href="mailto:Behave <at> ietf.org">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br><br> _______________________________________________<br> Behave mailing list<br><a href="mailto:Behave <at> ietf.org">Behave <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/behave" target="_blank">https://www.ietf.org/mailman/listinfo/behave</a><br> </div> </div> </blockquote> </div> <br> </div>
RSS Feed29 | |
|---|---|
52 | |
13 | |
5 | |
48 | |
11 | |
7 | |
12 | |
27 | |
12 | |
46 | |
125 | |
33 | |
7 | |
57 | |
11 | |
54 | |
16 | |
135 | |
73 | |
75 | |
97 | |
52 | |
33 | |
82 | |
22 | |
323 | |
75 | |
72 | |
21 | |
57 | |
118 | |
113 | |
49 | |
101 | |
29 | |
53 | |
62 | |
189 | |
159 | |
212 | |
378 | |
181 | |
290 | |
231 | |
250 | |
413 | |
58 | |
122 | |
208 | |
183 | |
112 | |
33 | |
138 | |
623 | |
212 | |
62 | |
87 | |
202 | |
109 | |
183 | |
219 | |
142 | |
116 | |
156 | |
196 | |
71 | |
52 | |
75 | |
79 | |
212 | |
90 | |
75 | |
206 | |
82 | |
78 | |
57 | |
50 | |
45 | |
89 | |
55 | |
35 | |
56 | |
89 | |
156 | |
52 | |
87 | |
12 | |
24 | |
67 | |
19 | |
16 | |
15 | |
14 | |
141 | |
101 | |
116 | |
36 | |
95 | |
108 | |
10 |
