Re[2]: Gen-art review of draft-shimaoka-multidomain-pki-11.txt
Elwyn, Now we released -12 as the result of reflecting your comments. See comments in-line, Thanks, -- Masaki SHIMAOKA [EMAIL PROTECTED] SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4122) On Tue, 1 Jan 2008 11:11:40 +0900 島岡 政基 [EMAIL PROTECTED] wrote: Hi Elwyn, Many thanks for your detailed reviews as Gen-ART. I am going to check your comments deeply next week and update the I-D. Thank you, -- Shima -Original Message- From: Elwyn Davies [mailto:[EMAIL PROTECTED] Sent: 2008/01/01 (火) 0:41 To: General Area Review Team Cc: Mary Barnes; 島岡 政基; [EMAIL PROTECTED]; [EMAIL PROTECTED]; IETF Discussion; Russ Housely Subject: Gen-art review of draft-shimaoka-multidomain-pki-11.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. Document: draft-shimaoka-multidomain-pki-11.txt Reviewer: Elwyn Davies Review Date: 28 December 2007 IETF LC End Date: 1 January 2008 IESG Telechat date: (if known) - Summary: In general this is a well written and, as far as I can see, comprehensive document. I have one major problem with it: it far exceeds the scope advertised in the Introduction. It is very definitely not just about terminology. It certainly gives definitions for names in a taxonomy of PKI Domains but it also defines the requirements and relationships of the components in the various models. At the very least it should advertise itself as a framework or architecture. Given the degree of detail and the (indirect) specification of bits on the wire, I would classify it as a standard. Whether it is a standard rather than a framework depends to some extent on what else you could or would need to specify a fully working system. Personally, not being an expert, the specification seems pretty complete. Not much would need to be changed IMO to make it good as a standard (just saying what it is and removing what appear to be unnecessary weasel words from the security section). ! Th! is seems to complement PKIX work and has had input for PKIX in the past. Aside from this there are a few minor issues and some editorial nits noted below. Comments: Abstract/s1.1: The objective of this document is to establish a standard terminology that can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other. I think that the document goes way beyond the stated aim of establishing terminology. I have no problem with what it does, but there should be honesty in advertising. At the very least this could be described as a framework document or maybe an architecture, but the degree of detailed requirements for the various different models which in many cases (indirectly) specifies the bits on the wire means that it would be quite possible to see this as a standard for PKI Domains. Not being an expert in this area, I am not sure what else a 'standard' might specify if it was built using this document as a 'framework': my immediate reaction is that there isn't much else to specify.. so is it really a standard? Or are we shying away from trying to make standards in this arena (the idea of creating standard terminology argues against this)? We revised the objective of the document as the following: Abstract: The objective of this document is to establish a terminology framework and to suggest the operational requirements of PKI domain for interoperability of multi-domain Public Key Infrastructure, ... s1.1: The objective of this document is to establish a terminology framework and to provide the operational requirements, which can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other. s6: Related to the previous point, stating Because this RFC defines terminology and not protocols or technology for implementing the terminology, technology-specific security considerations are not applicable. seems disingenuous. Actually quite a lot of specific technology is mandated. On the other hand, the actual security discussion seems to cover the situation quite well, and I think the disclaimer is unnecessary. Whether the document is recast as a framework or becomes a standard, I don't think much, if any, extra would be needed in the security section. deleted. s2.2, para 2: The second sentence appears to be incomplete: A CA which issued a public-key certificate to another (subordinate) CA. deleted. s3.2 and many other places: inadvertent trust - This term grates on my tongue. I am unsure if this is just that using it 'intransitively' in this way is not good English.
Re[2]: Last Call: draft-shimaoka-multidomain-pki-11.txt
Martin, Now we released -12 based on my previous response to you as the result of reflecting your comments. Additionally, - Introductionally text: I basically agree with Stephen. To update the text, I'm talking with co-authors. Revised the first sentence in the Abstract as the following: The objective of this document is to establish a terminology framework and to suggest the operational requirements of PKI domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. Thanks, -- Masaki SHIMAOKA [EMAIL PROTECTED] SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4122) On Thu, 06 Dec 2007 12:57:42 +0900 Masaki SHIMAOKA [EMAIL PROTECTED] wrote: Stephen and Martin, # sorry for twice posting. Thanks for your quick comments. - Trust Anchor definition: I agree your comments. I think the term trust anchor CA is more appropriate. - MUST NOT and MUST for trust anchor: I understand IETF statement, so I am going to replace MUST to strongly RECOMMEND regarding the trust anchor. - Introductionally text: I basically agree with Stephen. To update the text, I'm talking with co-authors. For publishing this document as informational RFC, is there any word I must consider elsewhere? Thanks, -- Shima -- Masaki SHIMAOKA [EMAIL PROTECTED] SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4122) On Tue, 4 Dec 2007 23:49:05 -0500 Stephen Kent [EMAIL PROTECTED] wrote: At 7:34 PM +0100 12/4/07, Martin Rex wrote: The document - 'Memorandum for multi-domain Public Key Infrastructure Interoperability' draft-shimaoka-multidomain-pki-11.txt as an Informational RFC creates the impression that trust anchors must always be self-signed CA certificates. What is a trust anchor MUST remain completely up to local policy (which might be a client-local policy in some scenarios), there should be NO restriction whatsoever what can be configured as a trust anchor. The idea of a trust anchor is that we trust the (public) key of the trust anchor, that the PKI implementation may perform a reduced (certificate) path validation only up to the trust anchor. The management of trust anchors is also completely a local (policy) issue, i.e. what keys are considered trust anchors, how they are distributed, managed and updated. I am violently opposed to the documents requirements and restrictions what may an what may not be a trust anchor certificate. Document published by the IETF (even if just Informational) should neither make unconditional restrictions (MUST NOT) nor unconditional requirements (MUST) for the selection of trust anchors. Instead, Protocols and implementations SHOULD support the use of arbitrary trust anchors as desired by local policy. -Martin Martin, You are right that a TA need not be a self-signed cert, although this is the most common format for TA representation. Your statement about how a TA allows a relying party to perform a reduced (certificate) path validation is confusing. I believe that we always assume that cert path validation terminates at a TA for the RP. We both agree that the selection and management of TAs is purely a local matter for each RP. In general I do not worry too much about what an informational RFC that is not the product of a working group says. However, looking at the abstract for this document I do see some words that cause me some concern, i.e., The objective of this document is to establish a standard terminology for interoperability of multi-domain Public Key Infrastructure (PKI), where each PKI Domain is operated under a distinct policy ... We ought not make such strong statements in a document of this sort. I agree that the authors need to soften the wording to indicate that this document defines terminology to describe multi-domain PKI models, as an aid to discussing issues in these contexts. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: RFC 5241 on Naming Rights in IETF Protocols
Can this be extended to WG naming rights as well. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 12:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RFC 5241 on Naming Rights in IETF Protocols A new Request for Comments is now available in online RFC libraries. RFC 5241 Title: Naming Rights in IETF Protocols Author: A. Falk, S. Bradner Status: Informational Date: 1 April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 25304 Updates/Obsoletes/SeeAlso: None URL:http://www.rfc-editor.org/rfc/rfc5241.txt This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FW: RFC 5241 on Naming Rights in IETF Protocols
Richard Shockey wrote: Can this be extended to WG naming rights as well. :-) Hmm, those cost more. But the really expensive items are Areas. ;) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5241 on Naming Rights in IETF Protocols
Just publish an RFC that contains the names of popular celebrities, and use Google ads. The IETF site should do well in link-rankings... A number of non-IETF sites already make money off RFCs courtesy of Google ads. On Apr 1, 2008, at 2:53 PM, Richard Shockey wrote: Can this be extended to WG naming rights as well. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 12:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RFC 5241 on Naming Rights in IETF Protocols A new Request for Comments is now available in online RFC libraries. RFC 5241 Title: Naming Rights in IETF Protocols Author: A. Falk, S. Bradner Status: Informational Date: 1 April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 25304 Updates/Obsoletes/SeeAlso: None URL:http://www.rfc-editor.org/rfc/rfc5241.txt This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ 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: Possible RFC 3683 PR-action
On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema [EMAIL PROTECTED] wrote a message of 12 lines which said: Does the IETF have a policy regarding misrepresented identities? For instance, I claim that the person mentioned in section 10 of RFC 5242 may be actually the same person who is the target of a PR-action, with just a small modification of his name. If this is true, he cannot post on IETF mailing lists and should be banned of Acknowledgments sections as well! ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Problems with ftp.ietf.org?
At 13:31 01-04-2008, Robert Moskowitz wrote: Can't connect to it via ftp. There seems to be a problem with the FTP service on ftp.ietf.org. The problem has been reported to the Secretariat. Regards, -sm ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
Stephane Bortzmeyer wrote: If this is true, he cannot post on IETF mailing lists and should be banned of Acknowledgments sections as well! The IESG Note in RFC 5242 is perfectly clear, with a length of 11 lines it reaches a third of the IESG Note size used in RFCs 4405, 4407, 4407, and 4408. For a shorter IESG Note I'd support an appeal or recall petition, but 11 lines ought to be good enough for everybody. It would be completely unjustfied to count empty lines, and then claim that 12 of 38 is less than a third, even if the 38 lines don't include a page header added by the RFC-editor without consent of the IESG, let alone any IETF Last Call. Frank ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
On 2008-04-02 09:41, Stephane Bortzmeyer wrote: On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema [EMAIL PROTECTED] wrote a message of 12 lines which said: Does the IETF have a policy regarding misrepresented identities? For instance, I claim that the person mentioned in section 10 of RFC 5242 may be actually the same person who is the target of a PR-action, with just a small modification of his name. If this is true, he cannot post on IETF mailing lists and should be banned of Acknowledgments sections as well! Do you believe that 'f' is isomorfic with 'ph'? Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
Stephane Bortzmeyer skrev: On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema [EMAIL PROTECTED] wrote a message of 12 lines which said: Does the IETF have a policy regarding misrepresented identities? For instance, I claim that the person mentioned in section 10 of RFC 5242 may be actually the same person who is the target of a PR-action, with just a small modification of his name. If this is true, he cannot post on IETF mailing lists and should be banned of Acknowledgments sections as well! No, this needs an RFC 3683 update - the RFC mentions acknowledgements only in the title of its acknowledgements section; steps need to be taken at once to rectify this severely overlooked issue. We can't have people mounting denial of service attacks against the IETF by being mentioned in acknowledgements section - that would be Just Too Impolite! Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Review of draft-ietf-pim-bsr-mib-04.txt
Hi, Bharat, What follows is my suggestion only, so please filter it appropriately... 5. Definitions pimBsrCandidateRPStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION The status of this row, by which new entries may be created, or old entries deleted from this table. Clarity: I'm sorry, but I don't get status by which new entries may be created/old entries deleted - is that actually how it works? I would have thought the status was the side effect of creation/deletion, not how creation/deletion actually happens. s/by which new/used to identify when new/? but I'm guessing here. The 'RowStatus' object is used for two purposes. One is to provide the current status of a Row and another is to create/delete a specific Row. So this statement looks ok. Your explanation is very helpful. It would be great if your explanation ended up in the description itself. Perhaps something like DESCRIPTION The status of this Row, used for two purposes - to create or delete a specific Row from this table, and to provide the status of a Row in this table If you're using a technique that's commonly used in MIB-land, fine, but manipulating an object by changing its status violates the principle of least astonishment, at least for this reader :-) Either way - thanks for the quick response. Gen-ART reviewers love quick responses because we can remember why we wrote what we wrote... Spencer ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
--On Wednesday, April 02, 2008 12:09 AM +0200 Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: For instance, I claim that the person mentioned in section 10 of RFC 5242 may be actually the same person who is the target of a PR-action, with just a small modification of his name. If this is true, he cannot post on IETF mailing lists and should be banned of Acknowledgments sections as well! No, this needs an RFC 3683 update - the RFC mentions acknowledgements only in the title of its acknowledgements section; steps need to be taken at once to rectify this severely overlooked issue. We can't have people mounting denial of service attacks against the IETF by being mentioned in acknowledgements section - that would be Just Too Impolite! Of course, this would contradict the requirements of various other documents that the acknowledgements contain a full description of everyone who contributed substantively. So those documents would all need to be updated to make appropriate exceptions. john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Action: Conclusion of Middlebox Communication (midcom)
The Middlebox Communication working group (midcom) in the Transport Area has concluded. The IESG contact persons are Magnus Westerlund and Lars Eggert. The mailing list will remain active. The MIDCOM WG has completed its chartered tasks, which primarily regards control of middlebox such as firewalls and NAT. The WG has produced documents that: - Describe the architecture and framework (RFC 3303) - Evaluate existing IETF protocols for usage for middlebox control (RFC 4097) - Specify a middlebox communication protocol (RFC 5189 and RFC 5190) This concludes the WG with a big thanks to the WG chair and the authors and WG participants. The mailing list will be kept open for some additional time. Magnus Westerlund ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-hautakorpi-sipping-uri-list-handling-refused (The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) ' draft-hautakorpi-sipping-uri-list-handling-refused-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 [EMAIL PROTECTED] mailing lists by 2008-04-29. 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-hautakorpi-sipping-uri-list-handling-refused-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14716rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services' to Proposed Standard
The IESG has approved the following document: - 'A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services ' draft-ietf-enum-calendar-service-04.txt as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-calendar-service-04.txt Technical Summary This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. Working Group Summary The document is one of a number of enumservice registrations in the series. The application suggests a mapping of phone number to find a calendaring service. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Richard Shockey is the PROTO Shepherd. GEN-ART review was provided by David Black. Note to RFC Editor In Section 2: OLD: Security considerations: See section 3. NEW: Security considerations: See section 4. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5241 on Naming Rights in IETF Protocols
A new Request for Comments is now available in online RFC libraries. RFC 5241 Title: Naming Rights in IETF Protocols Author: A. Falk, S. Bradner Status: Informational Date: 1 April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 25304 Updates/Obsoletes/SeeAlso: None URL:http://www.rfc-editor.org/rfc/rfc5241.txt This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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
RFC 5242 on A Generalized Unified Character Code: Western European and CJK Sections
A new Request for Comments is now available in online RFC libraries. RFC 5242 Title: A Generalized Unified Character Code: Western European and CJK Sections Author: J. Klensin, H. Alvestrand Status: Informational Date: 1 April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 31314 Updates/Obsoletes/SeeAlso: None URL:http://www.rfc-editor.org/rfc/rfc5242.txt Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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
Last Call: draft-ietf-iptel-tel-reg (The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry) to Proposed Standard
The IESG has received a request from the IP Telephony WG (iptel) to consider the following document: - 'The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry ' draft-ietf-iptel-tel-reg-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 [EMAIL PROTECTED] mailing lists by 2008-04-15. 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-iptel-tel-reg-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14101rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
