Subject: Re: [ANCP] comments on -12

From: Alan Kavanagh <[email-masked]>
Date: Fri, 1 Oct 2010 15:31:11 -0400

Thanks Tom

This works for me, good job.

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: September-23-10 10:58 PM
To: [email-masked]
Cc: Alan Kavanagh; [email-masked]; [email-masked]
Subject: AW: AW: [ANCP] comments on -12

Tom,

Thanx. So far I agree. But please refer to TR-147 instead of TR-101. 
TR-147 is the related BBF work für layer 2 control.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Tom Taylor [mailto:[email-masked]]
Gesendet: Freitag, 24. September 2010 04:45
An: Haag, Thomas
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: [ANCP] comments on -12

After some discussion with interested parties here at the BBF, here is my proposed resolution:

-- leave the text that says "implementations that support capability X must support the following protocol elements:"

-- remove all mention of "optional" and "mandatory" from the documentation of individual TLVs

-- perhaps add text in the procedural section that says that the usage of individual TLVs is as indicated by applicable specifications, in particular, TR-101.

On 23/09/2010 9:24 PM, [email-masked] wrote:
> All,
>
> I don't think that we should differentiate between optional and mandatory because the definitons of the TLVs are needed anyway and available in access nodes.
>
> Particular I refer to chapter 5.2.3.3.6.1 - 5.2.3.3.6.15 of current protocol draft version 12.
>
> Considering BBF TR-147 Table 1, page 45 there is no difference between mandatory and optional and all related parameters are mandatory.
> Only TR-101 allows to differenciate between optional and mandatory in conjunction to DHCP relay requirements.
> Implementations follow the whole parameterset.
>
> In order to keep consistency between both workflows and avoiding interoperability issues I really propose to set all these parameters mentioned above to "mandatory". It really does not make sense if different access node implementations may exist using different TLVs terminated possibly at same BRAS.
>
> Regards
>
> Thomas
>
...

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 04 Oct 2010 13:45:45 +0200

Hello,

On 24/09/2010 04:45, "Tom Taylor" <[email-masked]> wrote:

> -- leave the text that says "implementations that support capability X
> must support the following protocol elements:"

That does not appear to be normative terminology, and thus not terribly
useful. Furthermore, even if made normative, mandating all the protocol
elements is highly questionable as there are clear duplicates (eg ascii and
binary circuit-id) as well as items which are evidently optional (depending
on access technology, etc).

> documentation of individual TLVs

That would be a mistake, in that it will be interpreted as "all are
optional". If the protocol spec is to give some guidance to implementers,
the base minimum needs to be spelled out, and that minimum does not appear
to be "all".
Note: The protocol spec actually does not specify the behavior for messages
that get sent without the "required" TLVs...

> 
> -- perhaps add text in the procedural section that says that the usage
> of individual TLVs is as indicated by applicable specifications, in
> particular, TR-101.

If the usage of TLVs is unclear in the protocol spec, referring them to some
other doc is not going to make it any clearer! If anything point (or file an
errata) to the framework doc.

-Woj.

>> I don't think that we should differentiate between optional and mandatory
>> because the definitons of the TLVs are needed anyway and available in access
>> nodes.
>> 
>> Considering BBF TR-147 Table 1, page 45 there is no difference between
>> mandatory and optional and all related parameters are mandatory.
>> In order to keep consistency between both workflows and avoiding
>> interoperability issues I really propose to set all these parameters
>> mentioned above to "mandatory". It really does not make sense if different
>> access node implementations may exist using different TLVs terminated
>> possibly at same BRAS.
>> 
>> Regards
>> 
>> Thomas
>> 
> ...
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Mon, 4 Oct 2010 18:55:26 -0400

Based on these comments, we have some major updating to do. However, I'd 
sooner say that we are looking to specify what is mandatory to implement 
(yes, evben the duplicates). It is up to the operator or the BBF 
protocol profile to specify which ones get used in a specific context. 
Surely you aren't saying we have to duplicate the BBF documentation?

On 04/10/2010 7:45 AM, Wojciech Dec wrote:
> Hello,
>
>
> On 24/09/2010 04:45, "Tom Taylor"<[email-masked]>  wrote:
>

---

From: <[email-masked]>
Date: Tue, 5 Oct 2010 09:39:38 +0200

All,

In chapter 3.1 of RFC5851 all parameters are listed. If protocol draft refers to framework (what I think should be the case)it is a matter of consistency between protocol draft and framework to support all TLVs listed in the framework.

Regards
Thomas

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 05 Oct 2010 09:39:58 +0200

Let me elaborate:

* The protocol spec needs to show what are the attributes required, and
which ones are optional. That was actually what was there previosuly/so-far
give or take a few items. As such it¹s not clear why it would require major
updating 
* If the purpose and usage of an attribute is not clear from a protocol
spec, clarifying it by referring to another doc (that is none the less
clearer, until proven otherwise) won¹t help.
* The usage of attributes in messages is up to an operator to specify only
in case of optional ones, that do not alter the intended semantics of the
message, with the this semantic provided by mandatory attributes. Hence, if
we take a port-up message, sending that message in any of the presently
known usage contexts without a port-identifier field is of no use. Protocols
across the board, Radius, Diameter, DHCP, etc, have these notions.

-Woj.

On 05/10/2010 00:55, "Tom Taylor" <[email-masked]> wrote:

>>>> >>> Particular I refer to chapter 5.2.3.3.6.1 - 5.2.3.3.6.15 of current
>>>> protocol
>>>> >>> draft version 12.
>>>> >>>