IPv6 @ IETF-71, especially Jabber
What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because I've had an IPv6 mail server for years and a WWW proxy that allows IPv6-only hosts to get access to the IPv4 web is fairly trivial to set up (tip for XP users: XP can't do DNS lookups over IPv6, use Firefox and configure it with the IPv6 address of the proxy), my preperation for this has been mostly getting Jabber to work over IPv6. A while ago I managed to find a public Jabber server that is reachable over IPv6 (amessage.de with some other domains pointing to the same server). Unfortunately, the client I generally use, Apple's iChat, does support Jabber over IPv6 when there is IPv4 connectivity, but when the system has no IPv4 address it says that you're not connected to the internet and doesn't try to connect over IPv6. Recently I thought this was fixed but it turned out that the Parallels Desktop virtualization enviroment sets up a bunch of virtual interfaces with private addresses, which is enough for iChat to work over IPv6. Anyway, I started looking for Jabber clients that support IPv6. Most don't, but there are so many Jabber clients that there is actually a choice of ones that do. Unfortunately, none of them could connect to the jabber.ietf.org rooms. I first thought this was because of the clients, so I didn't keep a list of clients that support IPv6. But it turned out that this is a problem with my iljitsch at amessage.nl account on the amessage.de server, which doesn't seem IPv6-related. So... does anyone know a place to obtain a Jabber account that's usable over IPv6? I assumed psg.com would be a good candidate, but even though psg.com has a record, jabber.psg.com doesn't. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 @ IETF-71, especially Jabber
Iljitsch raises an interesting point that I'll generalize: can we maximize the learning by identifying specific applications to target for IPv6 compatibility during the IPv4 eclipse? - Ralph On Feb 29, 2008, at Feb 29, 2008,9:34 AM, Iljitsch van Beijnum wrote: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because I've had an IPv6 mail server for years and a WWW proxy that allows IPv6-only hosts to get access to the IPv4 web is fairly trivial to set up (tip for XP users: XP can't do DNS lookups over IPv6, use Firefox and configure it with the IPv6 address of the proxy), my preperation for this has been mostly getting Jabber to work over IPv6. A while ago I managed to find a public Jabber server that is reachable over IPv6 (amessage.de with some other domains pointing to the same server). Unfortunately, the client I generally use, Apple's iChat, does support Jabber over IPv6 when there is IPv4 connectivity, but when the system has no IPv4 address it says that you're not connected to the internet and doesn't try to connect over IPv6. Recently I thought this was fixed but it turned out that the Parallels Desktop virtualization enviroment sets up a bunch of virtual interfaces with private addresses, which is enough for iChat to work over IPv6. Anyway, I started looking for Jabber clients that support IPv6. Most don't, but there are so many Jabber clients that there is actually a choice of ones that do. Unfortunately, none of them could connect to the jabber.ietf.org rooms. I first thought this was because of the clients, so I didn't keep a list of clients that support IPv6. But it turned out that this is a problem with my iljitsch at amessage.nl account on the amessage.de server, which doesn't seem IPv6-related. So... does anyone know a place to obtain a Jabber account that's usable over IPv6? I assumed psg.com would be a good candidate, but even though psg.com has a record, jabber.psg.com doesn't. ___ 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: IPv6 @ IETF-71, especially Jabber
On Fri, Feb 29, 2008 at 03:34:41PM +0100, Iljitsch van Beijnum [EMAIL PROTECTED] wrote a message of 35 lines which said: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because IPv6-only events are already banal? http://www.civil-tongue.net/clusterf/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 @ IETF-71, especially Jabber
Hi, To the basic question of the IPv4 outage -- preparations are indeed underway, to implement it as Russ described on 12/22/2007[1]. Early next week, there will be a wiki page accessible specifically for our event, providing more detail and more pointers. In the meantime, if you have specific comments, you can send comments to the team Russ set up[2]. In the meantime, NANOG and APRICOT have had similar events. You can see some of the data captured here: http://www.civil-tongue.net/grandx/ and some writeups: http://www.networkworld.com/community/node/25276 http://www.circleid.com/posts/82283_ipv6_hour_ipv4_switched_off/ Leslie. [1] [On December 22, 2007, Russ Housley wrote:] Following the mail list discussion, we have considered several different configurations for achieving the desired network experiment environment. It is important that everyone have adequate opportunity for advance configuration, and it is important that severe impact on other network resources at the meeting venue be avoided. With these goals in mind, we intend to add an additional IPv6-only subnet, with a different SSID on the wireless network. The SSID will include some clever name that includes the string v6ONLY. This SSID will be available on all the wireless access points throughout the venue for the entire week. Everyone is encouraged to try using this network well before the plenary session. Neighbors and friends are encouraged to help each other debug problems, and the kind folks at the help desk in the Terminal Room will also be happy to assist with any configuration challenges, IPv6-related or otherwise. [2] [EMAIL PROTECTED] Iljitsch van Beijnum wrote: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because I've had an IPv6 mail server for years and a WWW proxy that allows IPv6-only hosts to get access to the IPv4 web is fairly trivial to set up (tip for XP users: XP can't do DNS lookups over IPv6, use Firefox and configure it with the IPv6 address of the proxy), my preperation for this has been mostly getting Jabber to work over IPv6. A while ago I managed to find a public Jabber server that is reachable over IPv6 (amessage.de with some other domains pointing to the same server). Unfortunately, the client I generally use, Apple's iChat, does support Jabber over IPv6 when there is IPv4 connectivity, but when the system has no IPv4 address it says that you're not connected to the internet and doesn't try to connect over IPv6. Recently I thought this was fixed but it turned out that the Parallels Desktop virtualization enviroment sets up a bunch of virtual interfaces with private addresses, which is enough for iChat to work over IPv6. Anyway, I started looking for Jabber clients that support IPv6. Most don't, but there are so many Jabber clients that there is actually a choice of ones that do. Unfortunately, none of them could connect to the jabber.ietf.org rooms. I first thought this was because of the clients, so I didn't keep a list of clients that support IPv6. But it turned out that this is a problem with my iljitsch at amessage.nl account on the amessage.de server, which doesn't seem IPv6-related. So... does anyone know a place to obtain a Jabber account that's usable over IPv6? I assumed psg.com would be a good candidate, but even though psg.com has a record, jabber.psg.com doesn't. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 @ IETF-71, especially Jabber
On Fri, 29 Feb 2008, Stephane Bortzmeyer wrote: On Fri, Feb 29, 2008 at 03:34:41PM +0100, Iljitsch van Beijnum [EMAIL PROTECTED] wrote a message of 35 lines which said: What's going on with the preparations to turn off IPv4 at IETF-71? It's been really quiet surrounding that topic since the initial discussion. Because IPv6-only events are already banal? Hardly that. My understanding is that the IETF experiment is designed to give additional experience with configuration options as the NANOG and Apricot events were focused on v6only and v4v6 via NAT-PT. We're still learning new things with each v6 hour and I (for one) hope to see these experiments carried out in a number of venues as the real world experience helps inform on-going work. http://www.civil-tongue.net/clusterf/ see: http://www.civil-tongue.net/clusterf/wiki/APRICOT2008-Handout http://www.civil-tongue.net/clusterf/wiki/APRICOT2008-Lessons for some the the details of the last go-round. - Lucy ___ 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
Missing materials
I just ran getdrafts [0] on the entire agenda. The output is below. getdrafts reports three kinds of errors: - WGs without agendas: As you can see 42/98 WGs have no agendas two days after the agenda deadline. - Missing drafts: Drafts on an agenda which can't be found [1] - Corrected drafts: Drafts on an agenda which appear to have the wrong version number (if this is far enough off, we will report these as missing). -Ekr [0] https://svn.resiprocate.org/rep/ietf-drafts/ekr/getdrafts.pl [1] I note that this appears to incorrectly identify mmusic's agenda as a draft. Doh! WGs without agendas: apparea trill mpls pkix esds shim6 softwire ccamp forces l3vpn csi manet 6lowpan v6ops nea autoconf rtgarea intarea mipshop capwap pim 16ng rpsec kitten idn 6man canmod hokey lemonade ntp opsarea dna grow msec l2vpn eai mip4 tictoc opsawg saag savi smime Missing drafts draft-agenda-71.txt (wg=mmusic) draft-ietf-rmt-bb-fec-ldpc-06.txt (wg=rmt) draft-rmt-pi-norm-revised-06.txt (wg=rmt) draft-ietf-tsvwg-admitted-voice-dscp-03.txt (wg=tsvwg) draft-ietf-pwe3-redundancy-00.txt (wg=pwe3) draft-ietf-ccid4-02.txt (wg=dccp) draft-fairhurst-tsvwg-qs-02.txt (wg=dccp) draft-ietf-dnsext-rfc2671-edns0-00.txt (wg=dnsext) draft-dietz-ipfix-mib-02.txt (wg=ipfix) draft-xia-pana-simplified-00.txt (wg=pana) draft-ietf-isis-bfd-tlv-00.txt (wg=isis) draft-ietf-sip-sec-flows-01.txt (wg=sip) draft-ietf-sip-hop-limit-diagnostics-03.txt (wg=sip) Corrected drafts draft-ietf-sip-dtls-srtp-framework-00.txt - draft-ietf-sip-dtls-srtp-framework-01.txt (wg=mmusic) draft-ietf-mmusic-rtsp-nat-evaluation-00.txt - draft-ietf-mmusic-rtsp-nat-evaluation-01.txt (wg=mmusic) draft-davie-tsvwg-rsvp-l3vpn-01.txt - draft-davie-tsvwg-rsvp-l3vpn-02.txt (wg=tsvwg) draft-natarajan-tsvwg-sctp-nrsack-00.txt - draft-natarajan-tsvwg-sctp-nrsack-01.txt (wg=tsvwg) draft-ietf-lemonade-imap-sieve-04.txt - draft-ietf-lemonade-imap-sieve-05.txt (wg=sieve) draft-freed-sieve-environment-01.txt - draft-freed-sieve-environment-02.txt (wg=sieve) draft-melnikov-sieve-notify-sip-message-00.txt - draft-melnikov-sieve-notify-sip-message-01.txt (wg=sieve) draft-freed-sieve-in-xml-00.txt - draft-freed-sieve-in-xml-01.txt (wg=sieve) draft-freed-sieve-date-index-07.txt - draft-freed-sieve-date-index-08.txt (wg=sieve) draft-ietf-dhc-vpn-option-07.txt - draft-ietf-dhc-vpn-option-08.txt (wg=dhc) draft-ietf-tls-rfc4366-bis-01.txt - draft-ietf-tls-rfc4366-bis-02.txt (wg=tls) draft-ietf-sasl-crammd5-09.txt - draft-ietf-sasl-crammd5-10.txt (wg=sasl) draft-ietf-sasl-rfc2831bis-12.txt - draft-ietf-sasl-rfc2831bis-13.txt (wg=sasl) draft-josefsson-password-auth-00.txt - draft-josefsson-password-auth-01.txt (wg=sasl) draft-ietf-pce-global-concurrent-optimization-01.txt - draft-ietf-pce-global-concurrent-optimization-02.txt (wg=pce) draft-otani-pce-gmpls-aps-req-00.txt - draft-otani-pce-gmpls-aps-req-01.txt (wg=pce) draft-chan-pcn-encoding-comparison-02.txt - draft-chan-pcn-encoding-comparison-03.txt (wg=pcn) draft-zhang-pcn-performance-evaluation-02.txt - draft-zhang-pcn-performance-evaluation-03.txt (wg=pcn) draft-ietf-ancp-mib-an-02.txt - draft-ietf-ancp-mib-an-01.txt (wg=ancp) draft-ietf-psamp-info-07.txt - draft-ietf-psamp-info-08.txt (wg=ipfix) draft-ietf-ipfix-file-00.txt - draft-ietf-ipfix-file-01.txt (wg=ipfix) draft-ietf-ipfix-exporting-type-00.txt - draft-ietf-ipfix-exporting-type-01.txt (wg=ipfix) draft-muenz-ipfix-configuration-03.txt - draft-muenz-ipfix-configuration-04.txt (wg=ipfix) draft-claise-ipfix-export-per-sctp-stream-02.txt - draft-claise-ipfix-export-per-sctp-stream-03.txt (wg=ipfix) draft-kobayashi-ipfix-large-ps-00.txt - draft-kobayashi-ipfix-large-ps-01.txt (wg=ipfix) draft-kobayashi-ipfix-mediator-model-01.txt - draft-kobayashi-ipfix-mediator-model-02.txt (wg=ipfix) draft-aitken-ipfix-new-infos-01.txt - draft-aitken-ipfix-new-infos-02.txt (wg=ipfix) draft-ietf-mboned-routingarch-12.txt - draft-ietf-mboned-routingarch-13.txt (wg=mboned) draft-ietf-mboned-ip-mcast-mib-07.txt - draft-ietf-mboned-ip-mcast-mib-08.txt (wg=mboned) draft-ietf-mboned-ipv4-uni-based-mcast-04.txt - draft-ietf-mboned-ipv4-uni-based-mcast-05.txt (wg=mboned) draft-kaplan-sip-info-events-00.txt - draft-kaplan-sip-info-events-01.txt (wg=sip) draft-kaplan-sip-info-use-cases-00.txt - draft-kaplan-sip-info-use-cases-01.txt (wg=sip) draft-kaplan-sip-baiting-attack-01.txt - draft-kaplan-sip-baiting-attack-02.txt (wg=sip) draft-harkins-emu-eap-pwd-00.txt - draft-harkins-emu-eap-pwd-01.txt (wg=emu) draft-ietf-behave-nat-behavior-discovery-02.txt - draft-ietf-behave-nat-behavior-discovery-03.txt (wg=behave) draft-denis-behave-nat-dccp-00.txt - draft-denis-behave-nat-dccp-01.txt (wg=behave) Found 307 out of 320 drafts ___
Re: Gen-ART Review of draft-ietf-smime-sha2-03.txt
Hi, Sean, This is much better than I feared. There were just too many places in -03 where I was guessing what was intended, for me to say ready for publication, or even almost ready with nits. I know you don't make the decisions about when drafts are last-called, but when you talk to your shepherd, you might suggest looking at diffs for the version posted for last call. that popped up a lot of the concerns i had (which were also concerns that denis had). Best wishes with the draft. Spencer Spencer, Thanks for taking the time to read the draft. Responses are inline. spt -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 12:27 AM To: General Area Review Team Cc: Sean Turner; Blake Ramsdell; ietf@ietf.org; [EMAIL PROTECTED] Subject: Gen-ART Review of draft-ietf-smime-sha2-03.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Will do. Document: draft-ietf-smime-sha2-03.txt Reviewer: Spencer Dawkins Review Date: 2008 02 28 IETF LC End Date: 2008-03-07 IESG Telechat date: (if known) Summary: This document isn't ready for publication as a Proposed Standard - it's got enough cut-and-paste errors and apparently-omitted text that I'd think twice about trying to implement it. And if it has a note that says normative reference still in progress, should be brought in line with normative reference before publishing as an RFC, I'm not sure why it's being last called now (of course, that decision is above my pay grade). Wrt the reference, that draft is being worked in PKIX. Hopefully, it will progress quickly - I'm hoping for this summer (or sooner) for it to complete WG LC and IETF LC. Also, the reference is for object identifiers all of which were assigned years ago and are stable. Comments: Please include any nits listed in http://www.ietf.org/mail-archive/web/ietf/current/msg50518.html that I may have missed in this review, by reference :-( Will do. When one of the last call comments is There are obvious errors (intentionnaly left by the editor in order to know how many people read the document), this does not inspire confidence. I note there is no shepherd writeup in the tracker yet. The of for typo below has been in every version since 00. Who else has read this draft? This was, I believe, his attempt at humor. See my response to Denis' email. Abstract This document describes the conventions for using the message digest algorithms SHA-224, SHA-256, SHA-384, SHA-512, as defined in FIPS Nit - I'm not sure what passes for normal in security drafts, but I'd expect to see SHA and FIPS expanded on first use in the abstract, and in the introduction of the document. Ditto for DSA, RSA, and ECDSA. I will expand the acronyms. 180-3, with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the DSA, RSA, and ECDSA signature algorithms. Conventions used in this document Nit - it is odd to see this section as part of the abstract... For some reason the tool picks up this section as part of the abstract. It's got a heading title so I don't think it's in the abstract. 1. Introduction This document specifies the algorithm identifiers and specifies parameters for the message digest algorithms SHA-224, SHA-256, SHA- 384, and SHA-512 for use with the Cryptographic Message Syntax (CMS) [RFC3852]. The message digest algorithms are defined in and [SHS]. Concern: in and seems to be missing something. Denis caught this too. Will fix by removing the and. If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document. Concern: this MUST (and the parallel MUST in the next paragraph) seem odd - do you need to say this? Hmmm ... I guess not. I'll remove both sentences. Note that [RFC4231] specifies the conventions for use of for the Concern: of for seems to be missing something. I will remove for use of so the sentence will read: Note that [RFC4231] specifies the conventions for the message authentication code (MAC) algorithms message authentication code (MAC) algorithms: HMAC with SHA-224, HMAC with SHA-256, HMAC with SHA-384, and HMAC with SHA-512. 2. Message Digest Algorithms The following addresses the parameters field: Nit - this sentence isn't clear and isn't required. I'd strike it. Removed. There are two possible encodings for the SHA AlgorithmIdentifier parameters field. The two alternatives arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got
Audio Streaming - IETF 71 Philadelphia, PA, USA 9-14 March 2008
Greetings, All 8 parallel tracks will be broadcast starting with the commencement of working group sessions on Monday March 10 at 0900 EST (UTC-5) and continue until Friday at 1130 EST. Additionally it is our intention to broadcast the IEPG meeting occurring on Sunday the 9th starting at 1000 EST. Because I have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule will be available thanks to the continued support of the Network Startup Resource Center in their traditional location: http://videolab.uoregon.edu/events/ietf/ I Look forward to seeing some of you in Philadelphia and hope that this facility remains useful for remote participants in and observers of the IETF Process. Regards Joel Jaeggli ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Impending publication: draft-iab-dns-choices-05
The IAB is ready to ask the RFC-Editor to publish Design Choices When Expanding DNS draft-iab-dns-choices-05 as an Informational RFC. This document provides a number of considerations to assist application and protocol designers in choosing a mechanism to store and retrieve data in the DNS. It treats, among other things the pros and cons of using TXT records, and of adding prefixes or suffixes to owner names. It argues that adding an new Resource Record is the best solution to add new data to the DNS and that the use of TXT Resource Records is the worst. The IAB solicits comments by February 23, 2008. Please send comments to the IAB ([EMAIL PROTECTED]), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-choices-03.txt From the Abstract: This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. Olaf Kolkman, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-hokey-emsk-hierarchy (Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)) to Proposed Standard
The IESG has received a request from the Handover Keying WG (hokey) to consider the following document: - 'Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) ' draft-ietf-hokey-emsk-hierarchy-04.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 [EMAIL PROTECTED] mailing lists by 2008-03-21. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-hokey-emsk-hierarchy-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15627rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5098 on Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)
A new Request for Comments is now available in online RFC libraries. RFC 5098 Title: Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) Author: G. Beacham, S. Kumar, S. Channabasappa Status: Standards Track Date: February 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 79 Characters: 159415 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipcdn-pktc-signaling-15.txt URL:http://www.rfc-editor.org/rfc/rfc5098.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS TRACK] This document is a product of the IP over Cable Data Network Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
