Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
james woodyatt writes: If it could be published as standards-track, instead of informational, *without* *any* *further* *delay*, that would be excellent. However, I believe there is nothing to be gained for the Internet community by any further delay in publishing this important document. It should have been published years go, fergawdzakes. Faster, please. It's not difficult to get a standards-track RFC out quickly from this point. Unusual, yes, but not difficult. Mark Crispin did it in a week or so for RFC 4315 (another basically sound document with severe but superficial problems). The document author/editor has to react to comments and fix issues promptly. That's all there really is to it. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. The situation remains that the IETF does not have any mechanism to apply pressure on organizations to disclose patent information. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt
Folks, At Tue, 24 Nov 2009 16:00:48 +0100, Julian Reschke wrote: To illustrate the problem: for IETF Experimental, with Consensus Call, we get: This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community... I think This document defines an Experimental Protocol for the Internet community. It is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community... would read much better. Best regards, Julian (1) For clarity in the Experimental case, I'd like to add: The sentence, Discussion and suggestions for improvement are requested. had been left over in multiple examples in Appendix A. It had been confirmed that it would be deleted in all instances, since this sentence does not appear in the normative text of the memo. But apparently, it has been left undetected in the example in A.2. At Mon, 26 Jan 2009 10:52:20 +0100, Olaf Kolkman wrote: On Jan 23, 2009, at 5:13 PM, Alfred Hönes wrote: ... Again Alfred, thanks ... You identified 2 issues, that have not been brought up before. And although we should have passed the done-is-done point I think that these points are substantive enough to address, while IMHO not really contentious, and since I am spinning the document for all the NITS I plan to address them as below. start quote However, I have one general concern, and one important suggestion: The boilerplate sentence Discussion and suggestions for improvement are requested. apparently now shall only be included for Experimental RFCs. In the past, it was generally applied, and I always understood it to be at the heart of the IETF process and culture. I don't recall that this topic has been discussed on the list, so it's dropping might have happened inadvertantly. Please check. IMHO, Proposed Standards (for instance) would need feedback perhaps even more than Experimental documents; only for RFCs immediately published as Historic this clause makes less sense. In the case of Independent Submissions describing 3rd-party protocols, RFC publication might have been sought for just this goal, to start discussion in the IETF at large. According to my experience, even the IAB appreciates feedback to IAB Stream RFCs after publication. :-) This inconsistency seemed to have been introduced inadvertently. I propose to _not_ have this information in the boilerplate but include it explicitly in where the Updates to this Reference refers to (in section 3.4). ... and so it has been confirmed on the list subsequently, and so happened the text changes, with the sincle exception of the leftover sentence in Appendix A.2. Hence, I conclude this sentence can be deleted by the RFC Editor or in AUTH48 without violating procedural rules. (2) Even worse from the stylistic perspective is the Historic case; for instance, assuming an IETF WG documenting an original contribution to its work (text constructed according to Sect.3): | This document is not an Internet Standards Track specification; it | has been published for the historical record. | |! This document defines a Historic Document for the Internet community. |! This document is a product of the Internet Engineering Task Force | (IETF). It has been approved for publication by the Internet | Engineering Steering Group (IESG). Not all documents approved by the | IESG are candidate for any level of Internet Standards; see Section 2 | of RFC . I strongly recommend to change This document defines a Historic Document ... to This document is a Historic Document ... and continuing with It is ... in the next sentence, as proposed by Julian for the Experimental case above. (3) IIRC, the IAB Chair once had stated on the rfc-interest list that, in order to speed up the approval and publication of the document, final wordsmithing shall be deferred to the RFC Editor. Does this still hold? If yes, please let the RFC Editor perform as usual what they are being paid for, or adjust the language in AUTH48! Thanks! Note -- for the record of those who did not follow the discussion: The much more pleasant and locical permutation of the same text for the above case ... | This document is a Historic Document for the Internet community. | It is not an Internet Standards Track specification; it has been | published for the historical record. | | This document is a product of the Internet Engineering Task Force | (IETF). It has been approved for publication by the Internet | Engineering Steering Group (IESG). Not all documents approved by the | IESG are candidate for any level of Internet Standards; see Section 2 | of RFC . ... had been rejected. There have been strong voices from the IESG insisting on that it is more important to state what a document
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Can we please recommend *not* to put a file extension into the URL? The text can be updated - there is no file extension. The URL is of the form: http://www.rfc-editor.org/static-path/rfcrfc-no For example: http://www.rfc-editor.org/info/rfc2026 RFC Editor/ah On Nov 24, 2009, at 7:01 AM, Julian Reschke wrote: Hi, I just created five test cases representing the appendices A.1 to A.5. Turns out that the text in the examples is not in sync with the definitions in Section 3 (see, for instance, http://greenbytes.de/tech/webdav/rfc2629xslt/samples/ sample.ipr.rfc.hab.a2.test.xhtml). Best regards, Julian Julian Reschke wrote: Julian Reschke wrote: http://tools.ietf.org/html/draft-iab-streams-headers- boilerplates-08#section-3.2.3 says: Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/static-path/rfcrfc-no.html Can we please recommend *not* to put a file extension into the URL? BR, Julian ... Hi, in the meantime I have finished a prototype implementation of the new boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is available from http://greenbytes.de/tech/webdav/rfc2629xslt.zip, and requires the use of two new extension Processing Instructions to enable the new boilerplate: ?rfc-ext h-a-b=yes? ?rfc-ext consensus=no? (where the first enables the new format, while the second provides the information about whether there was consensus, something the current xml2rfc format doesn't provide). I haven't found any problems in addition to what was reported before, except for a trailing dot in one of the boilerplate statements, and cases of repeating sentence beginnings -- maybe all of this can be fixed during AUTH48 (although I'd prefer to see this in a new draft for community review). For the record, here's a complete summary: -- snip -- 3.1. The title page header document source This describes the area where the work originates. Historically, all RFCs were labeled Network Working Group. Network Working Group refers to the original version of today's IETF when people from the original set of ARPANET sites and whomever else was interested -- the meetings were open -- got together to discuss, design and document proposed protocols [RFC0003]. Here, we obsolete the term Network Working Group in order to indicate the originating stream. The document source is the name of the RFC stream, as defined in [RFC4844] and its successors. At the time of this publication, the streams, and therefore the possible entries are: * Internet Engineering Task Force * Internet Architecture Board * Internet Research Task Force * Independent JRE: as discussed earlier: should this be Independent Submission instead of Independent? [RFC relation:RFC number[s]] Some relations between RFCs in the series are explicitly noted in the RFC header. For example, a new RFC may update one or more earlier RFCs. Currently two relationships are defined: Updates, and Obsoletes [RFC2223]. Variants like Obsoleted by are also used (e.g in [RFC5143]). Other types of relationships may be defined by the RFC Editor and may appear in future RFCs. JRE: Obsoleted By is not a variant of Obsoletes or Updates. 3.2.2. Paragraph 2 The second paragraph of the Status of This Memo will now include a paragraph describing the type of review and exposure the document has received. This is defined on a per-stream basis, subject to general review and oversight by the RFC Editor and IAB. There is a specific structure defined here to ensure there is clarity about review processes and document types. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. The paragraph may include some text that is specific to the initial document category, as follows: when a document is Experimental or Historic the second paragraph opens with: Experimental: This document defines an Experimental Protocol for the Internet community. Historic: This document defines a Historic Document for the Internet community. JRE: the way paragraph 2 is generated, we end up with instances where the 1st and 2nd sentence both start with This document. This is ugly. Is it too late to fix this? In addition a sentence indicating the consensus base within the IRTF may be added: This RFC represents the consensus of the insert_name Research Group of the Internet Research Task Force (IRTF). or alternatively This RFC represents the individual opinion(s) of one or more members of the insert_name Research Group of the Internet Research Task Force (IRTF). JRE: trailing dot missing in 2nd
RE: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Let's just get this published and go with what we have even if it does not necessarily read real pretty. The text of the strings can be updated at a later point by a modification of the RFC Style Guide if there are enough complaints about how the text looks. Given that it is boilerplate, I personally don't care that it does not flow. Jim -Original Message- From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest- boun...@rfc-editor.org] On Behalf Of Julian Reschke Sent: Tuesday, November 24, 2009 5:02 AM To: IETF discussion list; rfc-inter...@rfc-editor.org; xml2rfc Subject: [rfc-i] Important: do not publish draft-iab-streams-headers- boilerplates-08 as is! Hi, I just created five test cases representing the appendices A.1 to A.5. Turns out that the text in the examples is not in sync with the definitions in Section 3 (see, for instance, http://greenbytes.de/tech/webdav/rfc2629xslt/samples/sample.ipr.rfc.ha b.a2.test.xhtml). Best regards, Julian Julian Reschke wrote: Julian Reschke wrote: http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates- 08#section-3.2.3 says: Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/static-path/rfcrfc-no.html Can we please recommend *not* to put a file extension into the URL? BR, Julian ... Hi, in the meantime I have finished a prototype implementation of the new boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is available from http://greenbytes.de/tech/webdav/rfc2629xslt.zip, and requires the use of two new extension Processing Instructions to enable the new boilerplate: ?rfc-ext h-a-b=yes? ?rfc-ext consensus=no? (where the first enables the new format, while the second provides the information about whether there was consensus, something the current xml2rfc format doesn't provide). I haven't found any problems in addition to what was reported before, except for a trailing dot in one of the boilerplate statements, and cases of repeating sentence beginnings -- maybe all of this can be fixed during AUTH48 (although I'd prefer to see this in a new draft for community review). For the record, here's a complete summary: -- snip -- 3.1. The title page header document source This describes the area where the work originates. Historically, all RFCs were labeled Network Working Group. Network Working Group refers to the original version of today's IETF when people from the original set of ARPANET sites and whomever else was interested -- the meetings were open -- got together to discuss, design and document proposed protocols [RFC0003]. Here, we obsolete the term Network Working Group in order to indicate the originating stream. The document source is the name of the RFC stream, as defined in [RFC4844] and its successors. At the time of this publication, the streams, and therefore the possible entries are: * Internet Engineering Task Force * Internet Architecture Board * Internet Research Task Force * Independent JRE: as discussed earlier: should this be Independent Submission instead of Independent? [RFC relation:RFC number[s]] Some relations between RFCs in the series are explicitly noted in the RFC header. For example, a new RFC may update one or more earlier RFCs. Currently two relationships are defined: Updates, and Obsoletes [RFC2223]. Variants like Obsoleted by are also used (e.g in [RFC5143]). Other types of relationships may be defined by the RFC Editor and may appear in future RFCs. JRE: Obsoleted By is not a variant of Obsoletes or Updates. 3.2.2. Paragraph 2 The second paragraph of the Status of This Memo will now include a paragraph describing the type of review and exposure the document has received. This is defined on a per-stream basis, subject to general review and oversight by the RFC Editor and IAB. There is a specific structure defined here to ensure there is clarity about review processes and document types. These paragraphs will need to be defined and maintained as part of RFC stream definitions. Initial text, for current streams, is provided below. The paragraph may include some text that is specific to the initial document category, as follows: when a document is Experimental or Historic the second paragraph opens with: Experimental: This document defines an Experimental Protocol for the Internet community. Historic: This document defines a Historic Document for the Internet community. JRE: the way paragraph 2 is generated, we end up with instances where the 1st and 2nd sentence
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
Hi, - 'ESMTP and LMTP Transmission Types Registration ' [...] Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html Initial set of implementations is currently in the datatracker (see below). I do not know to whom I should write that. There is a trailing space at the end of the title. And the above URL is not the right one. -- Julien ÉLIE « Hâte-toi de bien vivre et songe que chaque jour est à lui seul une vie. » (Sénèque) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
Samuel Weiler writes: Registration of an IMAP keyword intended for common use (whether or not they use the $ prefix) requires Expert Review [RFC5226]. IESG appoints one or more Expert Reviewer, one of which is designated as the primary Expert Reviewer. IMAP keywords intended for common use SHOULD be standardized in IETF Consensus [RFC5226] documents. ... In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. Would it be better to say: requires either IETF Consensus or Expert Review? Not everybody is subscribed to ietf or ietf-announce mailing lists, so I would like for all common use registrations to go through the expert. I don't like the logic (while not everybody is subscribed to the lists, your expert surely could be, and it's easy from an AD to punt the doc to the expert). Acting as an IANA expert for IKEv2 registries, I have noticed that expert do not get any option to say anything for documents which go through IESG. The IANA registry is just updated without any discussion with expert in those cases. So I do not think whether it affects anything if you say requires Expert Review compared to the requires Expert Review or IETF Consensus, or at least you might want to add explicit text to make it sure that the review policy mandates that all assignments go through the Expert.. -- kivi...@iki.fi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
On Wed, 18 Nov 2009, Alexey Melnikov wrote: Further registrations will be done by the designated expert. I am concerned that if I put all of them in the document, then the document will never finish. Sympathies. And for the common-use: Registration of an IMAP keyword intended for common use (whether or not they use the $ prefix) requires Expert Review [RFC5226]. IESG appoints one or more Expert Reviewer, one of which is designated as the primary Expert Reviewer. IMAP keywords intended for common use SHOULD be standardized in IETF Consensus [RFC5226] documents. ... In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. Would it be better to say: requires either IETF Consensus or Expert Review? Not everybody is subscribed to ietf or ietf-announce mailing lists, so I would like for all common use registrations to go through the expert. I don't like the logic (while not everybody is subscribed to the lists, your expert surely could be, and it's easy from an AD to punt the doc to the expert). That said, since you want everything to go through the expert, to avoid confusion, I suggest removing the citation to the inapplicable 5226 metric: IETF Consensus [RFC5226]. (For example: do the registrations made in this doc have to go through Expert Review? No, because they are a part of the document that creates the registry ;-). Isn't it enough to have them in a consensus doc?) And how do you expect the expert to encourage/enforce the SHOULD, given the favour registering it over requiring perfect documentation guideline? Again, the current text isn't as clear as I'd like. This is intentional. This is a judgment call by the expert. This sounds inconsistent. I'm hearing it's within the scope of the expert's judgement to require an IETF Consensus doc and In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. If I were an implementer who got told you need a consensus doc, I'd be more than a little tempted to go ahead and deploy, then reapply for the registration. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have reviewed draft (-08) and support it, on the Informational track. Review comments. * The NSEC type is used for negative responses (from a discussion in DNSEXT). However, the draft specifies that only the bitmap for types 0-255 is to be included. I feel this is overly constrained. The restriction may prove burdensome, also since those types are not really in use anyway (except DLV), the effect of the rule is very low. Is this for backwards compatibility? If it is for packet size, well, TXT records can be large too and are not disallowed either. * The document is verbose, but well written. * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. * The mdns resolver is highly integrated into the device it is on, with an 'active interest and notification API'-recommended, with interface changes (up down netmasks) and sleep-wake cycle information used. Thus this is very different from unicast DNS, whose servers are more independent. The rule to do punycode (unicast) to utf8 (multicast) conversion does not make the codebase smaller. * There is a line about the use of DNSSEC when mdns is used during a unicast DNS outage. The sentiment about protecting against forged answers is fine (this issue is handled well in general), but I think building a chain of trust towards DNSSEC-attested data is going to be very hard when unicast DNS is down. * I noted that the TC flag on unicast still means TCP fallback but this does not work in all cases. It is of course very useful to get large replies to legacy (unicast) queriers. Case: the other hosts can see a multicast query, and the full answer cannot be sent on multicast (due to size, even with TC=1 on multicast for message concatenation), the other hosts conclude there is no answer after timeout. The unicast response to the querier does have the required effect, but only for the original querier. This is probably not an issue since such large (9kb RR rdata) records are not common. A response that would trigger TCP connections from all multicast hosts on the network is probably not such a good idea :-) Some multicast error response, SERVFAIL for that query, so the other hosts do not modify their cache? (since existing code ignores rcode!=0, this is probably backwards compatible) * It may be prudent to have in conflict resolution a line that says that if repeated conflicted announcements of unique records are observed by another host, then the host SHOULD consider itself to have lost (and rename itself). Or put differently: if a particular host on the network keeps causing conflicts, get out of the way, even if the spec says you should have won, because this avoids packet-chatter on the network. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksM/mEACgkQkDLqNwOhpPjivQCbBx+PkX9gYv5k5ZjVs8Wa1dZW 93EAoIcyGETGZf4UYXZMcVoS2Y2WGY++ =l/6N -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Simon Josefsson wrote: Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Hi Simon, This is certainly correct in principles. But to which extent the IETF disclosure approach is easy to work around by having two persons ... is a matter of appreciation. My understanding is that it is not easy to arrange protocol engineer rolls in such a way. I'm quite sure you don't have a clear case which you can refer to support the opposite view. The reason I am confident is that both inventor status and an IETF contributor require creativity in general. The IETF collective engineering faces technological challenges like any other design group. I guess it is not realistic to expect managers to send protocol engineers with little creativity traits to the IETF in order to preserve the ability to file patent applications without disclosure. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. The situation remains that the IETF does not have any mechanism to apply pressure on organizations to disclose patent information. This is certainly correct, but I am afraid the cause is more profound than the above IPR disclosure work around. Specifically, the Qualcom vs Broadcom case on JVT over H.264 IPR would have taught corporate lawyers that a standardization body membership contract binding to the corporation is a must for IPR disclosure enforcement against the corporation. (I am not a lawyer ...) The IETF does not use this approach. Regards, - Thierry Moreau /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard
I support draft-ietf-tls-renegotiation-01.txt. -- Robert DugalSenior Software Developer Certicom Corp. A Subsidiary of Research In Motion rdu...@certicom.com direct905.501.3848 fax 905.507.4230 www.certicom.com -Original Message- From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, November 30, 2009 10:38 AM To: IETF-Announce Cc: t...@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' draft-ietf-tls-renegotiation-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19412rfc_flag=0 ___ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
Samuel Weiler answers Alexey: Isn't it enough to have them in a consensus doc?) And how do you expect the expert to encourage/enforce the SHOULD, given the favour registering it over requiring perfect documentation guideline? Again, the current text isn't as clear as I'd like. This is intentional. This is a judgment call by the expert. This sounds inconsistent. I'm hearing it's within the scope of the expert's judgement to require an IETF Consensus doc and In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. If I were an implementer who got told you need a consensus doc, I'd be more than a little tempted to go ahead and deploy, then reapply for the registration. That's now how it happens. The consensus issues mostly have been about naming (different names for the same thing), and IMO were caused by lack of knowledge/communication. Merely talking two the expert would likely fix most. Also, I'd like to mention that Lisa asked two people whether they could serve; both of her nominees are people who would be likely to give helpful answers, not send implementers away with one-sentence answer such as go write a consensus doc. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes: Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? Make sure (through confidentiality agreements) that the second one do not talk with the first? Putting them in different continents helps. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
Julien ÉLIE wrote: Hi, Hi Julien, - 'ESMTP and LMTP Transmission Types Registration ' [...] Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html Initial set of implementations is currently in the datatracker (see below). I do not know to whom I should write that. There is a trailing space at the end of the title. RFC Editor is not responsible for that. I can ask Secretariat. And the above URL is not the right one. Implementation report for RFC 3848 is not upload yet to the URL listed above. It can be found at the URL you've deleted from your reply. The implementation report will be uploaded to http://www.ietf.org/iesg/implementation.html after IETF LC. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
The biggest problem I have with this document is among those pointed out by Wouter: * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. As stated above, it's already a somewhat common practice to use .local in *private* DNS namespaces (e.g., corporate networks), whether we like it or not, and the current text in the mdns draft section 3 is incompatible with this (i.e., it proposes to break them). The current practice is cited in many places including: http://tools.ietf.org/html/draft-kato-dnsop-local-zones-00 While it has yet been described in a RFC, .local is used to provide a local subspace of the DNS tree. Formal delegation process has not been completed for this TLD. In spite of this informal status, .local has been used in many installations regardless of the awareness of the users. http://en.wikipedia.org/wiki/Top-level_domain The top-level pseudo domain local is required by the Zeroconf protocol. It is also used by many organizations internally, which may become a problem for those users as Zeroconf becomes more popular. And there's lots of places people have complained about this conflict with mdns, such as: http://lists.apple.com/archives/Macnetworkprog/2004/Oct/msg00089.html http://www.markwilson.co.uk/blog/2007/11/managing-simultaneous-access-to-resources-from-both-internal-and-external-dns-namespaces.htm http://www.macosxhints.com/article.php?story=20040806232315819 etc -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-sasl-gs2-18
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-sasl-gs2-18 Reviewer: Spencer Dawkins Review Date: 2009-11-30 IETF LC End Date: 2009-11-18 (oops!) IESG Telechat date: 2009-12-03 Summary: This document is almost ready for publication as a Proposed Standard. I did have one minor question about 13.3 (in my LATE review), but it should not be difficult to resolve, if an AD agrees with my question. I did tag a fair number of nits, but these aren't part of the Gen-ART review, and are simply included as a convenience for anyone else who edits the document. 1. Introduction The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than The Kerberos V5 GSS-API mechanism [RFC1964] Spencer (nit): s/The Kerberos/The Kerberos/ [RFC4121], and has a number of problems that lead us to desire a new Spencer (nit): s/lead/led/ bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, SCRAM Spencer (nit): please expand SCRAM on first use. [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2. In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. 3.3. Examples The last step translate each decimal value using table 3 in Base32 Spencer (nit): s/translate/translates/? [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is GS2-DT4PIK22T6A. 8. GSS-API Parameters The mutual_req_flag MUST be set. If channel binding is used then the client MUST check that the corresponding ret_flag is set when the context is fully establish, else authentication MUST fail. Spencer (nit): s/establish/established/ Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS-API naming options. 11. GSS_Inquire_mech_for_SASLname call To allow SASL clients to more efficiently identify which GSS-API mechanism a particular SASL mechanism name refers to we specify a new GSS-API utility function for this purpose. Spencer (nit): whew! hard to parse. Suggest We specify a new GSS-API utility function to allow SASL clients to more efficiently identify the GSS-API mechanism that a particular SASL mechanism name refers to, or something like that? 13.3. Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS. Spencer (minor): If prefer the mechanism is the right way to describe this, I apologize, but I don't know what the MUST means in practice - if this needs to be at MUST strength, I'd expect text like MUST use X and MUST NOT use Y or Z, or MUST use X unless the server doesn't support X. 14. GSS-API Mechanisms that negotiate other mechanisms A GSS-API mechanism that negotiate other mechanisms interact badly Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will interact/ ? with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below. 14.1. The interoperability problem If a client implement GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implement GSS-API Spencer (nit): s/implement/implements/ mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail. 14.2. Security problem If a client's policy is to first prefer GSSAPI mechanism X, then non- GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports mechanisms Y and Z but not X, then if the client attempts to negotiate mechanism X by using a GSS-API mechanism that negotiate Spencer (nit): s/negotiate/negotiates/ other mechanisms (such as SPNEGO), it may end up using mechanism Z Spencer (nit): you provide a
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On 2009-12-01 06:03, Thierry Moreau wrote: Simon Josefsson wrote: Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Replying first to Simon: The requirement is indeed on individual participants and only if they reasonably and personally know about the IPR. But employees participating in an activity for their employer are (afaik, IANAL) acting as agents of their employer, and it's standard practice in most companies for them to have their legal obligations such as IPR disclosure handled by a company lawyer or IPR specialist. So the distinction really doesn't matter. I believe that we included reasonably and personally known exactly because of the problem of employees of one department of a big company not knowing what other departments were doing, and to avoid the onerous cost of a patent search for employees of companies holding tens of thousands of patents. I believe that this setting of the rules has worked well since the disclosure requirement was introduced in 1996. Hi Simon, This is certainly correct in principles. But to which extent the IETF disclosure approach is easy to work around by having two persons ... is a matter of appreciation. My understanding is that it is not easy to arrange protocol engineer rolls in such a way. I'm quite sure you don't have a clear case which you can refer to support the opposite view. The reason I am confident is that both inventor status and an IETF contributor require creativity in general. The IETF collective engineering faces technological challenges like any other design group. I guess it is not realistic to expect managers to send protocol engineers with little creativity traits to the IETF in order to preserve the ability to file patent applications without disclosure. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. The situation remains that the IETF does not have any mechanism to apply pressure on organizations to disclose patent information. This is certainly correct, but I am afraid the cause is more profound than the above IPR disclosure work around. Specifically, the Qualcom vs Broadcom case on JVT over H.264 IPR would have taught corporate lawyers that a standardization body membership contract binding to the corporation is a must for IPR disclosure enforcement against the corporation. (I am not a lawyer ...) The IETF does not use this approach. Replying to Thierry: Again, IANAL, but I understand that participants and their employers are bound by the IETF rules by the simple fact of participation, with no need for an explicit contract. The famous Note Well text is simply a reminder of that. The IETF doesn't need to enforce anything; patent holders who break the rules will have to explain why to a judge, if someone challenges their patent in court. Of course, we can underline the point by choosing to rescind a standard if a participant is found to have broken the rules. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On Mon, 2009-11-30 at 18:50 +0100, Simon Josefsson wrote: Arnt Gulbrandsen a...@gulbrandsen.priv.no writes: Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? Make sure (through confidentiality agreements) that the second one do not talk with the first? Putting them in different continents helps. Not relevant in this case - the participating individuals were named on the patent applications as inventors. It would be hard to convince a judge that they didn't know... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pkix-attr-cert-mime-type (Theapplication/pkix-attr-cert Content Type for AttributeCertificates) to Informational RFC
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-pkix-attr-cert-mime-type-02 Reviewer: Spencer Dawkins Review Date: 2009-11-30 IETF LC End Date: 2009-11-29 IESG Telechat date: (Not known) Summary: This document is ready for publication as an Informational RFC. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 25 Nov, 2009, at 01:52, W.C.A. Wijngaards wrote: * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. I think you may be misreading this. A statement of MUST do X does not imply MUST NOT do NOT X. A host implementing Multicast DNS, performing a Multicast DNS query, MUST send that query to the Multicast DNS port, or it won't work. There's no SHOULD about it. An implementation cannot choose to send the Multicast DNS query to a different port and expect it to work. A host implementing Multicast DNS generally implements a variety of other name resolution mechanisms like standard unicast DNS, NetBIOS, a local /etc/hosts file, etc., and names can be looked up via those mechanisms too. Indeed, you will find that if you install iTunes on your PC, even at a site that's set up a private DNS server for local, the sky does not fall. What happens is that Windows (and Mac OS X too) look up dot-local names both ways. Looking up names more than one way is not as efficient as it could be, and it might be better if we didn't have to do that, but it does work. I will add some text explaining this. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-hip-native-api-09
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-hip-native-api-09 Reviewer: Ben Campbell Review Date: 2009-11-30 IETF LC End Date: 2009-12-03 IESG Telechat date: (if known) Summary: This draft is ready for publication as an experimental RFC. I have a small number of editorial comments that might be worth addressing if there is a new version prior to publication. Major issues: None Minor issues: None Nits/editorial comments: --Section 1, paragraph 3: Please expand ORCHID on first mention. -- Section 1, paragraph 4: Please expand LSI on first mention. -- Section 4.2, first paragraph after figure 3: Am I correct in assuming the EAI_FAMILY error only happens if the ai_family field was set to AF_HIP? That is, it would not make sense for AF_UNSPEC? The paragraph structure makes it looks like it applies to both. -- idnits returns the following, which I include without prejudice: idnits 2.11.15 tmp/draft-ietf-hip-native-api-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): == The document has an IETF Trust Provisions (12 Sep 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: == Line 393 has weird spacing: '... structsoc...' == Line 395 has weird spacing: '... structadd...' == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking references for intended status: Experimental == Outdated reference: A later version (-10) exists of draft-ietf-shim6-multihome-shim-api-09 == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 Summary: 0 errors (**), 6 warnings (==), 0 comments (--). Run idnits with the --verbose option for more detailed information about the items above. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote: 90% of this proposal is equally relevant to the enterprise case. But the multicast part is not. The document is called Multicast DNS. Which parts of the document do you think do *not* relate to multicast? Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard
Paragraph 3 of section 4 says: Because this cipher suite is equivalent to an empty renegotiation_info extension, only renegotiation_info may be used rehandshakes. Leaving aside the incorrect punctuation, this doesn't make any sense to me. In section 5, suggest replacing all occurrences of the word draft with the word specification. In section 6.2, s/NOT allow clients who do not offer the renegotiation_info extension/NOT allow clients which do not offer the renegotiation_info extension/. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Arnt Gulbrandsen [mailto://a...@gulbrandsen.priv.no] writes: Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? It seems very easy to me, and need not imply any kind of plotting. Many large companies offer incentives for filing patents and in that case it is in one's own self interest to be on the lookout for patentable ideas whatever the source may be... Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-fecframe-dvb-al-fec (DVB-IPTV Application-Layer Hybrid FEC Protection) to Informational RFC
The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'DVB-IPTV Application-Layer Hybrid FEC Protection ' draft-ietf-fecframe-dvb-al-fec-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17674rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-fecframe-interleaved-fec-scheme (RTP Payload Format for 1-D Interleaved Parity FEC) to Proposed Standard
The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'RTP Payload Format for 1-D Interleaved Parity FEC ' draft-ietf-fecframe-interleaved-fec-scheme-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17673rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dkim-deployment (DomainKeys Identified Mail (DKIM) Development, Deployment and Operations) to Informational RFC
The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DomainKeys Identified Mail (DKIM) Development, Deployment and Operations ' draft-ietf-dkim-deployment-09.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dkim-deployment-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16634rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' draft-ietf-tls-renegotiation-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19412rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-duerst-mailto-bis (The 'mailto' URI Scheme) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'The 'mailto' URI Scheme ' draft-duerst-mailto-bis-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-01-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12939rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-duerst-mailto-bis (The 'mailto' URI Scheme) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'The 'mailto' URI Scheme ' draft-duerst-mailto-bis-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-01-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12939rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Handling of overlapping IPv6 fragments' to Proposed Standard
The IESG has approved the following document: - 'Handling of overlapping IPv6 fragments ' draft-ietf-6man-overlap-fragment-03.txt as a Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-overlap-fragment-03.txt Technical Summary The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. Working Group Summary The 6MAN working group has done extensive review of this document and it represents the strong consensus of the group. Document Quality This document has been reviewed by key members of the 6MAN working group and the chairs. Personnel Document Shepherd is Brian Haberman and the responsible Area Director is Jari Arkko. RFC Editor Note Please move references RFC 1858 and RFC 4942 to the informative references section. Please add the following text to the end of Section 4: Nodes MAY also provide mechanisms to track the reception of such packets, for instance, by implementing counters or alarms relating to these events. Please change the title of Section 4 to Node Behavior Please change the last sentence of Section 1 as follows: OLD: This document explores the issues that can be caused by overlapping fragments. NEW: This document explores the issues that can be caused by overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Language Tag Registry Update (ltru)
The Language Tag Registry Update (ltru) working group in the Applications Area has concluded. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. The LTRU working group has successfully completed its deliverables and can now be closed. The ADs would like to thank everyone who participated in the work over the years. The mailing list will remain open. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IMAP Support for UTF-8' to Experimental RFC
The IESG has approved the following document: - 'IMAP Support for UTF-8 ' draft-ietf-eai-imap-utf8-09.txt as an Experimental RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-09.txt Technical Summary This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. Working Group Summary The WG has consensus on the mechanisms described in this document. Document Quality Alexey Melnikov has reviewed this document most carefully before he became AD. One implementation of the document is known. Personnel Harald Alvestrand is the document shepherd. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 2, the last sentence: OLD: This specification creates five new IMAP capabilities to allow servers to advertise these new extensions, along with two new IMAP list extensions and a new IMAP list return option. NEW: This specification creates five new IMAP capabilities to allow servers to advertise these new extensions, along with two new IMAP LIST selection ^^ options and a new IMAP list return option. ^^^ In Section 3, 2nd paragraph, the last 2 sentences: OLD: (Note that the UTF8=ONLY capability described in Section 7 implies the UTF8=ACCEPT capability. See additional information in that section.) NEW: (Note that the UTF8=ONLY capability described in Section 7 and the UTF8=ALL capability described in Section 6 imply the UTF8=ACCEPT capability. See additional information in these sections.) Section 3.1., paragraph 7: would be the same as if other syntacticly valid but semantically Nit: s/syntacticly/syntactically/ Section 3.4., paragraph 1: LIST-EXTENEDED [RFC5258] capability, the server MUST support the Nit: s/LIST-EXTENEDED/LIST-EXTENDED/ In Section 5, please change the last sentence to read: OLD: The server MUST reject UTF-8 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. NEW: The server MUST reject UTF-8 which fails to comply with the formal syntax in RFC 3629 [RFC3629] or if it encounters a Unicode characters listed in section 2.3 of SASLprep [RFC4013]. In Section 6 add another paragraph to the end: NEW: Note that the UTF8=ALL capability implies the UTF8=ACCEPT capability. In Section 8, change the last sentence of the 3rd paragraph to read: OLD: Other widely deployed MIME charsets SHOULD be supported. NEW: If the server supports other charsets in IMAP SEARCH or IMAP CONVERT [RFC5259], it SHOULD also support those charsets in this conversion. and also add [RFC5259] to the list of Normative References. Add a new Appendix B Examples demonstrating relationships between UTF8= capabilities: UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ACCEPT UTF8=ALL UTF8=ALL ; Note, same as above UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY UTF8=USER UTF8=ONLY ; Note, same as above In the IANA Considerations section please replace RFC with the RFC number of this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Post-Repair Loss RLE Report Block Type for RTCP XR' to Proposed Standard
The IESG has approved the following document: - 'Post-Repair Loss RLE Report Block Type for RTCP XR ' draft-ietf-avt-post-repair-rtcp-xr-07.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-post-repair-rtcp-xr-07.txt Technical Summary This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss-repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP). Working Group Summary The document has been reviewed by the AVT working group to ensure consistency with RTCP XR. Document Quality There are implementations of RTCP-XR and this draft adds a new report type. The document was reviewed by Alan Clark and Geoff Hunt, both have been involved with the RTCP-XR work. Personnel Roni Even is the document shepherd. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
