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

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 13 Feb 2013 15:11:26 +0000

Hi All,

Here's my review/feedback regarding the draft-ietf-ancp-mib-an-10 draft:

Section 4.
While it may be obvious, it likely would be useful to add that the ANCP
Server MIB document is not scoped by this draft. Suggested text could be
something like:

"This document specifies a MIB module an ANCP client, such as an Access
Node (AN). An ANCP server, such as a NAS, would be typically expected to
implement an ANCP server MIB that is not covered by this document."

Section 5.4 (but applicable to whole document as it pops up throughout)
It would be preferable to recast sentences such as
 "This table is used to configure ANCP sessions at the AN towards a
      specific NAS"

To:
This table is used to configure ANCP sessions at the ANCP client towards a
      specific ANCP server.

Section 5.4
Text says: "Each session configured in ancpAnSessionConfigTable has a
corresponding row in ancpAnCurrentSessionTable."

As currently defined there seems to be little difference between the
ancpAnSessionConfigTable and the ancpAnCurrentSessionTable.
Shouldn't the intent be that only active sessions, makred as such in the
ancpAnSessionConfigTable, be represented in the ancpAnCurrentSessionTable?

Section 7.

AncpSessionCapabilities

The capabilities list does not reflect the capabilities we have in the
defined in other ANCP specs.
Missing are:
- Multicast 
(http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-08#section-6)
- PON (TBD)

The names of the capabilities shown should be aligned to what we have in:
http://tools.ietf.org/html/rfc6320#section-10.7

ancpAnSessionConfigNasIpAddressType and ancpAnCurrentSessionAnIpAddressType

Shouldn't the syntax also detail the allowed values for say
InetAddressType? Eg
SYNTAX     InetAddressType { ipv4(1), ipv6(2) }

ancpAnSessionConfigNasIpAddress and ancpAnCurrentSessionAnIpAddress

Shouldn't the syntax also indicate the size? Eg
SYNTAX InetAddress ( SIZE (4|16) )

Why isn't there an ancpANSessionConfigIPAddress* ? If the assumption is
that this address becomes derived only from the IF-MIB, and the assignment
of interfaces to the ANCP session, then it would be helpful to explain
that to the reader.

Regards,
Woj..

---

From: Moti Morgenstern <[email-masked]>
Date: Mon, 18 Feb 2013 13:50:29 +0000

Hi,

See inline my comments.

Regards,
Moti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, February 13, 2013 5:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [ANCP] comments on draft-ietf-ancp-mib-an-10

Hi All,

Section 4.
While it may be obvious, it likely would be useful to add that the ANCP Server MIB document is not scoped by this draft. Suggested text could be something like:

"This document specifies a MIB module an ANCP client, such as an Access Node (AN). An ANCP server, such as a NAS, would be typically expected to implement an ANCP server MIB that is not covered by this document."

**** MM: OK ****

Section 5.4 (but applicable to whole document as it pops up throughout) It would be preferable to recast sentences such as  "This table is used to configure ANCP sessions at the AN towards a
      specific NAS"

To:

**** MM: OK ****

Section 5.4
Text says: "Each session configured in ancpAnSessionConfigTable has a corresponding row in ancpAnCurrentSessionTable."

As currently defined there seems to be little difference between the ancpAnSessionConfigTable and the ancpAnCurrentSessionTable.
Shouldn't the intent be that only active sessions, makred as such in the ancpAnSessionConfigTable, be represented in the ancpAnCurrentSessionTable?

**** MM: 
The description clause of the ancpAnCurrentSessionTable currently says that "A row in this table is created when the corresponding row in the ancpAnSessionConfigTable is created". I agree that it is too early to expect any status associated with a session that was just created and still isn't fully configured. That is, the row in the status table is meaningful only after the row in the configuration table is activated. So, there is a need to correct the description.
However, I think that the term "active sessions" actually covers sessions that their ancpAnSessionConfigRowStatus object is either set to 'active' or 'notInService'. 
****

Section 7.

AncpSessionCapabilities

The capabilities list does not reflect the capabilities we have in the defined in other ANCP specs.
Missing are:
- Multicast
(http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-08#section-6)
- PON (TBD)

**** MM: 
There are plenty of capabilities in ANCP but I didn't manage to find any "list". So, probably 'multicast' and 'PON' should be added. I assume we need also to add 'Line Connectivity Testing'. But, I also assume that those three are not the only missing capabilities.
****

**** MM: OK ****

Shouldn't the syntax also detail the allowed values for say InetAddressType? Eg
SYNTAX     InetAddressType { ipv4(1), ipv6(2) }

**** MM: 
I think that the following two actions are required:
1) Add a sentence in the description clause of each object saying: "While other types of addresses are defined in the InetAddressType textual convention, this object is limited to IPv4
       and IPv6 addresses." 
2) Put a limit in the MODULE-COMPLIANCE statement, e.g.

    OBJECT ancpAnSessionConfigNasIpAddressType
    SYNTAX  InetAddressType { unknown(0), ipv4(1), ipv6(2) }
    DESCRIPTION
       "An implementation is only required to support IPv4 and IPv6 addresses."
****

Shouldn't the syntax also indicate the size? Eg SYNTAX InetAddress ( SIZE (4|16) )

**** MM: 
I think that the following two actions are required:
1) Indicate in the description clause of each object that the object is limited to IPv4 and IPv6 addresses. 
2) Put a limit in the MODULE-COMPLIANCE statement, e.g.

    OBJECT ancpAnSessionConfigNasIpAddress
    SYNTAX  InetAddress (SIZE(0|4|16))
    DESCRIPTION
       "An implementation is only required to support IPv4 and globally unique IPv6 addresses."
****

Why isn't there an ancpANSessionConfigIPAddress* ? If the assumption is that this address becomes derived only from the IF-MIB, and the assignment of interfaces to the ANCP session, then it would be helpful to explain that to the reader.

Regards,
Woj..

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 18 Feb 2013 10:52:38 -0500

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.

> This table is used to configure ANCP sessions at the ANCP client towards a
...

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 18 Feb 2013 16:18:29 +0000

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" <[email-masked]> wrote:

>>It would be preferable to recast sentences such as  "This table is used
>>to configure ANCP sessions at the AN towards a
>>        specific NAS"
>>
>> To:

---

From: Tom Taylor <[email-masked]>
Date: Mon, 18 Feb 2013 14:48:52 -0500

That is, it applies to the Access Node side.

...

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Tue, 19 Feb 2013 08:48:57 +0000

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.

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.

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: maandag 18 februari 2013 20:49
To: Wojciech Dec (wdec)
Cc: [email-masked]
Subject: Re: [ANCP] comments on draft-ietf-ancp-mib-an-10

...

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Feb 2013 09:00:52 +0000

Hi,

On 19/02/2013 09:48, "DE CNODDER, STEFAAN (STEFAAN)"
<[email-masked]> 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..

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Tue, 19 Feb 2013 09:17:44 +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:[email-masked]] 
Sent: dinsdag 19 februari 2013 10:01
To: DE CNODDER, STEFAAN (STEFAAN)
Cc: [email-masked]
Subject: Re: [ANCP] comments on draft-ietf-ancp-mib-an-10

Hi,

Regards,
Woj..