SNMP - RowStatus 표준 분석 (rfc 2579)

본 글은  RFC 2579 Textual Conventions for SMIv2 표준에 기술된 RowStatus에 대해 정리한 글입니다.

 

용어 정의

• 열 요구사항 : 개념적 행 생성을 위한 "SET" 프로토콜 동작 수행 시, 값이 반드시 제공되어야 하는 열 객체들
  • 해당 열 객체들 모두에 대한 값이 설정되지 않으면 개념적 행이 생성될 수 없다.
• 필요 열 : 개념적 행 생성을 위한 "SET" 프로토콜 동작 수행 시, 값이 반드시 제공되어야 하는 열 객체
  • 해당 열 객체에 대한 값이 설정되지 않으면 개념적 행이 생성될 수 없다.
• MIB 모듈 : 원하는 특정 MIB 를 정의한 것 (즉, ASN.1 파일에 정의된 내용이라고 보면 된다)

 

RowStatus 정의

개념

RowStatus textual convention은 개념적 행(Conceptual row) 정보를 생성하고 삭제하는데 사용된다.

 

가질 수 있는 값

RowStatus 유형으로 정의된 status 열 객체는 다음 6가지 값 중 하나의 값을 가진다.

(번역자 주) RowStatus는 다음 6가지 값을 통해 개념적 행의 상태 또는 요청유형을 표현하며, 해당 값은 실제로 INTEGER 유형의 값이다.

• active
  • 해당 개념적 행이 피관리장치에 의해 가용한 상태임을 나타낸다.
  • 상태를 나타내며, 읽기/쓰기가 가능하다.
• notInService
  • 해당 개념적 행이 존재하지만, 피관리장치에 의해 가용하지 않은 상태를 나타낸다.
    • 단, 가용한 상태가 되기 위해 필요한 정보는 충분히 포함되어 있는 상태이다 → notReady 상태와 다른 점.
  • 이 상태는 행의 내부적 일관성, 자원의 가용성, 피관리장치의 현재상태와의 일관성과는 무관한다.
  • 상태를 나타내며, 읽기/쓰기가 가능하다.
• notReady
  • 해당 개념적 행이 존재하지만, 해당 정보가 가용한 상태가 되기 위해서는 누락된 정보를 보충할 필요가 있음을 나타낸다.
    • 즉, 가용한 상태가 되기 위해 필요한 정보가 충분히 포함되어 있지 않은 상태이다 → notInService 상태와 다른 점.
  • 예를 들어, 하나 이상의 열 정보가 생성/설정되어 있지 않은 상태를 의미한다.
  • 상태를 나타내며, 읽기만 가능하다. (쓰기를 통해 설정할 수 없다)
• createAndGo
  • 관리장치가 "새로운 개념적 행 생성 후 자동으로 가용한 상태(=active)"로 생성 요청한 상태를 나타낸다.
  • 즉, 관리장치가 이 유형으로 개념적 행 생성을 요청하면, 행 생성 후 바로 가용한 상태로 천이된다.
  • 요청명령(Action)을 나타내며, 쓰기만 가능하다.
• createAndWait
  • 관리장치가 "새로운 개념적 행 생성 후 가용하지 않은 상태(=notInService)"로 생성 요청한 상태를 나타낸다.
  • 즉, 관리장치가 이 유형으로 개념적 행 생성을 요청하면, 행 생성 후 비가용 상태로 천이된다.
  • 요청명령(Action)을 나타내며, 쓰기만 가능하다.
• destroy
  • 관리장치가 특정 개념적 행을 삭제하도록 요청한 상태를 나타낸다.
  • 요청명령(Action)을 나타내며, 쓰기만 가능하다.

SYNTAX       INTEGER {
                     -- the following two values are states:
                     -- these values may be read or written
                     active(1),
                     notInService(2),

                     -- the following value is a state:
                     -- this value may be read, but not written
                     notReady(3),

                     -- the following three values are
                     -- actions: these values may be written,
                     --   but are never read
                     createAndGo(4),
                     createAndWait(5),
                     destroy(6)
                 }

 

