Using the Host Identity Protocol with Legacy Applications
RFC 5338
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
04 | (System) | Notify list changed from hip-chairs@ietf.org to (None) |
2012-08-22 |
04 | (System) | post-migration administrative database adjustment to the Abstain position for Lisa Dusseault |
2012-08-22 |
04 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2008-09-25 |
04 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2008-09-25 |
04 | Cindy Morgan | [Note]: 'RFC 5338' added by Cindy Morgan |
2008-09-18 |
04 | (System) | RFC published |
2008-07-26 |
04 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2008-07-25 |
04 | (System) | IANA Action state changed to No IC from In Progress |
2008-07-25 |
04 | (System) | IANA Action state changed to In Progress |
2008-07-25 |
04 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-07-25 |
04 | Cindy Morgan | IESG has approved the document |
2008-07-25 |
04 | Cindy Morgan | Closed "Approve" ballot |
2008-07-25 |
04 | Mark Townsley | Note field has been cleared by Mark Townsley |
2008-07-25 |
04 | Mark Townsley | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Mark Townsley |
2008-07-25 |
04 | Mark Townsley | [Note]: 'Approved.' added by Mark Townsley |
2008-07-13 |
04 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Abstain from Discuss by Lisa Dusseault |
2008-07-07 |
04 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2008-07-07 |
04 | (System) | New version available: draft-ietf-hip-applications-04.txt |
2008-07-06 |
04 | Russ Housley | [Ballot discuss] The Gen-ART Review from David Black said: Right track; open issues. The original Gen-ART review is here: http://www.alvestrand.no/ietf/gen/reviews/ … [Ballot discuss] The Gen-ART Review from David Black said: Right track; open issues. The original Gen-ART review is here: http://www.alvestrand.no/ietf/gen/reviews/ draft-ietf-hip-applications-01-black.txt = = = = = = = = = The last remaining update, which is expected in section 3.2 of -04, is: > other consumers of these log files may become confused to find LSIs > or HITs instead of IP addresses. Therefore, it is recommended that > the HIP software logs the HITs, LSIs (if applicable), corresponding > IP addresses, and FQDN-related information so that administrators > can correlate other logs with HIP identifiers. |
2008-06-28 |
03 | (System) | New version available: draft-ietf-hip-applications-03.txt |
2008-06-10 |
04 | Mark Townsley | DEAD doc warning email -------- Original Message -------- Subject: draft-ietf-hip-applications - In danger of being removed from publication path Date: Tue, 10 Jun 2008 15:50:21 … DEAD doc warning email -------- Original Message -------- Subject: draft-ietf-hip-applications - In danger of being removed from publication path Date: Tue, 10 Jun 2008 15:50:21 +0200 From: Mark Townsley <townsley@cisco.com> To: draft-ietf-hip-applications@tools.ietf.org CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, David Ward <dward@cisco.com>, Peter Koch <pk@DENIC.DE>, Roy Arends <roy@nominet.org.uk>, Black_David@emc.com References: <47F34383.7090807@ericsson.com> <48105A16.8000906@ericsson.com> <4810A497.1000801@cisco.com> <48229C0E.1010908@ericsson.com> This document was moved to Revised ID needed on June 7, one year ago. Multiple reminders have been sent. I'm treating documents which have been in IESG processing for a very long time (e.g., more than a year), as documents on the path to DEAD if not resolved soon. You have until July 10. There are two open discusses. Basically, I need some indication that what you are doing with DNS is sane (Lisa's discuss) and some attention to David Black's Gen-art review (Russ' discuss). The tracker show's one dns-dir review from Peter Koch. I was awaiting another from Roy Arends, I don't see that this ever arrived. Authors, please contact these individuals directly and come up with a good answer for Lisa. I've cc'd Peter and Roy. Similar for David Black's comment, whom I have cc'd. Please let me know the status these two issues ASAP. If I don't see any action, the clock will continue to tick towards removing the document from its current publication track. You have until July 10 to respond with either a new document that resolves these issues, or some explanation as to why the issues will not be resolved which I can take to the discussing ADs. Thanks and have a nice day! - Mark |
2008-06-10 |
04 | Mark Townsley | [Note]: 'It''s been a year since the doc hit the telechat. Sent email to chairs and doc authors that the doc was on a path … [Note]: 'It''s been a year since the doc hit the telechat. Sent email to chairs and doc authors that the doc was on a path to DEAD status if it doesn''t move soon.' added by Mark Townsley |
2007-12-18 |
04 | Russ Housley | [Ballot discuss] The Gen-ART Review from David Black said: Right track; open issues. The original Gen-ART review is here: http://www.alvestrand.no/ietf/gen/reviews/ … [Ballot discuss] The Gen-ART Review from David Black said: Right track; open issues. The original Gen-ART review is here: http://www.alvestrand.no/ietf/gen/reviews/ draft-ietf-hip-applications-01-black.txt As of 17 December 2007, IP address issues are still open. The following extract from an email message should make the remaining concerns clear. = = = = = = = = = The new version handles all of the minor comments in the Gen-ART review and handles the DNS aspect of the open issue, but fails to deal with the IP address aspect of the open issue. From the original review: Section 3.2 proposes replacing the IP addresses returned to a HIP-unaware application with HITs or LSIs. This seems somewhat risky, as even if the HIT or LSI is never visible to a user, it's likely to turn up in log records, where it will be confused with an IPv6 address. This is effectively a referral to the application or human that analyzes the log, but it's a very important case (in particular it escapes the "won't work over NATs" criticism of referrals, as log analysis should be aware of NAT configuration). The potential for a HIP-unaware application writing logs that cause HITs and LSIs to be mistaken for IP addresses needs to be discussed. As indicated above, display of a HIT or LSI as an IPv6 address in a user interface may be another problem area. In Section 3.2, this comment applies to the text that is introduced by: Return HIP LSIs and HITs instead of IP addresses: The only change made to this text was to add a reference to the Internet Indirection Infrastructure (i3) use of this technique. There is a log-file-related change in the chunk of text in Section 3.2 that is introduced by: Locally use a HIP-specific domain name prefix: That change involves a recommendation on the structure of HIP-extended domain names in order to avoid confusing applications such as "processes that generate system log files". The net is that the change made does not address the issue (any application may generate an application log file, which may contain LSIs and HITs that the application thinks are IP addresses because the OS returned them when an IP address was expected) and is not in the right place in the draft to address the issue (replacing the IP addresses returned to a HIP-unaware application with HITs or LSIs). |
2007-12-12 |
04 | Mark Townsley | dns-dir review from Peter Koch -------- Original Message -------- Subject: Re: Usage of .hip in draft-ietf-hip-applications-02.txt Date: Mon, 10 Dec 2007 19:17:13 +0100 From: Peter … dns-dir review from Peter Koch -------- Original Message -------- Subject: Re: Usage of .hip in draft-ietf-hip-applications-02.txt Date: Mon, 10 Dec 2007 19:17:13 +0100 From: Peter Koch <pk@denic.de> To: Mark Townsley <townsley@cisco.com> CC: dns directorate <dns-dir@ops.ietf.org>, hip-chairs@tools.ietf.org, Lisa Dusseault <lisa@osafoundation.org> References: <47540055.1010308@cisco.com> <47540119.4040903@cisco.com> Mark, > >In earlier emails, I had asked the dns-dir about this use of of a > >".hip" suffix in draft-ietf-hip-applications-01 - The document has I believe I've seen this before, but then I hope I'll be consistent in my review. > >been updated significantly here, and I'd like a quick review from > >someone in the dns-dir. Before addressing ".hip", I'd like to raise another issue: > 3.1. Using IP addresses in applications > > [...] > > Using DNS to map IP addresses to HIs: > > If the responder has host identifiers registered in the forward > DNS zone and has a PTR record in the reverse zone, the Initiator > could perform a reverse+forward lookup to learn the HIT associated > with the address. Although the approach should work under normal > circumstances, it has not been tested to verify that there are no > recursion or bootstrapping issues, particularly if HIP is used to > secure the connection to the DNS servers. Unless secured with DNS > security extensions, the use of the reverse DNS map is subject to > well-known security limitations (an attacker may cause an > incorrect IP address to domain name binding to occur). The applicability of DNSSEC can be read ambiguously and I'd suggest to clarify what kind of protection is expected from DNSSEC here. DNSSEC does not make the content more correct, i.e. the PTR RRs can still point to the "wrong" name, even with DNSSEC. I'm sure the authors understood this, but then the attack scenario should be explained in a bit more detail, e.g., involving spoofed responses to the PTR query, so to make the requestor go ahead with a domain name (and subsequently, HIT) under the attacker's control. Then of course, wouldn't that be true for the immediate domain to HIT mapping as well? Further below: > DNS with security extensions (DNSSEC) [5] could be used to > authenticate the bindings between IP address and host identifier, if > the necessary DNSSEC records were available and trusted. This is a brave assertion, since the DNSSEC signatures are _not_ meant to be certificates, i.e., they do support data origin authentication, but they do _not_ make an assertion about the binding between the DNS owner name and the RRSet's content. The difference is subtle and in practice the remaining attack path is rather small, but I'd like to avoid false promises made on behalf of DNSSEC. > >3.2. Using DNS to map domain names to HIs > > > > In the previous section, it was pointed out that a HIP-enabled system > > might make use of DNS to transparently fetch host identifiers prior > > to the onset of communication. For applications that make use of > > DNS, the name resolution process is another opportunity to use HIP. > > If host identifiers are bound to domain names (with a trusted DNS), > > the following are possible: > > > > > > Return HIP LSIs and HITs instead of IP addresses: > > > > The system resolver could be configured to return a Local Scope > > Identifier (LSI) or HIT rather than an IP address, if HIP > > information is available in the DNS that binds a particular domain > > name to a host identifier, and otherwise to return an IP address > > as usual. The system can then maintain a mapping between LSI and > > host identifier and perform the appropriate conversion at the > > system call interface or below. The application uses the LSI or > > HIT as it would an IP address. This technique has been used in > > overlay networking experiments such as the Internet Indirection > > Infrastructure (i3). > > > > > > Locally use a HIP-specific domain name prefix: > > > > One drawback to spoofing the DNS resolution is that some > > applications actually may want to fetch IP addresses (e.g., > > diagnostic applications such as ping, or processes that generate > > system log files). One way to provide finer granularity on > > whether the resolver returns an IP address or an LSI is to > > distinguish by the presence of a domain name prefix. > > Specifically, if the application requests to resolve "HIP- > > www.example.com" (or some similar prefix string), then the system > > returns an LSI, while if the application requests to resolve > > "www.example.com", IP address(es) are returned as usual. The use > > of a prefix rather than suffix is recommended, and the use of a > > string delimiter that is not a dot (".") is also recommended, to > > reduce the likelihood that such modified DNS names are mistakenly > > treated as names rooted at a new top-level domain. I'm still not too happy about the integration of the resolver path signalling into the "domain" name, but the way chosen here is better than the "hip" pseudo-TLD used in earlier versions. Also, I understand that the desire is to maintain "hostname" syntax compatibility, which is OK with the "hip-" prefix. Limits of domain name length or label length (255 or 63, respectively) might apply, though. Some of my earlier concerns have been addressed in the > 4. Security Considerations Maybe a forward reference could resolve some of the/my confusion. Replace "Unless secured ..." in setcion 3.2 by, e.g., "Discussion of the security implications of the use or absence of DNSSEC is deferred to security considerations section." [...] > The three outlined scenarios differ considerably in their security > properties. There are further differences related to whether DNSSEC > is used or not, and whether the DNSSEC zones are considered > trustworthy enough. Here we mean that the delegation chain from the > reverse IP root should be trusted (typical trust anchor issues), and What is meant by "reverse IP root"? Is that the "ARPA" trust anchor? > the DNS zone administrators in charge of the netblock should be > trusted to put in the right information. [...] > Using the forward DNS to map a domain name into an LSI is a case that > is closest to the most typical use scenarios today. If DNSSEC is > used, the result is fairly similar to the current use of certificates > with TLS. If DNSSEC is not used, the result is fairly similar to the > current use of plain IP, with the exception that HIP provides > protection against connection hijacking attacks. Comparison of DNSSEC with certificates make me nervous. If it's intended to say that TLS (I assume in a web server context) protects the channel and authenticity of the endpoint, but not the correctness of the transferred data, that's probably as close as one gets, but still I see ambiguity here. -Peter |
2007-12-12 |
04 | Mark Townsley | [Note]: 'Awaiting 2nd dns-dir review from Roy Arends' added by Mark Townsley |
2007-12-03 |
04 | Mark Townsley | [Note]: '-02 addresses .hip and other comments, awaiting check from dns-dir.' added by Mark Townsley |
2007-11-19 |
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-11-19 |
02 | (System) | New version available: draft-ietf-hip-applications-02.txt |
2007-07-12 |
04 | Mark Townsley | [Note]: 'Awaiting decision from dns-dir on whether to add warning text for usage of ".hip" DNS names or to use a different method.' added by … [Note]: 'Awaiting decision from dns-dir on whether to add warning text for usage of ".hip" DNS names or to use a different method.' added by Mark Townsley |
2007-06-08 |
04 | (System) | Removed from agenda for telechat - 2007-06-07 |
2007-06-07 |
04 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Amy Vezza |
2007-06-07 |
04 | David Ward | [Ballot Position Update] New position, Recuse, has been recorded by David Ward |
2007-06-07 |
04 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Blake Ramsdell. |
2007-06-07 |
04 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
2007-06-06 |
04 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-06-06 |
04 | Sam Hartman | [Ballot comment] I support Lisa's comment. If this has not received apps area review it should. Good document. |
2007-06-06 |
04 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2007-06-06 |
04 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-06-06 |
04 | Russ Housley | [Ballot discuss] The Gen-ART Review from David Black said: Right track; open issues. Private email discussion between David Black and Tom Henderson has … [Ballot discuss] The Gen-ART Review from David Black said: Right track; open issues. Private email discussion between David Black and Tom Henderson has made significant progress on the issues, but also indicates that a revised version of the draft is needed. The original Gen-ART review is here: http://www.alvestrand.no/ietf/gen/reviews/ draft-ietf-hip-applications-01-black.txt The primary reason a revised draft is needed is that the drawbacks of "use of HITs and LSIs instead of IP addresses in HIP-unaware applications" are not adequately discussed. See the review for an explanation of how this could cause problems in log files. |
2007-06-06 |
04 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2007-06-06 |
04 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-06-06 |
04 | Dan Romascanu | [Ballot comment] It would be useful to define either in the Abstract or in the Introduction what is meant by 'legacy applications' in this document … [Ballot comment] It would be useful to define either in the Abstract or in the Introduction what is meant by 'legacy applications' in this document (i.e. applications that are not HIP aware running in a HIP-aware system) |
2007-06-05 |
04 | Lisa Dusseault | [Ballot discuss] DISCUSS: I was surprised to see recommendations for DNS addresses of the form "www.example.com.hip". has that gone to the DNS Directorate for review? … [Ballot discuss] DISCUSS: I was surprised to see recommendations for DNS addresses of the form "www.example.com.hip". has that gone to the DNS Directorate for review? What are the chances of that addr leaking beyond the host where it's initially used? COMMENT: I do wish this had gone to the APP area review team but it may be too late for that. I'd like to ask that the HIP API draft go to APPs for review when it's close to WGLC. |
2007-06-05 |
04 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
2007-06-05 |
04 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-06-05 |
04 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to Yes from No Objection by Lars Eggert |
2007-06-05 |
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-06-05 |
04 | Lars Eggert | [Ballot comment] Section 3.1., paragraph 3: > There are a number of ways that HIP could be used in such a scenario. I'd … [Ballot comment] Section 3.1., paragraph 3: > There are a number of ways that HIP could be used in such a scenario. I'd be good to discuss that at least the "opportunistic" and "use DNS to map IP to HI" ways can incur additional delays compared to using plain IP: For opportunistic HIP, you don't know if the other guy speaks HIP, so you need to wait for a while before you can be reasonably sure no I2 will come in anymore. The DNS adds some roundtrips for the lookups. Section 3.2., paragraph 1: > If host identifiers are bound to domain names (with a trusted DNS) > the following are possible: A third option would be to temporarily cache the HITs returned with a DNS lookup, indexed by the IP addresses returned in the same entry, and pass the IP addresses up to the application as usual. If an application connects to one of those IP addresses within a short time after the lookup, initiate a base exchange using the cached HITs. The benefit is that this removes the uncertainty/delay associated with opportunistic HIP, because you know the peer speaks HIP. |
2007-06-04 |
04 | Chris Newman | [Ballot comment] While this discusses altering the results from DNS lookups to support HIP, it doesn't go into the details of whether this is done … [Ballot comment] While this discusses altering the results from DNS lookups to support HIP, it doesn't go into the details of whether this is done via one of the typical OS APIs in use or via a customized DNS server or some combination. An interesting issue is that certain high-performance server applications (typically email and web servers) bypass the OS-provided DNS APIs and perform DNS lookups directly. This is necessary because some OS DNS implementations do not support multiple lookups in progress at the same time. So how these mechanisms work may vary by the application. There is also the question of applications which have not yet been upgraded to support IPv6 APIs and the impact this has on these techniques. Consider these things to think about if a revision is made which goes into more technical depth. |
2007-06-04 |
04 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-06-04 |
04 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2007-05-28 |
04 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-05-23 |
04 | Yoshiko Fong | IANA Last Call Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2007-05-17 |
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Blake Ramsdell |
2007-05-17 |
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Blake Ramsdell |
2007-05-14 |
04 | Amy Vezza | Last call sent |
2007-05-14 |
04 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-05-14 |
04 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2007-05-14 |
04 | Mark Townsley | Ballot has been issued by Mark Townsley |
2007-05-14 |
04 | Mark Townsley | Created "Approve" ballot |
2007-05-14 |
04 | Mark Townsley | Placed on agenda for telechat - 2007-06-07 by Mark Townsley |
2007-05-14 |
04 | Mark Townsley | State Changes to Last Call Requested from Publication Requested by Mark Townsley |
2007-05-14 |
04 | Mark Townsley | Last Call was requested by Mark Townsley |
2007-05-14 |
04 | (System) | Ballot writeup text was added |
2007-05-14 |
04 | (System) | Last call text was added |
2007-05-14 |
04 | (System) | Ballot approval text was added |
2007-04-23 |
04 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, … PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document Shepherd for this document is Gonzalo Camarillo, who has personally reviewed this draft and believes it is read for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has been adequately reviewed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues 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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It represents the strong concurrence of all active WG participants. (1.f) 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 entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? This draft was checked with Version: 2.04.07 of the ID nits tool. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document only has Informative references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has a null IANA Considerations section. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document does not use formal language. (1.k) 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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The Host Identity Protocol (HIP) and architecture proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP- aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document is based on the experiences of several HIP implementors. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Document Shepherd: Gonzalo Camarillo AD: Mark Townsley |
2007-04-23 |
04 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2007-04-10 |
01 | (System) | New version available: draft-ietf-hip-applications-01.txt |
2006-11-26 |
00 | (System) | New version available: draft-ietf-hip-applications-00.txt |