Re: Last Call: draft-laurie-pki-sunlight-05.txt (Certificate Transparency) to Experimental RFC
At 11:33 20-12-2012, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Certificate Transparency' draft-laurie-pki-sunlight-05.txt as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be In Section 1: Certificate Transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates. It seems that CAs are having trust issues. ETSI TS 102 042 audits looks like paperwork instead of assessing what could go wrong [1]. Isn't Certificate Transparency trying to mitigate the problem of CAs issuing fake certificates instead of misissued certificates? In Section 3: Logs MUST NOT impose any conditions on copying data retrieved from the log. I am reading the above as meaning that the data retrieved is in the public domain. Is that correct? The wording could be improved as logs do not have any consciousness. In Section 3.1: In order to enable attribution of each logged certificate to its issuer, the log SHALL publish a list of acceptable root certificates (this list might usefully be the union of root certificates trusted by major browser vendors). Why is this a SHALL instead of a MUST? I suggest a better wording for log in the above as log is defined as a single, ever-growing, append-only Merkle Tree of such certificates. There are other occurrences of log in the draft that should be reviewed. In Section 4: Messages are sent as HTTPS GET or POST requests. Parameters for POSTs and all responses are encoded as JSON objects. I suggest adding a reference for JSON objects. It must map one-to-one to a known public key (how this mapping is distributed is out of scope for this document). This looks like a requirement. A compliant v1 implementation MUST NOT expect this to be 0 (i.e. v1). What happens if the v1 implementation gets a zero? In Section 7.3: Violation of the append-only property is detected by global gossiping, i.e., everyone auditing logs comparing their versions of the latest signed tree heads. In my humble opinion that's a practical approach. Section 7 is about security and privacy considerations. I didn't see any privacy considerations in Section 7. I don't think that it is really needed as the document is about publicly auditable logs. If there is any concern about information disclosure it could be mentioned that Certificate Transparency is for public end-entities. Regards, -sm 1. Confirm that there are automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks in 2011)
Standards-essential patents under RAND licensing
Recent actions by the US Department of Justice, the US Patent Office, the US Federal Trade Commission (which handles antitrust and consumer protection matters), and the US International Trade Commission (which has the power to exclude imports which violate US patents) suggest that US officials are starting to understand the proper way to handle standards-essential patents, that is, patented inventions which are incorporated into standards and the patent owner has promised to license under reasonable and non-discriminatory terms. It seems that in some cases, patent owners have not followed through to issue the required licenses, and then prosecuted other standard-users based on patent infringement. In particular (from the New York Times article linked below): Over the years [...] companies took Motorola at its word and developed products assuming they could routinely license Motorola's patents. But Motorola later refused to license its standard-essential patents and sought court injunctions to stop shipment of rival products. After Google purchased Motorola [...] it continued these same abusive practices. In recent months, the F.T.C. has issued position papers and filed friend-of-the-court briefs, opposing the motions for injunctions using standard patents. The Justice Department and European regulators have echoed the commission's stance. Justice Department and Patent Office Issue Policy Statement on Patents http://bits.blogs.nytimes.com/2013/01/08/justice-department-and-patent-office-issue-policy-statement-on-patents/ On Google, F.T.C. Set Rules of War Over Patents http://www.nytimes.com/2013/01/05/technology/in-google-patent-case-ftc-set-rules-of-engagement-for-battles.html?_r=0 United States Department of Justice and United States Patent Trademark Office Policy Statement on Remedies for Standards-Essential Patents Subject to Voluntary F/RAND Commitments http://www.justice.gov/atr/public/guidelines/290994.pdf Dale
Re: Standards-essential patents under RAND licensing
On 1/10/2013 1:22 PM, Dale R. Worley wrote: Recent actions by the US Department of Justice, the US Patent Office, the US Federal Trade Commission (which handles antitrust and consumer protection matters), and the US International Trade Commission (which has the power to exclude imports which violate US patents) suggest that US officials are starting to understand the proper way to handle standards-essential patents, that is, patented inventions which are incorporated into standards and the patent owner has promised to license under reasonable and non-discriminatory terms. It seems that in some cases, patent owners have not followed through to issue the required licenses, and then prosecuted other standard-users based on patent infringement. In particular (from the New York Times article linked below): Over the years [...] companies took Motorola at its word and developed products assuming they could routinely license Motorola's patents. But Motorola later refused to license its standard-essential patents and sought court injunctions to stop shipment of rival products. After Google purchased Motorola [...] it continued these same abusive practices. In recent months, the F.T.C. has issued position papers and filed friend-of-the-court briefs, opposing the motions for injunctions using standard patents. The Justice Department and European regulators have echoed the commission's stance. Justice Department and Patent Office Issue Policy Statement on Patents http://bits.blogs.nytimes.com/2013/01/08/justice-department-and-patent-office-issue-policy-statement-on-patents/ On Google, F.T.C. Set Rules of War Over Patents http://www.nytimes.com/2013/01/05/technology/in-google-patent-case-ftc-set-rules-of-engagement-for-battles.html?_r=0 United States Department of Justice and United States Patent Trademark Office Policy Statement on Remedies for Standards-Essential Patents Subject to Voluntary F/RAND Commitments http://www.justice.gov/atr/public/guidelines/290994.pdf Dale What do you do where a patent predates any standards use of the IP. I understand the issues of developing IP but what about IP that already existed before the standards processes incorporated it into their work product? Todd -- Regards TSG Ex-Cruce-Leo //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: Standards-essential patents under RAND licensing
tglassey == tglassey tglas...@earthlink.net writes: tglassey What do you do where a patent predates any standards use of the IP. I tglassey understand the issues of developing IP but what about IP that already existed tglassey before the standards processes incorporated it into their work product? I think that it depends upon whether the owner of the patent was involved in producing the standard. If not, and nobody knew of the patent, there is certainly a problem. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
Weekly posting summary for ietf@ietf.org
Total of 166 messages in the last 7 days. script run at: Fri Jan 11 00:53:03 EST 2013 Messages | Bytes| Who +--++--+ 11.45% | 19 | 7.53% | 127480 | abdussalambar...@gmail.com 7.23% | 12 | 7.18% | 121646 | say...@gmail.com 4.22% |7 | 8.90% | 150674 | jasn...@gmail.com 6.02% | 10 | 4.63% |78379 | jeanj...@comcast.net 0.60% |1 | 7.60% | 128690 | nabil.n.bi...@verizon.com 3.01% |5 | 3.17% |53598 | m...@mnot.net 3.01% |5 | 3.06% |51892 | hsan...@isdg.net 3.01% |5 | 2.22% |37592 | dean.wil...@softarmor.com 2.41% |4 | 2.72% |46130 | m...@sap.com 1.81% |3 | 3.04% |51406 | j...@10gen.com 2.41% |4 | 1.71% |29026 | s...@resistor.net 2.41% |4 | 1.38% |23413 | o...@cisco.com 2.41% |4 | 1.35% |22925 | jo...@taugh.com 1.20% |2 | 2.50% |42369 | ted.i...@gmail.com 1.20% |2 | 2.49% |42242 | gregimir...@gmail.com 0.60% |1 | 2.67% |45175 | neil.2.harri...@bt.com 1.81% |3 | 1.44% |24414 | petit...@acm.org 1.81% |3 | 1.40% |23650 | nar...@us.ibm.com 1.81% |3 | 1.37% |23260 | ned+i...@mauve.mrochek.com 1.81% |3 | 1.34% |22738 | huubatw...@gmail.com 1.20% |2 | 1.76% |29738 | m...@mpcm.com 1.81% |3 | 1.06% |17893 | glenz...@gmail.com 1.81% |3 | 1.00% |16855 | wor...@ariadne.com 0.60% |1 | 2.16% |36597 | b...@google.com 1.81% |3 | 0.93% |15686 | swm...@swm.pp.se 0.60% |1 | 1.99% |33745 | gregory.mir...@ericsson.com 1.20% |2 | 1.11% |18750 | eng.mahmoude...@yahoo.com 1.20% |2 | 1.10% |18668 | l...@cisco.com 1.20% |2 | 0.96% |16314 | pbr...@anode.ca 1.20% |2 | 0.88% |14906 | john-i...@jck.com 1.20% |2 | 0.80% |13623 | brian.e.carpen...@gmail.com 1.20% |2 | 0.77% |13020 | stbry...@cisco.com 1.20% |2 | 0.76% |12869 | s...@internet2.edu 1.20% |2 | 0.70% |11872 | rwfra...@acm.org 1.20% |2 | 0.68% |11451 | y...@checkpoint.com 1.20% |2 | 0.66% |11250 | rbar...@bbn.com 1.20% |2 | 0.65% |11078 | m...@sandelman.ca 1.20% |2 | 0.64% |10769 | ra...@psg.com 0.60% |1 | 0.85% |14372 | superu...@gmail.com 0.60% |1 | 0.74% |12562 | l...@pi.nu 0.60% |1 | 0.70% |11785 | alh-i...@tndh.net 0.60% |1 | 0.66% |11201 | thegreat...@gmail.com 0.60% |1 | 0.62% |10452 | presn...@qti.qualcomm.com 0.60% |1 | 0.58% | 9838 | conal.tu...@versi.edu.au 0.60% |1 | 0.57% | 9572 | daedu...@btconnect.com 0.60% |1 | 0.53% | 8965 | p...@frobbit.se 0.60% |1 | 0.51% | 8609 | c...@tzi.org 0.60% |1 | 0.48% | 8127 | d3e...@gmail.com 0.60% |1 | 0.47% | 7950 | sha...@juniper.net 0.60% |1 | 0.45% | 7590 | markus.lantha...@gmx.net 0.60% |1 | 0.44% | 7525 | tglas...@earthlink.net 0.60% |1 | 0.44% | 7519 | d...@cridland.net 0.60% |1 | 0.44% | 7418 | j...@juniper.net 0.60% |1 | 0.43% | 7324 | b...@nostrum.com 0.60% |1 | 0.42% | 7099 | melinda.sh...@gmail.com 0.60% |1 | 0.42% | 7041 | adr...@olddog.co.uk 0.60% |1 | 0.41% | 7007 | to...@isi.edu 0.60% |1 | 0.41% | 6861 | lber...@labn.net 0.60% |1 | 0.37% | 6335 | bcla...@cisco.com 0.60% |1 | 0.37% | 6287 | uyesh...@ifa.hawaii.edu 0.60% |1 | 0.37% | 6267 | bra...@isi.edu 0.60% |1 | 0.37% | 6234 | rdroms.i...@gmail.com 0.60% |1 | 0.34% | 5829 | framefri...@gmail.com 0.60% |1 | 0.34% | 5756 | ch...@ietf.org 0.60% |1 | 0.33% | 5623 | k...@bbn.com 0.60% |1 | 0.31% | 5222 | stpe...@stpeter.im 0.60% |1 | 0.30% | 5117 | he...@pobox.com +--++--+ 100.00% | 166 |100.00% | 1693270 | Total
Document Action: 'Support for RSVP-TE in L3VPNs' to Experimental RFC (draft-kumaki-murai-l3vpn-rsvp-te-09.txt)
The IESG has approved the following document: - 'Support for RSVP-TE in L3VPNs' (draft-kumaki-murai-l3vpn-rsvp-te-09.txt) as Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-kumaki-murai-l3vpn-rsvp-te/ Technical Summary IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS and a single provider edge (PE) node may provide access to multiple customer sites belonging to different VPNs. The VPNs may support a number of customer services including RSVP and RSVP-TE traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs. Working Group Summary The Working Group did not adopt the work, even though prior requirements exist within another working group document (RFC5824). However the working group chars felt the work had merit and good support from its co-authors therefore the document might be progressed as experimental and AD sponsored. Document Quality The authors mentioned that extensions defined in the document have been implemented and tested. Although I do think the document would benefit from a thorough review and I would be willing to do this. The document is Experimental therefore there are no IANA requests. No MIB currently exists to manage or report the status of these new protocol mechanisms. Personnel Daniel King is the Document Shepard. Stewart Bryant is the Responsible Area Director.'
Protocol Action: 'Pseudowire Preferential Forwarding Status Bit' to Proposed Standard (draft-ietf-pwe3-redundancy-bit-09.txt)
The IESG has approved the following document: - 'Pseudowire Preferential Forwarding Status Bit' (draft-ietf-pwe3-redundancy-bit-09.txt) as Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ Technical Summary This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates the PW operational status textual convention defined in RFC 5542. Working Group Summary This document represents the consensus of the working group. Document Quality There are no concerns regarding the document's quality. Personnel Andy Malis is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director.
Last Call: draft-ietf-idr-deprecate-dpa-etal-00.txt (Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID) to Informational RFC
The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID' draft-ietf-idr-deprecate-dpa-etal-00.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-01-24. 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 document requests IANA to deprecate the BGP path attributes DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet Draft and a Historic RFC, respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-ospf-ospfv3-iid-registry-update-00.txt (OSPFv3 Instance ID Registry Update) to Proposed Standard
The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPFv3 Instance ID Registry Update' draft-ietf-ospf-ospfv3-iid-registry-update-00.txt as 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 2013-01-24. 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 document modifies the Unassigned number space in the IANA OSPFv3 Instance ID Address Family Values registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-iid-registry-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-iid-registry-update/ballot/ No IPR declarations have been submitted directly on this I-D.
RFC 6772 on Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
A new Request for Comments is now available in online RFC libraries. RFC 6772 Title: Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information Author: H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson Status: Standards Track Stream: IETF Date: January 2013 Mailbox:schulzri...@cs.columbia.edu, hannes.tschofe...@gmx.net, jorge.cuel...@siemens.com, jmp...@cisco.com, i...@jmorris.org, martin.thom...@gmail.com Pages: 44 Characters: 87801 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-geopriv-policy-27.txt URL:http://www.rfc-editor.org/rfc/rfc6772.txt This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target. Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK] This document is a product of the Geographic Location/Privacy 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-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
RFC 6827 on Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
A new Request for Comments is now available in online RFC libraries. RFC 6827 Title: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols Author: A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed. Status: Standards Track Stream: IETF Date: January 2013 Mailbox:andrew.g.ma...@verizon.com, acee.lin...@ericsson.com, dimitri.papadimitr...@alcatel-lucent.com Pages: 30 Characters: 73279 Obsoletes: RFC5787 Updates:RFC5786 I-D Tag:draft-ietf-ccamp-rfc5787bis-06.txt URL:http://www.rfc-editor.org/rfc/rfc6827.txt The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane 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-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
RFC 6847 on Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)
A new Request for Comments is now available in online RFC libraries. RFC 6847 Title: Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) Author: D. Melman, T. Mizrahi, D. Eastlake 3rd Status: Informational Stream: Independent Date: January 2013 Mailbox:davi...@marvell.com, ta...@marvell.com, d3e...@gmail.com Pages: 13 Characters: 28693 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-mme-trill-fcoe-05.txt URL:http://www.rfc-editor.org/rfc/rfc6847.txt Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. 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
