ENUM 研究グループ 第4回研究会 議事録
1. 日 時： 2002年 12月 2日 (月) 10:30 - 12:30
2. 場 所： 東京都千代田区内神田2-3-4 国際興業神田ビル6階
(社)日本ネットワークインフォメーションセンター (JPNIC) 会議室
3. 議 題： 1) 前回の議事録の確認
2) IETF報告(JPRS)
3) 総務省 番号研究会WG報告(JPNIC)
4) 第1次報告書について(JPNIC)
5) 今後の進め方について
6) その他
4. 配布資料：
資料1 第3回研究会議事録
資料2 IETF55 ENUM WG Report
資料3 ENUM研究グループ活動報告
資料4 ENUM研究グループ第1次報告書(第2版)
資料5 検討課題&今後の進め方
■参加者：
(敬称略) 伊勢 禎和 社団法人日本ネットワークインフォメーションセンター
大内 勉 日本電気株式会社
大谷 哲也 日本サイバースペース株式会社
大宮 知己 日本電信電話株式会社
加藤 義文 社団法人テレコムサービス協会
北島 敏 日商エレクトロニクス株式会社
木原 誠司 日本電信電話株式会社
後藤 滋樹 早稲田大学
後藤 雅徳 沖電気工業株式会社
澤田 拓也 KDDI株式会社
佐野 晋 社団法人日本ネットワークインフォメーションセンター
澤木 錠詞郎 NTTコミュニケーションズ株式会社
塩田 要平 東京通信ネットワーク株式会社
白澤 進 日本電気株式会社
神野 公秀 日本電信電話株式会社
関 一朗 日本電信電話株式会社
田中 武四郎 三菱商事株式会社
堂坂 智明 株式会社日本レジストリサービス
根津 智子 社団法人日本ネットワークインフォメーションセンター
延坂 成人 ネットワンシステムズ株式会社
細見 昭英 三菱商事株式会社
堀崎 修宏 社団法人情報通信技術委員会
藤原 和典 株式会社日本レジストリサービス
堀田 博文 株式会社日本レジストリサービス
真鍋 尚 インターネットフォーラム
森 利行 JENS株式会社
吉井 裕重 日本テレコム株式会社
■オブザーバ: (敬称略) 総務省データ通信課 加藤 博司
5. 議事
1) 前回の議事録の確認
事務局の伊勢氏が、資料1の通り第3回研究会の議事録をレビューした。
日本サイバースペース株式会社の橋本氏の名前が抜けていたためそれを追加
した上で承認となった。
2) IETF報告(JPRS)
資料2に基づき、JPRSの藤原氏が2002年11月18日〜開催された第55回IETFの
ENUM WGの会合についての報告を行った。その後、下記の質疑応答が行なわれた。
Q: ENUM Trialのdraft-brandner-enumservices-compendium-00.txt は、
今後先に進める話なのか
A: カテゴリ分割は進めない方向であるようだ。
Q: このカテゴリにしたがってENUMを登録しなくても良いのか?
A: どちらでもよい。具体的には登録するときにtype, subtypeを記述するが
その際に、具体的に議論することになる
今回はその場では決めないという雰囲気だった。RFC2916bis をはやくRFC
にしたいという思惑があるようだ
3) 総務省 番号研究会WG報告(JPNIC)
資料3に基づき、JPNICの佐野氏が2002年11月27日に開催された番号研究会WGで
報告した「ENUM研究グループの活動報告」の内容について報告を行った。
4) 第1次報告書について(JPNIC)
資料4に基づき、事務局の佐野氏が今月の第1次報告に向けた、第2版の
第1次報告書をレビューした。案なので、足りないところを補足して近々に
再提出したいとの補足説明があった。その後、下記の質疑応答が行なわれた。
Q: 37ぺージ でオペレータENUMの場合はサービスの選択肢はないのか?
A: 事業者が決まれば、ユーザが決められる。ある程度の枠組みでお客様に
柔軟性をもたせるになる。
Q: 4項の感じでは、そうは感じない。オペレータENUMはユーザが関与できない
という印象を与える。実際にはコールセンタに問い合わせて、ユーザが
変えるというのは難しい。セキュリティもはっきりしているある管理主体の
場合、ユーザが自分でレコードを変えるのは出来るかもしれないが。
A: ここでは「あくまで事業者が主体」ということで、事業者のなかでとじて
いる話であって、どう書き変わるかはお客さんは知らない。事業者は
インターネット上でのお客様の要望にしたがって書き換えるだけでどう
書き変わるかはお客様が知る必要がない
Q: では、ユーザの要望が反映されるものではあるのですね
A: はい。
Q: 30ページに「アプリケーションの識別を数字だけで記述でき」という表現が
あるが、数字だけだと人間の認識に響きにくいという問題があるので、
ドメイン名等が出来た経緯がある。従ってこの表現は奇異に感じる。
A: その前に「電話番号を利用することによってアプリケーションを統合化する
ことによって」と限定して記載されているが、奇異だろうか?
Q: 電話機だって今時は番号だけではない。なので、数字だけを意識しなくても
良いのでは。
A：記述自体は間違っていない。 メリットの一つとして書いてある。
Q: 「はじめに」第三パラグラフは、ENUMが電話網を意識して出来てきたとい
うよりもインターネットの世界からの発展形としてそれなら既存の電話網
ともつなげるねという話に見えるが、これは違うのではないか。そもそも
普通の電話よりも安く、簡単に、というところからでてきたように思う
ので順番として変に感じる。
A: 元々の文章では2つのENUMの目的が記載されていた。
標準化は一義的な意味で、それの活用形としてIP電話の中でどう使うかと
いう話のなかで、1)最初にアプリケーションを識別する、2)その後に
インターネット電話の接続という話。
A: ENUM WGが出来たときにはDNSを使うことは予定されていなかったが、淘汰
された結果DNSを使う事になった。従って、この順番が正しくないいう主張
は正しいのではないか
O: 第2・3パラグラフを引っくり返せばいいのではないか
O: 今日的な理解をするのがこの場ではないか。昔の歴史ははじめてよむ人に
関しては有害の可能性もある。歴史なら別に書けばいいのであって、今日的
な理解を 先に書いたほうがいいのでは。
O: 論理的な位置付けを書くのか、それとも発生的などうしてこれが出来たのか
と書くのかの違いではないか。それなら歴史の章をつくってそこに書けば
いいのではないか
O: インターネットの立場からすると電話番号は単なる名前だから、歴史では
なく結果で書くべきだと思うが、 第三パラグラフで書かれているのが
追加的な記述になっているので、奇異に感じるのかもしれない。
他の例もいれたら良いのではないか
O：SIP、H323は電話系からでてきたサービスととらえるか、インターネットから
でた書き方かと感じるかもよる
O: どちらの方からも不満は残る
O： 11ページ 2.1 の題名が「ENUMで考慮しているURIスキームについて」と
記載されているが、「考慮している」という語は正しいか?
O： 2.1 と2.3 がダブっているように感じるので、2.1 は導入程度に書くに
留める
Q: tel: svc パラメータというのはあるのか
A: 現在の tel: では発呼の方法のみ規定していて、電話FAXなどの区別は
別の方法ですることになっている。tel URIにsvc parameterというものを
提案している人がいる。
Q: ENUM URI は ?
A: enum uriそのものの議論の話も、tel uri svc parameterを提案している
人が提案しているようだ。iptel-wgでは、tel uriに地域を指定する
パラメータをつけるという話で盛り上がってたようだ。
Q: NAPTRの記載についてだが、RFC3403,3404のflags SAUPのなかでこれはアプリ
ケーションとして定義されている。しかしこの表はNAPTR の一般的な定義
なので、SAUPなどは入っていないのではないか
A: サービスのところも同じ。記述を正確にする
5) 今後の進め方について
資料5に基づき、事務局の佐野氏が今後の活動の進め方について提案を行った。
その後、下記の質疑応答が行なわれた。
Q: 050 とインターネット電話の概念は必ずしも一致しないでよいか
A: Managed Ipの中の電話といえるのでは
Q: インターネット電話が品質が良くなればManaged Ipという概念はいらなくなる
のでは
A: それを実現する為の技術がManaged Ipではないのか
帯域が広くなることによって管理はしやすくなる
Q: これは第1次報告書にはいれないということか。第2次報告書にもいれないと
いう事であれば、使えない報告書になるのではないか
A: 本研究グループでは、ENUMを実際に利用する際の，ENUM以外の重要な項目、
例えば、
* 課金に関する事項
* 発呼・着呼時の相手の認証，成りすましの問題
* 通信の秘密
* ワン切り，スパム，ダイレクトメイルなど
* 通信の品質，信頼性
については検討の対象外としENUMにフォーカシングをあて検討するとしている
確かにこういった技術やSIPの相互説属性等も議論しなくてはいけないが
あえて第2次報告も含めてこれは議論をしないことに決めた。従ってこの様な
事項は別に場を設け Voip 協議会等と場合によってはリエゾンするなどして
検討する必要がある
Q: では、ENUMそのもののセキュリティ等は検討の対象なのか?
A: 通信が始まったあとの問題点については検討しない
DBに登録する登録者の認証、改竄 等のENUMそものものセキュリティについては
検討の対象である。
Q: では発呼・着呼時の相手の認証はやるという事ではないのか
A: やらない。ENUMを実際に利用する際の複数の対応付されるサービスが得られ
ると いうところまでをやる。実際にSIPの話、アプリケーションをどこが
選択するかということは対象外である。
O: では 1.1 にそういったニュアンスの事をいれてほしい。2行目を削除する事
は検討できないか
O: 「これらの検討対象外の項目は，実際にENUMをベースにしたサービスの構築を
行う際には、重要な事項である」を先に書くこととする
6) その他
その他、下記の質疑応答と決定事項があった。
O: ENUMの実験をするかしないかという話があるが、ここで全く記載していないが
どうするか。そのものに関しては提案する必要はないかもしれないが、どこが
やってみないとわからないかので実験してみる必要があるのではないか
O: テクニカルにはいろいろやってみたいとは思うが、ENUMが使える対象が
わからないうちは提案をしにくい
○ 決定事項
+ 今後どのように進めるか、どこに興味あるかについての意見を今週中に
コメントする。
+ 第1次報告書に関しては、12月9日にオンラインで発表する。