요약

  • 2026년 8월 27일 기준, DAWN은Proposed(제안) 상태의 그룹이었습니다. 그00-00헌장은 IESG/IAB 내부 검토 중이었고, 투표는 이 텍스트가 외부 검토로 넘어갈 준비가 되었는지 여부만을 물었습니다.
  • NETCONF는 이미Active(활동 중) 상태였지만,20-02는 제안된 재헌장이었습니다. Datatracker는 버전 20이 현재 승인된 헌장임을 명시적으로 밝히고 있었습니다.
  • RFC 2418은 승인된 헌장을 특정 과제 집합에 대한 경계가 있는 제도적 계약으로 규정합니다. 초안 작성, 내부 검토, 커뮤니티 검토, IESG 승인, 사무국 공지는 서로 별개의 행위입니다.
  • 승인된 헌장조차 특정 인터넷 초안, 기술적 결론, RFC 또는 운영 배포가 아니라 문제 공간을 승인하는 것입니다.

하나의latest포인터는 두 방향으로 모두 실패할 수 있다

텍스트 개정과 제도적 효력은 서로 다른 시계를 따릅니다. diff는 어떤 문장이 화요일에 추가되었다는 사실은 보여줄 수 있습니다. 그러나 그 문장을 승인할 권한이 있는 기구가 화요일에 행동했는지, 승인된 텍스트가 그 시점에 효력을 발생했는지는 보여줄 수 없습니다.

이 구분은 신규 설립과 재헌장에서 다르게 작동합니다. 초기 헌장이 승인되기 전에는 갱신할 워킹 그룹 권한 자체가 없습니다. 올바른 현재 헌장 값은 제안서가 아니라 명시적으로 비어 있음입니다. 재헌장 중에는 이미 기구와 승인된 범위가 존재합니다. 올바른 현재 헌장 값은 기록된 결정이 이를 대체할 때까지 이전 승인 버전에 머뭅니다.

따라서 최신 문서만 보관하는 서비스는 같은 규칙으로 정반대의 오류를 저지릅니다. 아직 형성되지 않은 그룹에 위임을 만들어내는 한편, 이미 활동 중인 그룹에 대한 제한을 조기에 철회합니다. 신뢰할 수 있는 레지스트리는latest proposal과current approved charter라는 두 개의 독립 참조를 필요로 합니다.

이것은 행정적 정돈의 문제가 아닙니다. 제안된 범위가 현재 상태처럼 제시되면, 회의는 그것에 주의를 배분하기 시작합니다. 개인 제안물이 워킹 그룹 방향의 외양을 갖게 됩니다. 인접 그룹과 다른 표준화 기구는 양보합니다. 제품 팀은 예상되는 IETF 작업을 이미 확정된 것처럼 서술합니다. 나중의 개정은 페이지를 고칠 수 있지만, 조기 발표를 둘러싸고 이미 구축된 코드, 조달 문구, 조직적 기대를 회수할 수는 없습니다.

DAWN에는 검토 가능한 제안이 있었지, 승인된 그룹은 없었다

관찰일 기준DAWN 그룹 페이지에는 “Proposed WG Discovery of Agents With Names”라는 제목이 걸려 있었습니다. 상태는Proposed, 헌장은charter-ietf-dawn-00-00, 절차 상태는Start Chartering/Rechartering (Internal Steering Group/IAB Review)였습니다.

텍스트는 상당한 분량이었습니다. AI 에이전트와 자원의 발견을 다루고, 로컬·조직 내·조직 간 설정을 구분하며, 가능한 메커니즘을 식별하고, 제안된 의장을 지명하고, 산출물과 일정을 정하며, 신원·신뢰·인터넷 전역 색인 관련 여러 질문을 초기 범위에서 제외했습니다. 상세함은 이 제안을 검토 가능하게 만들었습니다. 상세함이 효력을 만든 것은 아닙니다.

헌장 투표는 질문의 형태로 가장 중요한 한정어를 제공했습니다: “이 헌장은 외부 검토를 위한 준비가 되어 있는가?” Éric Vyncke는Yes를 기록했습니다. Mohamed Boucadair는Block을 기록했습니다. 나열된 다른 멤버들은No Record로 표시되었고, 요약은 Block이 해결되면 이 단계를 통과할 만한 충분한 의견이 제출되었다고 밝혔습니다.

