요약

  • 활성 상태인 ECRIT 드래프트는 LoST에 순서화된 계획 변경 폴링, 미래 날짜의asOf검증,revalidateAfter권고를 추가합니다. 이 메커니즘은 변경될 수 있는 기록을 식별하고 클라이언트가 유효 시점 이전에 대체 기록을 준비할 수 있게 합니다.
  • 드래프트는 서로 다른 시점에 수행된 동일한 미래 날짜 질의가 서로 다른 답변을 반환할 수 있음을 명시합니다. 미래 응답은 서버가 현재 알고 있는 것을 반영할 뿐이며, 이후의 매핑을 보장하지도, 클라이언트가 그것을 설치했다는 증거도 되지 않습니다.
  • 2단계 검증 영수증은 준비와 전환(cutover)을 별개의 관찰로 유지해야 합니다. 이는 Daniel Kade의 편집 제안이며, IETF의 요구사항도 아니고 배포의 증거도 아닙니다.

자정은 지면이 아니라 기록을 바꾼다

새 달의 첫 분에 한 지구가 한 자치체에 흡수되는 상황을 상상해 보십시오. 건물은 이동하지 않습니다. 위도도 뛰지 않습니다. 그러나 어제 비어 있거나 다른 값을 갖고 있던 행정 주소 요소 하나가 오늘은 자치체 이름을 갖도록 바뀌어야 할 수 있습니다. 도로명 변경이나 주소 재부여도 물리적 연속성과 행정적 변경 사이에 같은 분열을 만들 수 있습니다.

이것이Validation of Locations Around a Planned Change의 실용적인 출발점입니다. 제18개정판은 IETF의 Emergency Context Resolution with Internet Technologies 워킹 그룹의 활성 인터넷 드래프트입니다. 이는 진행 중인 작업이며, RFC도 아니고 어떤 운영자가 이 설계를 배포했다는 증거도 아닙니다.

기반 프로토콜인RFC 5222는 LoST를 정의합니다. 클라이언트가 위치 정보와 서비스 식별자를 제공하면, 서버는 서비스 URI와 관련 정보를 반환합니다. LoST는 행정 위치(civic location)를 검증할 수도 있습니다. 응답은 어떤 주소 요소가 유효하다고 인식되었는지, 무시되었는지, 무효로 판명되었는지를 말할 수 있습니다.RFC 5139는 드래프트 예제에 사용된 행정 위치 어휘를 제공합니다.

Location Information Server는 이런 기록을 다수 보유할 수 있습니다. 임박한 행정 변경에 대한 사전 통지가 없다면, 일정한 주기로 데이터베이스를 재검증하는 방법 외에는 드리프트를 발견할 방법이 없습니다. 그 일정은 전환에는 너무 느리고, 그 전에는 불필요하게 비쌀 수 있습니다. 이에 따라 이 드래프트는 LoST 서버에게 자신이 현재 변경될 것으로 예상하는 내용과 시점을 좁게 기술할 방법을 부여합니다.

거버넌스 문제는 계획이 바람직한지가 아닙니다. 문제는 그 결과로 얻어진 증거가 정직하게 무엇을 증명할 수 있는가입니다. 금요일에 변경될 것으로 예상되는 경계에 대비해 월요일에 준비된 기록은, 질의가 금요일을 물으면서도, 월요일의 지식에 속합니다.

드래프트는 서로 다른 세 개의 시계를 만든다

첫 번째 시계는 계획 변경 피드의 것입니다. 별도의 REST/JSON 인터페이스가 버전 발견, 폴링, ChangeSet 검색을 노출합니다. ChangeSet은 순서화된 식별자, 유효 시점, 하나 이상의 부분 위치를 갖습니다. 클라이언트는 마지막으로 받은 식별자를 유지하고 그 이후의 변경을 요청합니다. 이 시퀀스는 클라이언트에게 하나의 서버가 발행한 스트림 내의 위치를 제공합니다.

