Re: ppp draft issues - offset padding field

At 04:33 PM 6/26/2007 -0400, Carlos Pignataro wrote:
>> I would like to propose one of the following two alternatives:
>> 
>> 1) eliminate the offset padding field altogether.
>>    This is my preferred choice.
>> 
>> 2) if we decide to keep the offset padding field, it should be
>>    somehow negotiated with the sender side.
>> 
>> 
>> If option #2 was preferred, the negotiation could be done the
>> same way that it is done in RFC3573: each side tells the other
>> how far they are willing to go.
>> 
>> A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
>> the willingness of the message sender's side to insert an offset
>> and how long that offset might be. If the AVP is not included,
>> it means the message sender will not insert any offset (regardless
>> of any received Offset Size AVP).
>
>Rather than a session-level negotiation, how about a tunnel-level
>SCCRQ/SCCRP capability advertisement, much like the "Pseudowire
>Capabilities List" or the "Modem On-Hold Capable AVP" from Section 4.1
>of RFC3573. A "Offset Capability" AVP can indicate how big of an offset
>the sender is willing to insert, if requested at session-level.


Sure, session-level or tunnel-level is fine by me.

I would still like to make this feature disappear though and go
for the simpler solution of just removing something that has
questionable value.


>It could even be the same AVP number
>(with semantics depending on the type of message in which the AVP is
>in), or (my preference) a new AVP.

I think it will be better if it is a new AVP.
It is cleaner and it makes parsing and displaying much easier.
I don't think there is any AVP that has more than personality and
I think it is better to keep it that way.

Cheers,
-Ignacio