Boucadair의 코멘트는 작업 수행 자체는 지지하면서 더 선명한 경계를 요구하는 것이었습니다. 그는 발견의 트리거와 운영 모델, 로컬 사례와 조직 간 사례의 차이, 관련된 신뢰 장치, 하나의 프로토콜이 명시된 환경들을 합리적으로 커버할 수 있는지를 문제 삼았습니다. 이는 검토 중인 범위 이의의 근거입니다. DAWN에 대한 최종 거부도, 영구적 개인 거부권의 증거도 아닙니다.

Yes역시 똑같이 좁게 유지해야 합니다. 투표 질문을 지우면 “더 넓은 검토에 노출할 준비가 됨”이 “운영 승인됨”으로 바뀝니다.DAWN 이력은 8월 24일00-00텍스트와 투표 생성, 내부 검토 진입을, 이어서 8월 25일 Block을 기록합니다. 최종 설립은 기록되어 있지 않습니다.

7월의IETF 126 BoF 안건표도 이 구분을 뒷받침합니다. 참여자들은 이미 용어, 사용 사례, 요구사항, 후보 헌장을 발전시켜 왔습니다. BoF는 문제와 커뮤니티가 존재할 수 있다는 근거를 제공했습니다. 그러나 방 안의 사람들에게 IESG의 설립 결정을 이양하지는 않았습니다.

DAWN은 이후 승인되거나, 개정되거나, 반송되거나, 중단될 수 있습니다. 이 글은 어느 결과도 예측하지 않습니다. 미래의 승인은 귀속 가능한 효력 시점부터 권한을 만들 수 있습니다. 준비 기간을 소급하여 승인된 워킹 그룹 활동으로 만들 수는 없습니다.

NETCONF는 검토 기간 동안 승인된 경계를 유지했다

NETCONF는 이 경계선의 반대편에서 시작했습니다.워킹 그룹 페이지는 NETCONF, RESTCONF, YANG, 네트워크 관리를 둘러싼 확립된 영역과 함께 이 그룹을Active로 식별했습니다.

헌장 페이지는 8월 12일 마지막 갱신된charter-ietf-netconf-20-02를 재헌장 행위로서 내부 검토 중으로 표시했습니다. 결정적인 문장도 인쇄되어 있었습니다: 표시된 정보는 제안된 재헌장을 위한 것이며, 현재 승인된 헌장은버전 20이라는 것.

따라서 세 개의 개체가 공존했습니다. NETCONF는 활동 중인 제도적 컨테이너였습니다. 버전 20은 그 현재 승인된 범위였습니다.20-02는 그 범위의 변경을 요청하는 것이었습니다. 요청을 검토하는 것이 구헌장을 정지시키지 않았고, 더 최신 개정을 공표하는 것이 추가 사항에 정상적인 워킹 그룹 지위를 부여하지도 않았습니다.

NETCONF 투표는 외부 검토 준비성에 관한 같은 제한된 질문을 던졌습니다. Christopher Inacio는 마일스톤이 없다는 이유로 Block을 유지했습니다. Mahesh Jethanandani는Yes를 기록했고, 여러 멤버가No Objection을 기록했으며, 요약은 Block이 해결되면 투표를 통과할 수 있다고 밝혔습니다. 그 어떤 사실도 그날 유효한 헌장이 무엇인지 바꾸지 않았습니다.

IESG가 변경을 요청하면 이후의 제안이 실제 후보가 될 수 있습니다. 노력이 철회되면 버전 20은 계속됩니다. 새 헌장이 승인되면 결정과 공지가 최종 텍스트, 대체되는 버전, 효력 시점을 식별할 수 있습니다. 어떤 결과도20-02가 공표 시점에 그룹에 대해 법이 된 것처럼 가장할 필요를 만들지 않습니다.

