Naming Things with Hashes
draft-farrell-decade-ni-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-04-17
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-04-06
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-04-02
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-03-13
|
10 | (System) | RFC Editor state changed to EDIT from MISSREF |
2012-08-17
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-08-16
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-08-16
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-08-15
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-08-06
|
10 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-08-06
|
10 | (System) | IANA Action state changed to In Progress |
2012-08-05
|
10 | Barry Leiba | Ballot writeup was changed |
2012-08-04
|
10 | Cindy Morgan | State changed to Approved-announcement to be sent from None |
2012-08-04
|
10 | Cindy Morgan | IESG has approved the document |
2012-08-04
|
10 | Cindy Morgan | Closed "Approve" ballot |
2012-08-04
|
10 | Cindy Morgan | Ballot approval text was generated |
2012-08-03
|
10 | Barry Leiba | Ready to go, no RFC Ed notes needed |
2012-08-03
|
10 | Barry Leiba | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-08-03
|
10 | Sean Turner | [Ballot comment] Thanks for adding the text! |
2012-08-03
|
10 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-08-03
|
10 | Barry Leiba | Ballot writeup was changed |
2012-08-03
|
10 | Stephen Farrell | New version available: draft-farrell-decade-ni-10.txt |
2012-08-03
|
09 | Pete Resnick | [Ballot comment] After a very good conversation with Ted Hardie (which should be written up as an Informational document), I agree that this does *not* … [Ballot comment] After a very good conversation with Ted Hardie (which should be written up as an Informational document), I agree that this does *not* belong as a URN (since this is not a managed namespace, which is the purpose of URNs) and that other URIs are names instead of locators. So, with the changes in the intro which explain better that these are names, I am fine with this document going forward. *Please* undo the changes to section 3 changing "Required" and "Optional" to capitalized RFC2119 keywords. They are inappropriate. And they're inexact: Query Parameter Separator is *required* if any Query Parameter follows. Personally, I'd rather see them entirely dropped; they are already self-evident from the ABNF. 3986 doesn't use 2119 language; this document shouldn't either. |
2012-08-03
|
09 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2012-07-26
|
09 | Francis Dupont | Request for Telechat review by GENART Completed. Reviewer: Francis Dupont. |
2012-07-19
|
09 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2012-07-19
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-07-19
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-07-19
|
09 | Pete Resnick | [Ballot discuss] I do not think this document has a reasonable URI registration and I would like more information from the Expert Reviewer of how … [Ballot discuss] I do not think this document has a reasonable URI registration and I would like more information from the Expert Reviewer of how this passed muster. The current registration template says: Applications/protocols that use this URI scheme name: General applicability. I do not see how that satisfies the requirements of a URI registration. Moreover, I think this is indicative of a deeper problem: I cannot find an example of a URI that works the way ni: URI seems to work. The document provides no resolution mechanism for these URIs. The resolution mechanism seems to be "this will be resolved however your local implementation decides that they are to be resolved." This is not interoperable. And as far as I can tell, this is a big architectural shift from the normal use case of URIs. I think this needs pretty serious discussion. |
2012-07-19
|
09 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2012-07-19
|
09 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-07-19
|
09 | Stewart Bryant | [Ballot comment] Wes makes an interesting point about whether this should be experimental. If ever there were a good case for embedded mp4 in an … [Ballot comment] Wes makes an interesting point about whether this should be experimental. If ever there were a good case for embedded mp4 in an RFC it is the nih example in section 8.3 |
2012-07-19
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-07-18
|
09 | Martin Stiemerling | Ballot comment text updated for Martin Stiemerling |
2012-07-18
|
09 | Martin Stiemerling | [Ballot comment] I have only a question abot the downref ISOIEC7812. Can this be waived or wasn't it called out during the IETF LC? |
2012-07-18
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-07-17
|
09 | Sean Turner | [Ballot discuss] In s2 you point out that sha-256-32 is useful for naming but not so much for security. When values are included in the … [Ballot discuss] In s2 you point out that sha-256-32 is useful for naming but not so much for security. When values are included in the hash algorithm registry should a column be included to indicate whether they are useful for security and naming or just naming? If not in the registry then in the document in which they are defined? |
2012-07-17
|
09 | Sean Turner | [Ballot comment] 1) r/sha-256 with SHA-26 to match 180-3 ;) 2) s3: r/Required/REQUIRED and Optional/OPTIONAL - assuming these are supposed to be 2119 words 3) … [Ballot comment] 1) r/sha-256 with SHA-26 to match 180-3 ;) 2) s3: r/Required/REQUIRED and Optional/OPTIONAL - assuming these are supposed to be 2119 words 3) s4: did you mean to reference 2818 for HTTPS or 2617? 4) s6: Should probably add that Res fields SHOULD be ignore upon receipt too. 5) s7: liked the joke 6) s7: OPTIONALLY isn't a 2119 keyword. 7) s9: Shame we can't reuse https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml but I guess IANA registries are cheap. 8) s9.4: Is the sentence about before approving the request only about deprecating or is that in general? I'd love to give some advice to the initial expert along the lines of if anybody tries to register md2/4/5 then they can only be used for naming? Maybe add references to 6149-6151? 9) s12.1: Any reason you can't point to 180-3? |
2012-07-17
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-07-17
|
09 | Wesley Eddy | [Ballot comment] I don't have any technical problem with this document. I doubt that it needs to go on the standards track though; it smells … [Ballot comment] I don't have any technical problem with this document. I doubt that it needs to go on the standards track though; it smells experimental to me. There are lots of potential uses, but who is using it? There's a note that it's similar to magnet URIs, but no mention of why it's better. Since magnet is in widespread use, this seems important to give the analysis for, otherwise we should just be putting magnet on the standards track. |
2012-07-17
|
09 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-07-17
|
09 | Robert Sparks | [Ballot comment] Consider explicitly calling out that padding (=) is not included when base64url-ing. |
2012-07-17
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-07-16
|
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-07-16
|
09 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-07-15
|
09 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document. Here are a couple of minor thoughts you might consider before publication... --- … [Ballot comment] I have no objection to the publication of this document. Here are a couple of minor thoughts you might consider before publication... --- It would be helpful if the Abstract briefly stated the motivation for this work. --- In Section 2 Truncated hashes MAY be supported if needed. That is a bit confusing! "If needed" implies there could be cases where there is a need - "need" sounds like "MUST". If you stick with "MAY" then you will need to explain what happens when there is a "need" and truncated hashes are not supported. Alternatively, you need to scope when truncated hashes are needed and direct implementations to support truncated hashes (MUST) when they are operating in that environment. --- Section 7 The redefinition of "nih" merits a reference to RFC 5513 |
2012-07-15
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-07-15
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-07-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2012-07-12
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2012-07-09
|
09 | Francis Dupont | Request for Last Call review by GENART Completed. Reviewer: Francis Dupont. |
2012-07-09
|
09 | Stephen Farrell | [Ballot Position Update] New position, Recuse, has been recorded for Stephen Farrell |
2012-07-09
|
09 | Barry Leiba | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-07-09
|
09 | Barry Leiba | Placed on agenda for telechat - 2012-07-19 |
2012-07-09
|
09 | Barry Leiba | Ballot has been issued |
2012-07-09
|
09 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-07-09
|
09 | Barry Leiba | Created "Approve" ballot |
2012-07-09
|
09 | Barry Leiba | Ballot writeup was changed |
2012-07-06
|
09 | Barry Leiba | Ballot writeup was changed |
2012-07-05
|
09 | Stephen Farrell | New version available: draft-farrell-decade-ni-09.txt |
2012-07-02
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-06-25
|
08 | Pearl Liang | IANA has reviewed draft-farrell-decade-ni and has the following comments: IANA has questions about the actions related to IANA in this document. IANA understands that, upon … IANA has reviewed draft-farrell-decade-ni and has the following comments: IANA has questions about the actions related to IANA in this document. IANA understands that, upon approval of this document, there are five actions which IANA must complete. First, this document requests adding two URI schemes to the URI scheme registry located at: http://www.iana.org/assignments/uri-schemes.html The two URI schemes to be added are: ni nih Currently the URI scheme registry is maintained through expert review as defined in RFC 5226. IANA Question -> has the document been reviewed by the URI Scheme registry expert? Second, this document requests adding one Well-Known URI to the Well-Known URI registry located at: http://www.iana.org/assignments/well-known-uris/well-known-uris.xml The Well-Known URI to be added is: ni Currently the Well-Known URI registry is maintained through expert review as defined in RFC 5226. IANA Question -> has the document been reviewed by the Well-Known URL registry expert? Third, IANA is requested to create a new registry. The registry will be called the "ni Hash Algorithm Registry". Future management of the registry will be done via Expert Review as defined in RFC 5226. Each registry entry will have five fields, the suite ID, the hash algorithm name string, the truncation length, the underlying algorithm reference and a status field. There are initial values for this registry as follows: ID Hash name string Value length Reference Status 0 Reserved 1 sha-256 256 bits [SHA-256] current 2 sha-256-128 128 bits [SHA-256] current 3 sha-256-120 120 bits [SHA-256] current 4 sha-256-96 96 bits [SHA-256] current 5 sha-256-64 64 bits [SHA-256] current 6 sha-256-32 32 bits [SHA-256] current 32 Reserved Fourth, IANA is requested to crate a new registry. The new registry will be called "Named Information URI Parameter Definitions". Management of the registry will be done through Expert Review as defined in RFC 5226. The fields in this new registry are the parameter name, a description and a reference. There is an initial registration in this registry, as follows: Parameter Meaning Reference ----------- -------------------------------------------- --------- ct Content Type [ RFC-to-be ] IANA understands that these four actions are the only ones required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2012-06-22
|
08 | Stephen Farrell | New version available: draft-farrell-decade-ni-08.txt |
2012-06-19
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Nicolas Williams |
2012-06-19
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Nicolas Williams |
2012-06-07
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-06-07
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-06-04
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Naming Things with Hashes) to Proposed Standard … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Naming Things with Hashes) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Naming Things with Hashes' 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 ietf@ietf.org mailing lists by 2012-07-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a set of ways to identify a thing using the output from a hash function, specifying URI, URL, binary and human "speakable" formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1773/ http://datatracker.ietf.org/ipr/1775/ |
2012-06-04
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-06-04
|
07 | Amy Vezza | Last call announcement was generated |
2012-06-02
|
07 | Barry Leiba | Last call was requested |
2012-06-02
|
07 | Barry Leiba | Last call announcement was generated |
2012-06-02
|
07 | Barry Leiba | Ballot approval text was generated |
2012-06-02
|
07 | Barry Leiba | State changed to Last Call Requested from AD Evaluation |
2012-06-02
|
07 | Barry Leiba | Ballot writeup was changed |
2012-06-02
|
07 | Barry Leiba | Ballot writeup was generated |
2012-05-31
|
07 | Barry Leiba | State changed to AD Evaluation from Publication Requested::AD Followup |
2012-05-31
|
07 | Barry Leiba | The PROTO writeup: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper … The PROTO writeup: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is targeted at becoming a Proposed Standard, as indicated in the title page header. The document describes 2 new URI schemes and some associated mapping procedures intended for widespread use, thus Proposed is appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a set of ways to identify a thing using the output from a hash function, specifying URI, URL, binary and human "speakable" formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. Working Group Summary This is not a product of a WG and it never tried to become one. However it was discussed in DECADE, CORE, and WEBSEC. The CoAP base protocol will normatively reference this document. Document Quality There is at least one implementation of an earlier draft. It looks like this work might be applicable to multiple protocols (such as CoAP), so I think more implementations will come. It is also partially based on an unregistered magnet URI scheme, so there is desire in the community to implement something like this. Personnel Alexey Melnikov is the document shepherd. Barry Leiba is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd read the whole document, trying to identify issues with clarity, issues that might affect interoperability, etc, in particular invalid use of URI constructs. Some minor issues were reported and corrected. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No particular concerns, as this was already presented and reviewed by participants of several WGs. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document had a good number of review by Applications and Security Area people, so no additional reviews are needed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Use of the authority field in the "ni" URI scheme is unusual (because the scheme is not tied to any access protocol), but doesn't seem to be problematic according to URI reviews. No other concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, each author confirmed that no IPR disclosures need to be filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. There is an IPR disclosure from Xerox, a patent from 1998, filed on the document. The inventor became aware of this document just as it was ready for last call, and filed the disclosure immediately. As this is an individual submission, any discussion of the IPR disclosure will happen during last call. In any case, the patent in question has expired. http://datatracker.ietf.org/ipr/1773/ (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? I think there is solid support for this work. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. idnits 2.12.13 reports no errors, except for complaining about "[required]" and "[optional]" not being references, and they aren't. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document requires URI scheme and .well-known reviews. The latter has been completed, and the designated expert has approved the assignment. The former continues in parallel with the last call. Issues identified earlier were discussed and addressed, but more changes might be needed once the reviews finish. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references point to Standards Track RFCs except for one that points to an ISO document, ISO/IEC 7812-1:2006. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downrefs. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. The IANA Considerations section creates 1 new registry for hash functions (the document explains why a new registry), plus registers 2 new URI schemes and 1 .well-known URI scheme. I believe this is correct and complete as far as the rest of the document is concerned. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Yes. Confirm that any referenced IANA registries have been clearly identified. Yes. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Yes. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document creates a new registry that is used for defining hashed functions (and their truncated variants) for use in binary protocols such as CORE. The ideal candidate should have expertise in Security, with additional experience with low bandwidth/restricted power usage technologies being desirable. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. BAP was used to verify ABNF. |
2012-05-31
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-05-31
|
07 | Stephen Farrell | New version available: draft-farrell-decade-ni-07.txt |
2012-05-31
|
06 | Barry Leiba | State changed to Publication Requested::Revised ID Needed from Publication Requested::Point Raised - writeup needed |
2012-05-08
|
(System) | Posted related IPR disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation | |
2012-05-07
|
06 | Amy Vezza | State Change Notice email list changed to stephen.farrell@cs.tcd.ie, cdannewitz@upb.de, Borje.Ohlman@ericsson.com, kutscher@neclab.eu, philliph@comodo.com, ari.keranen@ericsson.com, draft-farrell-decade-ni@tools.ietf.org, Alexey.Melnikov@isode.com from stephen.farrell@cs.tcd.ie, … State Change Notice email list changed to stephen.farrell@cs.tcd.ie, cdannewitz@upb.de, Borje.Ohlman@ericsson.com, kutscher@neclab.eu, philliph@comodo.com, ari.keranen@ericsson.com, draft-farrell-decade-ni@tools.ietf.org, Alexey.Melnikov@isode.com from stephen.farrell@cs.tcd.ie, cdannewitz@upb.de, Borje.Ohlman@ericsson.com, kutscher@neclab.eu, philliph@comodo.com, ari.keranen@ericsson.com, draft-farrell-decade-ni@tools.ietf.org |
2012-05-07
|
06 | Amy Vezza | Note added 'Alexey Melnikov (Alexey.Melnikov@isode.com) is the document shepherd.' |
2012-05-07
|
(System) | Posted related IPR disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Larry Masinter | |
2012-05-06
|
06 | Barry Leiba | Waiting for shepherd writeup. |
2012-05-06
|
06 | Barry Leiba | State changed to Publication Requested::Point Raised - writeup needed from AD is watching |
2012-05-06
|
06 | Stephen Farrell | New version available: draft-farrell-decade-ni-06.txt |
2012-04-30
|
05 | Stephen Farrell | New version available: draft-farrell-decade-ni-05.txt |
2012-04-27
|
04 | Barry Leiba | Document shepherd is Alexey Melnikov |
2012-04-27
|
04 | Barry Leiba | Stream changed to IETF |
2012-04-27
|
04 | Barry Leiba | Intended Status changed to Proposed Standard |
2012-04-27
|
04 | Barry Leiba | IESG process started in state AD is watching |
2012-04-23
|
04 | Stephen Farrell | New version available: draft-farrell-decade-ni-04.txt |
2012-04-10
|
03 | Stephen Farrell | New version available: draft-farrell-decade-ni-03.txt |
2012-04-05
|
02 | Stephen Farrell | New version available: draft-farrell-decade-ni-02.txt |
2012-03-29
|
01 | Stephen Farrell | New version available: draft-farrell-decade-ni-01.txt |
2011-10-24
|
00 | (System) | New version available: draft-farrell-decade-ni-00.txt |