RE: The Last Call social contract (was - Re: Rude responses)
On 23 Aug 2013 04:22, l.w...@surrey.ac.uk wrote: LC should not be treated as a right of passage, to test the patience of folks who have developed a document. rite? Right - right or rite? Lloyd Wood http://sat-net.com/L.Wood/
Re: The Last Call social contract (was - Re: Rude responses)
On Thu, Aug 22, 2013 at 11:12 PM, Dave Crocker d...@dcrocker.net wrote: In pragmatic terms, the current operational model for a LC (and IESG) review tends to enforce no rules or limits to what can be challenged or suggested, while simultaneously expecting those who have been doing the work to then be responsible for educating the commenter and defending decisions in the document, at the level of re-arguing resolved issues. Your admonition that these folks are already at a disadvantage encourages this sense of obligation. However this is direct contradiction to our published rules for Last Call: RFC 2418, Working Group Guidelines and Procedures Section 8, Review of documents It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review. Note that last sentence. It's the essential point, if we are to have any real /respect/ for the extended effort already put into developing the document. Remember the discussion about how last call is more like the middle of a document's evolution, and we should admit that in our process documentation? This is closely related. If, in reality, people are frustrated at the attempted rapid pace of last calls, then we should allow for that. We have time. We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Simple comments and questions -- your educating everyone who tracked the wrong group -- can be dealt with easily through referral. Even substantial ones can be directed to specific discussion threads. Real issues can be considered. It's only too late if we say it is, in our processes, and if an issue is substantial, it should never be too late.
Re: The Last Call social contract (was - Re: Rude responses)
On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I expressed had nothing at all to do with this. What prompted my note that in turn prompted Pete's was a form of counter-productive LC behavior that I consider to be abusive and since it was from a highly experienced participant, inexcusable. Serious questions and suggestions from serious reviewers/critics are /essential/ to IETF quality assurance and I have as little patience for the sneering you describe as anyone else. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: The Last Call social contract (was - Re: Rude responses)
Dave Crocker wrote: On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I expressed had nothing at all to do with this. What prompted my note that in turn prompted Pete's was a form of counter-productive LC behavior that I consider to be abusive and since it was from a highly experienced participant, inexcusable. Serious questions and suggestions from serious reviewers/critics are /essential/ to IETF quality assurance and I have as little patience for the sneering you describe as anyone else. d/ My particular concern is that you using this abusive argument increasingly against people leading to a next public suggestion to justify invoking IETF moderation, if necessary. Once a well respected senior member as yourself speaks as such, people do listen and its extremely intimidating to constantly see this threatening form of excommunications and moderation against folks. If one responds, then they are risk of getting labeled abusive, and hence moderation is invoked. In my opinion, I don't see highly debated issues like the SPF typ99e issue all the time with last calls. At least I don't or I don't get involved with it if its not related to my work. This rarity suggest that the IETF LC system still works and that we are simply experiencing a real divided technical infrastructure design issue that was highly predictable to be a conflict outside the working group. Pete suggested as much with fewer cross area reviews occurring within the IETF. I agree that this is one of those diversity improvements areas. Not enough cross area peer review before the WGLC and IETF LC takes place. The goal is to minimizes these contentious engineering issues. I have been involved with the SPF protocol before MARID, during MARID, an early adopter and also involved in the SPFBIS efforts. It is my assessment the SPFBIS WG did not receive adequate cross area reviews and DNS industry input *before* the removal decision was made, which was practically immediate and expected before the first draft was even written. Instead, the same already discussed arguments was used and the removal decision was implemented in the draft. In my opinion, there was significant concerns about the removal within the WG and outside the WG, yet the decision was made to pull it anyway at the IETF meeting. This immediately put the burden on everyone to reverse or at least get a better discussion going about keeping the migration path and also get a better handle of whats going on with the dearth in the supportive infrastructure for the handling of unknown RR types. In my opinion, it would be better to seek the input from DNS vendors to see what the future is regarding new RR types and passthru handling of unknown types (RFC 3597). I request reaching out to folks in Microsoft DNS product management to determine what has fell through the cracks. If there is continued lack of interest, then the SPF type99 removal is reasonable to me. You seem to think that this was already done. I don't think so. Perhaps you believe that the infrastructure will never be ready to support new RR types. If so, that is important to know. -- HLS
Re: The Last Call social contract (was - Re: Rude responses)
Hi Dave, I read the messages on this thread. I suggested to the participant to comment. I am okay with the comments which were made. I had an off-list exchange before the message that generated the other thread. The exchange was not antagonistic. Some people read please read the archives as a requirement. That led to a misunderstanding. During a Last Call someone has to figure out what the issues are and whether they have been addressed or not. The misunderstandings do not make the work easier. Regards, S. Moonesamy
Re: The Last Call social contract (was - Re: Rude responses)
On Fri, Aug 23, 2013 at 3:46 PM, Dave Crocker d...@dcrocker.net wrote: On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I expressed had nothing at all to do with this. What prompted my note that in turn prompted Pete's was a form of counter-productive LC behavior that I consider to be abusive and since it was from a highly experienced participant, inexcusable. Serious questions and suggestions from serious reviewers/critics are /essential/ to IETF quality assurance and I have as little patience for the sneering you describe as anyone else. I think you were out of line because the type of issues being raised are precisely the type of issues that are appropriate to raise in IETF last call, indeed are the reason for having an IETF wide last call in the first place. If I see a WG railroading a scheme that I think is botched architecturally then of course IETF LC is the place to raise it. Adding in a requirement, sure. In this case the issues being raised are a repeat of the arguments made from ten years ago and I don't have much sympathy for them given the way the folk raising them behaved then and in particular their total lack of concern for the deployment issues raised by the group. But I don't criticize them on the process question, IETF LC is exactly the place to raise this issue. It is one area kibitzing on the work of another. That is an IETF layer issue for sure. -- Website: http://hallambaker.com/
RE: The Last Call social contract (was - Re: Rude responses)
LC should not be treated as a right of passage, to test the patience of folks who have developed a document. rite? Lloyd Wood http://sat-net.com/L.Wood/
