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