Re: [AAA-DOCTORS] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat

Tina TSOU <tena@huawei.com> Tue, 16 December 2008 08:27 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 15A7E28C125; Tue, 16 Dec 2008 00:27:09 -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 27E0028C125; Tue, 16 Dec 2008 00:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.545
X-Spam-Level:
X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1]
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 t3CnjCSCaNE8; Tue, 16 Dec 2008 00:27:06 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 070EA28C0F8; Tue, 16 Dec 2008 00:27:06 -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 <0KBY001QBNCCE5@szxga04-in.huawei.com>; Tue, 16 Dec 2008 16:24:12 +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 <0KBY001I8NCCUF@szxga04-in.huawei.com>; Tue, 16 Dec 2008 16:24:12 +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 <0KBY007P9NCC1O@szxml05-in.huawei.com>; Tue, 16 Dec 2008 16:24:12 +0800 (CST)
Date: Tue, 16 Dec 2008 16:24:07 +0800
From: Tina TSOU <tena@huawei.com>
To: IETF DNS Directorate <dns-dir@ietf.org>, ops-dir@ietf.org, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, aaa-doctors@ietf.org, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Message-id: <015f01c95f57$ace5bae0$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>
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="===============1139025483=="
Sender: aaa-doctors-bounces@ietf.org
Errors-To: aaa-doctors-bounces@ietf.org

Hi Dan et al,
Review of draft-ietf-tcpm-tcp-uto-10 is below.

 ---------
Review Questions:

Is the document readable?
[Tina: Yes.]

Does it contain nits?
[Tina: 
1) The connectivity sometimes appears as "connectivity", sometimes appears as "E2E connectivity". Should they be put consistent? Or does it mean intra-net, internet respectively?
2) Should "application-specified user timeout"be "application-specific user timeout"?
3) 
Section 3,
"Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO   values."  
Should "active" be "proactive"?
4) Section 5,
"Several approaches can help mitigate this issue."
Should "mitigate" be "mitigating"?]

Is the document class appropriate?
[Tina: Yes.]

Is the problem well stated?
[Tina: what's the real benefit to the network? In the document, I see that the timeout can be changed bigger or smaller, but it is already in the network by configuration. The only benefit is that this timeout change can be advertised from one end to the other, and then the other end could use it as an input to compute its own timeout. It is not a big benefit, IMHO.]

Is the problem really a problem?
[Tina: concern is as above.]

Does the document consider existing solutions?
[Tina: yes, it does. However, same concern is as above.]

Does the solution break existing technology?
[Tina: No.]

Does the solution preclude future activity?
[Tina: No.]

Is the solution sufficiently configurable?
[Tina: I would like to see clearer procedure in this document. For example,
Should the timeout be configured in the server, and then in the SYS segment, when the client requests, the server returns the time out to client? It is because one server has many unknown clients.]

Can performance be measured?  How?
[Tina: it does not show very well in the document.]

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