Subject: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 27 Dec 2009 08:44:11 +0100

Hi all, 

I just went through http://www.ietf.org/id/draft-ietf-ancp-framework-12.txt. 

It is a nice and interesting document but I noticed a few minor areas for improvement. 

0. Terminology

If you cite some ITU-T documents then put the cited text in quotes. If you modify their definition then say so. 

1. Definition of "Multicast flow"

Here is what you have in the draft 

"
   o  Multicast Flow: multicast Any Source Multicast (ASM) group or
      multicast Source Specific Multicast (SSM) (S,G) channel.  An
      application channel (such as a TV channel) is mapped onto a
      Multicast Flow.
"

This does not sound complete nor understandable. 
Looking at RFC 4045 http://tools.ietf.org/html/rfc4045 I can find the following definition:

"
   Multicast flow

      Designates datagrams sent to a group from a set of sources for
      which multicast reception is desired.
"

Maybe this is more appropriate? 

3. "General Architecture Aspects" Section 

The "Access Node Control Mechanism" term is described as 
"	  
   o  Access Node Control Mechanism: a method for multiple network
      scenarios with an extensible communication scheme that conveys
      status and control information between one or more ANs and one or
      more NASs without using intermediate element managers.
"

There are two concepts that readers are typically familiar with, namely a protocol and an architecture. 
The main product of the working group is the protocol. The architecture already exists elsewhere, namely largely in the Broadband Forum (former DSL Forum) and there is potential (maybe) applicability elsewhere (e.g., IEEE 802.16). 

Now, Section 2.1 describes something that others would typically call "architecture". Section 2.2 is a mixture of a) description of Figure 1, and 
b) the text provides an instantiation of the architectural figure shown in Section 2.1. 

Section 2.3. has the fancy title of "Access Node Control Mechanism Transport Methods". What this section only does is to discuss how QoS treatment of control traffic can be accomplished when used over Ethernet and ATM networks. I don't think that this is crucial for the description of the architecture but your view might be different. Maybe there is a chance to provide a better introduction to this section and a different title for the section. Something like "Preferential Treatment for Signaling Traffic" or "Separating Signaling and Control Traffic".

Section 2.4 is also not very fortunate with regard to the section heading. "Operations and Management" is a rather broad term and you address only a very specific aspect in this section, namely the challenge of having more than one management entities and the potential conflicts that may arise. 

Overall, I believe that there is something wrong with the structure of Section 2. The introduction of Section 2 talks about two aspects that are described but then there are 5 sub-sections, with an unclear relationship among either other. Some "glue" is missing here. 

4. Figures have a title.  

Figure 1 is missing a title. 

5. Abbreviations

When you introduce abbreviations please expand them (otherwise you will be asked again by the RFC Editor later). 

6. "Access Node" and other terms. 

Section 1.2 defines the term "Access Node" and Section 2.2.3 defines it again. 
The same is true for "Network Access Server" defined in Section 1.2 and again defined in Section 2.2.6.  

7. Justify your statements

When you talk about other mechanisms being error prone and complex then you need to provide a discussion why they are error prone or more complex than the mechanism being proposed here to gain credibility. 

Example:

"
   OSS systems are rarely able to enforce in a reliable and scalable
   manner the consistency of such data, notably across organizational
   boundaries. 
   The Access Topology Discovery function allows the NAS to
   perform these advanced functions without having to depend on an
   error-prone & possibly complex integration with an OSS system.
"

8. Section 3.2 - OPEX

I have a question regarding the OPEX statement in the following paragraph:

"
   Access Loop rates are typically configured in a static way.  When a
   Subscriber wants to change its Access Loop rate, the network operator
   needs to reconfigure the Access Port configuration, possibly implying
   a business-to-business transaction between an Internet Service
   Provider (ISP) and an Access Provider.  From an Operating
   Expenditures (OPEX) perspective this is a costly operation.

   Using the Access Node Control Mechanism to change the Access Loop
   rate from the NAS avoids those cross-organization business-to-
   business interactions and allows to centralize Subscriber-related
   service data in e.g. a Policy Server.
"  

