IPv6 Node Information Queries
RFC 4620
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
15 | (System) | Notify list changed from <bob.hinden@nokia.com> to (None) |
|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for Allison Mankin |
|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the No Objection position for David Kessens |
|
2006-08-10
|
15 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2006-08-10
|
15 | Amy Vezza | [Note]: 'RFC 4620' added by Amy Vezza |
|
2006-08-09
|
15 | (System) | RFC published |
|
2006-03-23
|
15 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-03-13
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-03-13
|
15 | Amy Vezza | IESG has approved the document |
|
2006-03-13
|
15 | Amy Vezza | Closed "Approve" ballot |
|
2006-03-12
|
15 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] Position for Steven Bellovin has been changed to Discuss from No Record |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, Discuss, has been recorded for Jeffrey Schiller |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] Position for Randy Bush has been changed to Discuss from No Record |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Patrik Faltstrom |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, Yes, has been recorded for Scott Bradner |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand |
|
2006-03-10
|
15 | (System) | [Ballot Position Update] New position, Discuss, has been recorded for Erik Nordmark |
|
2006-03-10
|
15 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens |
|
2006-03-03
|
15 | David Kessens | [Ballot discuss] This DISCUSS is also a placeholder for some questions that IANA has regarding this draft: --- For draft-ietf-ipngwg-icmp-name-lookups-15.txt, I have a some … [Ballot discuss] This DISCUSS is also a placeholder for some questions that IANA has regarding this draft: --- For draft-ietf-ipngwg-icmp-name-lookups-15.txt, I have a some questions. I'm going to try to get these questions to you by the end of today. Can you please hold this for IANA until I get these questions to you? Michelle IANA --- My own DISCUSS text follows below: I believe the following comments warrant a brief discussion. My intention is not to hold this document. Instead, I would like to know whether the authors have considered the following comments and whether they are really sure that they want to go this route instead of keeping things more simple. I received the following comments by Ólafur Guðmundsson <ogud@ogud.com> from the DNS review team: This document looks fine, from DNS perspective. It's main role is on local link and for debugging. My comments on the document: 1. The document assumes local names are only one DNS label ie node can not be named "apple.printer" or "b32.switch". the rule for how non fully qualified names are terminated is strange (two 0 labels). 2. The document recommends DNS name compression when there are multiple names. No feature of DNS has caused more problems than name compression, so earlier in the process I would have argued hard for having this removed, all it does is add complexity and errors, and the savings in packet size are not significant. Unless there are 10+ names and all in the same domain. (this falls into my category optimization-is-evil when the payoff is not likely to reduce the number of packets sent). |
|
2006-03-03
|
15 | (System) | Removed from agenda for telechat - 2006-03-02 |
|
2006-03-02
|
15 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2006-03-02
|
15 | David Kessens | [Ballot discuss] This DISCUSS is also a placeholder for the IANA considerations. My own DISCUSS text follows below: I believe the following comments warrant a … [Ballot discuss] This DISCUSS is also a placeholder for the IANA considerations. My own DISCUSS text follows below: I believe the following comments warrant a brief discussion. My intention is not to hold this document. Instead, I would like to know whether the authors have considered the following comments and whether they are really sure that they want to go this route instead of keeping things more simple. I received the following comments by Ólafur Guðmundsson <ogud@ogud.com> from the DNS review team: This document looks fine, from DNS perspective. It's main role is on local link and for debugging. My comments on the document: 1. The document assumes local names are only one DNS label ie node can not be named "apple.printer" or "b32.switch". the rule for how non fully qualified names are terminated is strange (two 0 labels). 2. The document recommends DNS name compression when there are multiple names. No feature of DNS has caused more problems than name compression, so earlier in the process I would have argued hard for having this removed, all it does is add complexity and errors, and the savings in packet size are not significant. Unless there are 10+ names and all in the same domain. (this falls into my category optimization-is-evil when the payoff is not likely to reduce the number of packets sent). |
|
2006-03-02
|
15 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
|
2006-03-02
|
15 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
|
2006-03-01
|
15 | David Kessens | [Ballot discuss] I believe the following comments warrant a brief discussion. My intention is not to hold this document. Instead, I would like to know … [Ballot discuss] I believe the following comments warrant a brief discussion. My intention is not to hold this document. Instead, I would like to know whether the authors have considered the following comments and whether they are really sure that they want to go this route instead of keeping things more simple. I received the following comments by Ólafur Guðmundsson <ogud@ogud.com> from the DNS review team: This document looks fine, from DNS perspective. It's main role is on local link and for debugging. My comments on the document: 1. The document assumes local names are only one DNS label ie node can not be named "apple.printer" or "b32.switch". the rule for how non fully qualified names are terminated is strange (two 0 labels). 2. The document recommends DNS name compression when there are multiple names. No feature of DNS has caused more problems than name compression, so earlier in the process I would have argued hard for having this removed, all it does is add complexity and errors, and the savings in packet size are not significant. Unless there are 10+ names and all in the same domain. (this falls into my category optimization-is-evil when the payoff is not likely to reduce the number of packets sent). |
|
2006-03-01
|
15 | David Kessens | [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens |
|
2006-03-01
|
15 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
|
2006-03-01
|
15 | Allison Mankin | [Ballot comment] The response to my Discuss issues was full. I'm also see the Security Considerations as having good knobs for controlling information exposure and … [Ballot comment] The response to my Discuss issues was full. I'm also see the Security Considerations as having good knobs for controlling information exposure and privacy (responding to the departed ADs' Discusses). I cleared with good will. Bob Hinden's responses to my Discuss: > My particular concern: there should be much less extensibility. > I think it would be reasonable to have a small space for > RFC approved new queries and a small space for private use, > and that's all. The current draft is less extensible and only allows new types by IETF consensus. From Section 7. IANA Considerations: This document defines five values of Qtype, numbers 0 through 4. Following the policies outlined in [16], new values, and their associated Flags and Reply Data, are to be defined by IETF Consensus. > Also a question: what happens if you send a query for node > address to the multicast address - what is the target? In the case of multicast, the query is only processed if the destination address was sent to a link-local scope multicast address that the node had joined. From Section 5 "Message Processing", fifth paragraph: Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing unless it is one of the Responder's unicast or anycast addresses, or a link-local scope multicast address which the Responder has joined. Typically the latter will be an NI Group Address for a name belonging to the Responder. A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es) but if so, the default configuration SHOULD be not to discard them. Also, the last paragraph of the same section: If the Query was sent to a multicast address, transmission of the Reply MUST be delayed by a random interval between zero and [Query Response Interval], as defined by Multicast Listener Discovery Version 2 [10]. > Overall I support others views that a very simple version of > this is of value (as it is used by KAME, e.g.). This is what is used by KAME (except for the change of multicast address assignments as describe in the questionnaire). |
|
2006-03-01
|
15 | Allison Mankin | [Ballot comment] The response to my Discuss issues was full. I'm also see the Security Considerations as having good knobs for controlling information exposure and … [Ballot comment] The response to my Discuss issues was full. I'm also see the Security Considerations as having good knobs for controlling information exposure and privacy (responding to the departed ADs' Discusses). I cleared with good will. Bob Hinden's responses to my Discuss: > My particular concern: there should be much less extensibility. > I think it would be reasonable to have a small space for > RFC approved new queries and a small space for private use, > and that's all. The current draft is less extensible and only allows new types by IETF consensus. From Section 7. IANA Considerations: This document defines five values of Qtype, numbers 0 through 4. Following the policies outlined in [16], new values, and their associated Flags and Reply Data, are to be defined by IETF Consensus. > Also a question: what happens if you send a query for node > address to the multicast address - what is the target? In the case of multicast, the query is only processed if the destination address was sent to a link-local scope multicast address that the node had joined. From Section 5 "Message Processing", fifth paragraph: Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing unless it is one of the Responder's unicast or anycast addresses, or a link-local scope multicast address which the Responder has joined. Typically the latter will be an NI Group Address for a name belonging to the Responder. A node MAY be configured to discard NI Queries to multicast addresses other than its NI Group Address(es) but if so, the default configuration SHOULD be not to discard them. Also, the last paragraph of the same section: If the Query was sent to a multicast address, transmission of the Reply MUST be delayed by a random interval between zero and [Query Response Interval], as defined by Multicast Listener Discovery Version 2 [10]. > Overall I support others views that a very simple version of > this is of value (as it is used by KAME, e.g.). This is what is used by KAME (except for the change of multicast address assignments as describe in the questionnaire). |
|
2006-03-01
|
15 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin |
|
2006-03-01
|
15 | Ted Hardie | [Ballot comment] I think this is okay for Experimental, but i frankly can't see it ever making the transition to standards track without a very … [Ballot comment] I think this is okay for Experimental, but i frankly can't see it ever making the transition to standards track without a very restrictive applicability statement . The work makes quite a few assumptions about the environment of use that seem unlikely, and its security properties give me the chills. In a debugging environment, I can see some usefulness, but even in a serverless environment I think the risk vs. reward is skewed. |
|
2006-03-01
|
15 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
|
2006-03-01
|
15 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
|
2006-02-24
|
15 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
|
2006-02-24
|
15 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
|
2006-02-24
|
15 | (System) | Ballot writeup text was added |
|
2006-02-24
|
15 | (System) | Last call text was added |
|
2006-02-24
|
15 | (System) | Ballot approval text was added |
|
2006-02-17
|
15 | Margaret Cullen | [Note]: 'The PROTO Shepherd is Bob Hinden <hinden@nokia.com>.' added by Margaret Wasserman |
|
2006-02-17
|
15 | Margaret Cullen | State Change Notice email list have been change to <bob.hinden@nokia.com> from <bob.hinden@nokia.com>, <mrw@windriver.com> |
|
2006-02-17
|
15 | Margaret Cullen | Placed on agenda for telechat - 2006-03-02 by Margaret Wasserman |
|
2006-02-17
|
15 | Margaret Cullen | State Changes to IESG Evaluation from AD Evaluation by Margaret Wasserman |
|
2006-02-17
|
15 | Margaret Cullen | Intended Status has been changed to Experimental from Proposed Standard |
|
2006-02-17
|
15 | Margaret Cullen | State Changes to AD Evaluation from AD is watching::AD Followup by Margaret Wasserman |
|
2006-02-17
|
15 | Margaret Cullen | Questionnaire below. Bob Hinden will be the shepherding chair. Bob Hinden & Brian Haberman IPv6 chairs ------------ > 1.a) Have the chairs personally reviewed … Questionnaire below. Bob Hinden will be the shepherding chair. Bob Hinden & Brian Haberman IPv6 chairs ------------ > 1.a) Have the chairs personally reviewed this version of the > Internet > Draft (ID), and in particular, do they believe this ID is > ready > to forward to the IESG for publication? > Yes. > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? Do you have any concerns about the > depth or breadth of the reviews that have been performed? > Yes. This document has been reviewed and commented on by many people in the working group. > > 1.c) Do you have concerns that the document needs more review > from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? > No. > 1.d) Do you have any specific concerns/issues with this document > that > you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain parts > of the > document, or have concerns whether there really is a need for > it. In any event, if your issues have been discussed in > the WG > and the WG has indicated it that it still wishes to advance > the > document, detail those concerns in the write-up. > 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? > The working group as a whole understands and agrees with the document. > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. > No. > 1.g) Have the chairs verified that the document adheres to all > of the > ID nits? (see http://www.ietf.org/ID-Checklist.html). > Yes. > > 1.h) Is the document split into normative and informative > references? > Are there normative references to IDs, where the IDs are not > also ready for advancement or are otherwise in an unclear > state? > (note here that the RFC editor will not publish an RFC with > normative references to IDs, it will delay publication > until all > such IDs are also ready for publication as RFCs.) > Yes. All normative references are either RFC or in the RFC-editor queue. > > 1.i) For Standards Track and BCP documents, the IESG approval > announcement includes a write-up section with the following > sections: > > * Technical Summary > > * Working Group Summary > > * Protocol Quality > This was submitted for experimental. However, Technical Summary This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. Working Group Summary The latest specification does differ from what is currently deployed. Reviews revealed that the multicast prefix used by the Node Info Queries does not conform to the requirements of RFC 3307. The editors corrected the oversight within the specification to ensure proper operation over the long-term. Those who have already implemented the protocol agreed with the change and plan on updating their code to conform to the new multicast prefix. Other minor changes were made to address deprecated functionality that no longer needs to be supported (e.g. IPv4-compatible addresses and site-local addresses). Protocol Quality IPv6 Node Information Queries have been widely implemented in the ping6 program in the KAME (<http://www.kame.net>), USAGI, and other IPv6 implementations. It is proved to be very useful when debugging problems or when bringing up IPv6 service where there isn't global routing or DNS name services available. IPv6's large auto- configured addresses make debugging network problems and bringing up IPv6 service difficult without these mechanisms. > |
|
2006-02-17
|
15 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
|
2006-02-17
|
15 | Dinara Suleymanova | PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready … PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes. This document has been reviewed and commented on by many people in the working group. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. 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? The working group as a whole understands and agrees with the document. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Yes. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes. All normative references are either RFC or in the RFC-editor queue. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality This was submitted for experimental. However, Technical Summary This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. Working Group Summary The latest specification does differ from what is currently deployed. Reviews revealed that the multicast prefix used by the Node Info Queries does not conform to the requirements of RFC 3307. The editors corrected the oversight within the specification to ensure proper operation over the long-term. Those who have already implemented the protocol agreed with the change and plan on updating their code to conform to the new multicast prefix. Other minor changes were made to address deprecated functionality that no longer needs to be supported (e.g. IPv4-compatible addresses and site-local addresses). Protocol Quality IPv6 Node Information Queries have been widely implemented in the ping6 program in the KAME (<http://www.kame.net>), USAGI, and other IPv6 implementations. It is proved to be very useful when debugging problems or when bringing up IPv6 service where there isn't global routing or DNS name services available. IPv6's large auto- configured addresses make debugging network problems and bringing up IPv6 service difficult without these mechanisms. |
|
2006-02-14
|
15 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-15.txt |
|
2006-02-03
|
14 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-14.txt |
|
2006-01-31
|
15 | Mark Townsley | Shepherding AD has been changed to Margaret Wasserman from Mark Townsley |
|
2006-01-31
|
15 | Mark Townsley | Shepherding AD has been changed to Mark Townsley from Thomas Narten |
|
2006-01-04
|
13 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-13.txt |
|
2005-08-18
|
15 | Randy Bush | [Ballot discuss] Discuss comment transferred from old ballot: extremely vulnerable to many kinds of attacks, e.g. adress spoofing. --- just when we have dnssec heading … [Ballot discuss] Discuss comment transferred from old ballot: extremely vulnerable to many kinds of attacks, e.g. adress spoofing. --- just when we have dnssec heading for the door, along comes nice totally insecure reverse lookup. --- despite saying In the global internet, the Domain Name System [1034, 1035] is the authoritative source of such information and this specifcation is not intended to supplant or supersede it. the folk in the wg admitted that this is part of the exceedingly underspecified serverless architecture, i.e. meant to replace dns. i.e. dig this The Querier constructs an ICMP NI Query and sends it to the address from which information is wanted. When the Subject of the Query is an IPv6 address, that address will normally be used as the IPv6 destination address of the Query, but need not be if the Querier has useful a priori information about the addresses of the target node. An NI Query may also be sent to a multicast address of link-local scope [2373]. When the Subject is a name, either fully-qualified or single- component, and the Querier does not have a unicast address for the target node, the query MUST be sent to a link-scope multicast address formed in the following way. The Subject Name is converted to the canonical form defined by DNS Security [2535], which is uncompressed with all alphabetic characters in lower case. (If additional DNS label types for host names are created, the rules for canonicalizing those labels will be found in their defining specification.) Compute the MD5 hash [1321] of the first label of the Subject Name -- the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length field. Append the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2::/96. The resulting multicast address will be termed the "NI Group Address" for the name. so i suggest that this could be a dns end-run and hence needs review in dnsext. though this may not be the best time to get calm adult review in that wg. --- the icmp types Type 139 - NI Query. 140 - NI Reply. are claimed to already be assigned for this protocol. i wonder how. --- 5.1. NOOP This NI type has no defined flags and never has a Data field. A Reply to a NI NOOP Query tells the Querier that a node with the Queried Address is up and reachable, implements the Node Information protocol, and incidentally happens to reveal whether the Queried Address was an anycast address. the whole subject of whether an anycast address should be differentiable is, or should be, undecided. --- The compressed form of the Reply Data consists of a sequence of blocks, each block consisting of two 16-bit unsigned integers, nWord and nSkip, followed by nWord 32-bit bitmasks describing the Responder's support for 32 consecutive Qtypes. nSkip is a count of 32-bit words following the included words which would have been all-zero and have been suppressed. The last block MUST have nSkip = 0. As an example, a Responder supporting Qtypes 0, 1, 2, 3, 60, and 4097 could express that information with the following Reply Data (nWord and nSkip fields are written in decimal for easier reading): how clever, and i do not mean that as a compliment. just how many qtypes does this intend? --- someone else already caught the TTL strangeness --- a6 resource records, now deprecated, are supported. --- this one is really cool If the Query was sent by a DNS server on behalf of a DNS client, the result may be returned to that client as a DNS response with TTL zero. so does the server return ad-is-secure to a stub resolver in this case? :-) oh, and note that this paragraph and the one following make it quite clear that this is meant to be part of the dns or a replacement for part of it. --- and also Because a node can only answer a Node Name Request when it is up and reachable, it may be useful to create a proxy responder for a group of nodes, for example a subnet or a site. --- since it is replacing the dns, it is good that it handles ipv4 addresses as well. --- there is nothing keeping these queries local or limiting them to zeroconf environments. -30- Jeff: Many application implementations do a reverse DNS lookup on an IP address to learn the DNS Name of the connecting system. This name is then used to make access control decisions. Some may believe that this mechanism can be used to replace the reverse lookup. However this introduces a new security vulnerability, which is to say that a bogus host could connect to a service and when queried with this protocol it would provide the DNS Name that the server is expecting and therefore make an inappropriate access control decisions. The Security Considerations section should have words in it to the effect that the FQDN information (and other information) provided cannot be trusted for making security relevant decisions unless some other mechanism beyond the scope of this document is used to authenticate that information. |
|
2005-08-18
|
15 | Steven Bellovin | [Ballot discuss] Discuss comment transferred from old ballot: 5.3 How can a DNS TTL be returned? TTLs depend on the original … [Ballot discuss] Discuss comment transferred from old ballot: 5.3 How can a DNS TTL be returned? TTLs depend on the original value and how long it's been since an authoritative server sent out the information. Besides, how does a typical kernel (the entity that usually processes ICMP messages) know anything about DNS replies or dhcp lease time? I can imagine a DHCP client installing the current lease expiration every time it does a rebind or renew, but on what basis should a host do DNS queries? I think the "use once" semantics mentioned are far better. The document speaks of A6. Should it? 5.4 It speaks of truncation for space reasons. How large can the reply be? |
|
2005-08-17
|
15 | Allison Mankin | [Ballot discuss] Discuss transferred from old style text ballot: My particular concern: there should be much less extensibility. I think it would be reasonable to … [Ballot discuss] Discuss transferred from old style text ballot: My particular concern: there should be much less extensibility. I think it would be reasonable to have a small space for RFC approved new queries and a small space for private use, and that's all. Also a question: what happens if you send a query for node address to the multicast address - what is the target? Overall I support others views that a very simple version of this is of value (as it is used by KAME, e.g.). |
|
2005-08-17
|
15 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Amy Vezza |
|
2005-08-17
|
15 | Amy Vezza | [Ballot Position Update] New position, Discuss, has been recorded for Allison Mankin by Amy Vezza |
|
2005-08-17
|
15 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Amy Vezza |
|
2005-08-17
|
15 | Amy Vezza | Created "Approve" ballot |
|
2005-07-14
|
15 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2005-07-14
|
12 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-12.txt |
|
2005-05-06
|
11 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-11.txt |
|
2003-06-27
|
10 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-10.txt |
|
2003-06-23
|
15 | Thomas Narten | IESG comments sent to WG June, 2002. WG hasn't decided what to do. |
|
2003-06-23
|
15 | Thomas Narten | State Changes to AD is watching :: Revised ID Needed from IESG Evaluation :: Revised ID Needed by Narten, Thomas |
|
2002-10-04
|
15 | Thomas Narten | State Changes to IESG Evaluation -- New ID Needed from IESG Evaluation -- Point Raised - writeup needed by narten |
|
2002-06-14
|
15 | Stephen Coya | Due date has been changed to 06/13/2002 from 06/06/2002<br>by scoya |
|
2002-06-14
|
15 | Stephen Coya | responsible has been changed to Narten from Unassigned |
|
2002-06-14
|
15 | Stephen Coya | State Changes to Evaluation: Discuss from Ready for Telechat … State Changes to Evaluation: Discuss from Ready for Telechat by scoya |
|
2002-06-09
|
15 | Stephen Coya | State Changes to Ready for Telechat from Last Call Issued … State Changes to Ready for Telechat from Last Call Issued by scoya |
|
2002-05-23
|
15 | Jacqueline Hargest | Due date has been changed to 06/06/2002 from 09/13/2001<br>by jhargest |
|
2002-05-23
|
15 | Jacqueline Hargest | State Changes to Last Call Issued from New Version … State Changes to Last Call Issued from New Version Needed (WG/Author) by jhargest |
|
2002-05-23
|
15 | (System) | Last call sent |
|
2002-05-20
|
09 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-09.txt |
|
2002-04-23
|
15 | Thomas Narten | Needs applicability statement to position it relative to using PTR records |
|
2002-04-23
|
15 | Thomas Narten | State Changes to New Version Needed (WG/Author) from Wait for Writeup … State Changes to New Version Needed (WG/Author) from Wait for Writeup by Thomas Narten |
|
2001-07-24
|
08 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-08.txt |
|
2000-08-29
|
07 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-07.txt |
|
2000-07-20
|
06 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-06.txt |
|
1999-10-26
|
05 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-05.txt |
|
1999-06-22
|
04 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-04.txt |
|
1999-03-03
|
03 | (System) | New version available: draft-ietf-ipngwg-icmp-name-lookups-03.txt |