두 번째 시계는asOf의 것입니다. 클라이언트는 LoST에 명시된 미래의 날짜와 시각에 대해 기록을 검증하도록 요청할 수 있습니다. 서버는 질의 시점에 그 미래 시점까지 유효할 것으로 알고 있는 내용으로 답합니다. 답변이 현재 시각에 대한 것이 아니면, 응답은asOf를 반드시 반향(echo)해야 하고, 그 매핑은NO-CACHE로 표시되어야 합니다.

세 번째 시계는 일반 재검증의 것입니다. 제안된revalidateAfter요소는 서버가 클라이언트가 언제 다시 확인하길 원할지 권고할 수 있게 합니다. 그NO-EXPIRATION값은 신중하게 한정되어 있습니다. 서버가 현재 검증에 영향을 줄 계획된 변경을 인지하지 못한다는 뜻일 뿐입니다. 나중에 변경이 알려질 가능성을 배제하지 않으며, 계획되지 않은 사건에 대한 주기적 재검증도 폐지하지 않습니다.

이 시계들은 서로 다른 질문에 답합니다. 폴링은 "내 유지된 위치 이후에 이 서버는 어떤 더 새로운 변경 통지를 알고 있는가?"라고 묻습니다. 미래 질의는 "이 서버가 지금 알고 있는 것에 비추어, 그 시점에 이 기록을 어떻게 검증할 것인가?"라고 묻습니다. 재검증 권고는 "언제 다시 물어봐야 하나?"라고 묻습니다. 어느 것도 "미래 사건이 계획대로 정확히 발생했고 모든 하류 시스템이 새 상태를 채택했다"라고 말하지 않습니다.

이 시계들을 하나의 초록 상태로 납작하게 눌러 넣으면, 드래프트가 보존하려는 그 불확실성 자체를 버리게 됩니다. 권위도 옮겨갑니다. 계획된 위치 데이터를 발행하는 서버가, 한 번도 관찰한 적 없는 클라이언트의 데이터베이스 실행을 인증하는 것처럼 보이게 됩니다.

ChangeSet은 선택자이지 판정이 아니다

계획된 변경이 유용하려면 서버가 모든 전체 주소를 열거해야 할 필요가 없어야 합니다. 그래서 드래프트는 부분 위치를 정의합니다. 위치 요소 이름, 네임스페이스, 값의 집합입니다. 클라이언트는 그 쌍들을 자신의 기록과 비교합니다. 제공된 쌍이 모두 일치하면, 그 클라이언트 기록은 영향을 받을 수 있습니다. 부분 위치에서 생략된 필드는 비교에 참여하지 않습니다.

이것은 의도적으로 폭넓습니다. 하나의 선택자는 도로명과 건물 번호에 관계없이 행정 구역 전체를 식별할 수도 있고, 건물 번호에 관계없이 한 도로를 식별할 수도 있습니다. 이는 미래의 경계 사건을 다룰 수 있는 국소 검색으로 바꿉니다.

그러나 "영향을 받을 수 있다"는 표현은 부실한 작초의 우연이 아닙니다. 이는 정확한 증거 경계입니다. 일치가 모든 선택된 기록이 반드시 바뀌어야 한다는 것을 증명하지는 않습니다. 클라이언트가 올바른 대체 기록을 만들었다는 것도 증명하지 않으며, 미래 검증 답변이 안정적으로 유지될 것이라는 것도, 대체 기록이 유효 시점에 활성 데이터베이스에 도달했다는 것도 증명하지 않습니다.

따라서 운영자는 선택의 양쪽 면을 모두 보존해야 합니다. 서버 측에는 ChangeSet ID, 유효 시점, 부분 위치 쌍, 인터페이스 버전. 클라이언트 측에는 매칭 규칙, 데이터베이스 스냅샷, 후보 기록의 수와 식별자, 제외 항목, 운영자가 승인한 예외. 클라이언트가 "432개 위치 영향"만 기록한다면, 나중의 검토자는 수정된 도로 값이 집합을 좁혔는지, 스키마 해석이 넓혔는지, 데이터베이스 필터가 어떤 지역을 조용히 빠뜨렸는지 판단할 수 없습니다.