관리장치는 'notReady'를 제외한 나머지 5개의 상태를 Set 동작을 통해 명시하며, 피관리장치는 이에 대한 응답으로 "notReady", "notInService", "active"를 응답한다(즉, 요청에 의해 생성되는 행은 이 3가지 상태만을 가진다).

주) 이 표현법(Textual Convention)은 MIB 테이블에 사용될 수 있다.

• 테이블의 개념적 행의 status가 'active'인 상태에서 해당 행 내의 다른 열 객체들의 값 수정이 가능한지 여부는 MIB 모듈 정의 시에 선택할 수 있으며, 이러한 내용은 status 열의 DESCRIPTION 절에 기술되어야 한다.
  • 만약 "active" 상태에서는 변경이 불가능하다는 기준이 적용되는 경우, status가 "active"가 아닌 경우에만, 관리장치가 전송하는 SNMP "SET" PDU 에 의해 열 객체의 값이 변경 가능할 것이다.
  • 만약 관리장치가 전송하는 단일 SNMP "SET" PDU 내에 특정 열 객체 값을 설정하는 요청 외에도 status 값을 변경하는 명령이 함께 포함되어 있다면, 다음 중 하나를 만족할 경우 해당 열 객체 값의 변경이 가능하다.
    • PDU 수신 시에 status 가 "active"가 아닌 경우,
    • PDU 내에 status 를 "active"가 아닌 다른 값으로 설정하는 요청이 함께 포함되어 있는 경우.

개념적 행 내에 하나의 열 객체라도 존재하면, status 열 객체는 반드시 존재해야 한다.

 

 

 

RowStatus 상태 다이어그램

RowStatus 유형의 status 열 객체가 포함된 개념적 행은 다음과 같은 상태 다이어그램을 가진다.

STATE
              +--------------+-----------+-------------+-------------
              |      A       |     B     |      C      |      D
              |              |status col.|status column|
              |status column |    is     |      is     |status column
    ACTION    |does not exist|  notReady | notInService|  is active
--------------+--------------+-----------+-------------+-------------
set status    |noError    ->D|inconsist- |inconsistent-|inconsistent-
column to     |       or     |   entValue|        Value|        Value
createAndGo   |inconsistent- |           |             |
              |         Value|           |             |
--------------+--------------+-----------+-------------+-------------
set status    |noError  see 1|inconsist- |inconsistent-|inconsistent-
column to     |       or     |   entValue|        Value|        Value
createAndWait |wrongValue    |           |             |
--------------+--------------+-----------+-------------+-------------
set status    |inconsistent- |inconsist- |noError      |noError
column to     |         Value|   entValue|             |
active        |              |           |             |
              |              |     or    |             |
              |              |           |             |
              |              |see 2   ->D|see 8     ->D|          ->D
--------------+--------------+-----------+-------------+-------------
set status    |inconsistent- |inconsist- |noError      |noError   ->C
column to     |         Value|   entValue|             |
notInService  |              |           |             |
              |              |     or    |             |      or
              |              |           |             |
              |              |see 3   ->C|          ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status    |noError       |noError    |noError      |noError   ->A
column to     |              |           |             |      or
destroy       |           ->A|        ->A|          ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4         |noError    |noError      |see 5
column to some|              |           |             |
value         |              |      see 1|          ->C|          ->D
--------------+--------------+-----------+-------------+-------------

 

