Re: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hello Stephen, On 2012/06/26 20:26, Stephen Farrell wrote: Hi again Martin, On 06/26/2012 12:11 PM, Martin J. Dürst wrote: So the question is really, what's the use case, and what's just a consequence of that use case. If confirmation of already available resources (e.g. like a fingerprint) is the (main?) use case, and the greater weight on speakability just a design consequence, then it makes sense to have two separate things. Yes, confirmation is the main current use-case for nih as I understand it and have said previously. I sincerely wish you had said this so clearly much, much earlier, or even better that it had been in the draft in cristal clear language. We could have avoided a lot of useless discussion. (Of course the resource might not yet be present, so already available isn't quite right, but that's a nit.) Have we beaten this to death sufficiently now? I hope so;-) If you want to suggest a sentence that says that, feel free. I really don't think it should be my job to explain this. There are enough coauthors on the draft who should be in a much better position than myself to write such text :-(. Anyway, here is a try: - In the abstract, replace and binary and human speakable formats for these names by , a binary form, and a form for confirming the presence (or absence) of resources. - In the introduction, replace and a human-speakable text form that could be used, e.g. for reading out (parts of) the name over a voice connection. with and a form optimized for confirming the presence (or absence) of resources by humans.. - Change the title of Section 7 from Human-speakable Format to Format for Resource Confirmation - Replace the first sentence at the start of Section 7 to say: There is often a need for humans to confirm that a particular resource, e.g. a public key, is already present, or to discover its absence. - Change (speaking the value of an ni URI) to confirm the presence or absence of a resource) - Nuke the second paragraph of section 7 (the one that starts with The justification for using a URI). The stuff it says about IDNs, for example, isn't really appropriate for IETF standardization. - In the example section, change Human-speakable form of a name to Form for resource confirmation (three occurrences). I'd also change the nih: scheme to something like fingerprint:, and allow the insertion of delimiter characters (allowing e.g. nih:3;5326-9057-e12f-e2b7-4ba0-7c89-2560a2;f instead of nih:3;53269057e12fe2b74ba07c892560a2;f because the former should be much easier to manipulate by humans), but I guess I'd again be shot down for proposing something like this at such a late date (I note we are still in IETF Last Call). Regards, Martin.
Re: Last Call: draft-farrell-decade-ni-07.txt (Naming Things with Hashes) to Proposed Standard
Hi Martin, On 07/02/2012 12:07 PM, Martin J. Dürst wrote: Hello Stephen, On 2012/06/26 20:26, Stephen Farrell wrote: Hi again Martin, On 06/26/2012 12:11 PM, Martin J. Dürst wrote: So the question is really, what's the use case, and what's just a consequence of that use case. If confirmation of already available resources (e.g. like a fingerprint) is the (main?) use case, and the greater weight on speakability just a design consequence, then it makes sense to have two separate things. Yes, confirmation is the main current use-case for nih as I understand it and have said previously. I sincerely wish you had said this so clearly much, much earlier, or even better that it had been in the draft in cristal clear language. We could have avoided a lot of useless discussion. I agree this has been harder than it ought have been for some reason. I guess that just happens sometimes. (Of course the resource might not yet be present, so already available isn't quite right, but that's a nit.) Have we beaten this to death sufficiently now? I hope so;-) If you want to suggest a sentence that says that, feel free. I really don't think it should be my job to explain this. There are enough coauthors on the draft who should be in a much better position than myself to write such text :-(. Well, you seemed motivated:-) Anyway, here is a try: - In the abstract, replace and binary and human speakable formats for these names by , a binary form, and a form for confirming the presence (or absence) of resources. - In the introduction, replace and a human-speakable text form that could be used, e.g. for reading out (parts of) the name over a voice connection. with and a form optimized for confirming the presence (or absence) of resources by humans.. - Change the title of Section 7 from Human-speakable Format to Format for Resource Confirmation - Replace the first sentence at the start of Section 7 to say: There is often a need for humans to confirm that a particular resource, e.g. a public key, is already present, or to discover its absence. - Change (speaking the value of an ni URI) to confirm the presence or absence of a resource) - Nuke the second paragraph of section 7 (the one that starts with The justification for using a URI). The stuff it says about IDNs, for example, isn't really appropriate for IETF standardization. - In the example section, change Human-speakable form of a name to Form for resource confirmation (three occurrences). I could live with more-or-less all of that. Will check if coauthors can similarly. I think human-speakable still needs to be mentioned though, since that's why its designed as it is, but I like those changes generally. I'd also change the nih: scheme to something like fingerprint:, and allow the insertion of delimiter characters (allowing e.g. nih:3;5326-9057-e12f-e2b7-4ba0-7c89-2560a2;f instead of nih:3;53269057e12fe2b74ba07c892560a2;f because the former should be much easier to manipulate by humans), Would rather not change the uri scheme name at this point, unless a load of people prefer it, but the idea of optional - delimiters seems useful all right. but I guess I'd again be shot down for proposing something like this at such a late date (I note we are still in IETF Last Call). Just:-) But improvements don't stop at the end of IETF LC and your suggestions above are, I think, improvements. Any other opinions before I go make changes along these lines? Cheers, S. Regards, Martin.
RE: Gen-ART review of draft-ietf-bliss-shared-appearances-11
That works for me, Thanks, --David -Original Message- From: Worley, Dale R (Dale) [mailto:dwor...@avaya.com] Sent: Friday, June 29, 2012 3:18 PM To: alan.b.johns...@gmail.com Cc: Black, David; mohsen.soro...@sylantro.com; ietf@ietf.org; gen- a...@ietf.org; bl...@ietf.org; vvenka...@gmail.com Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11 On Thu, 2012-06-28 at 20:05 -0500, Alan Johnston wrote: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a prerequisite as opposed to the same thing because seizing the line is immediately followed by a dialing request. This requirement is about sending one request that causes both actions to occur. In a PSTN ringdown circuit (a very specialized circuit, used for hotlines), the two operations are the same thing. Besides this statement, is REQ-16 itself not clear? Perhaps I should just remove this statement if it adds confusion rather than clarity to the requirement. IMHO, a good fix is: REQ-16 The mechanism should support a way for a UA to seize a particular appearance number and also send the request at the same time. This is needed when an automatic ringdown feature (a telephone configured to immediately dial a phone number when it goes off hook) is combined with shared appearances - in this case, seizing the line is integrated with dialing. Dale
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
At first I thought that it might be good to leave section 4.1, but now I changed my mind. I think the order of the preference might depend on the running environment: some people prefer secured one, some people prefer DNS... So I'd like to make the order configurable and move section 4.1 to appendix, as a hint for implementation. masahiro On Wed, 27 Jun 2012 15:00:29 -0400, Sam Hartman hartmans-i...@mit.edu said: t == t p daedu...@btconnect.com writes: t Just to make public what I have hinted at privately, I think that steps t in section 4.1 may be somewhat underspecified. t A related issue is that section 4.1 prefers DNS to DHCP for Kerberos t information but the Security Considerations stress the weakness of t DHCP and recommend authenticating DHCP. What if DHCP is secure t and DNS is not? Should DNS still be preferred? Yes probably. DNS has been and will continue to be the dominant way to discover KDCs. I see this as a specialized DHCP option for certain deployments, not something you'll see in the enterprise for desktops or laptops as an example. I mean some people may deploy it, but I suspect that you won't see it in most situations where DNS works well today. So, basically in all cases, including preconfigured DNS servers, I'd expect DNS to be preferred. Note that choosing the right KDC does impact availability--if you have the wrong KDC it won't work. In general though, choosing the wrong KDC does not compromise authentication. It's a bit more complex than that, but KDC location has not generally been considered security sensitive.
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
Hi, On 6/20/2012 5:57 PM, Masataka Ohta wrote: Though the ID states: This document underscores the point that not only is reassembly (and possibly subsequent fragmentation) required for translation, it can be used to avoid issues with IPv4 ID uniqueness. according to RFC2765, which does not need port numbers for address mapping: If the IPv6 packet contains a Fragment header the header fields are set as above with the following exceptions: Identification: Copied from the low-order 16-bits in the Identification field in the Fragment header. Flags: The More Fragments flag is copied from the M flag in the Fragment header. The Don't Fragments flag is set to zero allowing this packet to be fragmented by IPv4 routers. the translated IPv4 packets are not atomic with 16bit IDs. Note that the RFC is referred by NAT646 etc. Then, aren't IPv6 nodes are required to rate limit packets they generate with fragment headers assuming 16bit IDs? Or, are 6 to 4 translators are required to rate limit and drop rate-violating packets to make the stateless translators full of states. I would expect that the translator would be responsible for this, though there is the problem that multiple translators interfere with each other. Regardless, this is outside the scope of the ipv4-id-update doc. Or? Masataka Ohta PS As the RFC specifies ID=0 when DF is set 0, it should also be updated to conform to the robustness principle. That is an error in this RFC, which also is outside the scope of the ipv4-id-update doc. Joe
Protocol Action: 'Definition of the Opus Audio Codec' to Proposed Standard (draft-ietf-codec-opus-16.txt)
The IESG has approved the following document: - 'Definition of the Opus Audio Codec' (draft-ietf-codec-opus-16.txt) as Proposed Standard This document is the product of the Internet Wideband Audio Codec Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ Working Group Summary The chairs believe there is good consensus behind the document, particularly around the technology. There has not been any significant disagreement on any of the technical aspects of the codec. However, the working group has left the detailed specification work to the small author team. There are several vocal participants who continue to express dissatisfaction over the testing and codec validation associated with the work. The WG chairs do not believe that there was consensus to make these changes. This document has been the subject of a number of IPR declarations. See: Microsoft: https://datatracker.ietf.org/ipr/1670/ Skype: https://datatracker.ietf.org/ipr/1602/ Broadcom: https://datatracker.ietf.org/ipr/1526/ Xiph: https://datatracker.ietf.org/ipr/1524/ Qualcomm: https://datatracker.ietf.org/ipr/1520/ Huawei: https://datatracker.ietf.org/ipr/1712/ Huawei: https://datatracker.ietf.org/ipr/1741/ The WG has had an opportunity to review these disclosures in Last Call and has opted to proceed with document publication. Document Quality There is an existing implementation - the reference implementation which is included in the appendix of the document and has been maintained by the authors of the specification. One of the authors developed several independent decoder implementations in order to help validate the specification. There are no known alternative encoder implementations. There are no significant reviewers worth noting beyond the author team. The codec has gone through a great degree of testing that demonstrates its quality. Test results can be found at: http://datatracker.ietf.org/doc/draft-ietf-codec-results/. Personnel Shepherd: Jonathan D. Rosenberg, Ph.D. jdro...@jdrosen.net Responsible AD: Robert Sparks rjspa...@nostrum.com RFC Editor Note: Please replace the instances of rfc in this document with rfc number assigned for this draft. Please work with the draft editors to replace rfc as it appears in the files in the appendix with the rfc number assigned for this draft. Please work with the draft editors to ensure that the following is added (with replaced appropriately) to the README file in the appendix: These files were extracted from RFC. Please see that RFC for additional information.
BCP 179, RFC 6649 on Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
A new Request for Comments is now available in online RFC libraries. BCP 179 RFC 6649 Title: Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos Author: L. Hornquist Astrand, T. Yu Status: Best Current Practice Stream: IETF Date: July 2012 Mailbox:l...@apple.com, t...@mit.edu Pages: 7 Characters: 13498 Obsoletes: RFC1510 Updates:RFC1964, RFC4120, RFC4121, RFC4757 See Also: BCP0179 I-D Tag:draft-ietf-krb-wg-des-die-die-die-04.txt URL:http://www.rfc-editor.org/rfc/rfc6649.txt The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic. This memo documents an Internet Best Current Practice. This document is a product of the Kerberos WG Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 6654 on Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)
A new Request for Comments is now available in online RFC libraries. RFC 6654 Title: Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) Author: T. Tsou, C. Zhou, T. Taylor, Q. Chen Status: Informational Stream: Independent Date: July 2012 Mailbox:tina.tsou.zout...@huawei.com, cathy.z...@huawei.com, tom.taylor.s...@gmail.com, chenqi.0...@gmail.com Pages: 8 Characters: 16949 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-tsou-softwire-gwinit-6rd-06.txt URL:http://www.rfc-editor.org/rfc/rfc6654.txt This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed Gateway-initiated 6rd (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. 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