이것은 얇은 조율(thin coordination)에서 익숙한 구분입니다. 공유 형식은 참여자들이 상호운용하기 위해 필요한 최소한의 정보를 전송해야 합니다. 모든 국소적 결과를 결정하는 척해서는 안 됩니다. Lu Heng의Minimum Initial Specification원칙이 여기서 유용합니다. 공통 계층은 순서화된 통지와 결정적(deterministic) 필드를 운반하되, 각 운영자는 자신의 활성화 결정과 증거에 대한 책임을 유지합니다.

미래 답변은 의도적으로 수정 가능하다

드래프트 제4절은 이 한계를 직접 밝힙니다. 서버는 언제라도 계획된 또는 계획되지 않은 변경을 알게 될 수 있습니다. 따라서 같은 미래asOf값으로 서로 다른 날짜에 수행된 두 요청은 서로 다른 결과를 낼 수 있습니다. 서버는 같은 위치에 대한 이후 질의에 대해 어떤 보장도 하지 않습니다.

이것은 더 강한 문구로 고쳐야 할 결함이 아닙니다. 시간에 걸친 지식에 대한 정직한 서술입니다. 자치체의 결정은 연기될 수 있습니다. 도로 계획은 정정될 수 있습니다. 데이터셋은 늦게 도착할 수 있습니다. 원래 변경보다 다른 변경이 먼저 효력을 발생할 수도 있습니다. 미래 답변을 수정할 수 없는 서버는 초기 정보를 철회 불가능한 약속으로 바꿔버립니다.

NO-CACHE요구사항은 같은 경계를 프로토콜 수준에서 보호합니다. 미래 매핑이 내구성 있는 라우팅 상태처럼 다뤄지는 것을 막습니다. 드래프트는 또한 서비스에 실제로 연락하고자 하는 클라이언트가 그 필요와 동시적으로 LoST를 사용해야 한다고 말합니다. 기록을 준비하는 행위와 현재 적절한 서비스를 해석(resolve)하는 행위는 같지 않습니다.

이 구분이 가장 중요한 이유는 ECRIT이 관련 긴급 대응 센터와의 통신을 지원하는 시스템을 다루기 때문입니다.워킹 그룹 헌장도 하나의 중앙 권위가 아니라 여러 지역, 관할권, 독립된 위임을 예상합니다. 따라서 깨끗한 증거 사슬은 두 가지 과잉 주장을 동시에 피해야 합니다. 위치 검증이 긴급 통신의 완료를 증명하는 것도 아니고, 서버의 계획 상태가 독립적으로 운영되는 모든 클라이언트의 채택을 증명하는 것도 아닙니다.

좋은 보도는 Lu Heng의현실 대 연파(reality-not-advocacy) 규율을 따릅니다. 존재하는 질의, 응답, 시간 경계를 기술하십시오. 미래 버전이 행정적으로 편리하다는 이유로意도된 상태를 완료된 사건으로 승격시키지 마십시오.

폴링 위치는 잃어버릴 수 있다

계획 변경 폴링은 빈번한 사용을 위해 설계되었습니다. 클라이언트는 통상 마지막 ChangeSet ID를 유지하고 그 이후의 모든 것을 요청합니다. 빈 응답은 유지된 ID가 서버가 현재 알고 있는 최신 변경이라는 뜻입니다. 이는 유용한 연속성 서술이지만 그 범위는 좁습니다.

