[secdir] Review of draft-levin-mmusic-xml-media-control-12
Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall as an informational ID I believe the document is well written and it should be published as soon as possible. I have the following non-blocking COMMENTS: 1. Section 2, inconsistent use of RFC2119 language, shipping products and new products SHALL use ..., the preceding sentence seems to suggest it is a SHOULD not a SHALL. 2. Section 4, the inconsistently spelling of in time vs in-time. Not being an expert in this field, it is not clear to me what the parenthesis actually adds. 3. Section 4, (what I consider) incorrect use of RFC2119 language, ... MUST be validated by ..., I do not know what does the use of MUST imply here. Suggestion: it should be sufficient to drop the MUST keyword here, try is validated 4. Section 5, the UAC that sent..., please expand UAC on first use. 5. section 7, unclear statement, Note that this primitive is supported by all known implementations, it is not clear to me which primitive it refers to. Suggestion: quote a reference for the primitive in question. 6. section 10, overall this section could benefit from more details or references. For example, it is not clear how TLS can be applied to secure the signalling path. Also the last sentence seems to contradict with the rest of this section. The section in RFC2976 only explicitly mentions confidentiality. Suggestion: it might be sufficient to say the security considerations in RFC2976 apply here. Best regards, --larry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Vint for the Japan Prize on TCP/IP
Vint, Congraturation, (again)! jun = http://www.japanprize.jp/prize/2008/e1_cerf.htm ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[secdir] Review of draft-ietf-enum-calendar-service-03
Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have the following COMMENTS: 1. Overall, the document does not discuss I18N. Is it required that the mailto contains US ASCII only when it is encoded in DNS? This is unclear to me. 2. Section 4, what is the security implication if the same number is used to identify different URIs. In other words, what prevents the choice of numbers from collisions and what happens when there is a collision. Number squatting does not seem to be mitigated by DNS SEC as mentioned in the document. This is just not clear to me but I am not an expert here. 3. I agree with the comments that adding some description of potential use cases would help when the PROTO write-up mentions there is no implementation interest. For one thing, security considerations typically would make more sense in the context of use cases. Best regards, --larry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Call for Comment: RFC 4693 experiment
RFC 4693, Section 4 says: This experiment is expected to run for a period of 12 months, starting from the date of the first ION published using this mechanism. At the end of the period, the IESG should issue a call for comments from the community, asking for people to state their agreement to one of the following statements (or a suitable reformulation thereof): According to http://www.ietf.org/IESG/content/ions/ the first ION was published 12-Jan-2007. This means the experiment ended last Saturday, and it's time for the IESG to issue the call for comments. Please tell us what you think about the experiment. Have IONs been valuable? Should we continue to make use of this mechanism? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
I have to agree with Fred here: On Jan 17, 2008, at 2:21 PM, Fred Baker wrote: I would argue that (1) has not been shown. Several IONs have been produced, but I don't see people referring to them. It looks like it is being treated as a lightweight way to publish something a lot like an RFC, and I'm not sure why the proper response to our present situation shouldn't be to figure out what we once had - a lightweight way to publish an RFC. I've been on various IETF mailing lists for a year or two now and I've never seen any reference to these ION documents. Obviously there must have been and I must have missed it... but I've not had other people point me to them, either. For instance, at IETF 70, I agreed to take minutes for one of the sessions and when I asked if there was any preferred format, no one pointed me to this ION: http:// www.ietf.org/IESG/content/ions/ion-agenda-and-minutes.html Have now learned of them by this email exchange, some of the documents look both interesting and useful, but I'd agree with Fred that in order to call the series successful there really need to be more people pointing to them and using them. My 2 cents, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
On 2008-01-18 08:33, Dan York wrote: I have to agree with Fred here: On Jan 17, 2008, at 2:21 PM, Fred Baker wrote: I would argue that (1) has not been shown. Several IONs have been produced, but I don't see people referring to them. It looks like it is being treated as a lightweight way to publish something a lot like an RFC, and I'm not sure why the proper response to our present situation shouldn't be to figure out what we once had - a lightweight way to publish an RFC. I've been on various IETF mailing lists for a year or two now and I've never seen any reference to these ION documents. Obviously there must have been and I must have missed it... but I've not had other people point me to them, either. For instance, at IETF 70, I agreed to take minutes for one of the sessions and when I asked if there was any preferred format, no one pointed me to this ION: http://www.ietf.org/IESG/content/ions/ion-agenda-and-minutes.html Have now learned of them by this email exchange, some of the documents look both interesting and useful, but I'd agree with Fred that in order to call the series successful there really need to be more people pointing to them and using them. That's undoubtedly true - in fact they would need to be the normal way we post procedural stuff to the web site (i.e. things like http://www.ietf.org/ietf/1id-guidelines.html should be IONs). If we are to make IONs permanent, I'd want to see them better integrated in the web site as a whole, rather than being hidden in a corner at http://www.ietf.org/IESG/content/ions.html. Just as a reminder, the idea was to have something *easier and cheaper* than RFCs but more organized than arbitrary web pages. Fred might note that cheaper with his IAOC hat on ;-). Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Harald: This is my reservation as well. The ION process has not been as light-weight as I would like. Frankly, it is easier to generate an IESG Statement than an ION. Russ At 05:27 PM 1/17/2008, Harald Alvestrand wrote: Being the RFC author, I'm naturally very much interested. still, I'll observe that the procedure that seemed most important to me, which was getting new versions out whenever they were needed, has been exercised exactly once: in http://www.ietf.org/IESG/content/ions/dated/, the only document in 2 versions is Brian's procdocs document. So the 3rd option in the evaluation process: 3. We cannot decide yet; the experiment should continue might be an option to seriously consider. (This of course has some disadvantages - for instance, we have discovered that we can't write text into a BCP that says the information about X is to be published as an ION before IONs are permanent. But perfection seems to escape us every time) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Being the RFC author, I'm naturally very much interested. still, I'll observe that the procedure that seemed most important to me, which was getting new versions out whenever they were needed, has been exercised exactly once: in http://www.ietf.org/IESG/content/ions/dated/, the only document in 2 versions is Brian's procdocs document. So the 3rd option in the evaluation process: 3. We cannot decide yet; the experiment should continue might be an option to seriously consider. (This of course has some disadvantages - for instance, we have discovered that we can't write text into a BCP that says the information about X is to be published as an ION before IONs are permanent. But perfection seems to escape us every time) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: houston.rr.com MX fubar?
On Thu, 17 Jan 2008, Mark Andrews wrote: a) when RFC 2821 was written IPv6 existed and RFC 2821 acknowledged its existance. It did DID NOT say synthesize from . RFC 2821 only talks about IPv6 domain literals. The MX resolution algorithm in section 5 is written as if in complete ignorance of IPv6 so it is reasonable to interpret it in the way that RFC 3974 does. If you wanted to rule out MX synthesis from then it should have been written down ten years ago. It's too late now. We 99.9% of the time write down what we should do. We very rarely write down what we shouldn't do. Just because *you* think it was written in complete ignoranance doesn't mean that it was. If you follow what is written down there NOTHING breaks. If you think you know better then things break. They have already been upgraded in this way. Even without fallback-to- , they have to be upgraded to handle IPv6 anyway, because the IPv4 MX lookup algorithm breaks as I described in http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html MX additional section is a optimization. The lack of or A records is NOT a bug. Perhaps you could explain why the problem I described in the URL above isn't actually a problem. It is not as problem. Additional records have ALWAYS been optional. Any MTA that doesn't look for address records if they are missing from the additional section is *broken* and won't work in a pure IPv4 world let alone a mixed IPv4/IPv6 world. The few cases where there have been such MTA's they get fixed / replaced because they fail to deliver email. I've seen reports that a nameserver was broken because it failed to add additional records (usually because they were not in the cache). Once you point out that it is the MTA that is broken that is the last of the complaint. There will always be developers that fail to read the specifications. When the complaint comes that something is broken you bring out the specification and point out the fault. Mark Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER: WEST 4 OR 5, BACKING SOUTHEAST BECOMING CYCLONIC 5 TO 7, PERHAPS GALE 8 LATER. ROUGH. RAIN LATER. MODERATE OR GOOD. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). It absolutely is not true of the BCP series - they are single-stage normative documents, and not a subset of Informational documents. If there's text in RFC 2026 that implies otherwise, I need to update draft-carpenter-rfc2026-changes again. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
On 2008-01-18 13:14, Paul Hoffman wrote: At 12:50 PM +1300 1/18/08, Brian E Carpenter wrote: Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). It absolutely is not true of the BCP series - they are single-stage normative documents, and not a subset of Informational documents. If there's text in RFC 2026 that implies otherwise, I need to update draft-carpenter-rfc2026-changes again. Note that Section 8.1 (which currently doesn't mention BCPs at all, and thus the needed change) talks about Informational documents, not Informational RFCs. That might be too clever of a differentiation. Would you be happier if the list above the text you quoted had seven entries instead of six, with Best current practices (BCP) documents as a new entry in the list? Yes, that would be fine. Personally, I don't feel that RFC 2026 is clear enough on the status of BCPs, and we thus have BCPs whose meaning differs from what 2026 says BCPs are for. I don't think we can change 2026 in a way that won't invalidate some BCPs. It is, however, clear that they are approved like single-stage standards, with a required last-call and rough consensus, which doesn't apply to Informationals. You may want to check for consistency with RFC 4844 through 4846, too. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Updating the Tao of the IETF
Greetings again. In the year or so since the revised Tao of the IETF has come out, a few people have pointed out errors. I have started a new version; see below. We'll probably leave this as an I-D for about a year to catch up with changes in the IETF (IONs maybe?), then submit it for IETF last call. == A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force Author(s) : P. Hoffman Filename: draft-hoffman-tao4677bis-00.txt Pages : 51 Date: 2008-01-17 This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-tao4677bis-00.txt == --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
Paul Hoffman skrev: At 12:50 PM +1300 1/18/08, Brian E Carpenter wrote: Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). It absolutely is not true of the BCP series - they are single-stage normative documents, and not a subset of Informational documents. If there's text in RFC 2026 that implies otherwise, I need to update draft-carpenter-rfc2026-changes again. Note that Section 8.1 (which currently doesn't mention BCPs at all, and thus the needed change) talks about Informational documents, not Informational RFCs. That might be too clever of a differentiation. Would you be happier if the list above the text you quoted had seven entries instead of six, with Best current practices (BCP) documents as a new entry in the list? I would. Personally, I don't feel that RFC 2026 is clear enough on the status of BCPs, and we thus have BCPs whose meaning differs from what 2026 says BCPs are for. I don't think we can change 2026 in a way that won't invalidate some BCPs. Sure we can. A BCP is a document that is approved by the IESG as a BCP. :-) They are definitely not informational documents. (I long ago proposed splitting the series into the two effective subseries it has - process documents and forcefully recommended advice to operators/implementors - but that obvious move is Just Too Much Of A Hassle) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
At 12:50 PM +1300 1/18/08, Brian E Carpenter wrote: Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). It absolutely is not true of the BCP series - they are single-stage normative documents, and not a subset of Informational documents. If there's text in RFC 2026 that implies otherwise, I need to update draft-carpenter-rfc2026-changes again. Note that Section 8.1 (which currently doesn't mention BCPs at all, and thus the needed change) talks about Informational documents, not Informational RFCs. That might be too clever of a differentiation. Would you be happier if the list above the text you quoted had seven entries instead of six, with Best current practices (BCP) documents as a new entry in the list? Personally, I don't feel that RFC 2026 is clear enough on the status of BCPs, and we thus have BCPs whose meaning differs from what 2026 says BCPs are for. I don't think we can change 2026 in a way that won't invalidate some BCPs. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
Harald Alvestrand wrote: [BCP} I long ago proposed splitting the series into the two effective subseries it has - process documents and forcefully recommended advice to operators/implementors - but that obvious move is Just Too Much Of A Hassle ...it could be more straight forward than BCPs listed in the Procdoc ION (or not). Brian mentioned about FYIs: | which I believe the RFC Editor regards as dormant today RFC 4949 is now FYI 36, replacing RFC 2828. Is FYI simply a kind of 'informational favourites' picked by the rfc-editor.org folks ? About the TAO, I consider it as the nice or social version of Procdoc, where Procdoc is the emily postnews or marauder's map of the IETF for those who found that nice doesn't cut it. If the TAO tries to stay up to date with say the forever changing boilerplates of IPR maybe it should be also an ION (like Procdoc). The idea of IONs is to get official snapshots of changing details in the standards process not relevant for the Internet at large (incl. IANA), isn't it ? Or maybe TAO is the IETF user manual and public FAQ, while IONs not limited to Procdoc are the reference manual for folks trying to figure out why user manual and implementation are different. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
At 3:52 AM +0100 1/18/08, Frank Ellermann wrote: Or maybe TAO is the IETF user manual and public FAQ, while IONs not limited to Procdoc are the reference manual for folks trying to figure out why user manual and implementation are different. Something along that line, yes. The Tao really should be an RFC, which means that it will go out of date regularly. Its intended audience is quite different than IETF regulars who would read IONs. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
On 17-Jan-2008, at 18:50, Brian E Carpenter wrote: Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). For what it's worth, there's a document in the dnsop queue which the wg intends to send up the tree for publication as fyi, once past wg last call. So the series might be dormant today, but there's a reasonable chance it might snort in its sleep and roll over in due course. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 84 messages in the last 7 days. script run at: Fri Jan 18 00:53:02 EST 2008 Messages | Bytes| Who +--++--+ 9.52% |8 | 12.71% |66954 | [EMAIL PROTECTED] 10.71% |9 | 8.73% |45975 | [EMAIL PROTECTED] 8.33% |7 | 7.75% |40794 | [EMAIL PROTECTED] 5.95% |5 | 5.30% |27939 | [EMAIL PROTECTED] 5.95% |5 | 4.14% |21807 | [EMAIL PROTECTED] 4.76% |4 | 4.09% |21518 | [EMAIL PROTECTED] 3.57% |3 | 5.09% |26808 | [EMAIL PROTECTED] 2.38% |2 | 4.23% |22264 | [EMAIL PROTECTED] 3.57% |3 | 2.69% |14177 | [EMAIL PROTECTED] 2.38% |2 | 3.84% |20198 | [EMAIL PROTECTED] 2.38% |2 | 3.30% |17366 | [EMAIL PROTECTED] 2.38% |2 | 2.88% |15162 | [EMAIL PROTECTED] 2.38% |2 | 2.69% |14153 | [EMAIL PROTECTED] 1.19% |1 | 3.56% |18736 | [EMAIL PROTECTED] 2.38% |2 | 2.30% |12129 | [EMAIL PROTECTED] 2.38% |2 | 2.10% |11073 | [EMAIL PROTECTED] 2.38% |2 | 1.94% |10219 | [EMAIL PROTECTED] 2.38% |2 | 1.85% | 9724 | [EMAIL PROTECTED] 2.38% |2 | 1.76% | 9271 | [EMAIL PROTECTED] 1.19% |1 | 1.88% | 9900 | [EMAIL PROTECTED] 1.19% |1 | 1.40% | 7356 | [EMAIL PROTECTED] 1.19% |1 | 1.34% | 7034 | [EMAIL PROTECTED] 1.19% |1 | 1.27% | 6699 | [EMAIL PROTECTED] 1.19% |1 | 1.26% | 6649 | [EMAIL PROTECTED] 1.19% |1 | 1.20% | 6320 | [EMAIL PROTECTED] 1.19% |1 | 1.19% | 6281 | [EMAIL PROTECTED] 1.19% |1 | 1.04% | 5497 | [EMAIL PROTECTED] 1.19% |1 | 0.90% | 4715 | [EMAIL PROTECTED] 1.19% |1 | 0.88% | 4642 | [EMAIL PROTECTED] 1.19% |1 | 0.79% | 4160 | [EMAIL PROTECTED] 1.19% |1 | 0.79% | 4160 | [EMAIL PROTECTED] 1.19% |1 | 0.78% | 4126 | [EMAIL PROTECTED] 1.19% |1 | 0.77% | 4054 | [EMAIL PROTECTED] 1.19% |1 | 0.76% | 4014 | [EMAIL PROTECTED] 1.19% |1 | 0.75% | 3975 | [EMAIL PROTECTED] 1.19% |1 | 0.74% | 3908 | [EMAIL PROTECTED] 1.19% |1 | 0.69% | 3609 | [EMAIL PROTECTED] 1.19% |1 | 0.63% | 3299 | [EMAIL PROTECTED] +--++--+ 100.00% | 84 |100.00% | 526665 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Document Action: 'IPFIX Implementation Guidelines' to Informational RFC
The IESG has approved the following document: - 'IPFIX Implementation Guidelines ' draft-ietf-ipfix-implementation-guidelines-08.txt as an Informational RFC This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-08.txt Technical Summary The IP Flow Information eXport (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address template management, transport-specific issues, implementation of exporting and collecting processes and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). Working Group Summary This document records experience gained in three IPFIX interopability events. Some of that early experience gave rise to changes in the IPFIX protocol, later experience came in testing IPFIX over its three transports. Overall, this document provides in-depth discussion about IPFIX. It will be useful to implementors and to others wanting more detail about its implementation. The Working Group has reached consensus on this document. Protocol Quality This document addresses implementation and interoperablity issues based on implementations of the IPFIX protocol and interoperability events. The document was reviewed by the WG chairs, by Dan Romascanu on behalf of the IESG, by David Black on behalf of the Transport Directorate, and by Elwyn Davies on behalf of the Gen-Art team. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA
There are two (2) Internet-Draft cutoff dates for the 71st IETF Meeting in Philadelphia, PA, USA: February 18th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with draft-ietf must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 11th at 9:00 AM ET (14:00 UTC/GMT). February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 10th at 9:00 AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to [EMAIL PROTECTED] If you are submitting a version -00 WG draft that replaces non-WG draft, then you must submit it manually as the current IDST cannot handle replacements. Please be sure to state that one draft replaces another in the cover note that accompanies your submission. Also, please note that the IDST will not accept drafts submitted after their respective cutoff dates. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to [EMAIL PROTECTED] The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 71st IETF Meeting can be found at http://www.ietf.org/meetings/71-cutoff_dates.html. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
