Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
draft-ietf-alto-xdom-disc-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-02-04
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-01-30
|
06 | (System) | RFC Editor state changed to AUTH48 from TI |
2020-01-28
|
06 | (System) | RFC Editor state changed to TI from AUTH48 |
2020-01-27
|
06 | (System) | RFC Editor state changed to TI from AUTH48 |
2020-01-15
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-12-17
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-08-26
|
06 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Fred Baker was marked no-response |
2019-08-26
|
06 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-08-26
|
06 | (System) | RFC Editor state changed to EDIT |
2019-08-26
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-08-26
|
06 | (System) | Announcement was received by RFC Editor |
2019-08-26
|
06 | (System) | IANA Action state changed to In Progress |
2019-08-26
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-08-26
|
06 | Amy Vezza | IESG has approved the document |
2019-08-26
|
06 | Amy Vezza | Closed "Approve" ballot |
2019-08-23
|
06 | Mirja Kühlewind | IESG state changed to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup |
2019-08-23
|
06 | Mirja Kühlewind | Ballot approval text was generated |
2019-08-23
|
06 | Mirja Kühlewind | Ballot approval text was generated |
2019-08-20
|
06 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-06.txt |
2019-08-20
|
06 | (System) | New version approved |
2019-08-20
|
06 | (System) | Request for posting confirmation emailed to previous authors: Sebastian Kiesel , Martin Stiemerling |
2019-08-20
|
06 | Sebastian Kiesel | Uploaded new revision |
2019-07-26
|
05 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss |
2019-07-26
|
05 | Suresh Krishnan | [Ballot discuss] Thanks for addressing my DISCUSS points in version -05. |
2019-07-26
|
05 | Suresh Krishnan | Ballot discuss text updated for Suresh Krishnan |
2019-07-17
|
05 | Benjamin Kaduk | [Ballot comment] Thank you for the updates; they have captured enough of the discussion we had to clarify that most of my points of concern … [Ballot comment] Thank you for the updates; they have captured enough of the discussion we had to clarify that most of my points of concern are either non-concerns or have adequate workarounds. I'm still not entirely sure that DNSSEC in the reverse zone is available everywhere in a robust fashion, but it seems that there is enough availability that the mechanisms specified here can still be used in a useful manner. However, I do think that we need to clarify in Section 5.2.2 that this mechanism is compatible with the BCP 20 sub-allocation scheme only insamuch as you can add NAPTR records in the relevant locations -- the current procedures described in the text will not catch everything just on their own, IIUC. Also, one nit in Section 2: s/is usually always be set/is usually set/ |
2019-07-17
|
05 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-07-05
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-07-05
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-07-05
|
05 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-05.txt |
2019-07-05
|
05 | (System) | New version approved |
2019-07-05
|
05 | (System) | Request for posting confirmation emailed to previous authors: Sebastian Kiesel , Martin Stiemerling |
2019-07-05
|
05 | Sebastian Kiesel | Uploaded new revision |
2019-03-07
|
04 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2018-12-20
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer |
2018-12-20
|
04 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-12-19
|
04 | Eric Rescorla | [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3649 The security considerations for this document don't seem to be adequate. In general, the security of … [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3649 The security considerations for this document don't seem to be adequate. In general, the security of this mechanism seems to rely on DNSSEC, and yet it's not mandated. DETAIL S 6.1. > > However, it should also be noted that, if an attacker was able to > compromise the DNS infrastructure used for cross-domain ALTO > server discovery, (s)he could also launch significantly more > serious other attacks (e.g., redirecting various application > protocols). Hmm... Are there no settings in which ALTO servers give information that isn't something that is a subset of info in DNS? This seems like it needs more analysis. S 6.1. > certificate will contain the host name (CN). Consequently, only > the host part of the HTTPS URI will be authenticated, i.e., the > result of the ALTO server discovery procedure. The DNS/U-NAPTR > based mapping within the cross-domain ALTO server discovery > procedure needs to be secured as described above, e.g., by using > DNSSEC. This is not an acceptable description of how to use TLS. Given that you are using HTTPS, you need to cite 2818. And as this is a new application of HTTPS, you should be specifying modern TLS, i.e., mimimum 1.2 and 7525. S 6.4. > statement [RFC5693] and/or discussed in the ALTO working group, > this scenario has not been identified as a relevant threat. > > Protection Strategies and Mechanisms > No protection mechanisms for this scenario have been provided, as > it has not been identified as a relevant threat. However, if a Another threat here is the disclosure of the exact query you are making to the ALTO server. An attacker might be interested in that, and it's not all manifest in the DNS query. |
2018-12-19
|
04 | Eric Rescorla | [Ballot comment] S 2. > > The service parameter SHOULD always be set to "ALTO:https". However, > other parameter values MAY … [Ballot comment] S 2. > > The service parameter SHOULD always be set to "ALTO:https". However, > other parameter values MAY be used in some scenarios, e.g., > "ALTO:http" to search for a server that supports unencrypted > transmission for debugging purposes, or other application protocol or > service tags if applicable. What would be applicable here? S 2. > The discovery procedure sequentially tries two different lookup > strategies: First, an ALTO-specific U-NAPTR record is searched in the > "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. > corresponding to the given IP address or prefix. If this lookup does > not yield a usable result, the procedure tries further lookups with > truncated domain names, which correspond to shorter prefix lengths. Seems like wildcards could get a lot of this, no? S 3.4. > | IPv4 | 32 | R32 | R24, R16, R8 | > | IPv4 | 24 .. 31 | R24 | R16, R8 | > | IPv4 | 16 .. 23 | R16 | R8 | > | IPv4 | 8 .. 15 | R8 | (none) | > | IPv4 | 0 .. 7 | (none, abort: invalid prefix length L) | > +------------+------------+------------+----------------------------+ I'm trying to work out how this works. Say that AT=IPv4 and L=27, so we have like ff.ff.ff.ff/28 (I know this is illegal, but it saves me on math). My first look up should be: 240.255.255.255.in-addr.arpa, and then my next one should be 255.255.255.in-addr.arpa? Is that correct? Where does the text say that I should zero the low-order bits in R32? S 3.4. > | IPv6 | 64 (..127) | R64 | R56, R48, R32 | > | IPv6 | 56 .. 63 | R56 | R48, R32 | > | IPv6 | 48 .. 55 | R48 | R32 | > | IPv6 | 32 .. 47 | R32 | (none) | > | IPv6 | 0 .. 31 | (none, abort: invalid prefix length L) | > +------------+------------+------------+----------------------------+ What's the reasoning for this pattern? S 5.1.1. > mechanisms such as STUN [RFC5389] would be needed and considerations > for UNSAF [RFC3424] apply. Therefore, using the procedures specified > in this document for resource consumer based ALTO server discovery is > generally NOT RECOMMENDED. Note that a less versatile yet simpler > approach for resource consumer initiated ALTO server discovery is > specified in [RFC7286]. Why can't people do STUN? |
2018-12-19
|
04 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2018-12-19
|
04 | Benjamin Kaduk | [Ballot discuss] Section 3.3's procedures for shortening domain names seem potentially problematic. While I can understand the desire to reduce the number of DNS queries, … [Ballot discuss] Section 3.3's procedures for shortening domain names seem potentially problematic. While I can understand the desire to reduce the number of DNS queries, I'm not sure that it's really appropriate to place restrictions on what prefix lengths/boundaries can be used to divide administrative domains in a standards-track document. In particular, the IPv4 procedure only allows lengths that end on octet boundaries, which seems to ignore the possibility of using procedures from BCP 20. IPv6 is a somewhat different case, but my understanding is that in the general case prefix boundaries can land on arbitrary nibbles, and if we only look at a specific subset for NAPTR records we risk not matching up with reality. The lists in the fourth column of the table in Section 3.4 would presumably need to be revised as well, if this changes. From Section 5.2.1: We assume that if two organizations share parts of their DNS infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa. subdomains, they will also be able to operate a common ALTO server, Perhaps I am confused, but common subdomains in the reverse zones just implies a common IP address block. Why does it also imply a common DNS infrastructure? I also have a few points relating to the security of DNS and DNSSEC. From Section 6.1 However, it should also be noted that, if an attacker was able to compromise the DNS infrastructure used for cross-domain ALTO server discovery, (s)he could also launch significantly more serious other attacks (e.g., redirecting various application protocols). I'm not sure that this statement holds as strongly as one might like. In particular, this document is using the reverse zone (whereas normal ALTO usage would seem to only use the forward zone), and my understanding is that the management and operational practices for the reverse zone lag behind that of the forward zone. For example, I have encountered scenarios where I am issued an IPv4 address via DHCP that has no corresponding entry in the reverse zone, which broke some services for me at that site. Protection Strategies and Mechanisms The cross-domain ALTO server discovery procedure relies on a series of DNS lookups. If an attacker was able to modify or spoof any of the DNS records, the resulting URI could be replaced by a forged URI. The application of DNS security (DNSSEC) [RFC4033] provides a means to limit attacks that rely on modification of the DNS records while in transit. [...] I think we need to have a discussion about the efficacy and availability of DNSSEC for the reverse zone (and how those compare to the forward zone). It seems that the situation is less bad than I feared when I deferred the ballot on this document, but perhaps still not in a great place. In particular, I see that IANA and the RIRs do sign their reverse zones, and at least some RIRs have self-service options for inserting DS records into those zones, but my understanding is that in practice signing of the reverse zone is not in great shape. That is, while the technical pieces are all available (and in particular the pieces at the top are all present), it's not currently in any significant usage due to a lack of compelling use case and interest among (e.g.) ISPs. This document does not really seem like it's providing a compelling enough use case to drive adoption, so I think we're forced to treat DNSSEC as not actually useful in practice for this scenario. Separately, there is the question of what trust anchor to use for DNSSEC in the reverse zone for private-use addresses (which can be properly used in multiple locations and have no single point of authority). RFC 7216 includes some text about this issue, which would probably be appropriate to adopt to this case as well. |
2018-12-19
|
04 | Benjamin Kaduk | [Ballot comment] I didn't see a response to the secdir review, and agree that discussion of authorization policy would be appropriate. Section 3.1 Does this … [Ballot comment] I didn't see a response to the secdir review, and agree that discussion of authorization policy would be appropriate. Section 3.1 Does this procedure really make sense for a prefix length of zero (or should the inequalities in the second paragraph have a strict inequality for 0 < L)? In the intended usage scenario, the procedure SHOULD always be called with the parameter SP set to "ALTO:https". [...] This requirement is also stated in Section 2; generally we recommend to not duplicate normative requirements (with 2119 language) in multiple places, to avoid the risk of them getting out of sync. Section 3.2 First, the procedure checks the prefix length L for unsupported values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the procedure aborts and indicates an "invalid prefix length" error to the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "invalid prefix length" error to the caller. Is this in conflict with the inequalities in the second paragraph of section 3.1? If AT=IPv4, a domain name R32 is constructed according to the rules specified in Section 3.5 of [RFC1035] and it is rooted in the special domain "IN-ADDR.ARPA.". RFC1035 doesn't use the term "R32", so some sort of text or typographical clarification that the term is new to this document would be helpful. Similarly for "R128". Section 3.5 The procedure performs one or more DNS lookups in a well-defined order (corresponding to descending prefix lenghts, see Section 3.4), nit: "lengths" Section 4.1 An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix "X" and get a list of one or more IRD URI(s), including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRD(s) will always contain a network and a cost map, as these are mandatory information resources (see Section 11.2 of [RFC7285]). nit: There seems to be a missing transition here, since the IRD URI(s) are URIs, which must be dereferenced or otherwise accessed in order to retrieve the actual IRD(s) (and their network/cost maps). (Similarly for the subsequent sections as well.) nit: we probably need a reference (7285?) for "PID", as well as expansion on first usage. Please also expand ECS on first usage. Accessing cells outside column "X" and row "X" may not yield useful results. nit: I would suggest something like "accessing cells that relate to neither column 'X' nor row 'X'", since the current text could be read to indicate the single cell at their intersection, which is not a terribly interesting cell. Section 5.1.2 Similarly, resource consumers on mobile hosts SHOULD query the resource directory again after a change of IP address, in order to get a list of candidate resource providers that is optimized for the new IP address. Is it really the case that IP address change is the only situation for a mobile host what would cause refresh of the directory information to be advisable? Section 6.1 Note that if TLS is used to protect ALTO, the server certificate will contain the host name (CN). Consequently, only the host part of the HTTPS URI will be authenticated, i.e., the result of the ALTO server discovery procedure. [...] nit: I think this is talking about what happens after the ALTO server discovery procedure; the TLS CN check does not help with verifying the discovery procedure itself. (That is, something like "it only authenticates the result of the ALTO server discovery procedure and not the discovery procedure itself".) Section C.1 The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. However, in the considered scenario of a tracker-based P2P application, there are two fundamentally different possibilities where to place the ALTO client: nit: I think this is the first time that the P2P scenario is mentioned, so more lead-in than just "the considered scenario" might help the reader. In the second scenario (see Figure 4), the resource directory has an Is this Figure 4 or Figure 3? Section C.2 This analysis seems a little one-sided, in that it presents the benefit of tracker-based selection without mention of the additional costs that the tracker bears in this solution (needing to do quality-based selection over the N=10000 total peers instead of random selection). Depending on how that cost scales, the overal best choice may differ. |
2018-12-19
|
04 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-12-19
|
04 | Warren Kumari | [Ballot comment] Thank you for educating me :-) (previous position was discuss because I didn't understand the deployment scenario). |
2018-12-19
|
04 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2018-12-18
|
04 | Warren Kumari | [Ballot discuss] Note: I have not completed my review in detail (and so it may be answered further down), but I wanted to get this … [Ballot discuss] Note: I have not completed my review in detail (and so it may be answered further down), but I wanted to get this in early... I'm in no way an ALTO expert (I can barely spell it), so am hoping that I'm missing something obvious, but I'm really concerned by the scaling implications / cost shifting of this. Let's say this suddenly becomes very popular -- Apple includes this in the iOS App Store / iMessage app, or Chrome / Firefox decides to start doing this to find the best datacenter to send traffic to or something... Until the huge majority of ISPs start answering with these records for all of their subnets, it seems like there could be a sizable amount of traffic hitting a: the ISPs recursive servers, b: RIRs, and possibly c: AS112 servers. E.g: The address I get when I lookup www.google.com is 216.58.193.164. These are the lookups I'd need to do (I think!) if my $application (or, more worrying, framework / browser) were to use this: wkumari$ dig +nocomment +nostats +nocmd NAPTR 164.193.58.216.in-addr.arpa ;164.193.58.216.in-addr.arpa. IN NAPTR 193.58.216.in-addr.arpa. 59 IN SOA ns1.google.com. dns-admin.google.com. 226022060 900 900 1800 60 wkumari$ dig +nocomment +nostats +nocmd NAPTR 193.58.216.in-addr.arpa ;193.58.216.in-addr.arpa. IN NAPTR 193.58.216.in-addr.arpa. 59 IN SOA ns1.google.com. dns-admin.google.com. 225983176 900 900 1800 60 wkumari$ dig +nocomment +nostats +nocmd NAPTR 58.216.in-addr.arpa ;58.216.in-addr.arpa. IN NAPTR 216.in-addr.arpa. 1539 IN SOA z.arin.net. dns-ops.arin.net. 2017026288 1800 900 691200 10800 wkumari$ dig +nocomment +nostats +nocmd NAPTR 216.in-addr.arpa ;216.in-addr.arpa. IN NAPTR 216.in-addr.arpa. 1665 IN SOA z.arin.net. dns-ops.arin.net. 2017026288 1800 900 691200 10800 This is 4 lookups per host / app / connection hitting my recursive servers. In addition 2 of them hit Google's resolvers, and 2 hit ARINs. Yes, ARIN already gets many "reverse" queries, and my recursive already does lots of lookups, but the document doesn't (that I could see) discuss the potential fallout from potentially *lots* more load. Caching is only slightly effective here -- there are many many subnets, and e.g the ARIN NoData,NoError response will be cached for 1800 seconds (30 minutes). There are other examples -- for example, my laptop is currently on 192.168.0.65. If I try connect to 192.168.1.2 using an app which implements this, I'll have 4 queries hitting my recursive server (3 of which will get NXDOMAIN) and 192.in-addr.arpa. hitting ARINs servers. I'm assuming that I must be missing something obvious here, because I cannot see how the above sounds reasonable. |
2018-12-18
|
04 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2018-12-18
|
04 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-12-17
|
04 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-12-06
|
04 | Benjamin Kaduk | Telechat date has been changed to 2018-12-20 from 2018-12-06 |
2018-12-06
|
04 | Benjamin Kaduk | IESG state changed to IESG Evaluation - Defer from Waiting for Writeup |
2018-12-06
|
04 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-12-05
|
04 | Spencer Dawkins | [Ballot comment] In this text, One such scenario is detailed in Appendix C. there are several scenarios in Appendix C. I THINK you … [Ballot comment] In this text, One such scenario is detailed in Appendix C. there are several scenarios in Appendix C. I THINK you may want me to look at Appendix C.3, which is an example, which is fine, but whether that's what you want me to look at or not, it would be useful to point more specifically at what you're thinking about. |
2018-12-05
|
04 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-12-05
|
04 | Ben Campbell | [Ballot comment] Thanks for a very readable draft, especially given the that we are talking about naptr stuff :-) I agree with Alissa's comment. §2, … [Ballot comment] Thanks for a very readable draft, especially given the that we are talking about naptr stuff :-) I agree with Alissa's comment. §2, 4th paragraph: "The service parameter SHOULD always be set to "ALTO:https"." That SHOULD is redundant to the similar requirement in §3.1. Since that section describe the detailed procedures, I suggest leaving the normative keywords to it, and using descriptive language here. |
2018-12-05
|
04 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-12-05
|
04 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-12-05
|
04 | Adam Roach | [Ballot comment] I concur with Alissa's comment. |
2018-12-05
|
04 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-12-05
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-12-05
|
04 | Alissa Cooper | [Ballot comment] Section 6.4: It seems that people's understanding of the kind of threat described in this section has changed somewhat since 2009 when RFC … [Ballot comment] Section 6.4: It seems that people's understanding of the kind of threat described in this section has changed somewhat since 2009 when RFC 5693 was published. For example, work to provide confidentiality protection for DNS client requests to recursive resolvers (DoT and DoH) has occurred in the time since then, and the information revealed by such requests is arguably less sensitive than the information sent by ALTO clients. I don't know if the applicability of DoT/DoH to NAPTR has been written about anywhere, but at a minimum it seems that this is worthy of some discussion here. |
2018-12-05
|
04 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-12-05
|
04 | Suresh Krishnan | [Ballot discuss] * Section 5.1.2. I am having a hard time seeing how this can be implemented as described. "Therefore, a dual stack or multihomed … [Ballot discuss] * Section 5.1.2. I am having a hard time seeing how this can be implemented as described. "Therefore, a dual stack or multihomed resource consumer SHOULD either always use the same address for contacting the resource directory and the resource providers, i.e., overriding the operating system's automatic source IP address selection" What exactly is the mechanism to be used for the override? A policy table (manual or RFC7078)? I think it would be good if the document can provide an implementable description based on RFC6724. * Section 3.2. Step 1 "Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "invalid prefix length" error to the caller." I am trying to understand why is this a limitation. An IPv6 prefix can certainly legally have a length of < 32. |
2018-12-05
|
04 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
2018-11-28
|
04 | Liang Xia | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Liang Xia. Sent review to list. |
2018-11-28
|
04 | Amy Vezza | Placed on agenda for telechat - 2018-12-06 |
2018-11-28
|
04 | Mirja Kühlewind | Ballot has been issued |
2018-11-28
|
04 | Mirja Kühlewind | [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind |
2018-11-28
|
04 | Mirja Kühlewind | Created "Approve" ballot |
2018-11-28
|
04 | Mirja Kühlewind | Ballot writeup was changed |
2018-11-28
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-11-19
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2018-11-19
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2018-11-15
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Liang Xia |
2018-11-15
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Liang Xia |
2018-11-15
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Fernando Gont |
2018-11-15
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Fernando Gont |
2018-11-14
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-11-14
|
04 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-alto-xdom-disc-04, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-alto-xdom-disc-04, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Amanda Baber Lead IANA Services Specialist |
2018-11-14
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-11-14
|
04 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-11-28): From: The IESG To: IETF-Announce CC: Jan Seedorf , alto@ietf.org, ietf@kuehlewind.net, alto-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2018-11-28): From: The IESG To: IETF-Announce CC: Jan Seedorf , alto@ietf.org, ietf@kuehlewind.net, alto-chairs@ietf.org, draft-ietf-alto-xdom-disc@ietf.org, jan.seedorf@hft-stuttgart.de Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery) to Proposed Standard The IESG has received a request from the Application-Layer Traffic Optimization WG (alto) to consider the following document: - 'Application Layer Traffic Optimization (ALTO) Cross-Domain 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 2018-11-28. 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. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-11-14
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-11-14
|
04 | Mirja Kühlewind | Last call was requested |
2018-11-14
|
04 | Mirja Kühlewind | Ballot approval text was generated |
2018-11-14
|
04 | Mirja Kühlewind | Ballot writeup was generated |
2018-11-14
|
04 | Mirja Kühlewind | IESG state changed to Last Call Requested from Publication Requested |
2018-11-14
|
04 | Mirja Kühlewind | Last call announcement was generated |
2018-11-13
|
04 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-04.txt |
2018-11-13
|
04 | (System) | New version approved |
2018-11-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: Sebastian Kiesel , Martin Stiemerling |
2018-11-13
|
04 | Sebastian Kiesel | Uploaded new revision |
2018-10-29
|
03 | Mirja Kühlewind | 1. Summary Jan Seedorf is the document shepherd for draft-ietf-alto-xdom-disc. Mirja Kühlewind is the responsible Area Director. When the ALTO WG was last re-chartered, an … 1. Summary Jan Seedorf is the document shepherd for draft-ietf-alto-xdom-disc. Mirja Kühlewind is the responsible Area Director. When the ALTO WG was last re-chartered, an item was added to the charter to produce “One or more alternatives to the base ALTO server discovery mechanism”. draft-ietf-alto-xdom-disc targets exactly this item and presents an alternative way for ALTO-server discovery, addressing the ALTO charter milestone “Submit alternative server discovery document”. RFC 7286 specifies a mechanism to discover an ALTO server in the ALTO client’s network domain based on DHCP and DNS. However, in certain scenarios an ALTO client may want or need to discover other ALTO servers, possibly outside its own network domain. draft-ietf-alto-xdom-disc specifies such a mechanism, i.e. for an ALTO client to discover an ALTO server outside its own network domain. This “cross-domain” server discovery is technically based on reverse DNS lookups using ALTO-specific U-NAPTR records. The working group is targeting this document as Standards Track, which is appropriate as the document specifies a new mechanism on how to use reverse DNS lookups for ALTO server discovery. 2. Review and Consensus The initial draft for this document is from 2014. The document has been presented at multiple IETF meetings and discussed on the mailing list. It is well-known in the ALTO WG and there is clear consensus to standardise the proposed mechanism. A WGLC was issued on April 17, 2018, on draft-ietf-alto-xdom-disc-02, and a review with several comments was done by Sabine Randriamasy; draft-ietf-alto-xdom-disc-03 addresses these comments, in particular adding an extensive example of how to use the new server-discovery mechanism. Previously, a detailed review had already been produced on draft-ietf-alto-xdom-disc-01 by Richard Yang and and others, resulting in substantial updates on the document. In summary, there is clear support and consensus for draft-ietf-alto-xdom-disc in the ALTO WG, and it provides a very useful extension to the base ALTO protocol. A WGLC has successfully been passed, and extensive reviews were provided by various members of the WG and have all been addressed. 3. Intellectual Property The shepherd confirms that each author has stated to him that to the best of his/her (i.e. the author’s) knowledge, all IPR related to this document has been disclosed. 4. Other Points All normative references are ok (with respect to RFC 3967) as they are all towards documents with standards-level “Proposed Standards”, “Internet Standard”, or “BCP”. |
2018-10-16
|
03 | Jan Seedorf | 1. Summary Jan Seedorf is the document shepherd for draft-ietf-alto-xdom-disc. Mirja Kühlewind is the responsible Area Director. When the ALTO WG was last re-chartered, an … 1. Summary Jan Seedorf is the document shepherd for draft-ietf-alto-xdom-disc. Mirja Kühlewind is the responsible Area Director. When the ALTO WG was last re-chartered, an item was added to the charter to produce “One or more alternatives to the base ALTO server discovery mechanism”. draft-ietf-alto-xdom-disc targets exactly this item and presents an alternative way for ALTO-server discovery, addressing the ALTO charter milestone “Submit alternative server discovery document”. RFC 7286 specifies a mechanism to discover an ALTO server in the ALTO client’s network domain based on DHCP and DNS. However, in certain scenarios an ALTO client may want or need to discover other ALTO servers, possibly outside its own network domain. draft-ietf-alto-xdom-disc specifies such a mechanism, i.e. for an ALTO client to discover an ALTO server outside its own network domain. This “cross-domain” server discovery is technically based on reverse DNS lookups using ALTO-specific U-NAPTR records. The working group is targeting this document as Standards Track, which is appropriate as the document specifies a new mechanism on how to use reverse DNS lookups for ALTO server discovery. 2. Review and Consensus The initial draft for this document is from 2014. The document has been presented at multiple IETF meetings and discussed on the mailing list. It is well-known in the ALTO WG and there is clear consensus to standardise the proposed mechanism. A WGLC was issued on April 17, 2018, on draft-ietf-alto-xdom-disc-02, and a review with several comments was done by Sabine Randriamasy; draft-ietf-alto-xdom-disc-03 addresses these comments, in particular adding an extensive example of how to use the new server-discovery mechanism. Previously, a detailed review had already been produced on draft-ietf-alto-xdom-disc-01 by Richard Yang and and others, resulting in substantial updates on the document. In summary, there is clear support and consensus for draft-ietf-alto-xdom-disc in the ALTO WG, and it provides a very useful extension to the base ALTO protocol. A WGLC has successfully been passed, and extensive reviews were provided by various members of the WG and have all been addressed. 3. Intellectual Property The shepherd confirms that each author has stated to him that to the best of his/her (i.e. the author’s) knowledge, all IPR related to this document has been disclosed. 4. Other Points Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call. All normative references are ok (with respect to RFC 3967) as they are all towards documents with standards-level “Proposed Standards”, “Internet Standard”, or “BCP”. |
2018-10-16
|
03 | Jan Seedorf | Responsible AD changed to Mirja Kühlewind |
2018-10-16
|
03 | Jan Seedorf | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-10-16
|
03 | Jan Seedorf | IESG state changed to Publication Requested |
2018-10-16
|
03 | Jan Seedorf | IESG process started in state Publication Requested |
2018-10-16
|
03 | Jan Seedorf | Tag Doc Shepherd Follow-up Underway cleared. |
2018-10-16
|
03 | Jan Seedorf | Changed document writeup |
2018-10-16
|
03 | Jan Seedorf | Changed consensus to Yes from Unknown |
2018-10-16
|
03 | Jan Seedorf | Intended Status changed to Proposed Standard from None |
2018-10-09
|
03 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-03.txt |
2018-10-09
|
03 | (System) | New version approved |
2018-10-09
|
03 | (System) | Request for posting confirmation emailed to previous authors: Sebastian Kiesel , Martin Stiemerling |
2018-10-09
|
03 | Sebastian Kiesel | Uploaded new revision |
2018-09-06
|
02 | (System) | Document has expired |
2018-06-06
|
02 | Vijay Gurbani | Notification list changed to Jan Seedorf <jan.seedorf@hft-stuttgart.de> |
2018-06-06
|
02 | Vijay Gurbani | Document shepherd changed to Jan Seedorf |
2018-06-06
|
02 | Vijay Gurbani | The working group last call for this document ended on May 01, 2018 [1]. The set of comments on the mailing list reflects support to … The working group last call for this document ended on May 01, 2018 [1]. The set of comments on the mailing list reflects support to move it ahead. Sabine R. has performed a WGLC review. [1] https://www.ietf.org/mail-archive/web/alto/current/msg03676.html |
2018-06-06
|
02 | Vijay Gurbani | Tag Doc Shepherd Follow-up Underway set. |
2018-06-06
|
02 | Vijay Gurbani | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-03-05
|
02 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-02.txt |
2018-03-05
|
02 | (System) | New version approved |
2018-03-05
|
02 | (System) | Request for posting confirmation emailed to previous authors: Sebastian Kiesel , Martin Stiemerling |
2018-03-05
|
02 | Sebastian Kiesel | Uploaded new revision |
2018-01-04
|
01 | (System) | Document has expired |
2017-07-03
|
01 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-01.txt |
2017-07-03
|
01 | (System) | New version approved |
2017-07-03
|
01 | (System) | Request for posting confirmation emailed to previous authors: Sebastian Kiesel , Martin Stiemerling |
2017-07-03
|
01 | Sebastian Kiesel | Uploaded new revision |
2017-03-29
|
00 | Vijay Gurbani | This document now replaces draft-kiesel-alto-xdom-disc instead of None |
2017-03-29
|
00 | Sebastian Kiesel | New version available: draft-ietf-alto-xdom-disc-00.txt |
2017-03-29
|
00 | (System) | WG -00 approved |
2017-03-29
|
00 | Sebastian Kiesel | Set submitter to "Sebastian Kiesel ", replaces to draft-kiesel-alto-xdom-disc and sent approval email to group chairs: alto-chairs@ietf.org |
2017-03-29
|
00 | Sebastian Kiesel | Uploaded new revision |