海外の会議やメールにおける英語の略語

海外の会議に参加していて意外に困るのが“英語の略語“だ。日本の会議であったとしても企業毎や組織毎に進め方やルールが異なったり、独特な略称や識別子の使い方があるが、海外の会議でも同じだ。

会議自体の進め方は、その会議のどこかでドキュメントとしてまとまっていることもあるが、略称はどこにもないケースが多い。また、インターネット上で調べてもなかなかまとまっていない。今回はETSIの会議やメールにおいて利用される略称をまとめてみた。今後気づいた用語があれば随時追加していきたい。

ETSIの会議で利用される略語

  • rh: Raise Hand ("I want to say something")
    • 主に電話会議で利用される“挙手“の意思表示
    • チャットに”rh”と記載することで発言の許可を得て発言する
  • lh: Lower Hand ("cancel" the raise hand)
    • 主に電話会議で利用される挙手の取り下げ
    • ”rh“とワンセットで利用し、チャットで挙手を取り下げるときに”lh”と記載する。
  • CR: change request.
    • 現在の標準化仕様/ドキュメントの変更提案
    • 会議中やメールなどあらゆるところで利用される
  • w.r.t: with respect to (putting something into context of something else)
    • 議論中の内容に“追加で補足“という意思表示
    • 電話会議中のチャットでの補足やメールで割り込んで発言するときに“w.r.t [トピックや主張], ”と記載して補足を追加するときに利用
  • WI: Work Item
    • ETSIにおける標準化ドキュメントを作成するための活動アイテムの名称
    • 会議中やメールなどあらゆるところで利用され、CRや各種提案は全てWI単位で行われる
    • 新しいWIはNWI (New Work Item)と言われることもある
  • AP: Action Point
    • 特定の人/会社に割り当てられた課題/タスク
    • 主に議事録(Meeting Note)などに記載される
  • WG: Working Group
    • 特定の目的に基づいて作業するグループや会議体の総称
    • 会議中やメール、公式ドキュメントなどあらゆるところで利用される

メールやチャット等の文章で利用される略語

  • IMHO: In My Humble Opinion (“Personal opinion”)
    • 会社や組織の代表としての発言とは区別し“個人的な意見“として発言することの意思表示
    • メールなどで、ここから“個人的な意見“として記載するときに、”IMHO, [個人的な意見]”として利用
  • pov: Point Of View (“viewpoint, position”)
    • 様々な観点で異なる意見や分析が必要なときのどの観点での発言かの説明
    • メールやチャットなどで様々な議論をしているときに“it is interoperability issue from [観点] pov.”というように、意見の後に利用
  • AFAIK: As far as I know (“personal view”)
    • 断言しきれないときに“私の知る限り“というオブラートに包む言い方
    • メールやチャットなどで何かを質問されたときに“AFAIK, [回答]”と回答するときに利用

(参考)ETSIにおける特別な意味を持った用語

  • approved: WG understand the proposal, and the proposal will be reflected to document.
    • WGのメンバーの総意として正式に承認すること
  • agreed: 1) pre-approved for the proposal, 2) WG understand and support the direction for discussion paper.
    • approvedより少し弱く、WGのメンバーとして方向性を合意した状態
  • objection: disagree the proposal. If one member in WG objects the proposal, the proposal will not be reflected to draft.
    • 提案内容を反対すること
    • approvedの反対であり、ETSIの場合は1人でもobjectionするとapproved(承認)にならない
  • noted: 1) WG disagree the proposal, 2) WG understand the information.
    • WGとして提案内容をapproved(承認)しないこと
    • ETSIの場合2つの意味(提案内容の反対と提供された情報を理解したこと)があるので注意が必要
  • withdrawn: proposer cancel to propose the proposal.
    • 提案者が提案内容を取り下げること
    • ETSIの場合は余程のことがない限りNotedにはしないので、提案の再修正で済まないレベルの場合はwithdrawnを促されることが多い
  • grammar: rule of programming language.
    • 特定のプログラミング言語の文法のこと
    • ETSIは標準化団体のためgrammarに踏み入れた標準仕様の指定はしないが、異なるSolutionの場合はgrammarをある程度指定することもある
  • syntax: set of rule that defines the combinations of symbols in programming language, e.g. if ... then .. else
    • ETSIでは特定のキーワードをsyntaxと呼ぶことが多い
  • semantics: meaning of syntax or parameter.
    • ETSIでは特定のキーワードやparameterの意味をsemanticsと呼ぶことが多い

