Skip to main content

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 …
[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
to line up well with RFC 2818, I'm not at all convinced that the
requirements of RFC 3205 are met.
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