Re: Last Call: draft-klensin-rfc2821bis
On Mar 20, 2008, at 3:30 PM, John C Klensin wrote: > > > --On Friday, 21 March, 2008 09:03 +1100 Mark Andrews > <[EMAIL PROTECTED]> wrote: > >> I think Doug is saying don't let domains with just >> records be treated as valid RHS of email. Today we >> have to add records to domains with A records to say that >> these are not valid RHS of email. With MX synthesis >> from you create the same problem for domains with >> records. >> >> user@ >> user@ >> user@ * don't allow this. > > Mark, Doug, > > With the understanding that this is just my personal opinion (as > editor, I'll do whatever I'm told) _and_ that I'm personally > sympathetic to phasing out even the A record implicit MX... > > It seems to be that 2821bis is the wrong place to try to fix this, > especially via a comment posted well after the _second_ Last Call > closed. The current phrasing is not an oversight. It was > explicitly discussed on the mailing list and this is the behavior > that people decided they wanted. John, In the past you had made several comments that RFC2821bis would not change SMTP, and that you had also stated records where NOT defined as SMTP server discovery records. (Not in those words of course.) It does not appear this change was your choice, but nonetheless and surprisingly this unfortunate change is now being made. The "update" of RFC2821 is making a _significant_ architectural change to SMTP by explicitly stating records are within a list of SMTP server discovery records. This change represents a poor architectural choice since this _will_ increase the burden on networks being spoofed by abusive email. Due to high levels of abuse, confirming validity of email domains by checking for discovery (A and MX) records in the forward DNS zone often replaces an alternative of checking PTR records in the in-addr.arpa reverse DNS zone. The reverse zone suffers from poor maintenance where its use creates a sizeable burden for recipients. RFC2821bis now adds records to a list of records that must be checked to disqualify public SMTP server domains within the DNS forward direction. This change adds to the transactional burdens already headed in the wrong direction. It would seem a sound architectural change would be to deprecate A records as a means to qualify domains for message acceptance, but RFC2822bis adds records instead. This situation becomes considerably worse when domain tree walking or wildcards are then preferred over checks against discovery records. It was not my intention to post this after last call, but this only came to my attention recently. For that I am sorry, nevertheless this issue may deserve greater consideration. -Doug ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Possible RFC 3683 PR-action
LB: The first step is to appeal to Chris Newman. If you do not find his response satisfactory, then you raise the matter with me as IETF Chair. If you do not find my response satisfactory, then you raise the matter with the IESG. If you do not find the IESG response satisfactory, then you raise the matter with the IAB. The IAB is the end of the appeal chain for this matter. I do not know of any previous situation where two email identities were claimed to represent the same person, and on of those people already had a PR-Action. I hope this can be resolved in a satisfactory manner very soon without invoking all of these steps. Russ me as IETF Chair.At 05:22 AM 3/22/2008, LB wrote: >Dear Russ, >I am not sure what should be the "next step" and I wish that all is >clear and transparent in the management of what I take for a censure >for offence of opinion or nationality. I think like somebody else, I >use the technical vocabulary appropriate for my thought. I think in >the same mother tongue as another Frenchman. Is it to protest with Mr. >Newman or with Mr. Presuhn or to appeal directly to the IESG? > >I used in vain the RFC-Editor find out what was the rule. I found >nothing. Mr Presuhn says moreover that there are none. I would also >like to know how locate in your archives the cases where the identity >of somebody has been challenged within the IETF in such manner and >what procedures have been initiated. > >With my thanks and my best regards >-- >LB > >2008/3/21, Russ Housley <[EMAIL PROTECTED]>: > > LB: > > > > Randy has responded quite publicly. I think his position is quite > > clear. So, the next step is up to you. > > > > > > Russ > > > > > > > > At 08:38 PM 3/20/2008, LB wrote: > > >Dear Sir, > > >Like other members of the multilinguistic working list to which I > > >belong, since 2002 I received a copy of the mails exchanged between > > >JFC Morfin and your organization, on IDNs then langtags. And we have > > >often discussed them. I do not thus ignore big matter of this subject > > > > > >As JFC Morfin got everything we wanted except again: > > >(1) that the WG-IDNABIS quickly demonstrates the merits of IDNA or > > >finds a better solution. > > >(2) that the RFC 4646 is respected by the IESG what also calls for the > > >RFC 4646bis underway. > > >I proposed to replace him as an IETF watcher, given the importance of > > >his current work. > > > > > >In two months, I sent a half-dozen of messages and received courteous > > >answers. Of course I expected a possible ostracism. I was prepared to > > >respond with kind understanding. This was the case with Brian > > >Carpenter. He accused me of being JFC Morfin in an humorous but a way > > >a little hurtful. We exchanged and he had the courtesy to apologize > > >willingly and and to inform the IESG about it. > > > > > >I would have done the same with Randy Preshun if contacted me, even > > >impolitely, even after having ignored my question about a significant > > >breakthrough for us he implied, even after that he probably pushed a > > >"trap" by misrepresenting our position and that of ISO. Instead, he > > >dashes into a guerilla of racist censorship against me: it is because > > >of the MLTF ideas that he accuses me of not being me. > > > > > >2008/3/20, Randy Presuhn <[EMAIL PROTECTED]>: > > > > Hi - > > > > > > > > There have been expressions of support, and no objections > on this list, > > > > to the proposed metric (and one off-list objection by JFC Morfin) for > > > > identifying possible sock-puppets of those whose posting privileges > > > > have been revoked pursuant to RFC 3683. So, we're using it. > > > > > > > > We engaged the procedure with three independent working group > > > participants. > > > > All three identified the same email address, which was also > > > identified by the > > > > responsible area director and both co-chairs. Consequently, > > > future postings > > > > from [EMAIL PROTECTED] will not be delivered, since we believe > > > this address > > > > is a sock-puppet for JFC Morfin. > > > > > > > > Randy > > > > ltru co-chair > > > > > >You will understand that I have reached an age where I am not > > >impressed anymore and that I have time for a good cause: > > >-- or Randy Preshun apologizes and it stays there. > > >-- or he has suspended my rights without warning and is preparing for > > >a PR action against me without any reason. He does it with the support > > >of our two direct commercial competitors in his WG. Under these > > >conditions you will understand that I am not to be giving anything > > >that enables them to validate a practice of arbitrary exclusion of the > > >IETF. Today I, whom tomorrow? > > >-- > > >LB > > > > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-ietf-ospf-multi-area-adj-07
Hi Ben, I believe I've addressed your editorial comments and will send a draft copy to yourself and the other authors (not ietf.org). The updated version will also include Nischal Seth's comment regarding the wording inadvertently precluding OSPF point-to-point over LAN interfaces. With respect to your last comment regarding RFC 2740, we do have an update pending but would prefer not to hold up documents referencing RFC 2740. Given the size of the RFC 2740 BIS draft, it could take some time to make it through the process. Thanks, Acee On Mar 20, 2008, at 12:20 PM, Ben Campbell wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > > Document: draft-ietf-ospf-multi-area-adj-07 > Reviewer: Ben Campbell > Review Date: 2008-03-20 > IETF LC End Date: 2008-03-26 > IESG Telechat date: (if known) > > Summary: This draft is almost ready for publication as a proposed > standard. However, I have some editorial comments that should be > addressed first. > > Comments: > > Disclaimer: I am not an OSPF expert. I assume that others have > reviewed this draft for technical correctness. > > -- General: > > It would be helpful to see a little more coverage on the motivation > and background for this draft. > > -- Details: > > Abstract: > > Please expand OSPF on first use. > > Section 1.2: > > The first sentence is confusing and redundant-please rephrase. > Also, "There could be a requirement..." seems like a pretty weak > motivation; does the requirement exist or not? Please add more > background and motivation for why the requirement exists. > > Section 1.3, first paragraph: > > Please expand OSPF on first use. > > Paragraph 3, last sentence: > > It's not clear why it might not be acceptable. Policy? Is the > support of p2plan inadequate, or uncommon? > > Section 1.4, first paragraph, last sentence: > > s/consistent/"in a manner consistent" > > (or just "consistently") > > Section 2.3: > > It's not obvious what is intended here. Is this a complete > replacement of section 8.2? A replacement of certain paragraphs? I > can infer that you want to replace certain paragraphs by > examination, but please be explicit. > > Also, it would be helpful to mention that this draft updates [OSPF] > in the abstract and/or introduction. > > Section 3.1, last sentence: > > Can you elaborate on what it means to be "cleaner from a deployment > standpoint"? > > > > Section 4: > > Are there no updates to RFC 2740? > > > > > > > > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
On Sat, Mar 22, 2008 at 10:22:01AM +0100, LB <[EMAIL PROTECTED]> wrote a message of 96 lines which said: > what I take for a censure for offence of opinion or nationality. I > think like somebody else, I use the technical vocabulary appropriate > for my thought. I think in the same mother tongue as another > Frenchman. For the record, since I was one of the three LTRU participants consulted, and since I'm french, I insist that it has nothing to do with nationality. People from all over the world, not only USAns, think the same about the "LB" and "JFC" entities and their dummy organizations. It is not a matter of opinion either. To disagree with opinions require that opinions are expressed. The long and convoluted messages of LBJFC are "not even wrong" since they are not parsable by an ordinary engineer. (I can testify it is the same thing when they are written in french.) > I would also like to know how locate in your archives the cases > where the identity of somebody has been challenged within the IETF > in such manner and what procedures have been initiated. Randy Presuhn clearly said in his first message that there was no precedent (and I add that no reasonable person could have believed that someone was twisted enough to use a sock-puppet.) ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Possible RFC 3683 PR-action
> "LB" == LB <[EMAIL PROTECTED]> writes: LB> Dear Russ, I am not sure what should be the "next step" and I LB> wish that all is clear and transparent in the management of LB> what I take for a censure for offence of opinion or LB> nationality. I think like somebody else, I use the technical LB> vocabulary appropriate for my thought. I think in the same LB> mother tongue as another Frenchman. Is it to protest with Mr. LB> Newman or with Mr. Presuhn or to appeal directly to the IESG? I think the next step should be for you to contribute positevly and constructively to the ltru working group. As I understand it, your posts are moderated. That means that if they are constructive they will get through to the wg. Don't turn this into some story about persecution; help work on internet standards. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-eai-utf8headers-09.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Thanks, Spencer Document: draft-ietf-eai-utf8headers-09.txt Reviewer: Spencer Dawkins Review Date: 2008-03-22 IETF LC End Date: 2008-03-24 IESG Telechat date: (if known) Summary: This draft is on the right track for publication as an Experimental RFC. There are issues in the following review identified as "technical:" that need to be looked at. Comments identified as "clarity:" are probably nits, but affected the meaning enough that I wanted to include them in the review. Comments identified as "nit:" are not part of the review but are provided for editor convenience. >From idnits 2.08.04: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 338, but not defined -- Possible downref: Undefined Non-RFC (?) reference : ref. 'CFWS' == Unused Reference: 'ASCII' is defined on line 606, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-07) exists of draft-ietf-eai-downgrade-05 == Outdated reference: A later version (-09) exists of draft-klensin-net-utf8-07 Comments: 1. Introduction 1.1. Role of this specification Full internationalization of electronic mail requires several capabilities: o The capability to transmit non-ASCII content, provided for as part of the basic MIME specification [RFC2045], [RFC2046]. o The capability to express those addresses, and information related Clarity: which addresses are "those addresses"? This is the first use of "addresses in the document. Guessing that the bullets were reordered without taking this into account - the third bullet says "envelope addresses". to and based on them, in mail header fields, defined in this Nit: "related to and based on" is correct but doesn't parse easily. Suggest s/related to/related to them/ or something similar. document. And, finally, o The capability to use international characters in envelope addresses, discussed in [RFC4952] and specified in [EAI-SMTP-extension]. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the base form for Internet email header fields. This form is permitted in transmission, if authorized by the SMTP extension specified in [EAI-SMTP-extension] or by other transport mechanisms Technical: isn't this s/transport/transfer/? capable of processing it. 1.2. Relation to other standards This document also updates [RFC2822] and MIME, and the fact that an experimental specification updates a standards-track spec means that people who participate in the experiment have to consider those standards updated. Process: The ID Tracker is showing this draft in Last Call status, but I can't find (in the archive or in my personal folders) any Last Call announcement, which I was looking for, in order to check how Chris explained the downref at Last Call time - I'm expecting that it will be quite entertaining. Has anyone else seen such an announcement on IETF Announce? 2. Background and History The traditional format of email messages [RFC2822] allows only ASCII characters in the header fields of messages. This prevents users from having email addresses that contain non-ASCII characters. It further forces non-ASCII text in common names, comments, and in free text (su
Re: [Ltru] Possible RFC 3683 PR-action
Dear Russ, I am not sure what should be the "next step" and I wish that all is clear and transparent in the management of what I take for a censure for offence of opinion or nationality. I think like somebody else, I use the technical vocabulary appropriate for my thought. I think in the same mother tongue as another Frenchman. Is it to protest with Mr. Newman or with Mr. Presuhn or to appeal directly to the IESG? I used in vain the RFC-Editor find out what was the rule. I found nothing. Mr Presuhn says moreover that there are none. I would also like to know how locate in your archives the cases where the identity of somebody has been challenged within the IETF in such manner and what procedures have been initiated. With my thanks and my best regards -- LB 2008/3/21, Russ Housley <[EMAIL PROTECTED]>: > LB: > > Randy has responded quite publicly. I think his position is quite > clear. So, the next step is up to you. > > > Russ > > > > At 08:38 PM 3/20/2008, LB wrote: > >Dear Sir, > >Like other members of the multilinguistic working list to which I > >belong, since 2002 I received a copy of the mails exchanged between > >JFC Morfin and your organization, on IDNs then langtags. And we have > >often discussed them. I do not thus ignore big matter of this subject > > > >As JFC Morfin got everything we wanted except again: > >(1) that the WG-IDNABIS quickly demonstrates the merits of IDNA or > >finds a better solution. > >(2) that the RFC 4646 is respected by the IESG what also calls for the > >RFC 4646bis underway. > >I proposed to replace him as an IETF watcher, given the importance of > >his current work. > > > >In two months, I sent a half-dozen of messages and received courteous > >answers. Of course I expected a possible ostracism. I was prepared to > >respond with kind understanding. This was the case with Brian > >Carpenter. He accused me of being JFC Morfin in an humorous but a way > >a little hurtful. We exchanged and he had the courtesy to apologize > >willingly and and to inform the IESG about it. > > > >I would have done the same with Randy Preshun if contacted me, even > >impolitely, even after having ignored my question about a significant > >breakthrough for us he implied, even after that he probably pushed a > >"trap" by misrepresenting our position and that of ISO. Instead, he > >dashes into a guerilla of racist censorship against me: it is because > >of the MLTF ideas that he accuses me of not being me. > > > >2008/3/20, Randy Presuhn <[EMAIL PROTECTED]>: > > > Hi - > > > > > > There have been expressions of support, and no objections on this list, > > > to the proposed metric (and one off-list objection by JFC Morfin) for > > > identifying possible sock-puppets of those whose posting privileges > > > have been revoked pursuant to RFC 3683. So, we're using it. > > > > > > We engaged the procedure with three independent working group > > participants. > > > All three identified the same email address, which was also > > identified by the > > > responsible area director and both co-chairs. Consequently, > > future postings > > > from [EMAIL PROTECTED] will not be delivered, since we believe > > this address > > > is a sock-puppet for JFC Morfin. > > > > > > Randy > > > ltru co-chair > > > >You will understand that I have reached an age where I am not > >impressed anymore and that I have time for a good cause: > >-- or Randy Preshun apologizes and it stays there. > >-- or he has suspended my rights without warning and is preparing for > >a PR action against me without any reason. He does it with the support > >of our two direct commercial competitors in his WG. Under these > >conditions you will understand that I am not to be giving anything > >that enables them to validate a practice of arbitrary exclusion of the > >IETF. Today I, whom tomorrow? > >-- > >LB > > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