• (A) status 열 객체가 존재하지 않은 상태
  • (1) 'status → createAndGo' 요청 수신
    • (성공) noError 응답 후, D 상태(active)로 천이
    • (실패) inConsistentValue 응답 후 현재 상태(A) 유지
  • (2) 'status → createAndWait' 요청 수신
    • (성공) noError 응답 후, 가용한 상태가 되기 위한 정보가 충분하면, C 상태(notInService)로 천이
    • (성공) noError 응답 후, 가용한 상태가 되기 위한 정보가 충분하지 않으면, B 상태(notReady)로 천이
    • (실패) inConsistentValue 응답 후 현재 상태(A) 유지
  • (3) 'status → active' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(A) 유지
  • (4) 'status → notInService' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(A) 유지
  • (5) 'status → destroy' 요청 수신
    • (성공) noError 응답 후 현재 상태(A) 유지
  • (6) 기타 다른 열 객체 값 설정 요청 수신
    • 에이전트 재량(구현 방식)에 따라, 다음 중 하나로 진행됨.
      • (성공) noError 응답 후, 가용한 상태가 되기 위한 정보가 충분하면 C 상태(notInService)로 천이
        • 개념적 행이 존재하지 않은 상태에서 타 열 객체 설정 요청 수신 시 에이전트가 개념적 행을 생성하도록 구현된 경우에 해당.
        • 이 경우, status 인스턴스가 함께 생성되어야 한다.
      • (성공) noError 응답 후, 가용한 상태가 되기 위한 정보가 충분하지 않으면 B(notReady) 상태로 천이
        • 이러한 경우(개념적 행이 존재하지 않은 상태에서 타 열 객체 설정 요청 수신 시)에 에이전트가 개념적 행을 생성하도록 구현된 경우에 해당.
        • 이 경우, status 인스턴스가 함께 생성되어야 한다.
      • (실패) inconsistentName 응답 후 현재 상태(A) 유지
        • 이러한 경우(개념적 행이 존재하지 않은 상태에서 타 열 객체 설정 요청 수신 시)에 에이전트가 개념적 행을 생성하지 않도록 구현된 경우에 해당.
      • (실패) inconsistentValue 응답 후 현재 상태(A) 유지
        • 설정 요청된 값이 유효하지 않은 경우에 해당.
• (B) status 열 객체 값이 'notReady'인 상태
  • (1) 'status → createAndGo' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(B) 유지
  • (2) 'status → createAndWait' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(B) 유지
  • (3) 'status → active' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(B) 유지
    • (성공) noError 응답 후, D 상태(active)로 천이
      • 가용상태가 되기 부족했던 모든 열 객체들에 대한 값 설정 요청이 동일한 "SET" PDU에 함께 포함되어 있어서, 본 "SET" 동작으로 인해 충분한 정보가 포함되게 된 경우에 해당됨.
  • (4) 'status → notInService' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(B) 유지
    • (성공) noError 응답 후, C 상태(notInService)로 천이
      • 가용상태가 되기 부족했던 모든 열 객체들에 대한 값 설정 요청이 동일한 "SET" PDU에 함께 포함되어 있어서, 본 "SET" 동작으로 인해 충분한 정보가 포함되게 된 경우에 해당됨.
  • (5) 'status → destroy' 요청 수신
    • (성공) noError 응답 후, A 상태로 천이
  • (6) 기타 다른 열 객체 값 설정 요청 수신
    • (성공) noError 응답 후, 가용한 상태가 되기 위한 정보가 충분하면, C 상태(notInService)로 천이
    • (성공) noError 응답 후, 가용한 상태가 되기 위한 정보가 충분하지 않으면, 현재 상태(B) 유지
• (C) status 열 객체 값이 'notInService'인 상태
  • (1) 'status → createAndGo' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(C) 유지
  • (2) 'status → createAndWait' 요청 수신
    • (실패) inConsistentValue 응답 후 현재 상태(C) 유지
  • (3) 'status → active' 요청 수신
    • (성공) noError 응답 후, D 상태(active)로 천이
    • (실패) 개념적 행 내의 값들이 일치하지 않은 경우, inconsistentValue 응답 후, 현재 상태 유지
      • 추측컨대, 동일 PDU에 다른 객체 값을 변경하는 요청이 함께 포함되어 있고, 해당 값이 유효하지 않은 경우로 보임.
  • (4) 'status → notInService' 요청 수신
    • (성공) noError 응답 후, 현재 상태(C) 유지
  • (5) 'status → destroy' 요청 수신
    • (성공) noError 응답 후, A 상태로 천이
  • (6) 기타 다른 열 객체 값 설정 요청 수신
    • (성공) noError 응답 후, 현재 상태(C) 유지
