[Capwap] There is one issue (commented by Pasi) left

young <young@h3c.com> Tue, 26 January 2010 10:05 UTC

Return-Path: <capwap-bounces+capwap-archive=lists.ietf.org@frascone.com>
X-Original-To: ietfarch-capwap-archive@core3.amsl.com
Delivered-To: ietfarch-capwap-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453413A6405 for <ietfarch-capwap-archive@core3.amsl.com>; Tue, 26 Jan 2010 02:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.302
X-Spam-Level: *
X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-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 wBpj2ZPUUvwm for <ietfarch-capwap-archive@core3.amsl.com>; Tue, 26 Jan 2010 02:05:13 -0800 (PST)
Received: from lists.tigertech.net (lists.tigertech.net [64.62.209.34]) by core3.amsl.com (Postfix) with ESMTP id 21A493A68E4 for <capwap-archive@lists.ietf.org>; Tue, 26 Jan 2010 02:05:13 -0800 (PST)
Received: from zoidberg.tigertech.net (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0D97AE181CC for <capwap-archive@lists.ietf.org>; Tue, 26 Jan 2010 02:05:23 -0800 (PST)
Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by lists.tigertech.net (Postfix) with ESMTP id 83548E240E1 for <capwap@lists.tigertech.net>; Tue, 26 Jan 2010 02:05:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5CFE73610003 for <capwap@frascone.com>; Tue, 26 Jan 2010 02:05:16 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C76D53610001 for <capwap@frascone.com>; Tue, 26 Jan 2010 02:05:15 -0800 (PST)
X-TigerTech-Content-Filter: Clean
X-TigerTech-Spam-Status: Level 0 (High) (P0); Whitelisted TTSSA (young@h3c.com whitelisted)
Received: from huawei-3com.com (unknown [60.191.123.56]) by mx1.tigertech.net (Postfix) with ESMTP for <capwap@frascone.com>; Tue, 26 Jan 2010 02:05:15 -0800 (PST)
Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KWU00K3LN964J@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 26 Jan 2010 18:17:30 +0800 (CST)
Received: from h3cmta02-ds.h3c.com ([172.25.12.70]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KWU00KXSN96NV@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 26 Jan 2010 18:17:30 +0800 (CST)
Received: from smtp1.h3c.com ([172.25.14.252]) by h3cmta02-ds.h3c.com (Lotus Domino Release 8.5FP1) with ESMTP id 2010012618051416-1853633 ; Tue, 26 Jan 2010 18:05:14 +0800
Received: from unknown (HELO s00338) ([10.154.68.122]) by smtp1.h3c.com with ESMTP; Tue, 26 Jan 2010 18:02:05 +0800
Date: Tue, 26 Jan 2010 18:05:05 +0800
From: young <young@h3c.com>
In-reply-to: <808FD6E27AD4884E94820BC333B2DB775841199B38@NOK-EUMSG-01.mgdnok.nokia.com>
To: Pasi.Eronen@nokia.com
Message-id: <007701ca9e6f$08f67b10$7a449a0a@h3c.huawei3com.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook, Build 10.0.6856
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-MIMETrack: Itemize by SMTP Server on h3cmta02-ds/h3c(Release 8.5FP1|June 15, 2009) at 2010-01-26 18:05:14, Serialize by Router on h3cmta02-ds/h3c(Release 8.5FP1|June 15, 2009) at 2010-01-26 18:05:14, Serialize complete at 2010-01-26 18:05:14
Thread-index: AcqcprveNuuKdJCPS0+7LqXFIzj9XQBxK5xQAAC8lLA=
Cc: capwap-chairs@tools.ietf.org, capwap@frascone.com, yozhang@gmail.com, iesg@ietf.org, draft-ietf-capwap-base-mib@tools.ietf.org
Subject: [Capwap] There is one issue (commented by Pasi) left
X-BeenThere: capwap@frascone.com
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: A list for CAPWAP technical discussions <capwap.frascone.com>
List-Post: <mailto:capwap@frascone.com>
X-Tigertech-Mailman-Hint: 636170776170
List-Subscribe: <http://lists.frascone.com/mailman/listinfo/capwap>, <mailto:capwap-request@frascone.com?subject=subscribe>
List-Unsubscribe: <http://lists.frascone.com/mailman/listinfo/capwap>, <mailto:capwap-request@frascone.com?subject=unsubscribe>
List-Archive: <http://lists.frascone.com/pipermail/capwap>
List-Help: <mailto:capwap-request@frascone.com?subject=help>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com

Hi, Pasi:

Thanks a lot. 
So for your comments, there is only one issue (about section 9.1/9.2) left.
I would try to give reply by tomorrow.

BTW, in the end, once we could close this last issue, I would
Put all the changes required in one email, then asked you
give a double Confirm.
Thanks for your guidance. 

Regards
Richard

-----邮件原件-----
发件人: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
发送时间: 2010年1月26日 17:49
收件人: young@h3c.com
抄送: capwap-chairs@tools.ietf.org; capwap@frascone.com; dromasca@avaya.com;
yozhang@gmail.com; iesg@ietf.org; draft-ietf-capwap-base-mib@tools.ietf.org
主题: RE: Please check my comments,thanks (draft-ietf-capwap-base-mib)

shiyang 00338 wrote:

>> I'm still not sure the MIB object is useful. First of all, such
>> DTLS configuration MIB does not currently exist (and is not even
>> planned). Second, it hard-codes an assumption that all WTPs
>> connected to an AC use same type of authentication. The CAPWAP
>> protocol itself would allow some WTPs so use X.509 and others PSK,
>> so if your AC implementation supports this, it can't implement this
>> MIB object.
>> 
>> BTW, the same limitation seems to apply to
>> e.g. capwapBaseDataChannelDTLSPolicyConfig, too -- if your AC
>> supports configuring DTLS for only some WTPs (perhaps those located
>> in physically less secure environments), it cannot implement this
>> MIB object.
>> 
>> If the WG feels this MIB object is anyway useful, at the very least it
>> should point out that many ACs may not be able to implement it.

> ////////////////////
> [Richard]
> Any way, the configuration of such authentication parameter should
> not be in the scope of CAPWAP MIB (I explained it in the last
> email).  As per Pasi's comments, I agree to remove both
> capwapBaseControlChannelAuthenConfig and
> capwapBaseDataChannelDTLSPolicyConfig.

OK.

>>> [Richard]
>>> Yes, capwapBaseWtpState indicates the AC's CAPWAP FSM state for
>>> each WTP, not the WTP's FSM.  The capwapBaseWtpState is a MIB object
>>> on the AC.
> 
>> OK; please clarify the description accordingly.
>
> //////////
> [Richard]
> The description would be modified:
> capwapBaseWtpStateTable OBJECT-TYPE
>     SYNTAX      SEQUENCE OF CapwapBaseWtpStateEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "A table of objects that indicate the AC's CAPWAP FSM state
>          for each WTP, and helps the operator to query the WTPs'
>          current
>          configuration."
>     ::= { capwapBaseWtps 2 }
> 
> capwapBaseWtpStateEntry  OBJECT-TYPE
>     SYNTAX      CapwapBaseWtpStateEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "A set of objects that display the AC's CAPWAP FSM state
>          for each WTP.
>          Also, the operator could query the current configuration
>          of a WTP by using the identifier of the corresponding
>          WTP profile."
>     INDEX { capwapBaseWtpStateWtpId }
>     ::= { capwapBaseWtpStateTable 1 }
> 
> capwapBaseWtpStateEntry  OBJECT-TYPE
>     SYNTAX      CapwapBaseWtpStateEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "A set of objects that display the AC's CAPWAP FSM state
>          for each WTP.
>          Also, the operator could query the current configuration
>          of a WTP by using the identifier of the corresponding
>          WTP profile."
>     INDEX { capwapBaseWtpStateWtpId }
>     ::= { capwapBaseWtpStateTable 1 }
> 
>     capwapBaseWtpState  OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   dtls(1),
>                   join(2),
>                   image(3),
>                   configure(4),
>                   dataCheck(5),
>                   run(6),
>                   reset(7),
>                   dtlsTeardown(8),
>                   unknown(9)
>                 }
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>         "Represents the various possible the AC's CAPWAP FSM state
>          for each WTP.
>          The following enumerated values are supported:
>            dtls(1)         - DTLS negotiation states, which include
>                              DTLS setup, authorize, DTLS connect
>            join(2)         - The WTP is joining with the AC
>            image(3)        - The WTP is downloading software
>            configure(4)    - The WTP is getting configuration from
>                              the AC
>            dataCheck(5)    - The AC is waiting for the Data Channel
>                              Keep Alive Packet
>            run(6)          - The WTP enters the running state
>            reset(7)        - The AC transmits a reset request message
>                              to the WTP
>            dtlsTeardown(8) - DTLS session is tear down
>            unknown(9)      - Operator already prepared configuration
>                              for the WTP, while the WTP has not contact
>                              with the AC till now"
>     REFERENCE
>         "Section 2.3.1. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseWtpStateEntry 5 }
> 
> The section 6 also needs change:
>    4) capwapBaseWtpStateTable
>    The WTPs status table is used to indicate the AC's CAPWAP FSM state
>    for each WTP, and helps operator to query WTPs' current
> configuration.

Looks good!

<snip>
(I see there're separate emails about the NAT-related things,
so I'm omitting those from here.)

<snip>
>>> [Richard] You are correct, it is not required to give a scope limit
>>> to the capwapBaseMacAclId. The editors misunderstood the value 255
>>> mentioned in the RFC5415.
>> 
>> OK.
>
> ////////////////
> [Richard]
> the change would be:
> capwapBaseMacAclId OBJECT-TYPE
>     SYNTAX      Unsigned32
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>         "Represents the unique identifier of an ACL."
>     ::= { capwapBaseMacAclEntry 1 }

Looks good!

Best regards,
Pasi



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap