Re: [ANCP] comments on draft-ietf-ancp-mib-an-10

"DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com> Tue, 19 February 2013 09:18 UTC

Return-Path: <stefaan.de_cnodder@alcatel-lucent.com>
X-Original-To: ancp@ietfa.amsl.com
Delivered-To: ancp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933B121F8CF2 for <ancp@ietfa.amsl.com>; Tue, 19 Feb 2013 01:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ll0eqSE8ZYu for <ancp@ietfa.amsl.com>; Tue, 19 Feb 2013 01:18:06 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B879821F85E7 for <ancp@ietf.org>; Tue, 19 Feb 2013 01:18:05 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1J9I1Ub012762 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Feb 2013 10:18:01 +0100
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 19 Feb 2013 10:17:45 +0100
Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.242]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 19 Feb 2013 10:17:45 +0100
From: "DE CNODDER, STEFAAN (STEFAAN)" <stefaan.de_cnodder@alcatel-lucent.com>
To: "Wojciech Dec (wdec)" <wdec@cisco.com>
Thread-Topic: [ANCP] comments on draft-ietf-ancp-mib-an-10
Thread-Index: AQHOCfxkxE0hg9WvI06dFUQKsmGrTJh/h66ggAAziQCAAAc5gIAAOsgAgADppSCAAHm+gP//jxiw
Date: Tue, 19 Feb 2013 09:17:44 +0000
Message-ID: <5F657CFC59E51E4B842F0D51C19AC36CF007@FR711WXCHMBA06.zeu.alcatel-lucent.com>
References: <5F657CFC59E51E4B842F0D51C19AC36CEF95@FR711WXCHMBA06.zeu.alcatel-lucent.com> <19F346EB777BEE4CB77DA1A2C56F20B3224723@xmb-aln-x05.cisco.com>
In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B3224723@xmb-aln-x05.cisco.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: "ancp@ietf.org" <ancp@ietf.org>
Subject: Re: [ANCP] comments on draft-ietf-ancp-mib-an-10
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2013 09:18:06 -0000

Yes, I agree, naming and numbering of the capabilities should be made in line with RFC 6320, something like:

	DslTopologyDiscovery (1)
      DslLineConfiguration (2)
	DslRemoteLineConnectivityTesting (4)

instead of what is now in the MIB.

Thanks,
Stefaan


-----Original Message-----
From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] 
Sent: dinsdag 19 februari 2013 10:01
To: DE CNODDER, STEFAAN (STEFAAN)
Cc: ancp@ietf.org
Subject: Re: [ANCP] comments on draft-ietf-ancp-mib-an-10

Hi,

On 19/02/2013 09:48, "DE CNODDER, STEFAAN (STEFAAN)"
<stefaan.de_cnodder@alcatel-lucent.com> wrote:

>Hi,
>
>I think indeed that the document may be more explicit that it is only for
>AN and not for NAS.  However, introducing new terminology in a MIB
>document is the wrong place.  It is indeed a client-server protocol, but
>saying that this is a client MIB while "client" has never been defined
>before, is not going to make it clearer.

I'm fine with that - just clarify.

>
>About the capabilities: it is a MIB for only RFC 6320.  If other
>documents introduce new functionality like PON or multicast, then this
>requires a new MIB module that also defines objects to enable and disable
>the capabilities of that functionality.

We should have some brief text around that (ie advice on how this MIB
module should be extended).
On further inspection I also noticed that the current capability code
points in the MIB do not align not only in naming but also in numbering
with RFC6320. Would suggest that the two be aligned (which is better than
getting an IANA registry for the MIB)

Regards,
Woj..

>
>regards,
>Stefaan
>
>
>-----Original Message-----
>From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of
>Tom Taylor
>Sent: maandag 18 februari 2013 20:49
>To: Wojciech Dec (wdec)
>Cc: ancp@ietf.org
>Subject: Re: [ANCP] comments on draft-ietf-ancp-mib-an-10
>
>That is, it applies to the Access Node side.
>
>On 18/02/2013 11:18 AM, Wojciech Dec (wdec) wrote:
>> Yes, and in retrospect its rather unfortunate, since it is a
>>client-server
>> protocol with the functions in AN-NAS respectively.
>> The main point though is that the ANCP MIB draft does not apply to the
>> server side.
>>
>> Regards,
>> Woj..
>>
>> On 18/02/2013 16:52, "Tom Taylor" <tom.taylor.stds@gmail.com> wrote:
>>
>>> Could I point out that the RFC 6320 does not talk about clients and
>>> servers? It talks about the AN and the NAS. And either side can
>>>initiate
>>> transactions, depending on the transaction, so I think the
>>>client-server
>>> terminology would actually be confusing. Sorry, I should have noted
>>>this
>>> point earlier.
>>>
>>> On 18/02/2013 8:50 AM, Moti Morgenstern wrote:
>...
>_______________________________________________
>ANCP mailing list
>ANCP@ietf.org
>https://www.ietf.org/mailman/listinfo/ancp