• (D) status 열 객체 값이 'active'인 상태
  • (1) 'status → createAndGo' 요청 수신
    • (실패) inConsistentValue 응답 후 현재상태(D) 유지
  • (2) 'status → createAndWait' 요청 수신
    • (실패) inConsistentValue 응답 후 현재상태(D) 유지
  • (3) 'status → active' 요청 수신
    • (성공) noError 응답 후, 현재 상태(D) 유지
  • (4) 'status → notInService' 요청 수신
    • (성공) noError 응답 후, C 상태(notInService)로 천이
    • (실패) wrongValue 응답 후, 현재 상태(D) 유지
      • 에이전트가 notInService를 지원하지 않는 경우 (이 경우, createAndWait도 지원하지 않는 것임)
    • (실패) inconsistentValue 응답 후, 현재 상태(D) 유지
      • 현 시점에 해당 개념적 행을 비활성화 할 수 없는 상태인 경우 (예: 피관리장치가 해당 정보를 사용 중)
  • (5) 'status → destroy' 요청 수신
    • (성공) noError 응답 후, C 상태(notInService)로 천이
    • (실패) incosistentValue 응답 후, 현재 상태(D) 유지
      • 현 시점에 해당 개념적 행을 삭제할 수 없는 상태인 경우 (예: 피관리장치가 해당 정보를 사용 중)
  • (6) 기타 다른 열 객체 값 설정 요청 수신
    • (성공) noError 응답 후 현재 상태(D) 유지
      • status = active 상태에서도 각 객체 값을 수정할 수 있도록 MIB 모듈이 정의된 경우
    • (실패) inconsistent 응답 후 현재 상태(D) 유지
      • status = active 상태에서는 각 객체 값을 수정할 수 없도록 MIB 모듈이 정의된 경우

 

 

 

개념적 행(Conceptual row) 생성 절차

개념적 행을 생성할 때 상호작용(Interaction)하는 방식(=단계를 의미하는 것으로 보임)은 다음 4가지 단계로 이루어진다.

• 인스턴스 식별자 선택 (Selecting an instance-identifier)
• 개념적 행 생성 (Creating the conceptual row)
• 기본값이 없는 객체 초기화 (Initializing non-defaulted Objects)
• 개념적 행 활성화 (Making the Conceptual Row Available)

 

Interaction 1: 인스턴스 식별자 선택 (Selecting an instance-identifier)

인스턴스 식별자를 선택하는데 사용되는 알고리즘은 각 개념적 행(conceptual row)마다 다르다.

다음과 같은 4가지 알고리즘이 사용될 수 있다.

(1) 인스턴스 식별자는 의미적으로 중요하며(예: 경로의 목적지 주소), 관리장치는 의미론에 따라 인스턴스 식별자를 선택한다.

(2) 인스턴스 식별자는 단지 개념적 행을 구분하는데 사용되며, 개념적 행에 대한 특정 지식이 없는 관리장치는 사용되지 않는 인스턴스 식별자를 결정하기 위해 존재하는 인스턴스를 검사할 수 있다. (이러한 접근법은 매우 차선책으로 사용될 수 있다. 그러나, 이 멍청한 관리장치가 이런 방식으로 개념적 행 작성을 시도하는 것이 실제로 가능한 사례인지 의문이다) → 즉, 사용 안 하는 게 낫다는 의미로 보임.

(3) 개념적 행을 정의하는 MIB 모듈은 사용되지 않는 인스턴스 식별자를 결정하는데 도움을 주는 하나 이상의 객체를 제공할 수 있다. 예를 들어, 개념적 행이 정수 값으로 색인화(indexed)되는 경우, 정수값 유형의 열 객체가 이러한 목적으로 정의되어, 관리장치로 하여금 검색을 할 수 있도록 제공할 수 있다. 경쟁관계인 관리장치들(다수의 관리장치가 존재하는 경우) 간의 불필요한 충돌을 방지하기 위해, 이 객체에 대한 '인접(adjacent)' 검색은 달라야 한다(먼 소리인지...).

(4) 관리장치는 의사난수를 인덱스(=인스턴스 식별자)로써 사용할 수 있다. 해당 인덱스값이 이미 사용 중이어서 관리프로토콜 "SET" 동작에 대해 "inconsistentValue"가 반환되는 경우, 관리장치는 새로운 의사난수값을 생성하여 재시도할 수 있다.

MIB 모듈 설계자는 테이블의 크기(결국, 알고리즘의 효율성)에 기반하여 (3)과 (4) 중 하나의 알고리즘을 선택해야 한다.

