Meeting報告の後編をお届けします。後編では全体会議、メールアドレスの国際化、ENUM等についてお伝えします。Meetingよりも人数・国数ともに増加したとのことでした。Carpenter氏から報告されました。継続している、IETFとITU-T間における協調を図る動きの一環であるといえるでしょう。IETFでは現在、ここ数年やや停滞していた活動を再び活発化させるための様々な構造改革を進めており、今回はそれらの試みについての進捗報告が行われました。Team(IETFの運営を円滑にするための各種ツール・Webサイト等を作るプロジェクト)からの報告では、実際のプロトタイプを用いたデモが行われました。プロトタイプは次のURIで公開されています。Award(ジョン・ポステル賞)を受賞しました。表彰式での村井氏のスピーチにおける「最初に私がIETFに参加した時は、日本からの参加は私一人だった。今は各国からの多くの参加者がここにいる。」という言葉が印象的でした。BOFAPPAREAは、アプリケーションエリア全般に関して話し合いを行うBoFです。Address:国際化メールアドレス。Team)での検討状況の発表が行われました。JETの提案内容は、国際化ドメイン名に用いた技術を、メールアドレスのローカルパートに応用するものです。ドメイン名では、大文字や小文字の区別を行う必要はありませんが、メールアドレスのローカルパートでは、これらの区別を行う必要があります。JETの提案は、この点を考慮した手法となっています。この提案に対しては、一部のメールアドレスにおいて問題が発生する場合があり、この点について検討を更に深める必要があるという指摘があり、この点を含め引き続きJETで検討することになりました。Huitema氏よりパスワードなどのセキュリティに関する注意勧告を促す発表があり次の説明が行われました。ドル以下のコストである-無線LANでは通信内容を簡単に覗き見ることができることが多く、とても危険であるこの注意勧告の結論としては、-パスワードはもう安全ではない-チャレンジ・レスポンス型の認証(*1)であっても安心はできない-SSHやIPsecなど、通信相手を正しく特定でき、かつ、通信路を暗号化するプロトコルを利用することが重要であるとまとめていました。通信元と通信先で同じキーワード(secret:パスワード等に相当するもの)を保持し、認証時に通信先から毎回変わる文字列(challenge)を受け取り、通信元ではsecretとchallengeを組み合わせたものをMD5などのハッシュ関数で変換した文字列(response)を送って認証を行う技術。通信路上でのパスワードを隠蔽できるので安全な認証であると考えられている。WGは、ENUM技術の標準を決め、運用のための技術資料を作成し、ENUM運用に関する情報交換を行うためのWGです。Standardとしての標準化は完了しており、現在は実際の使い方や実装を考えた提案が増えてきています。コンテンツを表現するENUMサービスの提案、ENUMシステムを実装するために必要なアーキテクチャの提案などが行われました。WG会議の後ろ半分の時間を用いて集中的に議論されました。キャリアENUMは、以前からユーザENUMとは違うという合意は得られていましたが、まだ詳細な合意には至っていません。このような状況の中で、今回は次の三つの提案が行われました。(1)キャリアENUMを実装するためにENUMプロトコルを大きく変更し、一つのENUMドメイン名にユーザENUMとキャリアENUMの内容を共存させる提案(2)e164.arpaの中にサブツリーを作成する提案(3)キャリアENUMのためのドメイン名として、e164.arpaではない新しいDNSツリーを用いる提案(1)の提案に対しては、すでに標準化したプロトコルを変更することは困難であるというコメントや、従来の実装との不整合を指摘するコメントがありました。(2)の提案については、サブツリーの作り方に注意する必要があるというコメントがありました。(3)の提案については、明確なコメントはありませんでしたが、新しいDNSツリーを使用することは困難を伴うという暗黙の合意がありました。以上の議論を受け、今回の会議では次の二点が合意されましたが、これからも継続して議論を行うことになりました。Callとすることとなりました。報告書http://www.nic.ad.jp/ja/enum/report/enum-report2003.pdf「キャリアENUM」は、(社)日本ネットワークインフォメーションセンターのENUM研究グループが上記報告書で「オペレータENUM」としてまとめたものと同じ概念です。オペレータENUM」をご参照ください。WGは、これまでのWhoisを機能的に置き換え、ドメイン名情報などのインターネット資源情報を検索するための新しいプロトコルを検討するWGです。Service)プロトコルです。Check)という低負荷なドメイン名存在確認プロトコルについて、ほぼ議論が完了しました。ミーティングに参加していたTLD運用組織を対象に、CRISP導入に関する検討状況のアンケートが行われました。12組織から回答があり、すでに実装してテストしているTLD運用組織が2つあること、それ以外の10のTLD運用組織は導入を検討していることがわかりました。BoFは、世界的にVoIPシステムが普及してきている中、VoIP網間の相互接続にかかわる問題点について議論するBoFで、今回初めて開催されました。VoIP/SIP網の相互接続について、短期的な要求仕様と事例のドキュメント化を行うこと、および長期的な議論を行うことを目的としています。日本のVoIP/SIP相互接続検証タスクフォースと同じ問題意識で開催されました。各WGからの技術解説と、電話番号と経路制御の問題のまとめが報告されました。等の紹介がありました。BoFのまとめとして、VoIP/SIPの相互接続は、ISPなどには大きなニーズがあることが確認され、事例、シナリオ、用語などのドキュメントが必要だということと、活動を継続し、次回IETF会議でもBoFを開催することが合意されました。JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。認証方法についてサイトシールについて設定マニュアル対応環境についてルート証明書・中間CA証明書について失効申請における失効理由コードの指定についてサーバー証明書発行サービスに関するリポジトリ/利用規約サーバー証明書情報等の外国組織への提供ご利用にあたっての注意事項サーバー証明書発行サービスについてのお知らせメンテナンス情報サーバー証明書の更新のご案内について株式会社日本レジストリサービス(JPRS)は、ドメイン名の登録管理と、ドメインネームシステム(DNS)の運用を通して、インターネットの基盤を24時間×365日支えています。