LoST: A Location-to-Service Translation Protocol
RFC 5222
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
10 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2018-12-06
|
Jenny Bui | Removed related IPR disclosure: Todd S. Glassey's Statement about IPR related to RFC 5222 | |
|
2015-10-14
|
10 | (System) | Notify list changed from ecrit-chairs@ietf.org, draft-ietf-ecrit-lost@ietf.org to (None) |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the Yes position for Lisa Dusseault |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2011-03-07
|
(System) | Posted related IPR disclosure: Todd S. Glassey's Statement about IPR related to RFC 5222 | |
|
2008-08-05
|
10 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2008-08-05
|
10 | Cindy Morgan | [Note]: 'RFC 5222' added by Cindy Morgan |
|
2008-08-05
|
10 | (System) | RFC published |
|
2008-06-12
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2008-06-11
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2008-06-11
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2008-06-11
|
10 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2008-06-10
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2008-06-10
|
10 | (System) | IANA Action state changed to In Progress |
|
2008-06-10
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2008-06-10
|
10 | Amy Vezza | IESG has approved the document |
|
2008-06-10
|
10 | Amy Vezza | Closed "Approve" ballot |
|
2008-06-10
|
10 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2008-06-05
|
10 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
|
2008-05-28
|
10 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
|
2008-05-28
|
10 | (System) | New version available: draft-ietf-ecrit-lost-10.txt |
|
2008-04-22
|
10 | Cullen Jennings | [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: … [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: The advice on how a geodetic-2d profile implements matching to the service areas needs to be well enough constrained that we don't have two servers that both think the other server is responsible for the query and redirect to the other server. The worry here is not that a loop would be formed but that the client would never get a useful response from either server. I will try and explain this with an example. Imagine we had 3 PSAP regions that corresponded to Canada, US, and Mexico. Say we received a Lost query form a device very near the US/Mexico boarder that had a shape that crossed into both Mexico and US. I don't think usage of this protocol would work for it's intended uses if it is OK for the lost server to return Canada - I don't think that is the WG's understanding of what a LOST server will do but if people feel I am wrong on this then let me know so I can understand the WG consensus. Next imagine that the centroid of the query is in Mexico but the maximal area of overlap is with the US. And furthermore imagine that the US server just uses the centroid to determine if it the query matched a service regions while the Mexico server computes the area over overlap with each regions and chooses the region with the maximal overlap area to decide which service regions should be used. In this case the US server will redirect to Mexico server and the Mexico server will redirect to US server. I don't think the protocol will work if a Lost server in Mexico says to contact the US lost server and server in the US says to contact the one in Mexico - the problem is not the loop - the problem is the client can not get a useful answer. There are reports of location implementations that use centroid and at least one vendor has suggested that maximal area overlap would be the optimal solution so this seems like a very plausible scenario to have happen in the real world. My assumption is that the WG believes that in this Mexico, US example that the client should get sent to either the US or Mexico region but that it is not required for the specifications to mandate which one. Ted proposed an RFC editor note to fix this which I edited a bit but tried to keep within my understanding of the principles that Ted wanted to preserve. I think the following would be one way to address by concerns and I'm not suggesting this is what the WG should do but only offering it to try and help illustrate what I see as the problem and a possible solution. OLD When clients place a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within the < location > element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. A server MAY return multiple <mapping> elements if the polygon extends across multiple service areas. NEW When a client uses a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within a < location > element, it is indicating that it will be satisfied by query results appropriate to any portion of the shape. It is left to the server to select an appropriate matching algorithm. A server MAY return multiple < mapping > elements if the shape extends across multiple service areas. Because this section does not specify a single matching algorithm, it is possible for a server to select an algorithm which does returns a null result even if some points in the shape are within a service area known to the server. In cases where two or more adjacent service areas are served by separate LoST servers, this has the potential to lead to a situation in which the client request a shape which intersects both service areas, but due to the algorithms selected by each server, both servers return null results, rendering the client unable to obtain the address of any service. This is a particular issue in emergency service use cases, where it is important that the client be able to reach some server, even if it is not the optimal one. Accordingly, the LoST server SHOULD ensure that the algorithm used does not return null results if any point in the shape is within a known service area. I think there have been several misunderstanding on this issue in the email back and forth so far - it's not easy to explain and my previous write up was very poor. I hope this one is better but I'm not sure it makes sense either. I'm glad to set up a call to try and make sure I am clearly explaining this, check that I am not making any false assumptions about what the WG decided on, then worry about how to resolve it. Multiple Result Issue: One of the authors of this draft does not seem to think there is WG consensus to return multiple URLs for the emergency service. That position seems to be consistent with the bulk of the other documents in ecrit/geopriv so I think this needs to be resolved as well. I will work with the chairs to try and resolve what the consensus is. I am not trying to push this one way or the other - I am just noting that it is important and there seems to be inconsistency about it so I would like to confirm that. Reference Issue: I agree with Ted's response that this could normatively refer to the GML doc instead of [13]]. Reference 13 should include the OCG specifier for a specific version of this document to be a stable references. (So it should have OGC 06-142r1 and likely a good idea to include the date of 2007-04-10). The document contains the text "There will be a 30-day public comment period to solicit input and comments from the broader geospatial community." which is sort of surprising for a stable reference but I assume folks are sure this is a final document. |
|
2008-04-22
|
10 | Cullen Jennings | Had call with Hannes and Andy last week. Meant with Hannes, Henning, Richard Barnes and Brian Rosen today. Seems to be agreement their is an … Had call with Hannes and Andy last week. Meant with Hannes, Henning, Richard Barnes and Brian Rosen today. Seems to be agreement their is an issues that needs to be resolved here. Authors are going to propose some text. |
|
2008-04-04
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
|
2008-04-04
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
|
2008-03-28
|
10 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Yes from Discuss by Lisa Dusseault |
|
2008-03-28
|
09 | (System) | New version available: draft-ietf-ecrit-lost-09.txt |
|
2008-03-28
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2008-03-28
|
08 | (System) | New version available: draft-ietf-ecrit-lost-08.txt |
|
2008-03-19
|
10 | Cullen Jennings | [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: … [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: The advice on how a geodetic-2d profile implements matching to the service areas needs to be well enough constrained that we don't have two servers that both think the other server is responsible for the query and redirect to the other server. The worry here is not that a loop would be formed but that the client would never get a useful response from either server. I will try and explain this with an example. Imagine we had 3 PSAP regions that corresponded to Canada, US, and Mexico. Say we received a Lost query form a device very near the US/Mexico boarder that had a shape that crossed into both Mexico and US. I don't think usage of this protocol would work for it's intended uses if it is OK for the lost server to return Canada - I don't think that is the WG's understanding of what a LOST server will do but if people feel I am wrong on this then let me know so I can understand the WG consensus. Next imagine that the centroid of the query is in Mexico but the maximal area of overlap is with the US. And furthermore imagine that the US server just uses the centroid to determine if it the query matched a service regions while the Mexico server computes the area over overlap with each regions and chooses the region with the maximal overlap area to decide which service regions should be used. In this case the US server will redirect to Mexico server and the Mexico server will redirect to US server. I don't think the protocol will work if a Lost server in Mexico says to contact the US lost server and server in the US says to contact the one in Mexico - the problem is not the loop - the problem is the client can not get a usefull answer. There are reports of location implementations that use centroid and at least one vendor has suggested that maximal area overlap would be the optimal solution so this seems like a very plausible scenario to have happen in the real world. My assumption is that the WG believes that in this Mexico, US example that the client should get sent to either the US or Mexico region but that it is not required for the specifications to mandate which one. Ted proposed an RFC editor note to fix this which I edited a bit but tried to keep within my understanding of the principles that Ted wanted to preserve. I think the following would be one way to address by concerns and I'm not suggesting this is what the WG should do but only offering it to try and help illustrate what I see as the problem and a possible solution. OLD When clients place a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within the < location > element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. A server MAY return multiple <mapping> elements if the polygon extends across multiple service areas. NEW When a client uses a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within a < location > element, it is indicating that it will be satisfied by query results appropriate to any portion of the shape. It is left to the server to select an appropriate matching algorithm. A server MAY return multiple < mapping > elements if the shape extends across multiple service areas. Because this section does not specify a single matching algorithm, it is possible for a server to select an algorithm which does returns a null result even if some points in the shape are within a service area known to the server. In cases where two or more adjacent service areas are served by separate LoST servers, this has the potential to lead to a situation in which the client request a shape which intersects both service areas, but due to the algorithms selected by each server, both servers return null results, rendering the client unable to obtain the address of any service. This is a particular issue in emergency service use cases, where it is important that the client be able to reach some server, even if it is not the optimal one. Accordingly, the LoST server SHOULD ensure that the algorithm used does not return null results if any point in the shape is within a known service area. I think there have been several misunderstanding on this issue in the email back and forth so far - it's not easy to explain and my previous write up was very poor. I hope this one is better but I'm not sure it makes sense either. I'm glad to set up a call to try and make sure I am clearly explaining this, check that I am not making any false assumptions about what the WG decided on, then worry about how to resolve it. Multiple Result Issue: One of the authors of this draft does not seem to think there is WG consensus to return multiple URLs. That position seems to be consistent with the bulk of the other documents in ecrit/geopriv so I think this needs to be resolved as well. I will work with the chairs to try and resolve what the consensus is. I am not trying to push this one way or the other - I am just noting that it is important and there seems to be inconsistency about it so I would like to confirm that. Reference Issue: The document contains text such as The < Polygon > element is described in Section 5.2.2 of [13]. The restriction to 16 points for a polygon contained in Section 7.2.2 of [12] is not applicable to this document. and text like When clients place a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within the < location > element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. I can not see how this draft can be implemented without reading Ref 13 which defined the shapes such as Polygon. These are not defined in 4119. Because of this I feel that Ref 13 needs to be a normative reference. Ref 13 is already publication requested so I do not see this causing significant delay. |
|
2008-03-19
|
10 | Cullen Jennings | [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: … [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: The advice on how a geodetic-2d profile implements matching to the service areas needs to be well enough constrained that we don't have two servers that both think the other server is responsible for the query and redirect to the other server. The worry here is not that a loop would be formed but that the client would never get a useful response from either server. I will try and explain this with an example. Imagine we had 3 PSAP regions that corresponded to Canada, US, and Mexico. Say we received a Lost query form a device very near the US/Mexico boarder that had a shape that crossed into both Mexico and US. I don't think usage of this protocol would work for it's intended uses if it is OK for the lost server to return Canada - I don't think that is the WG's understanding of what a LOST server will do but if people feel I am wrong on this then let me know so I can understand the WG consensus. Next imagine that the centroid of the query is in Mexico but the maximal area of overlap is with the US. And furthermore imagine that the US server just uses the centroid to determine if it the query matched a service regions while the Mexico server computes the area over overlap with each regions and chooses the region with the maximal overlap area to decide which service regions should be used. In this case the US server will redirect to Mexico server and the Mexico server will redirect to US server. I don't think the protocol will work if a Lost server in Mexico says to contact the US lost server and server in the US says to contact the one in Mexico - the problem is not the loop - the problem is the client can not get a usefull answer. There are reports of location implementations that use centroid and at least one vendor has suggested that maximal area overlap would be the optimal solution so this seems like a very plausible scenario to have happen in the real world. My assumption is that the WG believes that in this Mexico, US example that the client should get sent to either the US or Mexico region but that it is not required for the specifications to mandate which one. Ted proposed an RFC editor note to fix this which I edited a bit but tried to keep within my understanding of the principles that Ted wanted to preserve. I think the following would be one way to address by concerns and I'm not suggesting this is what the WG should do but only offering it to try and help illustrate what I see as the problem and a possible solution. OLD When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand> element within the < location > element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. A server MAY return multiple <mapping> elements if the polygon extends across multiple service areas. NEW When a client uses a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within a < location > element, it is indicating that it will be satisfied by query results appropriate to any portion of the shape. It is left to the server to select an appropriate matching algorithm. A server MAY return multiple <mapping> elements if the shape extends across multiple service areas. Because this section does not specify a single matching algorithm, it is possible for a server to select an algorithm which does returns a null result even if some points in the shape are within a service area known to the server. In cases where two or more adjacent service areas are served by separate LoST servers, this has the potential to lead to a situation in which the client request a shape which intersects both service areas, but due to the algorithms selected by each server, both servers return null results, rendering the client unable to obtain the address of any service. This is a particular issue in emergency service use cases, where it is important that the client be able to reach some server, even if it is not the optimal one. Accordingly, the LoST server SHOULD ensure that the algorithm used does not return null results if any point in the shape is within a known service area. I think there have been several misunderstanding on this issue in the email back and forth so far - it's not easy to explain and my previous write up was very poor. I hope this one is better but I'm not sure it makes sense either. I'm glad to set up a call to try and make sure I am clearly explaining this, check that I am not making any false assumptions about what the WG decided on, then worry about how to resolve it. Multiple Result Issue: One of the authors of this draft does not seem to think there is WG consensus to return multiple URLs. That position seems to be consistent with the bulk of the other documents in ecrit/geopriv so I think this needs to be resolved as well. I will work with the chairs to try and resolve what the consensus is. I am not trying to push this one way or the other - I am just noting that it is important and there seems to be inconsistency about it so I would like to confirm that. Reference Issue: The document contains text such as The < Polygon > element is described in Section 5.2.2 of [13]. The restriction to 16 points for a polygon contained in Section 7.2.2 of [12] is not applicable to this document. and text like When clients place a < Polygon >, < Circle >, < Ellipse > or < ArcBand > element within the < location > element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. I can not see how this draft can be implemented without reading Ref 13 which defined the shapes such as Polygon. These are not defined in 4119. Because of this I feel that Ref 13 needs to be a normative reference. Ref 13 is already publication requested so I do not see this causing significant delay. |
|
2008-03-19
|
10 | Cullen Jennings | [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: … [Ballot discuss] I am updating this to focus this discuss down to the part that still seem contentious and clarify the discuss. Shape Matching Issue: The advice on how a geodetic-2d profile implements matching to the service areas needs to be well enough constrained that we don't have two servers that both think the other server is responsible for the query and redirect to the other server. The worry here is not that a loop would be formed but that the client would never get a useful response from either server. I will try and explain this with an example. Imagine we had 3 PSAP regions that corresponded to Canada, US, and Mexico. Say we received a Lost query form a device very near the US/Mexico boarder that had a shape that crossed into both Mexico and US. I don't think usage of this protocol would work for it's intended uses if it is OK for the lost server to return Canada - I don't think that is the WG's understanding of what a LOST server will do but if people feel I am wrong on this then let me know so I can understand the WG consensus. Next imagine that the centroid of the query is in Mexico but the maximal area of overlap is with the US. And furthermore imagine that the US server just uses the centroid to determine if it the query matched a service regions while the Mexico server computes the area over overlap with each regions and chooses the region with the maximal overlap area to decide which service regions should be used. In this case the US server will redirect to Mexico server and the Mexico server will redirect to US server. I don't think the protocol will work if a Lost server in Mexico says to contact the US lost server and server in the US says to contact the one in Mexico - the problem is not the loop - the problem is the client can not get a usefull answer. There are reports of location implementations that use centroid and at least one vendor has suggested that maximal area overlap would be the optimal solution so this seems like a very plausible scenario to have happen in the real world. My assumption is that the WG believes that in this Mexico, US example that the client should get sent to either the US or Mexico region but that it is not required for the specifications to mandate which one. Ted proposed an RFC editor note to fix this which I edited a bit but tried to keep within my understanding of the principles that Ted wanted to preserve. I think the following would be one way to address by concerns and I'm not suggesting this is what the WG should do but only offering it to try and help illustrate what I see as the problem and a possible solution. OLD When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand> element within the <location> element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. A server MAY return multiple <mapping> elements if the polygon extends across multiple service areas. NEW When a client uses a <Polygon>, <Circle>, <Ellipse> or <ArcBand> element within a <location> element, it is indicating that it will be satisfied by query results appropriate to any portion of the shape. It is left to the server to select an appropriate matching algorithm. A server MAY return multiple <mapping> elements if the shape extends across multiple service areas. Because this section does not specify a single matching algorithm, it is possible for a server to select an algorithm which does returns a null result even if some points in the shape are within a service area known to the server. In cases where two or more adjacent service areas are served by separate LoST servers, this has the potential to lead to a situation in which the client request a shape which intersects both service areas, but due to the algorithms selected by each server, both servers return null results, rendering the client unable to obtain the address of any service. This is a particular issue in emergency service use cases, where it is important that the client be able to reach some server, even if it is not the optimal one. Accordingly, the LoST server SHOULD ensure that the algorithm used does not return null results if any point in the shape is within a known service area. I think there have been several misunderstanding on this issue in the email back and forth so far - it's not easy to explain and my previous write up was very poor. I hope this one is better but I'm not sure it makes sense either. I'm glad to set up a call to try and make sure I am clearly explaining this, check that I am not making any false assumptions about what the WG decided on, then worry about how to resolve it. Multiple Result Issue: One of the authors of this draft does not seem to think there is WG consensus to return multiple URLs. That position seems to be consistent with the bulk of the other documents in ecrit/geopriv so I think this needs to be resolved as well. I will work with the chairs to try and resolve what the consensus is. I am not trying to push this one way or the other - I am just noting that it is important and there seems to be inconsistency about it so I would like to confirm that. Reference Issue: The document contains text such as The <Polygon> element is described in Section 5.2.2 of [13]. The restriction to 16 points for a polygon contained in Section 7.2.2 of [12] is not applicable to this document. and text like When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand> element within the <location> element then it indicates that the query is about any point contained in the given area; it is left to the server to select an appropriate matching algorithm, such as using computing the centroid. I can not see how this draft can be implemented without reading Ref 13 which defined the shapes such as Polygon. These are not defined in 4119. Because of this I feel that Ref 13 needs to be a normative reference. Ref 13 is already publication requested so I do not see this causing significant delay. |
|
2008-03-14
|
10 | Pasi Eronen | [Ballot discuss] In the beginning, Leslie and Andrew created S-NAPTR; and the IESG saw the draft, that it was good; and RFC 3958 was given … [Ballot discuss] In the beginning, Leslie and Andrew created S-NAPTR; and the IESG saw the draft, that it was good; and RFC 3958 was given unto the people. Seeing that men, wandering Lost in the desert, might be tempted by false prophets and Held from reaching their true destination, the LADY and the LORD commanded the man, saying, 3958:20:1 Whether or not DNSSEC is used, applications should define some form of end-to-end authentication to ensure that the correct destination has been reached. Being filled with wisdom, and understanding, the LADY and the LORD saw the need to authenticate thine true destination, or the input of NAPTR processing. Instead of inscribing detailed commandments on stone tablets, it was proclaimed, 3958:20:8 Definitions of S-NAPTR for particular application protocols MUST define these. On the second day, the LADY saweth a need for URIs, and U-NAPTR was created. The security considerations of S-NAPTR were passed unto U-NAPTR, as from father to son. I pray thee, let this not be forgotten, and properly considered in draft-ietf-ecrit-lost. The children of Internet shall abide many days without DNSSEC. Thou shalt rejoice in thy feast, thou that can solveth the problem of verifying that the correct LoST server hath been contacted. If it be impossible, thee shall confess thine sins to the reader of the document, counting the possible solutions and speaking on why wasting and destruction are in their paths. |
|
2008-03-14
|
10 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
|
2008-03-06
|
10 | Cullen Jennings | [Ballot discuss] Section 5.6, 2nd para, I I think "omit" should be "emit" There is an ongoing discussion about if the example in section 8.2.1 … [Ballot discuss] Section 5.6, 2nd para, I I think "omit" should be "emit" There is an ongoing discussion about if the example in section 8.2.1 could overlap more than one service area - basically the argument about if it represents a thick point or not. There is ongoing conversation about if and when it would be appropriate for a server to return multiple service areas and I don't think I understand what the WG consensus is on these which makes it hard to evaluate this. Note, I'm not saying there is not WG consensus on this, there might be, I just don't know what it is. Ref 13 needs to normative and changes to it will impact what needs to be specified in this document. The advice on how a geodetic-2d profile implements matching to the service areas needs to be well enough constrained that we don't get bounced between servers with neither claiming responsibility and well enough constrained that they meet the assumptions clients are making. It also needs to be implementable. Let me try to illustrate with an example, imagine we had 3 PSAP regions that corresponded to Canada, US, and Mexico. Say we received a Lost query form a device very near the US/Mexico boarder that had a shape that crossed into both Mexico and US. I don't think usage of this protocol would work for it's intended uses if it is OK for the lost server to return Canada - I don't think that is the WG's understanding of what a LOST server will do. My read of the text is that it allows this but perhaps this is just a confusion on my part in reading the spec and we can wordsmith it. I don't think the protocol will work if a Lost server in Mexico says to contact the US lost server and server in the US says to contact the one in Mexico - the problem is not the loop - the problem is the client can not get an answer. One of the authors of this draft does not seem to think there is WG consensus to return both US and Mexico. That position seems to be consistent with the bulk of the other documents in ecrit/geopriv so I think this needs to be resolved as well. |
|
2008-03-06
|
10 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2008-03-06
|
10 | Sam Hartman | [Ballot discuss] Section 18 claims that authorization is not generally required. I agree that LOST servers do not typically need to authorize clients, but authentication … [Ballot discuss] Section 18 claims that authorization is not generally required. I agree that LOST servers do not typically need to authorize clients, but authentication and authorization of LOST servers by clients seems critical to the security of the system. Please clarify the text. [Ted's proposed clarification is fine] This spec proposes that RFC 2818 be used to describe how TLS certificates are validated. However let's think about how LOST works. I get some identifier L from a secure source--static configuration of my domain. I look up L as a NAPTR record. I get a URI, and then apply the rules of RFC 2818 to it. What secures the translation from L to the URI? You could argue dnssec, but I don't think that is a practical suggestion for today's internet and LOST clients. So, it seems that as specified LOST has a very significant attack on server authentication and authorization. I think that RFC 2818 is an inappropriate mapping of how to use TLS for LOST. The easiest way to handle this is to require that L (the string configured in DNS) appear in the TLS certificate. I'm not sure that doing so is compatible with the https URI scheme, nor am I sure that most HTTPs stacks will easily support implementing this. However I'm sure this problem is very important to solve. Note that if dnssec is actually used, then the mechanism as specified is fine. |
|
2008-03-05
|
10 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2008-03-05
|
10 | Jari Arkko | [Ballot comment] > <path>elelment, Typo. |
|
2008-03-05
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2008-03-05
|
10 | Sam Hartman | [Ballot comment] I'd really like to see some thought applied to RFC 3205 and this protocol. Especially given that the security requirements do not seem … |
|
2008-03-05
|
10 | Sam Hartman | [Ballot discuss] Section 18 claims that authorization is not generally required. I agree that LOST servers do not typically need to authorize clients, but authentication … [Ballot discuss] Section 18 claims that authorization is not generally required. I agree that LOST servers do not typically need to authorize clients, but authentication and authorization of LOST servers by clients seems critical to the security of the system. Please clarify the text. This spec proposes that RFC 2818 be used to describe how TLS certificates are validated. However let's think about how LOST works. I get some identifier L from a secure source--static configuration, SIP configuration, something. I look up L as a NAPTR record. I get a URI, and then apply the rules of RFC 2818 to it. What secures the translation from L to the URI? You could argue dnssec, but I don't think that is a practical suggestion for today's internet and LOST clients. So, it seems that as specified LOST has a very significant attack on server authentication and authorization. I think that RFC 2818 is an inappropriate mapping of how to use TLS for LOST. The easiest way to handle this is to require that L (the string configured in DNS) appear in the TLS certificate. I'm not sure that doing so is compatible with the https URI scheme, nor am I sure that most HTTPs stacks will easily support implementing this. However I'm sure this problem is very important to solve. |
|
2008-03-05
|
10 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
|
2008-03-04
|
10 | Dan Romascanu | [Ballot comment] 1. second paragraph of Section 1 - PIDF-LO is duplicated 2. second paragraph of Section 1 - please explain what are "2-1-1" and … [Ballot comment] 1. second paragraph of Section 1 - PIDF-LO is duplicated 2. second paragraph of Section 1 - please explain what are "2-1-1" and "3-1-1" services. Maybe this is common knowledge in the US, but for a non-American reader they have no significance. Better describe the service for example 'non-emergency municipal services or a citizen community services (e.g. "3-1-1" in the United States', etc. 3. in section 13.2 - I doubt that the three MAY in the descriptions of the warnings are appropriate. If I am not mistaken if each of the warning conditions is met in particular, including the earning message in the response is not optional. 4. Reference [21] has a corrupted content at the time I am writing this comment. This makes me wonder wheter a better protected place can be found for the on-line examples quoted in Appendix B. |
|
2008-03-04
|
10 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
|
2008-03-04
|
10 | Dan Romascanu | [Ballot comment] 1. second paragraph of Section 1 - PIDF-LO is duplicated 2. second paragraph of Section 1 - please explain what are "2-1-1" and … [Ballot comment] 1. second paragraph of Section 1 - PIDF-LO is duplicated 2. second paragraph of Section 1 - please explain what are "2-1-1" and "3-1-1" services. Maybe this is common knowledge in the US, but for a non-American reader they have no significance. Better describe the service for example 'non-emergency municipal services or a citizen community services (e.g. "3-1-1" in the United States', etc. 3. in section 13.2 I dount that the three MAY in the descriptions of the warnings are appropriate. If I am not mistaken if each of the warning conditions is met in particular, including the earning message in the response is not optional. 4. Reference [21] has a corrupted content at the time I am writing this comment. This makes me wonder wheter a better protected place can be found for the on-line examples quoted in Appendix B. |
|
2008-03-04
|
10 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
|
2008-03-03
|
10 | Tim Polk | [Ballot discuss] The introduction suggests that LoST may be appropriate for non-emergency services as well, but does not revisit that notion anywhere else in the … [Ballot discuss] The introduction suggests that LoST may be appropriate for non-emergency services as well, but does not revisit that notion anywhere else in the document. As noted in Joe Salowey's secdir review, there may be different threats or motivations which could affect the applicability of LoST to such applications. From his review: 3) Use in non-ecrit cases - has much thought been given to the use of LoST in non-Ecrit cases? There may be different threats or at least motivations than those covered in draft-ietf-ecrit-security-threats. For example, in non-ecrit cases an attacker may seek monetary benefit through attacking the LoST protocol to return inaccurate service mapping information. The suggestion here is to either consider this case of non-ecrit in more detail or to state that threats outside ecrit cases may be different. At a minimum, the security considedrations section should note that non-emergency services may face a different set of threats. The requirements for these services should be carefully reviewed to ensure that LoST can be used to achieve the service's security requirements. |
|
2008-03-03
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Discuss from No Objection by Tim Polk |
|
2008-03-02
|
10 | Cullen Jennings | [Ballot discuss] Section 5.6, 2nd para, I I think "omit" should be "emit" There is an ongoing discussion about if the example in section 8.2.1 … [Ballot discuss] Section 5.6, 2nd para, I I think "omit" should be "emit" There is an ongoing discussion about if the example in section 8.2.1 could overlap more than one service area - basically the argument about if it represents a thick point or not. There is ongoing conversation about if and when it would be appropriate for a server to return multiple service areas and I don't think I understand what the WG consensus is on these which makes it hard to evaluate this. Note, I'm not saying there is not WG consensus on this, there might be, I just don't know what it is. Ref 13 needs to normative and changes to it will impact what needs to be specified in this document. The advice on how a geodetic-2d profile implements matching to the service areas needs to be well enough constrained that we don't get bounced between servers with neither claiming responsibility and well enough constrained that they meet the assumptions clients are making. It also needs to be implementable. Ted and I have discussed this and he is going to propose some clarifying text before I try to evaluate this. |
|
2008-03-02
|
10 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
|
2008-02-22
|
10 | (System) | Removed from agenda for telechat - 2008-02-21 |
|
2008-02-20
|
10 | Cullen Jennings | State Changes to IESG Evaluation - Defer from Waiting for Writeup::AD Followup by Cullen Jennings |
|
2008-02-20
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2008-02-20
|
10 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2008-02-20
|
10 | Lisa Dusseault | [Ballot discuss] 1. Redirects The section on redirect (13.3) is shockingly short. Are redirects permanent or temporary? Should other servers change their listings when seeing … [Ballot discuss] 1. Redirects The section on redirect (13.3) is shockingly short. Are redirects permanent or temporary? Should other servers change their listings when seeing a redirect? Redirects have caused interoperability problems in HTTP; perhaps a little deeper review of the need for the functionality would help here. I'm inferring from section 14. that HTTP redirects MUST be supported by clients as well as LoST redirects. Can that be made a normative requirement? 2a. Open-ended URI types I'd like to see more guidance on what URIs are returned. The risk that the LoST server will return a URI that can't be used by the seeker is a bad risk to take when it comes to emergency services. - Add "tel" URI examples to the examples; Explain that in the worst case of not being able to use the URI types presented, seekers that have user interfaces should present the telephone number to the user; recommend that phone numbers be provided this way as fallbacks for emergency services - limit the types used: no data or mailto URIs; better yet have a registry of types that *can* be used - In the case of SIP URIs, what kind of contact can be made? Can this URI get a human voice, a voice mailbox, a presentity or other? - Differentiate between contact and resource URIs? A resource URI obtains something static, a contact URI may be able to begin a conversation... I'd like a little discussion of the requirement that each URI scheme may appear only once. That seems to prevent some fairly common use cases like providing one number for voice mail and one number to reach an operator. The proliferation of http URIs makes this even worse -- many different kinds of services can be hosted on http URIs. The Atom link rel provides an example of how one might deal with this problem. 2b. IRIs Is support for IRIs explicitly not desired? 2c. URI security/privacy I assume both LoST URIs (found in NAPTR) and service URIs can contain anything allowed by the URI scheme; long paths, query elements, anchor points. I can see a slight privacy issue here, because the URIs can contain tokens allowing communication from the LoST server that provided the URI to the service hosting that URI. This document doesn't talk about preserving URIs end-to-end. What if a LoST resolver were to "helpfully" try to change URIs before passing them on to seekers? Is there some other document that covers this? 3. Overlooked HTTP features. A number of features that are commonly overlooked when using HTTP this way are not mentioned. I like that HTTP caching is disabled but it looks like there's a cut-and-paste error in that part of the spec: The HTTP request MUST use the Cache-Control response directive "no-cache" to HTTP-level "caching even by caches that have been configured to return stale responses to client requests." For the rest I suggest adding: "LoST servers MUST handle the Expect header, conditional headers and Content-* headers on requests according to HTTP requirements (possibly by failing the request). They MUST also handle OPTIONS and HEAD and GET requests even if it's by responding with canned 200 responses. "LoST clients MUST include a Host header and MUST handle all possible HTTP response codes. "Both LoST clients and servers MUST handle chunked transfer-encoded message bodies." |
|
2008-02-20
|
10 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
|
2008-02-20
|
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2008-02-20
|
10 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2008-02-20
|
10 | Magnus Westerlund | [Ballot comment] Abtract: Usage of "PSAP" acronym. Please write it out. |
|
2008-02-20
|
10 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2008-02-19
|
10 | Russ Housley | [Ballot discuss] Based on the Gen-ART Review by Ben Campbell. In Section 12, first paragraph, it says: "To achieve interoperability, this document defines … [Ballot discuss] Based on the Gen-ART Review by Ben Campbell. In Section 12, first paragraph, it says: "To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the manner in which location information is transmitted. It is possible to standardize other profiles in the future. The three baseline profiles are:" Are there really three baseline profiles and two of them are mandatory-to-implement? |
|
2008-02-19
|
10 | Russ Housley | [Ballot comment] As pointed out by Ben Campbell in his Gen-ART Review, these things should probably be reworded as normative statements: - … [Ballot comment] As pointed out by Ben Campbell in his Gen-ART Review, these things should probably be reworded as normative statements: - Section 5.2, last paragraph: "... it is the responsibility of the client to check the 'expires' attribute... " - Section 6, paragraph 3: "If a query is answered iteratively, the querier includes all servers that it has already contacted." - Section 8.3.1: "The order of location elements is significant; the server uses the first location element where it understands the location profile." |
|
2008-02-19
|
10 | Russ Housley | [Ballot discuss] In Section 12, first paragraph, it says: "To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the … [Ballot discuss] In Section 12, first paragraph, it says: "To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the manner in which location information is transmitted. It is possible to standardize other profiles in the future. The three baseline profiles are:" Are there really three baseline profiles and two of them are mandatory-to-implement? |
|
2008-02-19
|
10 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2008-02-15
|
10 | (System) | Ballot has been issued |
|
2008-02-15
|
10 | Amy Vezza | [Ballot Position Update] New position, Yes, has been recorded by Amy Vezza |
|
2008-02-15
|
10 | Amy Vezza | Created "Approve" ballot |
|
2008-02-15
|
10 | Amy Vezza | Placed on agenda for telechat - 2008-02-21 by Amy Vezza |
|
2008-02-07
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2008-02-07
|
07 | (System) | New version available: draft-ietf-ecrit-lost-07.txt |
|
2007-12-13
|
10 | Jon Peterson | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Jon Peterson |
|
2007-11-29
|
10 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2007-11-20
|
10 | Amanda Baber | IANA Last Call comments: IANA has questions. First, the Schema registration is incorrect (it uses the wrong URI). Second, do you need a registry for … IANA Last Call comments: IANA has questions. First, the Schema registration is incorrect (it uses the wrong URI). Second, do you need a registry for Errors and Warnings (13.1, 13.2)? Third, you reference U-NAPTR but IANA currently only has a registry for S-NAPTR. Finally, has the media type been reviewed by the designated expert and/or the mailing list? Action 1 (Section 17.1): Upon approval of this document, the IANA will make the following assignment in the "S-NAPTR Parameters - per [RFC3958, RFC4848]" registry located at http://www.iana.org/assignments/s-naptr-parameters sub-registry "S-NAPTR Application Service Tags" Tag Reference ---------------------------- --------- LoST [RFC-ecrit-lost-06] Action 2 (Section 17.1): Upon approval of this document, the IANA will make the following assignments in the "S-NAPTR Parameters - per [RFC3958, RFC4848]" registry located at http://www.iana.org/assignments/s-naptr-parameters sub-registry "S-NAPTR Application Protocol Tags" Tag Reference ---------------------------- --------- http [RFC2616, RFC-ecrit-lost-06] https [RFC2818, RFC-ecrit-lost-06] Action 3 (Section 17.2): IESG Note: Expert Review Required Upon approval of this document, the IANA will make the following assignments in the "Application Media Types" registry located at http://www.iana.org/assignments/media-types/application/ application lost+xml [RFC-ecrit-lost-06] Action 4 (Section 17.3): [ The document is registering an "ns" as a schema. This isn't allowed. We suspect the correct URI would be urn:ietf:params:xml:schema:lost1 in section 17.3, and this should be corrected appropriately. Schema is in Section 15. ] Upon approval of this document, the IANA will make the following assignments in the "schema" registry located at http://www.iana.org/assignments/xml-registry/schema.html ID URI Filename Reference -- -------- --------- --------- lost1 urn:ietf:params:xml:schema:lost1 [lost1] [RFC-ecrit-lost-06] Action 5 (Section 17.4): Upon approval of this document, the IANA will make the following assignments in the "ns" registry located at http://www.iana.org/assignments/xml-registry/ns.html Registration ID URI Template Reference -- -------- --------- --------- lost1 urn:ietf:params:xml:ns:lost1 [lost1] [RFC-ecrit-lost-06] Action 6 (Section 17.5): Upon approval of this document, the IANA will create a registry called "LoST Location Profiles," which will be located at http://www.iana.org/assignments/TBD Registration Procedures: Standards Action Initial contents of this registry will be: Profile Name Reference ------------ --------- geodetic-2d [RFC-ecrit-lost-06 Section 12.2] civic [RFC-ecrit-lost-06 Section 12.3] We understand the above to be the only IANA Actions for this document. |
|
2007-11-16
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
|
2007-11-16
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
|
2007-11-15
|
10 | Amy Vezza | Last call sent |
|
2007-11-15
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2007-11-15
|
10 | Jon Peterson | Last Call was requested by Jon Peterson |
|
2007-11-15
|
10 | Jon Peterson | State Changes to Last Call Requested from AD Evaluation by Jon Peterson |
|
2007-11-15
|
10 | (System) | Ballot writeup text was added |
|
2007-11-15
|
10 | (System) | Last call text was added |
|
2007-11-15
|
10 | (System) | Ballot approval text was added |
|
2007-11-07
|
10 | Jon Peterson | State Changes to AD Evaluation from Publication Requested by Jon Peterson |
|
2007-09-27
|
10 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, … PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner (marc.linsner@cisco.com). The document is ready for publication and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The LoST specification has experienced extensive review, including reviews by other SDOs. The work has been presented to other organizations working in the area of emergency services at different meetings, including two emergency services workshops (see http://www.emergency-services-coordination.info/) and other smaller information sharing events with the 3GPP and the IEEE. The protocol is also an important building block in the NENA i3 architecture and reviews have been provided by NENA members. Two WGLCs were issued, on 14 February 2007 and on 15 August 2007. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. A few working group members raised issues with the usage of the Relax NG schema (instead of an XML schema). Tool support for XML schemas is better than with Relax NG. Two IPR claims have recently been announced. Active participants in the working group are authors of patent filings, but not the authors of this document. One WG participant raised the following concern, "the timing of the disclosure doesn't appear to meet the spirit of Section 6.2 of RFC 3979, possibly opening us up to the ramifications of Section 7 (whatever those may be)." (see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04191.html) (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? There is solid consensus behind this document. Section 19 extensively lists the reviewers. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into a normative and informative references. There are no downrefs. There are, however, references to documents that were published outside the IETF, namely reference [11] and [12]. These documents refer to XML-based location formats developed by the OGC. A few other dependencies to unfinished documents exist: * draft-ietf-ecrit-service-urn-06: This document is in 'Approved-announcement to be sent' state. * draft-ietf-geopriv-revised-civic-lo-05: This document is in 'Publication Requested' state. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists and is consistent with the rest of the document. The document was sent to the URI review team in February 2007. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. The schema and the instance document have been validated. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for draft-ietf-ecrit-lost-06.txt Technical Summary This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Working Group Summary There is consensus in the WG to publish this document. Document Quality The LoST protocol has been implemented during the development of the specification. Two public implementations are available and other company-internal implementations have been reported to the chairs. Tests have been performed between two public implementations and useful feedback was provided to the working group. The LoST specification has experienced extensive review, including reviews by other SDOs. The protocol is an important building block in the NENA i3 architecture. Two WGLCs were issued, on 14 February 2007 and on 15 August 2007. Personnel Marc Linsner is the document shepherd for this document. The document was sent to the URI review team in February 2007. |
|
2007-09-27
|
10 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2007-08-22
|
(System) | Posted related IPR disclosure: Cisco's Statement about IPR claimed in draft-ietf-ecrit-lost-06.txt | |
|
2007-08-13
|
06 | (System) | New version available: draft-ietf-ecrit-lost-06.txt |
|
2007-08-09
|
(System) | Posted related IPR disclosure: Cisco's Statement about IPR claimed in draft-ietf-ecrit-lost-06.txt | |
|
2007-03-07
|
05 | (System) | New version available: draft-ietf-ecrit-lost-05.txt |
|
2007-02-13
|
04 | (System) | New version available: draft-ietf-ecrit-lost-04.txt |
|
2007-01-18
|
03 | (System) | New version available: draft-ietf-ecrit-lost-03.txt |
|
2006-10-24
|
02 | (System) | New version available: draft-ietf-ecrit-lost-02.txt |
|
2006-09-06
|
01 | (System) | New version available: draft-ietf-ecrit-lost-01.txt |
|
2006-06-20
|
00 | (System) | New version available: draft-ietf-ecrit-lost-00.txt |