I guess I understand that there are still two organizations involved but you essentially claim that by using some protocol mechanisms the OPEX cost would be reduced compared to a potential human interaction as it is done today. 
Is my understanding correct? 

9. Section 5 "Policy Server Interaction" is useless. Maybe better to delete this section?
   
10. Editorial issues 

Let some native English speaker read through the text to make sure that the language, punctuation, etc. problems get fixed. 

Ciao
Hannes

---

From: Tina TSOU <[email-masked]>
Date: Sun, 27 Dec 2009 21:19:25 +0800

Hi Hannes,
Merry X'mas and see comments in line...
I'm not the editor, just one participant of many.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

On Dec 27, 2009, at 3:44 PM, Hannes Tschofenig wrote:

> If you cite some ITU-T documents then put the cited text in quotes.  
> If you modify their definition then say so.
>
Agreed.
> The main product of the working group is the protocol. The  
> architecture already exists elsewhere, namely largely in the  
> Broadband Forum (former DSL Forum) and there is potential (maybe)  
> applicability elsewhere (e.g., IEEE 802.16).
>
> Now, Section 2.1 describes something that others would typically  
> call "architecture". Section 2.2 is a mixture of a) description of  
> Figure 1, and
> Section 2.3. has the fancy title of "Access Node Control Mechanism  
> Transport Methods". What this section only does is to discuss how  
> QoS treatment of control traffic can be accomplished when used over  
> Ethernet and ATM networks. I don't think that this is crucial for  
> the description of the architecture but your view might be  
> different. Maybe there is a chance to provide a better introduction  
> to this section and a different title for the section. Something  
> like "Preferential Treatment for Signaling Traffic" or "Separating  
> Signaling and Control Traffic".
>
> Section 2.4 is also not very fortunate with regard to the section  
> heading. "Operations and Management" is a rather broad term and you  
> address only a very specific aspect in this section, namely the  
> challenge of having more than one management entities and the  
> potential conflicts that may arise.
I thought the section of "Operations and Management" is required to be  
considered, and be described if any. And different draft put the  
specific aspect under this section. Perhaps keep the section heading  
"Operations and Management", and add some texts saying this draft only  
has a specific aspect regarding OPS.
>
> Overall, I believe that there is something wrong with the structure  
> of Section 2. The introduction of Section 2 talks about two aspects  
> that are described but then there are 5 sub-sections, with an  
> unclear relationship among either other. Some "glue" is missing here.
>
> 4. Figures have a title.
>
> When you introduce abbreviations please expand them (otherwise you  
> will be asked again by the RFC Editor later).
>
Need to fix them.
> When you talk about other mechanisms being error prone and complex  
> then you need to provide a discussion why they are error prone or  
> more complex than the mechanism being proposed here to gain  
> credibility.
>
> Example:
>
> "
Agreed.
> I guess I understand that there are still two organizations involved  
> but you essentially claim that by using some protocol mechanisms the  
> OPEX cost would be reduced compared to a potential human interaction  
> as it is done today.
I think so.
> 9. Section 5 "Policy Server Interaction" is useless. Maybe better to  
It is used in the network, so it is needed.
>
> 10. Editorial issues
>
> Let some native English speaker read through the text to make sure  
> that the language, punctuation, etc. problems get fixed.
Agreed.
>
>
> Ciao
> Hannes
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 27 Dec 2009 19:26:01 +0100

Hi Tina, 

thanks for the response. See below. 

-------- Original-Nachricht --------
> Datum: Sun, 27 Dec 2009 21:19:25 +0800
> Von: Tina TSOU <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: [email-masked]
> Betreff: Re: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt

> http://tinatsou.weebly.com/contact.html

~snip~

> has a specific aspect regarding OPS.

There is no requirement to have a section with the title "Operations and Management" in IETF drafts. 

I am, however, not saying that it isn't useful to consider these types of aspects. 

~snip~

> It is used in the network, so it is needed.

Someone else in the document it is already said that there is an interaction with a AAA/Policy Server but it is outside the scope of the document. I am fine with such a scope restriction and hence I don't think it makes sense to make the same statement twice, once in the text and then as a subsection. 

Ciao
Hannes