Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
On Nov 29, 2011, at 5:51 PM, The IESG wrote: The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' draft-ietf-sidr-rpki-rtr-19.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 2011-12-13. 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. Support. I have (carefully) read and reviewed this document and support publication…. W Abstract In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' draft-ietf-sidr-rpki-rtr-19.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 at ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I am familiar with this document and support its advancement. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-6lowpan-nd-18.txt (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard
I support to move this document to IESG. I'm sad that the TID issue was not resolved, which means that there will be a problem for interop with the backbone router and RPL. Cheers, Pascal -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: vendredi 16 décembre 2011 22:02 To: IETF-Announce Cc: 6low...@lists.ietf.org Subject: Last Call: draft-ietf-6lowpan-nd-18.txt (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard The IESG has received a request from the IPv6 over Low power WPAN WG (6lowpan) to consider the following document: - 'Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)' draft-ietf-6lowpan-nd-18.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 2012-01-04. 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. Abstract The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IAOC Member Selection Announcement
The IESG is responsible for selecting one IETF Administrative Oversight Committee (IAOC) member for a two-year term starting in March 2012. The selection was made in accordance with BCP 101 and BCP 113. A call for nominations was issued on 2011-11-13. The IESG had four willing nominees, and these names were announced. I am pleased to say that we heard from more people in this process than we did two years ago. After obtaining written input from all nominees, the IESG held a lengthy discussion. The IESG decided to appoint Ole J. Jacobsen for another term on the IAOC. The IESG thanks all of the nominees for their willingness to serve the IETF community. The nominees that were not selected is strongly encouraged to get involved with the subcommittees of the IAOC and put their names forward again in the future. On behalf of the IESG, Russ Housley IESG Chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER
I thought that this would be of wide interest. Regards Marshall -- Forwarded message -- From: Richard Shockey rich...@shockey.us Date: Mon, Dec 19, 2011 at 12:45 PM Subject: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER To: dispa...@ietf.org FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER (Washington, D.C.) – FCC Chairman Julius Genachowski announced today the appointment of Henning Schulzrinne as Chief Technology Officer. FCC Chairman Genachowski said, “I’m delighted that Henning will be joining us. The communications technology revolution is key to our economy and broad opportunity. With the appointment of Henning – a world-class technologist – we extend our commitment to technology excellence at the FCC and to strong engagement with outside technology experts.” As Chief Technology Officer, Schulzrinne will guide the FCC’s work on technology and engineering issues, together with the FCC’s Office of Engineering and Technology. He will advise on matters across the agency to ensure that FCC policies are driving technological innovation, including serving as a resource to FCC Commissioners. He will also help the FCC engage with technology experts outside the agency and promote technical excellence among agency staff. He will be based in the FCC’s Office of Strategic Planning and Policy Analysis. Schulzrinne is Julian Clarence Levi Professor of Mathematical Methods and Computer Science and Professor of Engineering at The Fu Foundation School of Engineering at Columbia University. He has been an Engineering Fellow at the FCC since 2010. He has published more than 250 journal and conference papers, and more than 70 Internet Requests for Comment (RFCs). He is widely known for the development of key protocols that enable voice-over-IP (VoIP) and other multimedia applications that are now Internet standards, including the Session Initiation Protocol (SIP). His research interests include Internet multimedia systems, applied network engineering, wireless networks, security, quality of service, and performance evaluation. Schulzrinne received his undergraduate degree in economics and electrical engineering from the Darmstadt University of Technology, Germany, his MSEE degree as a Fulbright scholar from the University of Cincinnati, Ohio and his Ph.D. from the University of Massachusetts in Amherst, Massachusetts. He was a member of technical staff at ATT Bell Laboratories, Murray Hill and an associate department head at GMD-Fokus (Berlin), before joining the Computer Science and Electrical Engineering departments at Columbia University, New York. He is an IEEE Fellow and a former member of the Internet Architecture Board (IAB). Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org ___ dispatch mailing list dispa...@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC Member Selection Announcement
At 09:36 19-12-2011, IETF Chair wrote: The IESG thanks all of the nominees for their willingness to serve the IETF community. The nominees that were not selected is strongly encouraged to get involved with the subcommittees of the IAOC and I suggest adding information about the subcommittees of the IAOC on the IAOC website if the aim is to strongly encourage the nominees and future nominees to get involved. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FCC Names Henning Schulzrinne Chief Technology Officer
http://www.fcc.gov/document/fcc-names-henning-schulzrinne-chief-technology-officer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: FCC Names Henning Schulzrinne Chief Technology Officer
It's a great appointment and the IETF community should rightfully be thrilled and excited. I'm a cross posting a note I made to the RAI DISPATCH List. There are interesting things going on with core Layer 7 services and itsnot US centric. Its is the beginning of the transition of the entire real time communications service to IP networks. And yours truly was the opening act at the Workshop. Henning is absolutely right here. If there was ever a time for the RAI community to reach out the policy folks its now. BTW if you really want to understand what is going on here you can add this to your holiday reading list. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1122/FCC-11-1 61A1.pdf War and Peace without the plot. If it seems overwhelming, it is but regulators have to deal with the law as it is, not as they would prefer it to be. Though some of these issues are US specific I would suspect that other national jurisdictions will start to take up these issues in the upcoming months and years. There are very relevant technical issues our community might have to deal with or certainly clarify. The above order specifically calls out non modification of the SIP headers by forwarding elements as it might relate to billing data such as Calling Party Number or SS7 Charge number. -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, December 19, 2011 2:06 PM To: Paul Kyzivat Cc: dispa...@ietf.org Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER VoIP and related issues will play a major role in the FCC's work in the next year or two. For example, the FCC Technical Advisory Committee (TAC) will be looking at the PSTN transition; a video of a recent workshop can be found at http://www.fcc.gov/events/public-switched-telephone-network-transition-0 The Commission needs input from technically-oriented folks. Thus, don't hesitate to contact me if you or your organization wants to stop by at the Commission, or you have information you want to share. (FCC staff meets with both individuals and groups regularly, both within the rule making process and outside. No campaign donation or JD degree required.) For what it's worth, I've been tasked with outreach to standardization organizations as one of my responsibilities. Henning -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Fred Baker Sent: Monday, December 19, 2011 5:07 PM To: IETF Discussion Subject: FCC Names Henning Schulzrinne Chief Technology Officer http://www.fcc.gov/document/fcc-names-henning-schulzrinne-chief-technology-o fficer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-softwire-gateway-init-ds-lite-05.txt (Gateway Initiated Dual-Stack Lite Deployment) to Proposed Standard
The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'Gateway Initiated Dual-Stack Lite Deployment' draft-ietf-softwire-gateway-init-ds-lite-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-01-04. 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. Abstract Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1411/ http://datatracker.ietf.org/ipr/1630/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6453 on A URN Namespace for the Open Grid Forum (OGF)
A new Request for Comments is now available in online RFC libraries. RFC 6453 Title: A URN Namespace for the Open Grid Forum (OGF) Author: F. Dijkstra, R. Hughes-Jones Status: Informational Stream: IETF Date: December 2011 Mailbox:freek.dijks...@sara.nl, richard.hughes-jo...@dante.net Pages: 9 Characters: 16678 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-dijkstra-urn-ogf-06.txt URL:http://www.rfc-editor.org/rfc/rfc6453.txt This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. This document is not an Internet Standards Track specification; it is published for informational purposes. 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6466 on IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)
A new Request for Comments is now available in online RFC libraries. RFC 6466 Title: IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) Author: G. Salgueiro Status: Standards Track Stream: IETF Date: December 2011 Mailbox:gsalg...@cisco.com Pages: 6 Characters: 11660 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-salgueiro-mmusic-image-iana-registration-09.txt URL:http://www.rfc-editor.org/rfc/rfc6466.txt This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK] 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6467 on Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
A new Request for Comments is now available in online RFC libraries. RFC 6467 Title: Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) Author: T. Kivinen Status: Informational Stream: IETF Date: December 2011 Mailbox:kivi...@iki.fi Pages: 10 Characters: 21987 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-kivinen-ipsecme-secure-password-framework-03.txt URL:http://www.rfc-editor.org/rfc/rfc6467.txt This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods. 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-vpn-option-14.txt (Virtual Subnet Selection Options for DHCPv4 and DHCPv6) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6' draft-ietf-dhc-vpn-option-14.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 2012-01-04. 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. Abstract This memo defines a Virtual Subnet Selection (VSS) option for each of DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay- agent-information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. This memo updates RFC 3046 [RFC3046] regarding details relating to copying of sub-options (see Section 8). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1245/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IAOC Member Selection Announcement
The IESG is responsible for selecting one IETF Administrative Oversight Committee (IAOC) member for a two-year term starting in March 2012. The selection was made in accordance with BCP 101 and BCP 113. A call for nominations was issued on 2011-11-13. The IESG had four willing nominees, and these names were announced. I am pleased to say that we heard from more people in this process than we did two years ago. After obtaining written input from all nominees, the IESG held a lengthy discussion. The IESG decided to appoint Ole J. Jacobsen for another term on the IAOC. The IESG thanks all of the nominees for their willingness to serve the IETF community. The nominees that were not selected is strongly encouraged to get involved with the subcommittees of the IAOC and put their names forward again in the future. On behalf of the IESG, Russ Housley IESG Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RADIUS Extensions for Dual-Stack Lite' to Proposed Standard (draft-ietf-softwire-dslite-radius-ext-07.txt)
The IESG has approved the following document: - 'RADIUS Extensions for Dual-Stack Lite' (draft-ietf-softwire-dslite-radius-ext-07.txt) as a Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-radius-ext/ Technical Summary This document specifies a RADIUS attribute, DS-Lite-Tunnel-Name, that carries an FQDN identifying a DS-Lite AFTR. The DS-Lite-Tunnel-Name attribute is to be used between DHCPv6 server and AAA server. The document also describe the use of the DS-Lite-Tunnel-Name attribute in combination with DHCPv6 and with PPP sessions. Working Group Summary This document was carefully reviewed by the working group and discussed in depth. There were some disagreement over small details, which were addressed in the most recent revision of the document. Working group consensus is to accept the resolution of those details and overall WG consensus is strong in support of publication this document. Document Quality We haven't seen any implementations yet, but there is a vendor working on this. Personnel Yong Cui cuiy...@tsinghua.edu.cn is the document shepherd. Ralph Droms rdroms.i...@gmail.com is the responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
REVISED Last Call: draft-ietf-dhc-vpn-option-14.txt (Virtual Subnet Selection Options for DHCPv4 and DHCPv6) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Virtual Subnet Selection Options for DHCPv4 and DHCPv6' draft-ietf-dhc-vpn-option-14.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Note that this document has been extensively revised based on previous IESG review, and this is a second IETF Last Call on this document. Please send substantive comments to the i...@ietf.org mailing lists by 2012-01-04. 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. Abstract This memo defines a Virtual Subnet Selection (VSS) option for each of DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay- agent-information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. This memo updates RFC 3046 [RFC3046] regarding details relating to copying of sub-options (see Section 8). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-vpn-option/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1245/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Multicast DNS' to Proposed Standard (draft-cheshire-dnsext-multicastdns-15.txt)
The IESG has approved the following document: - 'Multicast DNS' (draft-cheshire-dnsext-multicastdns-15.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/ Technical Summary Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. Working Group Summary This document is AD-sponsored. Document Quality An earlier revision of this document was reviewed by the IETF and the IESG for publication as Informational. The current revision has been updated based on feedback from the earlier reviews. Ralph Droms reviewed the current revision. mDNS is widely implemented. Personnel Ralph Droms (rdr...@cisco.com) is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Results of IETF-conflict review for draft-mckenzie-arpanet-host-host-protocol-01.txt
The IESG has completed a review of draft-mckenzie-arpanet-host-host-protocol consistent with RFC5742. This review is applied to all non-IETF streams. The IESG has no problem with the publication of 'Host/Host Protocol for the ARPA Network' draft-mckenzie-arpanet-host-host-protocol-01.txt as a Historic. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-mckenzie-arpanet-host-host-protocol/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-mckenzie-arpanet-host-host-protocol/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary IESG Note The IESG has concluded that there is no conflict between this document and IETF work. Further, no IESG Note is requested. COMMENTS FOR ISE I strongly encourage the RFC Editor to work with the authors to replace this URL: http://alexmckenzie.weebly.com/hosthost-protocol-for-the-arpa-network.html with a PDF version of the document that contains the introduction that appears in the Internet-Draft followed by the scanned Document Number 1. In this way, the figures, italic text, and bold text can be preserved in the RFC series itself. Further, the ASCII version of the RFC can replace this reference will a pointer to the PDF version of the RFC. Section 2 says: ... TCP is usually referred to as a layer 3 protocol. This is not correct. TCP is usually considered the Transport Layer, which is layer 4. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