새 클라이언트, 또는 마지막 ID를 잃은 클라이언트는 ID 없이 폴링하여 서버가 여전히 알고 있는 모든 ChangeSet을 받을 수 있습니다. "여전히"라는 말이 중요합니다. 드래프트는 무기한 보존을 요구하지 않습니다. 서버가 바쁜 지역에서는 3개월, 한산한 지역에서는 12개월 동안 오래된 ChangeSet을 유지할 수 있다는 예를 제시합니다. 늦은 클라이언트는 그 창 밖으로 벗어날 수 있습니다.

따라서 시스템에는 명시적인 재동기화 상태가 필요합니다. 위치를 잃은 클라이언트는 가장 오래된 보존 ChangeSet을 조용히 역사의 시작으로 취급해서는 안 됩니다. 격차를 기록하고, 완전한 현재 검증 또는 다른 유한한 기준선을 얻고, 새로운 에포크를 확립해야 합니다. 그렇지 않으면 완벽하게 순서화된 스트림도 불완전한 국소 역사를 만들 수 있습니다.

빈 폴링 역시 과잉 해석하기 쉽습니다. 계획되지 않은 변경이 발생하지 않았다는 증거가 아니며, 이전 ChangeSet이 처리되었다는 증거도 아니고, 국소 후보 기록들이 대체되었다는 증거도 아닙니다. 클라이언트가 제공한 ID와 서버의 현재 목록 사이의 관계만을 증명합니다.

이것이 Lu Heng의Policy Mirror에서 말하는 대장(ledger)과 왕좌의 차이입니다. 서버의 기록은 그것이 수행하는 기능에 대한 존중을 받아야 합니다. 그것이 관찰하지 않은 사실들에 대한 주권으로 만들어져서는 안 됩니다.

2단계 검증 영수증을 만들라

유용한 구현은 프로토콜에게 국소 운영을 통제하라고 요구하지 않고도 준비를 감사 가능하게 만들 수 있습니다. 기록은 연결되어 있으나 분리된 두 개의 관찰이 필요합니다.

준비 관찰은 다음을 보존해야 합니다.

  1. LoST 서버와 계획 변경 인터페이스 버전;
  2. 폴링 시각, 이전 ChangeSet ID, 반환된 순서화 ID 목록;
  3. ChangeSet 유효 시점과 정확한 부분 위치 선택자;
  4. 국소 데이터베이스 스냅샷, 매칭 규칙, 후보 수, 예외;
  5. 검증에 제공된 위치와 서비스, 미래asOf시각, 서버의 답변;
  6. revalidateAfter, 캐시 상태, 원천 문서 개정판, 사용된 시계; 그리고
  7. 계획된 대체 기록, 승인 상태, 롤백 준비.

전환 관찰은 다음을 보존해야 합니다.

  1. 국소 운영자가 실제로 인식한 유효 시점;
  2. 오래된 기록이 비활성화되고 대체 기록이 활성화된 시점;
  3. 동시적 검증 결과와 준비 답변과의 차이;
  4. 서비스가 실제로 필요할 때 사용된 현재 LoST 조회;
  5. 실패, 연기, 대체됨, 수동으로 처리된 기록;
  6. 롤백 또는 예외 상태; 그리고
  7. 변경을 종결한 책임 시스템 또는 담당자.

"2단계 검증 영수증"은 여기서 사용된 편집 용어이며, 드래프트의 요구사항이 아닙니다. 전체가 공개될 필요는 없습니다. 위치 데이터베이스는 민감한 운영 데이터를 포함할 수 있습니다. 공개 뷰는 집계 수, 시간 창, ChangeSet 참조, 완료 상태, 미해결 예외를 노출할 수 있고, 보호 뷰는 기록 수준의 증거를 유지합니다. 다이제스트가 두 뷰를 결합할 수 있지만, 어떤 다이제스트도 근본적인 결정이 올바르다는 것을 증명하지는 않습니다.

중요한 설계 선택은 준비가 관찰을 덮어쓰지 않는다는 것입니다. 금요일의 답변이 월요일과 다르면, 양쪽 모두 그대로 남아 있어야 합니다. 그 차이는 단순한 오류 수가 아니라, 기관의 지식이 어떻게 바뀌었는지에 대한 역사입니다.