コメント

コメントを投稿

このブログの人気の投稿

CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

イメージ
ETSI-NFV仕様の各Release機能 の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4は IFA039のSBA の影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？については こちら を参照して頂きたい。 Kubernetesによるクラウド管理 Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。 仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。 Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。 Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長...
続きを読む

モバイルネットワークの保守運用の基礎

イメージ
O-RANや Sliceの管理 によって、最近モバイルネットワークの保守運用が脚光を浴びるようになってきた。しかし、運用方法や保守系装置は“オペレータやベンダ毎に異なる領域“というイメージであり、なかなかまとまったドキュメントや資料が見つからない。 保守運用の基本 これまでネットワークの保守運用のデファクトや標準仕様と言えばTM Forumの eTOM 程度しか無かったと思う。eTOMや各種標準化機能やOpen Sourceを踏まえると、大きく以下のような考え方がありそうだ。 保守運用のプロセス strategy： 新サービス導入やユーザの利用状況を踏まえた設備計画 保守運用の観点から見るとfulfillmentのInput情報 fulfilment(fulfillment)：設備計画に基づいたネットワーク装置(NF)や、それらを接続するネットワーク(NW)の設計・工事 assurance：運用しているNFやサービスの監視や復旧、更新作業 4Gまでの保守運用というと、assuranceを指すことが billing：利用状況に基づいた課金 保守運用の観点から見ると運用結果のOutput 保守運用レイヤ Business Management System (BMS)： 顧客の契約情報を管理 一般的にBusiness Support System (BSS)を利用 Service Management System (SMS)： 提供サービスの管理運用 Network Management System (NMS)： (サービスを実現する)NFの接続性の管理運用 4GまでのOperation Support System (OSS)と言うとNMSのことを指すことが多かったようだ Element Management System (EMS)： NF自体の管理運用 NFのFCAPSと言えば、EMSのことを指すことが多い 一般的にネットワークの保守運用というと、EMSまたはNMSのレイヤのfulfilment＋assuranceを指すことが多いように感じる。しかしながら、システムによる実装と人手での運用という観点では、4GまではEMSのassuranceまでを実装し、残りは手作業ということも多かったようだ。規模が大きな企業では、NMSやSMSの一部を取り入れてOSSを導入し...
続きを読む

VNFMとは？

仮想化された交換機等のテレコム設備(VNF: Virtualised Network Function)の管理機能部としてETSI-NFVではVNFM(VNF Manager)が定義されている。VNFMの主な役目として VNF LCM を行うというものがあるが、VNFMが入ることでNFVOやVIMとの機能的な違いが分かりにくくなっている。VNFMの役割とは何だろう？ ETSI-NFVにおけるVNFMの役割 ETSI GS NFV-MAN 001 の過去の提案資料(寄書)や議論状況を見ていると、どうやら以下のような考え方で機能部を検討してきたようだ。 テレコム設備(Network Function)の仮想化(VNF) Compute/Storage/Networkの仮想リソースプール化(NFVI: NFV Infrastructure) 複数のNFVIの管理/クラウド化(VIM: Virtual Infrastructure Manager) 複数のVIMのキャパシティ管理と既存保守機能部(OSS: Operation Support System)の接続と自動化(NFVO: NFV Orchestrator) 既存のNFのOAM部(EM: Element Manager)やVNFの仮想化に伴う不足機能の補完(VNFM) MAN001の議論状況だけ見ると、上記の通りNFVOとVIMしかなかったようだ。MAN001の発行直前に、既存のVNF/EM/OSSと新機能部であるNFVO/VIMの不足機能を補完するためにVNFMが定義されている。 問題はこの“不足機能“とは何かが不明瞭なため、VNFMは様々な機能部との境界ラインが曖昧になってしまっている。 VNFMの機能 ETSI GS NFV-IFA 010 を確認すると、VNFMが保持する機能としてはVirtualised Resource (VR) Mgmt、VNF  LCM、VNF Config Mgmt、VNF Info、VNF FM、VNF PM、VNF Indicator、Policy Mgmt、Snapshot Mgmt、VNF workload Mgmtがある。VNF LCMやVNF workload Mgmtは NFV-Tacker workshopのレポート「NFV＃34会合サマリとNFV-Work...
続きを読む