Subject: [ANCP] comments on draft-ietf-ancp-protocol-01

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 27 Aug 2007 09:21:20 +0200

Hi,

I have a number of comments on draft-ietf-ancp-protocol-01:

1) There are some inconsistencies in terminology with the framework
document:  The framework talks about CPE and HGW while the protocol
draft uses the terms DSL modem, RG, and subscriber devices (see fig.1).
  Best to allign with the framework document.  Also in section  4.5,
second paragraph the term CPE is used while this is called the HGW in
the framework document and in the framework, CPE means something else.

2) although the draft is not anymore based on
draft-ietf-gsmp-v3-base-spec but on RFC 3292 instead, it is still using
a number of extensions defined in that draft, which do not make sense
anymore:

2a) Tech type in section 5.4.1.1: tech type 1-4 were defined in
draft-ietf-gsmp but not in RFC 3292 so it makes no sense in saying that
these are already in use by other technologies.  Just make them
reserved.  Also tech type 0xff is not in use by the base spec (which is
RFC 3292).

2b) Message format on page 24: The "block length" field was defined in
draft-ietf-gsmp but not in RFC 3292.  Since this field is only 1 byte
and not sufficient for ANCP, the ANCP protocol draft defines a new
length field of 2 bytes.  Since the GSMP draft does not exist anymore,
it makes no sense in keeping the original 1-byte "block length" field.
Better to call this 1-byte field now "Reserved"

2c) The X-Function field on page 32 is not used by ANCP and is also not
defined by RFC 3292.  It looks better to me to use the original GSMP
message format in this case by using a 2 byte Function field.

2d) Like the message on page 24, also the message format on page 32 has
a 1-byte Block length field that is better renamed to "Reserved".

3) Section 5.2 says that the pType field should be set to 0.  Is this
also the case when partitions are used?  The framework mentions
partitions and I believe the protocols spec should support partitions as
well.

4) Section 5.3: ANCP should be extensible to support multiple
technologies but I do not see how the capability message can be extended
with multiple technologies because it looks that only 1 techtype can be
put in the message.  Is it the intention that when there is a second
technogoly, then there are 2 independent capability negotiations (with 2
different messages?  This comment does not apply to other messages
because for instance in a PORT UP, there will always only be 1 technology.

5) Related to bulk transaction messages:

5a) For the bulk transaction message, what should be the result if 1 
message fails?  I guess the whole bulk message would fail but is there a 
specific code for it?

5b) can PORT UP or DOWN messages also be part of a bulk transaction? 
And what about OAM?  I believe the bulk transaction is only for Line 
configuration messages?

6) For line configuration, an unknown TLV is to be ignored.  Would it 
not be better for these TLVs to have a result field per TLV such that 
the NAS knows which configuration is done, and which not?  For PORT UP 
it is not relevant because the AN does not have to know what the NAS is 
doing with the information but for line configuration this looks different.

7) action 0x8 defined in section 5.4.3 is already in use by RFC 3292

8) The IANA considerations section looks incomplete to me:

8a) Besides of defining new numbers for Tech-type, ..., also a complete 
new name space has to be defined and maintained by IANA.

8b) the name spaces for result field and code field should be modified 
because ANCP is changing the length of these fields, and hence also the 
numbers that can be assigned for it.  The name spaces "failure response 
message" and "Result type" have to be redefined.

8c) 0x81 failure code to be assigned by IANA, also the OAM codes.

Some minor comments:
- section 3.1, second paragrah, first sentence: replace "Access Network"
by "Access Aggregation Network" to be in line with figure 1.
- section 5, page 15: : "However, the usage of these messages by ANCP, 
along with relevant modifications and extensions required by ANCP, are 
described in sections 5.3, 5.4.1, 5.4.2 and 5.4.3 of this document." -> 
also section 5.4.4 defines extensions.  Better to change this into 
Section 5.4.
- why are the Access-Loop-Circuit-ID limited to 63 bytes?  And why is 
"upto 63 bytes" put between brackets?

regards,
Stefaan

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