재검증 권고는 비용을 배분한다

검증 사이의 간격은 잡무가 아닙니다. 그것은 낡은 데이터의 리스크와 질의의 비용을 배분합니다. 드래프트는 안정적이고 완전히 구축된 지역은 6개월 이상의 기간을, 빠르게 성장하는 지역은 20~30일을 정당화할 수 있다고 언급합니다. 이것들은 예시적 판단이지 보편적 서비스 수준이 아닙니다.

서버는 불필요한 부하를 피하려는 유인이 있습니다. 클라이언트는 낡은 기록을 피하려는 유인이 있습니다. 공공 안전 운영자는 다른 LoST 소비자보다 모호성에 대해 더 엄격한 허용도를 가질 수 있습니다. 많은 기록을 운영하는 조직은 대상화된 ChangeSet을 선호할 수 있고, 작은 클라이언트는 주기적 전체 검증을 부담 가능한 것으로 여길 수 있습니다.revalidateAfter는 서버가 클라이언트의 리스크 결정을 대신하지 않고 권고할 수 있게 합니다.

따라서 영수증은 최종 간격을 누가 수용했고 왜 그랬는지를 기록해야 합니다. 서버 권고와 국소 재정의를, 긴급 재검증과 일반 스케줄링을,NO-EXPIRATION과 영구성의 약속을 구분해야 합니다. 클라이언트가 비용을 줄이기 위해 간격을 늘린다면 그것은 국소적 결정입니다. 폴링이나 검증이 서버에 부담이 되도록 공격적으로 간격을 줄인다면, 그것에도 책임 주체가 있습니다.

드래프트의 보안 절은 과도한 폴링이 다른 LoST 처리를 저해할 수 있다고 언급합니다. 가용성과 신선함은 용량과 결합되어 있습니다. 한쪽을 무시하는 간격 정책은 다른 쪽을 거짓으로 만들 수 있습니다.

증거가 말할 수 있는 것과 없는 것

완전한 준비 영수증은 한 클라이언트가 한 서버로부터 특정 계획 변경 기록을 얻었고, 정의된 데이터베이스 스냅샷과 대조했으며, 명시된 시각에 명시된 미래 검증 답변을 받았다는 것을 증명할 수 있습니다. 대체 기록이 발표된 유효 시점 이전에 준비 완료되었다는 것을 보여줄 수 있습니다.

완전한 전환 영수증은 클라이언트가 이후 무엇을 활성화했는지, 동시적 검증이 무엇을 반환했는지, 예외가 남아 있었는지를 보여줄 수 있습니다. 그러나 두 기록을 합쳐도, 모든 가능한 LoST 서버가 동일한 데이터를 갖고 있었다는 것, 행정 당국의 근본 법률 행위가 유효했다는 것, 서비스 매핑이 이후 변하지 않았다는 것, 긴급 통신이 대응자에게 도달했다는 것을 증명하지 않습니다.

이는 기록을 폐기할 이유가 아닙니다. 각 주장을 그것을 뒷받침하는 관찰로 레이블해야 하는 이유입니다. 행정 당국이 경계를 변경합니다. LoST 서버는 자신의 역할 내에서 위치와 서비스 데이터를 표현합니다. 클라이언트는 국소 기록을 선택하고 활성화합니다. 동시적 질의는 현재 매핑을 반환합니다. 통신 시스템은 전달을 시도합니다. 각 동사는 서로 다른 증인을 가집니다.

드래프트의 강점은 그 동사들을 하나로 접어버리지 않는다는 점입니다. 사전 준비를 허용하면서도 미래 답변이 수정 가능하도록 요구합니다. 거버넌스는 그 겸손함을 대시보드, 감사, 공개 주장까지 끝까지 보존해야 합니다.

출처