Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat
Tina TSOU <tena@huawei.com> Wed, 17 December 2008 06:20 UTC
Return-Path: <aaa-doctors-bounces@ietf.org>
X-Original-To: aaa-doctors-archive@optimus.ietf.org
Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104C13A6AE9; Tue, 16 Dec 2008 22:20:38 -0800 (PST)
X-Original-To: aaa-doctors@core3.amsl.com
Delivered-To: aaa-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730683A6ACF for <aaa-doctors@core3.amsl.com>; Tue, 16 Dec 2008 22:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level:
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9ktoX-WBTNp for <aaa-doctors@core3.amsl.com>; Tue, 16 Dec 2008 22:20:34 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 09F2C3A689C for <aaa-doctors@ietf.org>; Tue, 16 Dec 2008 22:20:34 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC000F2UCA08L@szxga04-in.huawei.com> for aaa-doctors@ietf.org; Wed, 17 Dec 2008 14:20:24 +0800 (CST)
Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC000BSPCA09P@szxga04-in.huawei.com> for aaa-doctors@ietf.org; Wed, 17 Dec 2008 14:20:24 +0800 (CST)
Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KC000GE2CA081@szxml05-in.huawei.com> for aaa-doctors@ietf.org; Wed, 17 Dec 2008 14:20:24 +0800 (CST)
Date: Wed, 17 Dec 2008 14:20:24 +0800
From: Tina TSOU <tena@huawei.com>
To: Glen Zorn <glenzorn@comcast.net>, aaa-doctors@ietf.org
Message-id: <012101c9600f$8bd3a890$7427460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-Priority: 3
X-MSMail-priority: Normal
References: <EDC652A26FB23C4EB6384A4584434A04011F6F98@307622ANEX5.global.avaya.com> <00d601c95ffd$05192b70$7427460a@china.huawei.com> <001801c96004$62b0cf20$28126d60$@net>
Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2022685740=="
Sender: aaa-doctors-bounces@ietf.org
Errors-To: aaa-doctors-bounces@ietf.org
Hi Glen, I just replied to all in the cc list of Dan sent. Should I just reply to Dan himself? Wish you a joyful greeting season! :D B. R. Tina ----- Original Message ----- From: Glen Zorn To: aaa-doctors@ietf.org Cc: 'Romascanu, Dan (Dan)' ; 'Tina TSOU' Sent: Wednesday, December 17, 2008 1:00 PM Subject: RE: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat I've seen several of this kind of message recently & (not that I don't really appreciate increasing the volume of email that I receive ;-), I'm having trouble understanding what they have to do w/AAA in general or specifically AAA Doctors. Perhaps I'm just ignorant of the relevance but if not could we be a bit more selective in the CC:s? From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Tina TSOU Sent: Wednesday, December 17, 2008 11:08 AM To: IETF DNS Directorate; ops-dir@ietf.org; MIB Doctors (E-mail); aaa-doctors@ietf.org; Romascanu, Dan (Dan) Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat Hi Dan et al, This is a review of Review of draft-ietf-mext-nemo-v4traversal-06 for its operational impact. Summary: The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. Review summary: ----------- Possible Operational Issues: Below are listed a number of issues that may have significant operational impact. Further explanation or investigations is warranted on each of these. --------- Review Questions: Is the document readable? [Tina: Yes] Does it contain nits? [Tina: In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous, Should "vanilla UDP encapsulation" be "valid UDP encapsulation" ] Is the document class appropriate? [Tina: Yes.] Is the problem well stated? [Tina: In section 5.3, it mentioned that if the mobile node is not active, it will send binding update to the home agent, I'm wondering what home agent operates upon receiving the binding update message? Also if the mobile node is not active, does it mean the mobile node is not reachable? And in section 5.3, it mentions that the mobile node maintains NAT binding, if the mobile node is not reachable, then it need not to refresh the NAT binding? What I confuse here is that NAT device also maintains NAT binding associated with the mobile node, so if the mobile node is not reachable, whether the mobile node refreshes the NAT binding in itself or in NAT on the path between the mobile node and the home agent? Moreover if the mobile node is not reachable, does it mean the mobile node change the port or private address? What's the difference for NAT keep alive between the mobile node behind NAT and the home agent behind NAT?] Is the problem really a problem? [Tina: See comment above.] Does the document consider existing solutions? [Tina: Yes.] Does the solution break existing technology? [Tina: No.] Does the solution preclude future activity? [Tina: No.] Is the solution sufficiently configurable? [Tina: Yes.] Can performance be measured? How? [Tina: Yes.] Does the solution scale well? [Tina: Yes.] ---------------- Wish you a joyful greeting season! :D B. R. Tina ----- Original Message ----- From: Romascanu, Dan (Dan) To: aaa-doctors@ietf.org ; MIB Doctors (E-mail) ; ops-dir@ietf.org ; IETF DNS Directorate Sent: Friday, December 12, 2008 4:20 PM Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18,2008 Telechat Please find below the preliminary agenda of the 12/18 telechat. Please review the relevant documents and let me know if there are any concerns or comments until 12/17 COB the latest. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tcpm-tcp-uto-10.txt TCP User Timeout Option (Proposed Standard) - 1 of 12 Token: Magnus Westerlund o draft-ietf-forces-protocol-19.txt ForCES Protocol Specification (Proposed Standard) - 2 of 12 Token: Ross Callon o draft-ietf-forces-mib-10.txt ForCES MIB (Proposed Standard) - 3 of 12 Token: Ross Callon o draft-ietf-calsify-rfc2445bis-09.txt Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Proposed Standard) - 4 of 12 Token: Lisa Dusseault o draft-ietf-mext-nemo-v4traversal-06.txt Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed Standard) - 5 of 12 Token: Jari Arkko o draft-ietf-nfsv4-rpc-netid-05.txt IANA Considerations for RPC Net Identifiers and Universal Address Formats (Proposed Standard) - 6 of 12 Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com) Token: Lars Eggert o draft-ietf-ospf-lls-05.txt OSPF Link-local Signaling (Proposed Standard) - 7 of 12 Token: David Ward o draft-ietf-smime-3851bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Proposed Standard) - 8 of 12 Token: Tim Polk o draft-ietf-smime-3850bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling (Proposed Standard) - 9 of 12 Token: Tim Polk o draft-ietf-pkix-ecc-subpubkeyinfo-10.txt Elliptic Curve Cryptography Subject Public Key Information (Proposed Standard) - 10 of 12 Note: Document shepherd is stefans@microsoft.com Token: Pasi Eronen o draft-freed-sieve-ihave-03.txt Sieve Email Filtering: Ihave Extension (Proposed Standard) - 11 of 12 Token: Lisa Dusseault o draft-ietf-mpls-cosfield-def-08.txt Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field renamed to "Traffic Class" field (Proposed Standard) - 12 of 12 Token: Ross Callon 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-kucherawy-sender-auth-header-18.txt Message Header Field for Indicating Message Authentication Status (Proposed Standard) - 1 of 1 Token: Lisa Dusseault 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-mpls-ldp-igp-sync-03.txt LDP IGP Synchronization (Informational) - 1 of 3 Token: David Ward o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3 Token: David Ward o draft-ietf-roll-urban-routing-reqs-02.txt Urban WSNs Routing Requirements in Low Power and Lossy Networks (Informational) - 3 of 3 Token: David Ward _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
_______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors
- [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package … Romascanu, Dan (Dan)
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Tina TSOU
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Tina TSOU
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Tina TSOU
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Glen Zorn
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Hannes Tschofenig
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Glen Zorn
- Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agend… Romascanu, Dan (Dan)