• 많은 수의 엔트리가 포함될 테이블에 대해서는, 생성 가능한 인덱스를 리턴하는 MIB 객체를 정의하는 것이 좋다. (즉, (3)번 알고리즘)
• 적은 수의 엔트리가 포함될 테이블에 대해서는, 의사난수값을 사용하는 메커니즘을 적용하는 것이 좋다. (즉, (4)번 알고리즘)

 

Interaction 2: 개념적 행 생성 (Creating the conceptual row)

사용되지 않는 인스턴스식별자가 선택되면, 관리장치는 다음 중 하나를 결정한다.

• 단일 트랜잭션을 통한 개념적 행 생성 및 활성화 → createAndGo
• 협상된 다수 단계를 통한 개념적 행 생성 및 활성화 → createAndWait

Interaction 2a: 개념적 행 생성 및 활성화 (Creating and Activating the Conceptual Row)

관리장치는 먼저 열(column) 요구사항들을 정의해야 한다. 즉, 행 생성 시에 값이 제공되어야 할 열과 제공되지 않아야 할 열을 정의한다.

이러한 정의는 다음 두 가지 사항에 따라 관리장치가 자체적으로 로컬에서 정의한다.

• 테이블의 복잡도
• 관리장치가 알고 있는 에이전트의 지원 기능(capabilities)

또는 관리장치가 "GET" 동작을 수행함으로써 생성하고자 하는 개념적 행의 모든 열을 검사한다. 이에 대한 응답으로, 각 열 객체에 대해 다음과 같은 3가지 가능한 결과가 응답된다.

• 해당 열 객체의 값이 응답된다.
  • 이는 다른 관리장치가 해당 개념적 행을 이미 생성했음을 의미한다. 이 경우 Interaction 1 단계로 돌아간다.
• "noSuchInstance" 에러가 응답된다.
  • 이는 에이전트가 이 열에 연관된 오브젝트 유형을 구현하고 있으며, 검색에 사용된 "MIB 보기"에서 하나 이상의 개념적 행 내의 이 열에 접근이 가능함을 나타낸다.
  • 에이전트가 "read-create" 접근을 제공하는 열들에 대해, 본 에러는 관리장치에게 다음을 말하는 것이다.
    • 개념적 행이 생성되기 위해서는 이 열에 대한 값이 제공되어야 한다.
• 'noSuchObject' 에러가 응답된다.
  • 이는 에이전트가 이 열에 연관된 오브젝트 유형을 구현하고 있지 않거나, 검색에 사용된 "MIB 보기"에서 이 열에 접근할 수 있는 개념적 행이 존재하지 않음을 나타낸다.
  • 따라서 관리장치는 이 열의 인스턴스를 생성하기 위한 "SET" 프로토콜 동작을 수행할 수 없다.

열 요구사항들(생성 시 값을 제공해야 할 열들)이 결정되면, status = 'createAndGo'인 "SET" 프로토콜 동작이 수행된다.

에이전트가 "SET" 동작을 처리할 때, 에이전트는 해당 개념적 행이 관리장치에서 가용한 상태가 되기에 충분한 정보를 가지고 있는지 확인한다.

가용한 정보는 다음과 같은 두 가지 방식을 통해 에이전트에 제공된다.

• 개념적 행을 생성하는 "SET" 프로토콜 동작
• 에이전트에 의해 제공되는 기본값 (implementation-specific) → 에이전트는 최소한 read-only 유형 객체에 대해서는 implementation-specific 한 기본값 설정 메커니즘을 구현해야 한다.

가용한 상태가 되기에 충분한 정보가 있는 경우, 개념적 행이 생성되고, 'noError' 응답이 리턴되며, status 열은 'active' 상태가 되고, 더 이상의 상호작용 절차는 필요하지 않다(즉, interaction 3, 4 는 생략된다)

충분한 정보가 있지 않은 경우, 개념적 행은 생성되지 않고, "SET" 프로토콜 동작은 'inconsistentValue" 에러로 실패한다. 이 에러 발생 시, 관리장치는 해당 에러의 원인을 판별하기 위해 "RETRIEVAL" 프로토콜 동작**(아마도 walk 인 듯)**을 수행할 수 있으며, 에러 원인은 다음과 같이 분류된다.