조기 교체는 입증 부담도 뒤집습니다. 승인 전에는 제안자가 추가 작업이 NETCONF에 속하는 이유를 보여야 합니다. 그러나 회의, 채택 호출, 구현이 그림자 범위 아래에서 쌓이고 나면, 검토자는 한 번도 부여된 적 없는 권한을 “빼앗는” 행위를 정당화해야 하는 압박을 받습니다. 신청의 검토가 매몰비용의 추인이 됩니다.

RFC 2418은 결정권자를 지정한다; 참여를 지우지 않는다

관찰일의 공개 기준은 여전히RFC 2418, 즉 BCP 25의 일부였습니다. RFC 2418은 워킹 그룹을 IETF가 명세와 가이던스를 개발하는 주요 메커니즘으로, 통상 특정 문제와 산출물 집합을 중심으로 구성된다고 기술합니다.

제안된 의장과 관련 Area Director가 통상적으로 헌장을 협상합니다. IAB는 조언을 제공하고, IESG가 최종 승인을 내립니다. 내부 검토 이후 제안 텍스트는 더 넓은 커뮤니티 검토에 노출됩니다. IESG는 이를 승인하거나, 변경하거나, 그룹 설립을 거절할 수 있습니다. 승인 이후 사무국이 그룹을 기록하고 공지합니다.

RFC 2418은 헌장을 IETF와 워킹 그룹 사이, 과제 집합에 대한 계약이라고 부릅니다. 여기서 “계약”은 상업적 합의, 조약, 기술 영향을 받는 모든 사람으로부터의 정치적 위임이 아니라 제도적인 업무 배분입니다. 이것은 공개 포럼, 절차적 관리, 경계가 있는 범위를 하나로 묶습니다.

이 경계에는 운영적 결과가 있습니다. 의장은 범위 외 입력을 지연시키면서 개방성과 진행을 유지할 수 있습니다. Area Director는 전제나 과제가 바뀔 때 재헌장, 리더십 교체, 폐쇄를 추진할 수 있습니다. 인접 그룹은 중복을 식별할 수 있습니다. 다른 표준화 기구는 liaison이 필요한지 판단할 수 있습니다. 잠재 기여자는 어디에 노력을 투입할지 결정할 수 있습니다.

RFC 3710은 역할 분배를 명확히 합니다. 이니셔티브는 참여자나 Area Director에서 시작될 수 있습니다. 예비 의장은 실현 가능한 계획을 만듭니다. 참여자는 전문성, 관심, 이의를 보여줍니다. IAB는 아키텍처적 함의를 검토합니다. 더 넓은 검토는 개인정보, 보안, 운영, 관할 결과를 드러냅니다. Area Director는 이러한 접점을 조율합니다. IESG는 제도적 결정의 책임을 집니다.

참여가 승인이 아니라고 말하는 것이 검토를 의례화하는 것은 아닙니다. 강한 이의는 제안 범위를 바꾸거나, liaison을 추가하거나, 산출물을 분할하거나, 그룹이 준비되지 않았음을 보여줄 수 있습니다. 검토는 결정권자에게 근거를 제공하고 공개 기록을 남깁니다. 참석 자체가 위임을 만들지 않는다는 것을 전제로 결정에 정보를 공급하기 때문에 가치 있는 것입니다.

포럼의 승인은 답의 승인이 아니다

헌장은 워킹 그룹이 어떤 질문을 조직할 수 있는지를 정합니다. 그룹이 시작되기 전에 기술적 답을 선택하지는 않습니다.

절차는 여러 독립 단계로 이루어집니다. 탐색은 개인 초안을 만들 수 있습니다. 승인된 헌장은 워킹 그룹 컨테이너를 만들 수 있습니다. 워킹 그룹은 모든 내용에 동의하지 않고서도 하나의 인터넷 초안을 작업 기반으로 채택할 수 있습니다. 러프 컨센서스와 워킹 그룹 라스트 콜은 이후의 판단입니다. IESG 평가는 또 다른 행위입니다. RFC 공표는 문서에 안정된 식별자를 부여하며, 스트림과 카테고리가 그 RFC의 실제 지위를 결정합니다.

