Application-Layer Traffic Optimization (ALTO) Server Discovery
draft-ietf-alto-server-discovery-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-11-11
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-06-17
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-06-09
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-05-20
|
10 | (System) | RFC Editor state changed to REF from EDIT |
2014-03-06
|
10 | (System) | RFC Editor state changed to EDIT from MISSREF |
2013-09-12
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-09-12
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-09-10
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-09-10
|
10 | (System) | IANA Action state changed to In Progress |
2013-09-10
|
10 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-09-10
|
10 | (System) | RFC Editor state changed to MISSREF |
2013-09-10
|
10 | (System) | Announcement was received by RFC Editor |
2013-09-10
|
10 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-09-10
|
10 | Amy Vezza | IESG has approved the document |
2013-09-10
|
10 | Amy Vezza | Closed "Approve" ballot |
2013-09-10
|
10 | Amy Vezza | Ballot approval text was generated |
2013-09-10
|
10 | Spencer Dawkins | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-09-09
|
10 | Barry Leiba | [Ballot comment] Version -10 addresses my comments, and thanks for considering them. |
2013-09-09
|
10 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2013-09-09
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-09-09
|
10 | Martin Stiemerling | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-09-09
|
10 | Martin Stiemerling | New version available: draft-ietf-alto-server-discovery-10.txt |
2013-09-03
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-09-03
|
09 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-09-03
|
09 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-alto-server-discovery-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-alto-server-discovery-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action IANA is required to complete. In the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at: http://www.iana.org/assignments/s-naptr-parameters a new Application Service Tag is to be registered as follows: Tag: ALTO Reference: [ RFC-to-be ] IANA understands that this is the only actions required to be completed 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. |
2013-08-29
|
09 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-08-29
|
09 | Joel Jaeggli | [Ballot Position Update] New position, Abstain, has been recorded for Joel Jaeggli |
2013-08-29
|
09 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2013-08-28
|
09 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-08-28
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-08-28
|
09 | Sean Turner | [Ballot discuss] s6.1: For DHCP isn't it a bit more than just following BCP on safely operating DHCP - shouldn't it be that DHCP authentication … [Ballot discuss] s6.1: For DHCP isn't it a bit more than just following BCP on safely operating DHCP - shouldn't it be that DHCP authentication is enabled to ensure the ALTO/DHCP client isn't tricked in to taking information from the wrong DHCP server? Dditto for modifying the DNS records - shouldn't it be that DNSSEC be enabled? |
2013-08-28
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-08-28
|
09 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-08-28
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-08-28
|
09 | Barry Leiba | [Ballot discuss] I believe that alto-protocol is a normative reference, not an informative one. It's used as the reason in the second paragraph of Section … [Ballot discuss] I believe that alto-protocol is a normative reference, not an informative one. It's used as the reason in the second paragraph of Section 3.2 for limiting discovered URI schemes. If alto-protocol should change in that regard, this would have to also. |
2013-08-28
|
09 | Barry Leiba | [Ballot comment] Some non-blocking comments that I would like you to seriously consider, and feel free to chat with me about: -- Section 2 -- … [Ballot comment] Some non-blocking comments that I would like you to seriously consider, and feel free to chat with me about: -- Section 2 -- In bullet 1, is it correct to be more specific, like this?: OLD One or - in case of multiple interfaces and/or IPv4/v6 dual stack operation - more DNS domain names are retrieved NEW One DNS domain name is retrieved for each combination of interface and address family By "manual input", are you really talking about client (or resource consumer) configuration here? Wouldn't it be clearer to say that? --Section 3.1.1 -- Not to make too big a thing of this, but it strikes me that the MAY and SHOULD in the second paragraph have nothing to do with the protocol, and are just non-normative advice about implementation for better user experience. Maybe lose the 2119 key words here? -- Section 4.1 -- The first sentence confused me for a while, as I tried to figure out what is "enabled". I finally decided it's not the right word, nor the right phrasing. Maybe this?: OLD Section 3.1.2 describes the usage of a DHCP option. It enables the network operator of the network, in which the ALTO client is located, to provide a DNS domain name. NEW Section 3.1.2 describes the usage of a DHCP option that provides a means for the operator of the network in which the ALTO client is located to provide a DNS domain name. -- Section 6.1 -- Best current practices for safely operating DHCP should be followed. Do you have a pointer to help the reader find those best practices? Note that if TLS is used to protect ALTO, the HTTPS URI will be authenticated, i.e., the result of the U-NAPTR resolution, not the input domain name. I'm really trying to make sense out of that sentence, but I can't. Can you try to rephrase it more clearly, please? If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random results, the usage of the ALTO server may be discontinued. How do you discontinue the use of a server that users have configured (as opposed to one that's been discovered through DHCP)? |
2013-08-28
|
09 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2013-08-27
|
09 | Stewart Bryant | [Ballot comment] I have no objection to the publication of this document, but I do have a comment and a nit. ===== I find the … [Ballot comment] I have no objection to the publication of this document, but I do have a comment and a nit. ===== I find the following text strange: "In other words, this document tries to meet requirement AR-32 in [RFC6708] while AR-33 is out of scope. A different approach, which tries to meet requirement AR-33, i.e., third-party ALTO server discovery, is addressed in [I-D.kist-alto-3pdisc]." What does it mean to "try to meet"? If the RFC meets the requirement, then it is useful for the reader to be left in no doubt. If on the other hand it only partially succeeds, it would be useful to the reader to know this early in the text together with a list of issues with the approach. This may of course be a case of modesty, in which case I suggest s/tries to meet/meets/ ======== i.e., a PTR lookup PTR is used without a definition ======= |
2013-08-27
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-08-26
|
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-08-26
|
09 | Barry Leiba | [Ballot discuss] -- Section 4.2 -- The SHOULD in the second paragraph, and, indeed, the whole second paragraph confuses me. I don't understand how it … [Ballot discuss] -- Section 4.2 -- The SHOULD in the second paragraph, and, indeed, the whole second paragraph confuses me. I don't understand how it fits into the protocol described in Section 3, which requires that configuration settings take precedence over DHCP queries. Please explain this to me. -- references -- I believe that alto-protocol is a normative reference, not an informative one. It's used as the reason in the second paragraph of Section 3.2 for limiting discovered URI schemes. If alto-protocol should change in that regard, this would have to also. |
2013-08-26
|
09 | Barry Leiba | [Ballot comment] Some non-blocking comments that I would like you to seriously consider, and feel free to chat with me about: -- Section 1 -- … [Ballot comment] Some non-blocking comments that I would like you to seriously consider, and feel free to chat with me about: -- Section 1 -- This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. In other words, this document tries to meet requirement AR-32 in [RFC6708] while AR-33 is out of scope. A different approach, which tries to meet requirement AR-33, i.e., third-party ALTO server discovery, is addressed in [I-D.kist-alto-3pdisc]. It appears from this that the two approaches aren't just to meet different requirements, but to address different use cases. Would.it be reasonable to say something about the use cases, as well as the requirements? -- Section 2 -- In bullet 1, is it correct to be more specific, like this?: OLD One or - in case of multiple interfaces and/or IPv4/v6 dual stack operation - more DNS domain names are retrieved NEW One DNS domain name is retrieved for each combination of interface and address family By "manual input", are you really talking about client (or resource consumer) configuration here? Wouldn't it be clearer to say that? --Section 3.1.1 -- Not to make too big a thing of this, but it strikes me that the MAY and SHOULD in the second paragraph have nothing to do with the protocol, and are just non-normative advice about implementation for better user experience. Maybe lose the 2119 key words here? -- Section 4.1 -- The first sentence confused me for a while, as I tried to figure out what is "enabled". I finally decided it's not the right word, nor the right phrasing. Maybe this?: OLD Section 3.1.2 describes the usage of a DHCP option. It enables the network operator of the network, in which the ALTO client is located, to provide a DNS domain name. NEW Section 3.1.2 describes the usage of a DHCP option that provides a means for the operator of the network in which the ALTO client is located to provide a DNS domain name. -- Section 6.1 -- Best current practices for safely operating DHCP should be followed. Do you have a pointer to help the reader find those best practices? Note that if TLS is used to protect ALTO, the HTTPS URI will be authenticated, i.e., the result of the U-NAPTR resolution, not the input domain name. I'm really trying to make sense out of that sentence, but I can't. Can you try to rephrase it more clearly, please? If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random results, the usage of the ALTO server may be discontinued. How do you discontinue the use of a server that users have configured (as opposed to one that's been discovered through DHCP)? |
2013-08-26
|
09 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-08-26
|
09 | Martin Stiemerling | [Ballot Position Update] New position, Recuse, has been recorded for Martin Stiemerling |
2013-08-25
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-08-23
|
09 | Spencer Dawkins | [Ballot comment] I thought this draft was well-written and clear. I had two minor and non-blocking comments and would appreciate if they were considered, along … [Ballot comment] I thought this draft was well-written and clear. I had two minor and non-blocking comments and would appreciate if they were considered, along with any other comments that may come out of IESG Evaluation. In 3.1.1. Step 1, Option 1: User input The preferred way to acquire a domain name related to an interface's point of network attachment is the usage of DHCP (see Section 3.1.2). However, in some network deployment scenarios there is no DHCP server available. Furthermore, a user may want to use an ALTO service instance provided by an entity that is not the operator of the underlying IP network. Therefore, we allow the user to specify a DNS domain name, for example in a configuration file option. An example domain name is: my-alternative-alto-provider.example.org Implementations MAY give the user the opportunity (e.g., by means of configuration file entries or menu items) to specify an individual domain name for every address family on every interface. Implementations SHOULD allow the user to specify a default name that is used if no more specific name has been configured. So, if you MAY have the opportunity to specify an individual domain name for every address family on every interface, but you don't, and you SHOULD be able to specify a default name, but you can't, can you still use ALTO? In 6.1. Integrity of the ALTO Server's URI Due to the nature of the protocol, DHCP is rather prone to attacks. As already mentioned, an attacker that is able to inject forged DHCP replies into the network may do significantly more harm than only configuring a wrong ALTO server. Best current practices for safely operating DHCP should be followed. Is there a reference you can point to for best current practices when operating DHCP? Your answer may be "not really", of course - RFC 2131, in section 7, just says it's easy for unauthorized servers to forge DHCP replies, and I didn't see any of the RFCs listed as updating RFC 2131 solving that problem. |
2013-08-23
|
09 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2013-08-23
|
09 | Spencer Dawkins | [Ballot comment] I thought this draft was well-written and clear. I had two minor and non-blocking comments and would appreciate if they were considered, along … [Ballot comment] I thought this draft was well-written and clear. I had two minor and non-blocking comments and would appreciate if they were considered, along with any other comments that may come out of IESG Evaluation. In 3.1.1. Step 1, Option 1: User input The preferred way to acquire a domain name related to an interface's point of network attachment is the usage of DHCP (see Section 3.1.2). However, in some network deployment scenarios there is no DHCP server available. Furthermore, a user may want to use an ALTO service instance provided by an entity that is not the operator of the underlying IP network. Therefore, we allow the user to specify a DNS domain name, for example in a configuration file option. An example domain name is: my-alternative-alto-provider.example.org Implementations MAY give the user the opportunity (e.g., by means of configuration file entries or menu items) to specify an individual domain name for every address family on every interface. Implementations SHOULD allow the user to specify a default name that is used if no more specific name has been configured. So, if you MAY have the opportunity to specify an individual domain name for every address family on every interface, but you don't, and you SHOULD be able to specify a default name, but you can't, this text may be saying that the user can't use an ALTO service instance. If there are workarounds, perhaps it's worth saying so. In 6.1. Integrity of the ALTO Server's URI Due to the nature of the protocol, DHCP is rather prone to attacks. As already mentioned, an attacker that is able to inject forged DHCP replies into the network may do significantly more harm than only configuring a wrong ALTO server. Best current practices for safely operating DHCP should be followed. Is there a reference you can point to for best current practices when operating DHCP? Your answer may be "not really", of course - RFC 2131, in section 7, just says it's easy for unauthorized servers to forge DHCP replies, and I didn't see any of the RFCs listed as updating RFC 2131 solving that problem. |
2013-08-23
|
09 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2013-08-23
|
09 | Spencer Dawkins | Ballot has been issued |
2013-08-23
|
09 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-08-23
|
09 | Spencer Dawkins | Created "Approve" ballot |
2013-08-23
|
09 | Spencer Dawkins | Ballot writeup was changed |
2013-08-23
|
09 | Spencer Dawkins | Placed on agenda for telechat - 2013-08-29 |
2013-08-23
|
09 | Spencer Dawkins | My apologies for the inadvertent second IETF Last Call. |
2013-08-23
|
09 | Spencer Dawkins | State changed to IESG Evaluation from In Last Call |
2013-08-22
|
09 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (ALTO Server Discovery) to Proposed … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (ALTO Server Discovery) to Proposed Standard The IESG has received a request from the Application-Layer Traffic Optimization WG (alto) to consider the following document: - 'ALTO Server Discovery' 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 2013-09-05. 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 The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers. This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1952/ |
2013-08-22
|
09 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-08-22
|
09 | Spencer Dawkins | Last call announcement was generated |
2013-08-22
|
09 | Spencer Dawkins | Last call was requested |
2013-08-22
|
09 | Spencer Dawkins | State changed to Last Call Requested from AD Evaluation::AD Followup |
2013-08-22
|
09 | Spencer Dawkins | Last call announcement was generated |
2013-08-22
|
09 | Spencer Dawkins | Very nice work ... I have a couple of Last Call-ish questions, but I'll request Last Call now. |
2013-08-22
|
09 | Spencer Dawkins | State changed to AD Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup |
2013-08-22
|
09 | Spencer Dawkins | Changed document writeup |
2013-07-29
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-07-29
|
09 | Sebastian Kiesel | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-07-29
|
09 | Sebastian Kiesel | New version available: draft-ietf-alto-server-discovery-09.txt |
2013-07-16
|
08 | Spencer Dawkins | Please revise as appropriate based on Last Call comments received from Gen-ART and sec-dir reviewers. |
2013-07-16
|
08 | Spencer Dawkins | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-06-22
|
08 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2013-06-20
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tina Tsou. |
2013-06-20
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-06-18
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-06-18
|
08 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-alto-server-discovery-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-alto-server-discovery-08. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. WE understand that, upon approval of this document, there is a single action which we must complete. In the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at: http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml a new U-NAPTR will be registered as follows: Tag: ALTO Reference: [ RFC-to-be ] We understand that this is the only action required to be completed 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. |
2013-06-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2013-06-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2013-06-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2013-06-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2013-06-06
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-06-06
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (ALTO Server Discovery) to Proposed … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (ALTO Server Discovery) to Proposed Standard The IESG has received a request from the Application-Layer Traffic Optimization WG (alto) to consider the following document: - 'ALTO Server Discovery' 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 2013-06-20. 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 The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1952/ |
2013-06-06
|
08 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-06-06
|
08 | Amy Vezza | Last call announcement was generated |
2013-06-05
|
08 | Spencer Dawkins | Last call was requested |
2013-06-05
|
08 | Spencer Dawkins | Ballot approval text was generated |
2013-06-05
|
08 | Spencer Dawkins | Ballot writeup was generated |
2013-06-05
|
08 | Spencer Dawkins | State changed to Last Call Requested from AD Evaluation |
2013-06-05
|
08 | Spencer Dawkins | Last call announcement was generated |
2013-05-29
|
08 | Martin Stiemerling | Last call announcement was generated |
2013-05-28
|
08 | Richard Barnes | Shepherding AD changed to Spencer Dawkins |
2013-04-17
|
08 | Richard Barnes | State changed to AD Evaluation from Publication Requested |
2013-04-02
|
08 | Martin Stiemerling | Shepherding AD changed to Richard Barnes |
2013-03-28
|
08 | Martin Stiemerling | IESG process started in state Publication Requested |
2013-03-28
|
08 | Martin Stiemerling | Changed consensus to Yes from Unknown |
2013-03-28
|
08 | Martin Stiemerling | Intended Status changed to Proposed Standard from None |
2013-03-28
|
08 | Martin Stiemerling | Shepherding AD changed to Martin Stiemerling |
2013-03-21
|
08 | Vijay Gurbani | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2013-03-21
|
08 | Vijay Gurbani | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2013-03-21
|
08 | Vijay Gurbani | 2nd WGLC complete. Shepherd review and writeup complete. |
2013-03-21
|
08 | Sebastian Kiesel | New version available: draft-ietf-alto-server-discovery-08.txt |
2013-03-20
|
07 | Vijay Gurbani | Changed protocol writeup |
2013-01-25
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to Draft-ietf-alto-server-discovery-07 | |
2013-01-17
|
07 | Vijay Gurbani | Changed shepherd to Vijay Gurbani |
2013-01-17
|
07 | Vijay Gurbani | IETF state changed to In WG Last Call from WG Document |
2013-01-17
|
07 | Vijay Gurbani | IETF state changed to WG Document from In WG Last Call |
2013-01-17
|
07 | Vijay Gurbani | Annotation tag Doc Shepherd Follow-up Underway set. |
2013-01-17
|
07 | Vijay Gurbani | Starting shepherd writeup |
2013-01-17
|
07 | Sebastian Kiesel | New version available: draft-ietf-alto-server-discovery-07.txt |
2012-11-28
|
06 | Vijay Gurbani | IETF state changed to In WG Last Call from WG Document |
2012-11-28
|
06 | Vijay Gurbani | In WGLC. |
2012-11-28
|
06 | Sebastian Kiesel | New version available: draft-ietf-alto-server-discovery-06.txt |
2012-10-22
|
05 | Sebastian Kiesel | New version available: draft-ietf-alto-server-discovery-05.txt |
2012-07-16
|
04 | Martin Stiemerling | New version available: draft-ietf-alto-server-discovery-04.txt |
2012-03-08
|
03 | Nico Schwan | New version available: draft-ietf-alto-server-discovery-03.txt |
2011-09-14
|
02 | (System) | New version available: draft-ietf-alto-server-discovery-02.txt |
2011-07-11
|
01 | (System) | New version available: draft-ietf-alto-server-discovery-01.txt |
2011-05-05
|
00 | (System) | New version available: draft-ietf-alto-server-discovery-00.txt |