• 요구되는 열에 대한 값을 명시하는 데 실패
  • 이 경우, 관리장치는 추가적인 정보를 포함한 "SET" 프로토콜 동작을 다시 수행하거나, 개념적 행 생성을 협상하기 위해 'createAndWait' 를 사용하여 Interaction 2를 다시 수행할 수 있다.
• 선택된 인스턴스가 이미 존재
  • 이 경우 Interaction 1 절차로 돌아간다.

주) 열 요구사항들을 정의하는데 사용되는 방법과 무관하게, 에이전트가 특정 열 인스턴스가 생성되거나 쓰여지는 것을 허용하지 않을 때 관리장치가 해당 열을 필요 열로 간주할 수도 있다. 이 경우, "SET" 프로토콜 동작은 'noCreation' 또는 'notWritable' 에러와 함께 실패한다. 이 경우, 관리장치는 해당 열 인스턴스에 값을 설정 가능할 필요가 있을지 여부를 결정한다. 필요가 없다면, 관리장치는 해당 열 인스턴스에 대한 값 설정이 포함되지 않은 "SET" 프로토콜 동작을 다시 수행한다. 그렇지 않으면, 관리장치는 행 생성 알고리즘을 중단한다.

Interaction 2b: 개념적 행 생성 협상 (Negotiating the Creation of the Conceptual Row)

관리장치는 status 열의 값을 'createAndWait'로 설정한 "SET" 프로토콜 동작을 수행한다.

에이전트가 이 절차를 수행하지 않고자 하는 경우(예: 지원하지 않는 경우), 해당 동작은 'wrongValue' 에러와 함께 실패한다. (그 결과로, 이런 에이전트는 단일 "SET" 프로토콜 동작(createAndGo)을 수용할 준비를 해야 한다. 즉, 열 요구사항에 의한 모든 열들에 대한 설정 값이 포함된 동작 - Interaction 2a)

에이전트가 이 절차를 지원하는 경우, 개념적 행이 생성되고, 'noError' 응답이 리턴되며, status 열의 값이 즉각적으로 'notInService' 또는 'notReady'로 설정된다(정보가 충분한지 여부에 따라).

• 정보가 충분하면 'notInService' 상태가 된다.
• 정보가 충분하지 않으면 'notReady' 상태가 된다.

그리고 이어서 Interaction 3이 수행된다.

Interaction 3: 기본값이 없는 객체 초기화 (Initializing non-defaulted Objects)

관리장치는 이제 열 요구사항들을 정의해야 한다. 관리장치는 생성된 개념적 행 내의 모든 열들을 확인하기 위해 "GET" 프로토콜 동작을 수행한다. 이에 대한 응답으로, 각 열에 대해 다음 중 하나의 결과가 응답된다.

• 해당 열의 값이 리턴된다.
  • 이는 에이전트가 해당 열에 관련된 오브젝트 유형을 구현하고 있으며, 값을 제공하기에 충분한 정보를 가지고 있음을 나타낸다.
  • "read-create" 접근을 제공하는 열의 경우, 값이 리턴된다는 것은 관리장치로 하여금 필요한 경우 해당 열의 값을 변경하기 위해서 추가적인 "SET" 프로토콜 동작을 수행할 수 있음을 의미한다
• 'noSuchInstance' 에러가 반환된다.
  • 이는 에이전트가 이 열에 연관된 오브젝트 유형을 구현하고 있으며, 검색에 사용된 "MIB 보기"에서 하나 이상의 개념적 행 내의 이 열에 접근이 가능함을 나타낸다.
  • 하지만, 에이전트가 값을 제공하기에 충분한 정보를 가지고 있지 않으며, 값이 제공되기 전까지, 해당 개념적 행은 가용상태가 되지 못함을 의미한다.
  • "read-create" 접근을 제공하는 열의 경우, 이 에러는 다음을 의미한다.
    • 해당 열에 관련된 값을 제공하기 위해서는 추가적인 "SET" 동작이 수행되어야 한다. (즉, 값이 설정되어야 한다)
• 'noSuchObject' 에러가 반환된다.
  • 이는 에이전트가 이 열에 연관된 오브젝트 유형을 구현하고 있지 않거나, 검색에 사용된 "MIB 보기"에서 이 열에 접근할 수 있는 개념적 행이 존재하지 않음을 나타낸다.
  • 따라서 관리장치는 이 열의 인스턴스를 생성하기 위한 "SET" 프로토콜 동작을 수행할 수 없다.