배포는 그보다 더 멉니다.RFC 3935는 IETF가 유용한 엔지니어링 문서를 개발하지만 인터넷 전역에서 그 사용을 강제할 수 없다고 기술합니다. 운영자에게는 여전히 선택된 버전, 책임 있는 소유자, 테스트 근거, 변경 범위, 롤백 조건, 운영 중인 시스템으로부터의 관찰이 필요합니다.

이 구분은 RFC 2418의 제안된 후속 문서에서도 확인됩니다.draft-ietf-procon-2418bis-04는 8월 27일 기준 활성 PROCON WG Document였으며, IESG 상태는I-D Exists였습니다. 문서 머리말은 승인될 경우 RFC 2418과 RFC 3934를 폐기(obsolete)하게 된다고 명시합니다. 그 조건 자체가 사실의 일부입니다.

초안 텍스트는 헌장을 범위에 대한 커밋이라고 기술하고, 인터넷 초안의 채택은 그 내용에 대한 합의를 보여주는 것이 아니라 작업 기반이 되는 것임을 명시합니다.PROCON 헌장은 명명된 프로세스 RFC 계열의 통합을 승인하며, 재헌장 없이는 다른 실질적 작업을 제한합니다. 후속 문서를 개발할 권한은 후속 문서를 사전에 승인하지 않습니다.

RFC 9281은 표준화 과정에 관여하는 별개의 주체들을 매핑합니다. 내구성 있는 거버넌스 기록은 그 분리를 “IETF”라는 배지 하나로 압축하는 대신 보존해야 합니다.

인계에는 접수증이 필요하다

신뢰할 수 있는 헌장 기록은 먼저 행위를 명명해야 합니다:INITIAL_CHARTER또는RECHARTER. 그룹 상태, 제안 식별자, 개정, 정확한 텍스트 지문을 저장해야 합니다. 별도 필드는 현재 승인된 헌장과 그 지문을 담거나, 아직 설립되지 않은 그룹에 대해 명시적 null을 담아야 합니다.

범위 기록은 추가, 제거, 유지되는 작업, 제외 항목, 산출물, 인접 그룹, 외부 조율을 식별해야 합니다. 검토 기록은 담당 Area Director, 제안 또는 현 의장, 시작일, 정확한 투표 질문, 모든 의견, 각 Block과 그 해결, IAB 조언, 외부 검토 공지, 실질적 코멘트의 처리를 보존해야 합니다.

결정 기록은 IESG 결과, 공개 이유, 날짜, 사무국 공지, 효력 시점, 대체된 구헌장을 식별해야 합니다. 승인, 변경을 위한 반송, 구헌장 하의 지속, 철회, 거절, 해산은 모두 명시적 상태를 필요로 합니다.

각 승인된 헌장은 두 개의 부정적 진단을 수반해야 합니다: 특정 문서에 대한 합의를 보여주지 않으며, 구현이나 배포를 명령하지 않는다는 것. 이 한도는 헌장을 약화시키지 않습니다. 실제 권한을 과장 없이 이동 가능하게 만듭니다.

출처

  1. IETF Datatracker: 현재 헌장화 또는 재헌장 중인 그룹
  2. IETF Datatracker: 제안된 DAWN 워킹 그룹
  3. IETF Datatracker: DAWN 헌장 투표
  4. IETF Datatracker: DAWN 헌장 이력
  5. IETF Datatracker: IETF 126 DAWN BoF 안건표
  6. IETF Datatracker: NETCONF 제안 재헌장
  7. IETF Datatracker: 승인된 NETCONF 헌장 버전 20
  8. IETF Datatracker: 활동 중인 NETCONF 워킹 그룹
  9. IETF Datatracker: NETCONF 헌장 투표
  10. RFC 2418: IETF 워킹 그룹 지침 및 절차
  11. RFC 3710: IESG 헌장
  12. RFC 6292: 워킹 그룹 헌장 도구 요구사항
  13. IETF Datatracker: draft-ietf-procon-2418bis 상태
  14. IETF Datatracker: draft-ietf-procon-2418bis 텍스트
  15. IETF Datatracker: PROCON 워킹 그룹 헌장
  16. RFC 3935: IETF 미션 선언문
  17. RFC 9281: IETF 표준화 과정에 관여하는 주체들