Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Le 2012-05-04 à 12:08, Leaf yeh a écrit : Jacni - Anyway, if generally we have a single target or design goal,… There are many design goals here. What Ole said in this email is the solution of Encapsulation Translation will meet the different ones, which sounds mutually exclusive. Will you go for the further clarification or discussion on it here? I would be open to accept these 2 solutions, which share part of the same address format. And let the operator get the right to pick one he believe it is feasible suitable, or even not pick any of these solution. Would you agree, though, that if a solution is confirmed to cover design goals of both Encapsulation and Translation, it would better meet the WG objective objective to have a single standard? (Operators would be relieved from having to make a choice.) Regards, RD Best Regards, Leaf From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Jacni Qin Sent: Friday, May 04, 2012 10:03 AM To: Ole Trøan Cc: softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Ole, On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: Jacni, My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? I'd rather prefer you pick one only. wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are. I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in motivation, then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ... Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever. Cheers, Jacni cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
2012-05-04 18:16, Leaf yeh: Remi - Would you agree, though, that if a solution is confirmed to cover design goals of both Encapsulation and Translation, it would better meet the WG objective objective to have a single standard? (Operators would be relieved from having to make a choice.) That sounds great if the solution (eg. 4rd-U) is confirmedly feasible Yes, feasibility is clearly a decisive criterion. (Not forgetting that feasibility of MAP-T+E, with all what there is in the specification without having be tested before, has also to be confirmed.) and extensively accepted by the group. Right? That's the purpose of this question: will standard unicity be confirmed by the WG an important criterion? If you agree, we can resume this discussion when all specifications are available. Kind regards, RD Best Regards, Leaf From: Rémi Després [despres.r...@laposte.net] Sent: Friday, May 04, 2012 20:55 To: Leaf yeh Cc: Jacni Qin; Ole Trøan; softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Le 2012-05-04 à 12:08, Leaf yeh a écrit : Jacni - Anyway, if generally we have a single target or design goal,… There are many design goals here. What Ole said in this email is the solution of Encapsulation Translation will meet the different ones, which sounds mutually exclusive. Will you go for the further clarification or discussion on it here? I would be open to accept these 2 solutions, which share part of the same address format. And let the operator get the right to pick one he believe it is feasible suitable, or even not pick any of these solution. Would you agree, though, that if a solution is confirmed to cover design goals of both Encapsulation and Translation, it would better meet the WG objective objective to have a single standard? (Operators would be relieved from having to make a choice.) Regards, RD Best Regards, Leaf From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Jacni Qin Sent: Friday, May 04, 2012 10:03 AM To: Ole Trøan Cc: softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Ole, On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: Jacni, My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? I'd rather prefer you pick one only. wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are. I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in motivation, then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ... Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever. Cheers, Jacni cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
I'll be open to accept N solutions, in case of necessity. Of course, operators get the right to pick one, e.g. from DS-Lite, stateless like MAPs/4rd .., etc., but it'll be our fault to let them try to pick one from different variables of the stateless, if there's no sufficient reason. Back to the motivation document, I failed to see the mutually exclusive requirements were stated. Have we left it all behind or chosen to miss it, since the mission to prove stateless approaches are needed is complete? Ok, let's wait for the output of the design team, while may I again suggest that you consider seriously the mutually exclusive requirements from E T before moving forward? Cheers, Jacni On 5/4/2012 Friday 6:08 PM, Leaf yeh wrote: Jacni - Anyway, if generally we have a single target or design goal,… There are many design goals here. What Ole said in this email is the solution of Encapsulation Translation will meet the different ones, which sounds mutually exclusive. Will you go for the further clarification or discussion on it here? I would be open to accept these 2 solutions, which share part of the same address format. And let the operator get the right to pick one he believe it is feasible suitable, or even not pick any of these solution. Best Regards, Leaf *From:*softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] *On Behalf Of *Jacni Qin *Sent:* Friday, May 04, 2012 10:03 AM *To:* Ole Trøan *Cc:* softwires@ietf.org *Subject:* Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Ole, On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: Jacni, My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? I'd rather prefer you pick one only. wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are. I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in motivation, then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ... Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever. Cheers, Jacni cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Ole, On Thursday, May 03, 2012 2:58:35 PM, Ole Trøan wrote: Jacni, My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? I'd rather prefer you pick one only. Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T. examples? Section 5.4, the BR address, And the 6 about the design of IID, I'm not a fan of the statement like The encoding of the full IPv4 address into the interface identifier, both for the source and destination IPv6 addresses have been shown to be useful for troubleshooting. ... Cheers, Jacni cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
2012-05-03 à 10:38, Ole Trøan: ... let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. Agreed: each of E or T doesn't cover by itself all expressed requirements for a stateless 4via6 solution. The question that remains, however, is whether 4rd does cover, or not, all these requirements in a unified solution. This question will better be answered when the WG drafts on both MAP and 4rd are available and stabilized. Looking forward to it, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Ole, On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: Jacni, My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? I'd rather prefer you pick one only. wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are. I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in motivation, then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ... Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever. Cheers, Jacni cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Re-, On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: Well, even the WG decided to go with MAP, we would still need to coin toss between MAP-T and MAP-E, wouldn't we? May I share your concern. Cheers, Jacni On 4/26/12 10:50 AM, Jan Zorz @ go6.sij...@go6.si wrote: On 4/26/12 11:50 AM, Mark Townsley wrote: Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan P.S: I'll not waste more bits on this topic as it's apparently a waste of bandwidth :) P.P.S: Should we deprecate RFC6346? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. From: Jacni Qin ja...@jacni.com Date: Wednesday, May 2, 2012 9:03 PM To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Jan Zorz @ go6.si j...@go6.si, softwires@ietf.org softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Re-, On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: Well, even the WG decided to go with MAP, we would still need to coin toss between MAP-T and MAP-E, wouldn't we? May I share your concern. Cheers, Jacni On 4/26/12 10:50 AM, Jan Zorz @ go6.si j...@go6.si mailto:j...@go6.si wrote: On 4/26/12 11:50 AM, Mark Townsley wrote: Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan P.S: I'll not waste more bits on this topic as it's apparently a waste of bandwidth :) P.P.S: Should we deprecate RFC6346? ___ Softwires mailing list Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Re-, On 5/3/2012 Thursday 10:18 AM, Lee, Yiu wrote: My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T. Cheers, Jacni From: Jacni Qin ja...@jacni.com mailto:ja...@jacni.com Date: Wednesday, May 2, 2012 9:03 PM To: Yiu L. LEE yiu_...@cable.comcast.com mailto:yiu_...@cable.comcast.com Cc: Jan Zorz @ go6.si j...@go6.si mailto:j...@go6.si, softwires@ietf.org mailto:softwires@ietf.org softwires@ietf.org mailto:softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Re-, On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: Well, even the WG decided to go with MAP, we would still need to coin toss between MAP-T and MAP-E, wouldn't we? May I share your concern. Cheers, Jacni On 4/26/12 10:50 AM, Jan Zorz @ go6.sij...@go6.si wrote: On 4/26/12 11:50 AM, Mark Townsley wrote: Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan P.S: I'll not waste more bits on this topic as it's apparently a waste of bandwidth :) P.P.S: Should we deprecate RFC6346? ___ Softwires mailing list Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Well, even the WG decided to go with MAP, we would still need to coin toss between MAP-T and MAP-E, wouldn't we? On 4/26/12 10:50 AM, Jan Zorz @ go6.si j...@go6.si wrote: On 4/26/12 11:50 AM, Mark Townsley wrote: Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan P.S: I'll not waste more bits on this topic as it's apparently a waste of bandwidth :) P.P.S: Should we deprecate RFC6346? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Chairs, ADs, I regret this decision. *Whatever* the results of the poll, your text below explicitly suggests a discrimination between voters. Basically, you seem to distinguish between people who are entitled to vote because they have supposedly participated to the stateless specification effort (whatever the flavour) and people who are not entitled to vote because you clearly assume they have not participated to the said specification effort, let alone the discussions. I think this decision is a shame for the IETF precisely because of this discrimination. We all perfectly know how the IETF procedures have been working for many years. And we all perfectly know what kind of side effect the rough consensus motto can sometimes lead to. But I don't think this is a good enough reason to speculate on the degree of participation to the WG effort of the people who have expressed an opinion. I, for one, never sent a comment on either the MAP or the 4rd-U stuff on this list. Yet, I can assure you that I have extensively discussed both approaches with my colleagues internally. Does that make me ineligible to respond to this poll? I certainly don't think so. I don't think anyone of us is entitled to decide who has the right to vote and who hasn't. Your corrected math clearly reflect a strong consensus to (1) standardize one and only one approach and (2) adopt the MAP effort as a softwire WG item. Your decision contradicts the results of this poll. I therefore strongly encourage you to revisit your position and accept the results of this poll. If you stick to this decision, you will not only do any favor to the softwire WG, but also to the whole IETF. Cheers, Christian. -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 26 avril 2012 03:41 À : softwires@ietf.org WG Objet : [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward The chairs and ADs met to look at the results of the consensus call that ended Wednesday and decide the way forward. First, we would like to offer a couple observations on the raw results from the consensus call: - We had a number of people responding more than once, sometime with different email addresses. Having their name and affiliation in the response helped us removed those duplicate/triplicate/... - Number of unique response: 75 - Question 1: 75 yes, 0 No, few responded put both on experimental track - Question 2: 73 MAP 2 4rd-U This does not reflect at all the results we had in the Paris meeting (about 30 MAP and 20 4rd-U): a) It seems that some of the 4rd-U people who did express support for it in Paris when the same question was asked have not participated in this consensus call. b) the number of MAP responses seem to be inflated, we see a disproportionate number of response from some particular organizations. We also see a large number of responses coming from people who have not participated before in the working group. Also, it is apparent that a number of people have joined the mailing list for the sole purpose of expressing support for MAP. None of the above behaviors do any favors for the working group. We do need participation in the official call for consensus from all the active participants of the working group. As we mentioned before, in such calls, silence is consent. Also, the inflated participation in the consensus call from 'new' members that have never participate in the discussion before, creates noise that makes the results harder to read. Furthermore, we have observed that, even during the call, the analysis of both solutions did continue, and missing elements on both sides have been pointed out. We also observed a willingness of various participants to improve those specs to bring them to a level where we could start a working group last call. As a result, we have decided to approve both MAP and 4rd-U as working group work items. As work items, each document can be further refined until the working group reaches consensus about advancing the documents for IETF review. Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. When
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Dear all, I personally regret this decision and reject the justifications provided. If you don't want people to contribute and express their opinion, it is easy: make it a close community. If you insist to ignore what expressed the majority of individuals who participated to the poll, may I suggest: we stop all this stateless A+P work. It does not make sense at all to continue work on two parallel efforts having 90% of similarities. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 26 avril 2012 03:41 À : softwires@ietf.org WG Objet : [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward The chairs and ADs met to look at the results of the consensus call that ended Wednesday and decide the way forward. First, we would like to offer a couple observations on the raw results from the consensus call: - We had a number of people responding more than once, sometime with different email addresses. Having their name and affiliation in the response helped us removed those duplicate/triplicate/... - Number of unique response: 75 - Question 1: 75 yes, 0 No, few responded put both on experimental track - Question 2: 73 MAP 2 4rd-U This does not reflect at all the results we had in the Paris meeting (about 30 MAP and 20 4rd-U): a) It seems that some of the 4rd-U people who did express support for it in Paris when the same question was asked have not participated in this consensus call. b) the number of MAP responses seem to be inflated, we see a disproportionate number of response from some particular organizations. We also see a large number of responses coming from people who have not participated before in the working group. Also, it is apparent that a number of people have joined the mailing list for the sole purpose of expressing support for MAP. None of the above behaviors do any favors for the working group. We do need participation in the official call for consensus from all the active participants of the working group. As we mentioned before, in such calls, silence is consent. Also, the inflated participation in the consensus call from 'new' members that have never participate in the discussion before, creates noise that makes the results harder to read. Furthermore, we have observed that, even during the call, the analysis of both solutions did continue, and missing elements on both sides have been pointed out. We also observed a willingness of various participants to improve those specs to bring them to a level where we could start a working group last call. As a result, we have decided to approve both MAP and 4rd-U as working group work items. As work items, each document can be further refined until the working group reaches consensus about advancing the documents for IETF review. Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. When the document sets are ready for working group last call, the working group will reconsider the question of the publication status: Proposed Standard or Experimental. We will try to consider all document sets for advancement at the same time, but we will not allow a delay in completing one document to hold up the working group indefinitely. - Alain Yong, WG co-chairs - Ralph Biran, ADs ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. Seems like a pending procedural quagmire. Perhaps we would have been better off with the coin toss. - Mark ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
I'm new to the group, but I made my vote because I have studied both solutions. I was unable to find any running code for 4rd-U that I could test and verify, while I was able to do that with MAP. I voted based on the quote about the IETF from David Clark: We reject kings, presidents and voting. We believe in rough consensus and running code. As I was unable to find 4rd-U running code I voted against 4rd-U. I believe that the author of 4rd-U should explore his idea and have running code to prove it works. When the 4rd-U comes to this stage come back to the group. This is similar to what happened with 6rd. If this code already exist, please make it public so it could be verified. Edwin Cordeiro Em 26-04-2012 06:50, Mark Townsley escreveu: Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. Seems like a pending procedural quagmire. Perhaps we would have been better off with the coin toss. - Mark ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
On 4/26/12 11:50 AM, Mark Townsley wrote: Perhaps we would have been better off with the coin toss. +1 bingo. Cheers, Jan P.S: I'll not waste more bits on this topic as it's apparently a waste of bandwidth :) P.P.S: Should we deprecate RFC6346? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
Hi Jan, P.P.S: Should we deprecate RFC6346? A+P is in MAP T, MAP E and 4rd-U. I don't understand why you are worried about it? Having said that I for one think that A+P should be restricted to the CPEs. Otherwise you are creating another NAT. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Result from the consensus call on Map vs 4rd-U and official way forward
The chairs and ADs met to look at the results of the consensus call that ended Wednesday and decide the way forward. First, we would like to offer a couple observations on the raw results from the consensus call: - We had a number of people responding more than once, sometime with different email addresses. Having their name and affiliation in the response helped us removed those duplicate/triplicate/... - Number of unique response: 75 - Question 1: 75 yes, 0 No, few responded put both on experimental track - Question 2: 73 MAP 2 4rd-U This does not reflect at all the results we had in the Paris meeting (about 30 MAP and 20 4rd-U): a) It seems that some of the 4rd-U people who did express support for it in Paris when the same question was asked have not participated in this consensus call. b) the number of MAP responses seem to be inflated, we see a disproportionate number of response from some particular organizations. We also see a large number of responses coming from people who have not participated before in the working group. Also, it is apparent that a number of people have joined the mailing list for the sole purpose of expressing support for MAP. None of the above behaviors do any favors for the working group. We do need participation in the official call for consensus from all the active participants of the working group. As we mentioned before, in such calls, silence is consent. Also, the inflated participation in the consensus call from 'new' members that have never participate in the discussion before, creates noise that makes the results harder to read. Furthermore, we have observed that, even during the call, the analysis of both solutions did continue, and missing elements on both sides have been pointed out. We also observed a willingness of various participants to improve those specs to bring them to a level where we could start a working group last call. As a result, we have decided to approve both MAP and 4rd-U as working group work items. As work items, each document can be further refined until the working group reaches consensus about advancing the documents for IETF review. Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. When the document sets are ready for working group last call, the working group will reconsider the question of the publication status: Proposed Standard or Experimental. We will try to consider all document sets for advancement at the same time, but we will not allow a delay in completing one document to hold up the working group indefinitely. - Alain Yong, WG co-chairs - Ralph Biran, ADs ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