status 열의 값이 'notReady'인 경우, 관리장치는 모든 'noSuchInstance' 열을 다뤄야 한다(=값을 설정해야 한다). 이 동작이 완료되면, status 열은 'notInService' 상태가 되고, Interaction 4 절차를 수행한다.

Interaction 4: 개념적 행 활성화 (Making the Conceptual Row Available)

관리장치가 개념적 행 내의 열 객체들의 값에 대해 만족하면(=다 설정했으면?), 관리장치는 status 열을 'active'로 설정하는 "SET" 동작을 수행한다.

만약 에이전트가 개념적 행을 가용한 상태로 만들기 위한 충분한 정보를 가지고 있다면, 해당 "SET" 동작은 성공한다('noError' 응답이 반환된다).

충분한 정보를 가지고 있지 않다면, 해당 "SET" 동작은 'InconsistentValue' 예외값과 함께 실패한다.

주) 'notInService' 또는 'notReady' 값을 갖는 status 열을 포함한 개념적 행은, 피관리장치에서 가용하지 않다 → 동작에 활용되어서는 안 된다. 따라서, 피관리장치는 "createAndWait" 상태로 설정하는 "SET" 동작과 'active' 상태로 설정하는 'SET' 동작 사이의 시간 동안 사용될 자체 인스턴스를 생성하는 것도 가능하다. 이 경우, status를 'active'로 설정하기 위한 "SET" 동작이 수행될 때, 관리장치가 사용하는 값보다 에이전트가 보유한 값이 우선한다.

관리장치가 status 열을 'active'로 설정하지 못하는 경우(예: 관리장치 또는 네트워크 에러로 인한), 개념적 행은 자원을 무한정 소모하면서 'notInService' 또는 'notReady' 상태를 유지한다. 에이전트는 비정상적으로 오랜 기간 동안 이러한 상태에 있는 개념적 행을 감지하고 제거해야 한다. "비정상적으로 오랜 기간"이 얼마인지에 대해서는 status 열의 DESCRIPTION 절에 기술되어야 한다. 이 값은 개념적 행이 생성된 시점부터 'active'로 설정되는 시점까지 인간이 응답할 수 있을 만큼 충분히(생각하는 시간 포함) 길게 정의되어야 한다. DESCRIPTION 절에 이러한 정보가 포함되어 있지 않으면, 5분을 사용하는 것을 권장한다. 이러한 삭제 동작은 새로 생성된 개념적 행 뿐만 아니라, 기존에 active 상태에서 notInService로 변경된 후, 사전에 정의된 긴 시간 동안 그 상태로 남아 있는 개념적 행에 대해서도 동일하게 적용된다.

 

개념적 행 중지(Conceptual Row Suspension) 절차

개념적 행이 'active' 상태일 때, 관리장치는 status 열을 'notInService'로 설정하는 "SET" 프로토콜 동작을 수행할 수 있다.

에이전트가 이를 수행하고 싶지 않으면, 이러한 "SET" 동작은 'wrongValue' 또는 'inconsistentValue' 에러와 함께 실패한다.

에이전트가이를 수행할 경우에는, 해당 개념적 행은 비 가용 상태가 되고, 'noError' 응답이 반환된다.

어떤 상황에서 status 열이 비가용 상태가 되어야 하는지는 status 열의 DESCRIPTION 절에 기술되어야 한다.

(예: 동일한 행 내에 속한 다른 열 값을 변경하기 위해서는 status 열이 비가용상태가 되어야 한다 등)

 

개념적 행 삭제(Conceptual Row Deletion) 절차

개념적 행을 삭제하기 위해, status 열 값을 'destroy'로 설정하는 "SET" 프로토콜 동작이 수행된다. 이 요청은 status 열의 현재 상태와 무관하게 수행될 수 있다(예: 'notReady', 'notInService', 'active' 상태인 개념적 행을 삭제할 수 있다).

동작이 성공하면, 해당 개념적 행에 관련된 모든 인스턴스들은 즉시 삭제된다.