Re: [CHANNEL-BINDING] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard
I support the goal of this document, i.e. to publish the text in the IANA repository as an RFC. There are differences between the text in the current IANA repository and the document. These differences are not spelled out in the document for the 'tls-server-end-point' channel binding. The document says: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. That is not correct, compare the content registered with IANA The hash of the TLS server's end entity certificate as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's end entity certificate.) The hash function to be selected is as follows: if the certificate's signature hash algorithm is either MD5 or SHA-1, then use SHA-256, otherwise use the certificate's signature hash algorithm. The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. with what the document says: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's certificate). The hash function is to be selected as follows: o if the certificate's signatureAlgorithm uses a single hash function, and that hash function is either MD5 [RFC1321] or SHA-1 [RFC3174] then use SHA-256 [FIPS-180-2]; o if the certificate's signatureAlgorithm uses a single hash function and that hash function neither MD5 nor SHA-1, then use the hash function associated with the certificate's signatureAlgorithm; o if the certificate's signatureAlgorithm uses no hash functions or multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises). The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. I suggest that the first paragraph quoted above from section 4 is modified like this: OLD: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. NEW: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a clarification to the description related to certificate's that do not use hash functions or use multiple hash functions. We also added a note indicating that this specification contains applicability advice, and we moved security considerations notes to the security considerations section of this document. The last sentence is copied from section 3 for consistency. Also missing is in section 3 and section 5 is a note that references were added to the text. I suggest: OLD: ...security considerations section of this document. All other fields of the registration are copied here for the convenience of readers. NEW: ...security considerations section of this document. References were added to the description. All other fields of the registration are copied here for the convenience of readers. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF
John, Dave, I disagree, at least slightly, but that is because I suffer from a concern --documented in a request for review and previous notes to this list-- that the IAOC/Trustees are _not_ doing their job, or at least the part of that job that requires keeping the community informed about the decisions they are making and the reasons for them. Speaking as myself. I think we have heard this message and we are working on improving communications. We have spent time to get all outstanding meetings done, we are now working on making minutes of new meetings more readable for somebody not present at the meeting. We also started to explicitly ask the community about choices we have to make for meetings, for example, Quebec vs. Vancouver or China or no China. BTW, we are still looking for a volunteer scribe for our meetings :-) Suppose he posted a list of questions to which he thought we should have answers before we put a meeting in any location that has a reputation (justified or not) for regulating the free flow of information, asked whether the IAOC had answers to those questions for a particular case, and, if they did, that they share those answers with the community? I think that would be reasonable and that the IAOC could reasonably respond to such a question by saying yes, similar questions were asked, we think the answers are reasonable, and the discussion is documented in the IAOC Minutes of Except that he did ask, hasn't gotten an answer like that and, by the way, there are no minutes of enough substance to be pointed to on that (or any other) issue. We have a long list with issues that we think should be settled before we decide to go there or not, and we are working on the document describing why we decided one way or another. Henk -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IETF and the SmartGrid
Brian E Carpenter wrote: On 2009-10-06 10:20, Richard Shockey wrote: The Utility Industry does not understand the current IPv4 number exhaust problem ... Ironic, really, since IP addresses for every streetlight was one of the favourite examples in the IPng days. +1 EPRI was an active participant in the IETF IPng discussions, in the early 90s, back when other IETF folk were claiming that we had no immediate pressure for expanded IP Addresses, and didn't have to solve this until 2010 or 2020... EPRI was /already/ being turned down for IPv4 address blocks, back then! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF
Cullen, For purposes of discussion, one comment below and one addition to your list... --On Monday, October 05, 2009 11:07 -0600 Cullen Jennings flu...@cisco.com wrote: I have done a little digging around on the questions I asked and thought I might summarize some of the responses I got back to my email. ... 3) Are there any rules around discussion, publication, or export of of cryptography algorithms and technology? publishing weaknesses of national crypto algorithms? The advice I got was that unless we got a license if the IETF developed crypto in China and we exported it out, then this would be illegal in PRC. It was pointed out PRC is not part of Wassenaar Arrangement. I was advised our broadcasts of and export of minutes from meetings would be Deemed Export. It seems pretty hard to argue that the IETF does not develop any crypto. Has the IAOC received any legal advice on this? Another piece of this question is whether PGP (or CACert) key-signing activities, with signed private keys being taken out of the country afterwards, would violate any law or require a license. I had previously assumed that the answer would be no, but the answers you have given to this question, the P2PSIP/CA one, and maybe others, leads me to wonder a bit. 7) Would we be OK running a BOF on techniques for firewall advancement in general and in particular on getting around any firewalls China runs? [Seriously, you know someone will propose this BOF, the questions is could we run it or not?] Answer I got was discussion of security policies of PRC's firewall and methods to get around it would definitely not be OK to discuss. Two of the many problems would be: 1) this is defamatory towards the state agency that run the firewalls 2) this could be considered release of state secrets Answer seemed pretty solid that this topic was not one that most people would consider a really bad idea to discuss in PRC. Too many negatives in that sentence for me to parse. Did you mean was one that ...bad idea to discuss or ok to discuss? 10) If the meeting is canceled, will the IETF be reimbursing the registration fees? That question may have an answer under US or European law (and probably other places): if someone paid the registration fee for a meeting, and paid for non-refundable airline tickets, hotel room, etc., on the basis of a good-faith assumption that the meeting would be held, would he or she have the right to a reasonable expectation of recovering those costs if the meeting were called off? Called off on any basis other than what I believe some lawyers call an Act of God? If the IAOC has gotten legal advice on this --from the IAOC's point of view, IASA's liability to participants if a meeting were cancelled-- could that advice be shared. As an interesting side note, it seems that some people think that many of these things are officially illegal but they are fine to do anyway because other meetings are doing them etc. This is not a position I share and more importantly, it is not a position where I am willing to ask our WG Chairs, authors, and other volunteers to do something illegal because it will all be fine. Even if there are no short term consequences, I can imagine a case where 10 years later someone is seeking security clearance and this comes back to bite them. Concur For the record, I'm still generally in favor of a meeting in Beijing. But I agree with Cullen that answers to these types of questions should be extremely clear before a decision to go is made and that, if any of the answers are sub-optimal, that the IESG should make a formal decision, after reviewing community input, etc., as to whether they believe that a satisfactory meeting can be held in spite of them. And I believe we should hold any potential meeting site to those standards, i.e., that this is not about the PRC. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF
While I do think that the IAOC should be aware of the potential legal implications of where we hold our meetings, I wonder if we are treating China unfairly in this discussion... On Oct 5, 2009, at 2:30 PM, Cullen Jennings wrote: The PGP Key signing is a good question - I have no idea - it's certainly something we have done in the past but if it is not legal in the PRC, I could live with a meeting where we did not do any PGP key signing. It detracts a bit from the meeting but is not in what I consider the mediatory must have core of the meeting. Of course this would mean that a group of people that did not often travel out of the PRC would be missing a great opportunity to sign with a group of people outside of China which I view as one of the benefits of having a meeting in Beijing. Do you know if the PGP signing (and taking the keys home) was legal when we did it in France? It is my understanding that there are (or were) French laws forbidding the export of crypto. However, I don't remember this being raised as a big concern when we held the IETF in Paris. Did we hire a Swedish lawyer to determine if all of our planned activities were legal before going to Stockholm? Does anyone know what laws there are about public assembly and/or public discussion of political issues in Japan? I realize that there is a lot of concern about going to China, and some of it may be justified. But, we should also be careful that we don't end-up holding China to a higher standard than other countries that we visit. If we believe that we should only go to countries where a specific set of activities are legal, we should (IMO) itemize those activities and seek to determine that they are legal in all of our destination countries before we commit to going there. Perhaps this is something that we could expect our host to help us determine? Margaret ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [CHANNEL-BINDING] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard
On Tue, Oct 06, 2009 at 09:45:16AM +0200, Simon Josefsson wrote: I support the goal of this document, i.e. to publish the text in the IANA repository as an RFC. There are differences between the text in the current IANA repository and the document. These differences are not spelled out in the document for the 'tls-server-end-point' channel binding. The document says: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. That is not correct, compare the content registered with IANA This is true, though the difference isn't likely to have any real impact, ever. That may be why I neglected to update the above note. I suggest that the first paragraph quoted above from section 4 is modified like this: OLD: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. NEW: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a clarification to the description related to certificate's that do not use hash functions or use multiple hash ^ remove apostrophe. functions. We also added a note indicating that this specification contains applicability advice, and we moved security considerations notes to the security considerations section of this document. The last sentence is copied from section 3 for consistency. Also missing is in section 3 and section 5 is a note that references were added to the text. I suggest: OLD: ...security considerations section of this document. All other fields of the registration are copied here for the convenience of readers. NEW: ...security considerations section of this document. References were added to the description. All other fields of the registration are copied here for the convenience of readers. I'm happy with your proposed changes. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard
FYI - Forwarded message from ji...@ties.itu.ch - Date: Fri, 2 Oct 2009 16:46:53 +0200 From: ji...@ties.itu.ch Reply-To: ji...@ties.itu.ch Subject: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard To: i...@ietf.org hi, As a carrier, we think it is very important to operate MPLS-TP OAM with a behavior that is consistent with transport network operations. So we propose the following requirement to be added to MPLS-TP OAM requirements draft: It MUST be possible to operate the MPLS-TP OAM protocols, which satisfy functional requirements that are common to general transport layer network (i.e., independent of technology), in a way that is similar to the way equivalent mechanisms are operated in other transport layer technologies (e.g., SONET/SDH, OTN and Ethernet). Best regards Jing Ruiquan China Telecom -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, September 21, 2009 4:31 PM To: IETF-Announce Cc: m...@ietf.org Subject: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Requirements for OAM in MPLS Transport Networks ' draft-ietf-mpls-tp-oam-requirements-03.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-10-05. 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-mpls-tp-oam-req uirements-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=18036rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce - End forwarded message - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-oam-requirements (RequirementsforOAMin MPLS Transport Networks) to Proposed Standard
Hi Adrian, Sorry for the mistake, I have resend the mail to IETF. As for your comments about specific requirements, IMHO, I think most of the requirements in the document are actually a little bit generic.And requirement 21 of RFC 5654 is so generic as well. The proposed requirement is specifying what that requirement means in the context of OAM. Another comments is about the Diagnostic Tests which include loopback and estimation of bandwidth. From a carrier's viewpoint, I think loopback and Route Tracing belonging to the same tpye of function, Bandwidth Measurement and Packet loss Measurement belonging to the same tpye of function. So I propose to make loopback as a individual requirement just as Route Tracing. Best regards Ruiquan Jing China Telecom -Original Message- From: Adrian Farrel [mailto:adrian.far...@huawei.com] Sent: Saturday, October 03, 2009 11:28 PM To: ruiquan.j...@ties.itu.int Cc: i...@ietf.org Subject: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (RequirementsforOAMin MPLS Transport Networks) to Proposed Standard By the way, was there an exceptional circumstance driving you to send direct to the IESG rather than to the IETF list? Thanks, Adrian - Original Message - From: Adrian Farrel adrian.far...@huawei.com To: ruiquan.j...@ties.itu.int; i...@ietf.org Sent: Friday, October 02, 2009 11:49 PM Subject: Re: Last Call: draft-ietf-mpls-tp-oam-requirements (RequirementsforOAMin MPLS Transport Networks) to Proposed Standard Hi Jing, As a carrier, we think it is very important to operate MPLS-TP OAM with a behavior that is consistent with transport network operations. So we propose the following requirement to be added to MPLS-TP OAM requirements draft: It MUST be possible to operate the MPLS-TP OAM protocols, which satisfy functional requirements that are common to general transport layer network (i.e., independent of technology), in a way that is similar to the way equivalent mechanisms are operated in other transport layer technologies (e.g., SONET/SDH, OTN and Ethernet). I want to make sure that your opinion is heard. To do this, we must convert this text into something more concrete that it is possible to implement. The problem is that what you have written is very widely scoped and would require an implementer to go and find out (from somewhere) what the actual requirements are. We need specific and tightly scoped requirements. That means that you need to document the individual functional requirements that are common to general transport layer networks and the mode of operation that would be similar to the [] equivalent mechanisms [] in other transport layer technologies. It is simply not enough to say I want the OAM to be sort of like something else. While I can sympathise with your desire, I could not produce a product that was certain to meet your requirements. So, I suggest that what you need to do is list specific requirements for functions or operational behavior that you believe are not already covered by this document. I know that the authors were trying to make the MPLS-TP OAM similar to both general packet networks and general transport networks - but they tried to do this by listing the detailed requirements one by one. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART Telechat review of draft-ietf-rtgwg-lf-conv-frmwk-06
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-rtgwg-lf-conv-frmwk-06 Reviewer: Ben Campbell Review Date: 06 Oct 2009 IESG Telechat date: 08 Oct 2009 Summary: This document is ready for publication as an informational RFC. I have a few remaining nits that may be worth addressing if there is a new revision, or possibly in auth 48--but none are worth blocking publication. Note: I reviewed revision 5 at last call. This review is incremental to that one. Most of my comments are addressed in revision 6. Major issues: None Minor issues: None Nits/editorial comments: -- A few nits from my previous review resulted in no change. I don't know if these were intentional choices (which is okay), or oversights, So I will paste them below, along with any additional comments where relevant: -- [Section 2] 2nd to last paragraph: congestion loss Did you mean congestion or packet loss? No change. To amplify, you use the term congestion loss, which I read to mean a reduction in congestion, i.e. a good thing. I don't think that's what you meant. Do you mean something like packet loss due to congestion? -- section 5.1, second to last paragraph: Is there a reference for the simulations? No change. It would be nice to have some evidence (a reference, or a sentence of two describing the simulations ) to back up assertions like simulations indicate. Otherwise they come off as weasel-words [ http://en.wikipedia.org/wiki/Weasel_words ] -- 6.1, first paragraph: s/can be proved/can be proven Also, is there a reference for such a proof? No change. See previous comment re: weasel words. -- idnits returns the following: Miscellaneous warnings: == 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.). Checking references for intended status: Informational == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ipfrr-framework-11 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
To the best of my knowledge, in the countries you mention, there was no contractual risk that normal activities of the IETF would result in arbitrary cancelation of the remainder of the meeting. On Mon, 5 Oct 2009, Margaret Wasserman wrote: While I do think that the IAOC should be aware of the potential legal implications of where we hold our meetings, I wonder if we are treating China unfairly in this discussion... On Oct 5, 2009, at 2:30 PM, Cullen Jennings wrote: The PGP Key signing is a good question - I have no idea - it's certainly something we have done in the past but if it is not legal in the PRC, I could live with a meeting where we did not do any PGP key signing. It detracts a bit from the meeting but is not in what I consider the mediatory must have core of the meeting. Of course this would mean that a group of people that did not often travel out of the PRC would be missing a great opportunity to sign with a group of people outside of China which I view as one of the benefits of having a meeting in Beijing. Do you know if the PGP signing (and taking the keys home) was legal when we did it in France? It is my understanding that there are (or were) French laws forbidding the export of crypto. However, I don't remember this being raised as a big concern when we held the IETF in Paris. Did we hire a Swedish lawyer to determine if all of our planned activities were legal before going to Stockholm? Does anyone know what laws there are about public assembly and/or public discussion of political issues in Japan? I realize that there is a lot of concern about going to China, and some of it may be justified. But, we should also be careful that we don't end-up holding China to a higher standard than other countries that we visit. If we believe that we should only go to countries where a specific set of activities are legal, we should (IMO) itemize those activities and seek to determine that they are legal in all of our destination countries before we commit to going there. Perhaps this is something that we could expect our host to help us determine? Margaret ___ 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: Update on IETF 76 ANA Hotel Availability
The ANA Hotel plans to ozone-deodorize all rooms in the IETF block, simply because the vast majority of our delegates prefer non smoking rooms. Alexa On Oct 5, 2009, at 11:27 AM, Ben Campbell wrote: Hi Alexa, How should one go about expressing to the hotel that they preferred non-smoking but were unable to get it? I assume they need some lead time for this, so mentioning it at arrival time might be too late. Thanks! Ben. On Oct 1, 2009, at 5:15 PM, Alexa Morris wrote: There are still a limited number of rooms available at the ANA Hotel (the IETF 76 venue) from November 5 through November 15th. We anticipate that these rooms will be sold out in the next couple of days. so please book now if you want one. Currently non-smoking rooms are available only on the block shoulder dates -- November 5-7 and 12-15. However, all smoking rooms will be ozone-deodorized prior to occupation by any IETF attendee who wanted a non-smoking room but was unable to secure one. The ozone deodorization process is considered one of the more effective odor removal methods. In addition, all sleeping rooms at the ANA have windows that do open several inches, allowing for fresh air. We are waiting to hear more about the availability of non smoking rooms at the overflow properties and hope to have an update for you shortly. 37 days until IETF 76! Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-forces-sctptml (SCTP based TML (Transport Mapping Layer) for ForCES protocol) to Proposed Standard
The IESG has received a request from the Forwarding and Control Element Separation WG (forces) to consider the following document: - 'SCTP based TML (Transport Mapping Layer) for ForCES protocol ' draft-ietf-forces-sctptml-06.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-10-20. 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-forces-sctptml-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=1rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-l3vpn-e2e-rsvp-te-reqts (Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN) to Informational RFC
The IESG has received a request from the Layer 3 Virtual Private Networks WG (l3vpn) to consider the following document: - 'Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN ' draft-ietf-l3vpn-e2e-rsvp-te-reqts-04.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-10-20. 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-l3vpn-e2e-rsvp-te-reqts-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17192rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-eai-pop (POP3 Support for UTF-8) to Experimental RFC
The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'POP3 Support for UTF-8 ' draft-ietf-eai-pop-07.txt as an Experimental 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-10-20. 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-eai-pop-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14991rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
