Re: [Tsvwg] WGLC for draft-ietf-tsvwg-2960bis-02 starts NOW

[Michael Tuexen <[e-mail]>]

Hi Dan,

see my comments in-line.

Best regards
Michael

On Oct 31, 2006, at 11:33 AM, Romascanu, Dan (Dan) wrote:

> Randall,
>
> Thank you and the other folks who answered and tried to clarify me on
> the details of the evolution of SCTP.
>
> Please see in-text.
>
>
>
>
>
>> -----Original Message-----
>> From: Randall Stewart [mailto:[e-mail]]
>> Sent: Tuesday, October 31, 2006 2:08 AM
>> To: Romascanu, Dan (Dan)
>> Cc: James M. Polk; tsvwg
>> Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-2960bis-02 starts NOW
>>
>> Dan:
>>
>> A couple of thoughts here..
>>
>>
>> Romascanu, Dan (Dan) wrote:
>>> 1. I believe that the document could benefit from a section
>> describing
>>> the changes relative to RFC 2960.
>>
>> The changes are documented in RFC4460.. this is what the
>> whole point of the document was.. a living history of why we
>> changed what we changed in the BIS document. I would not like
>> to see the protocol document cluttered with this.. since the
>> new RFC will replace 2960... just like 793 replaced the
>> previous TCP document (can't remember the number off the top
>> of my head :-o)
>>
>
> For the benefit of the readers who are less educated in the history  
> but
> would need to use these documents in the future it would be useful to
> have a phrase that explains that the changes from RFC 2960 are
> documented in RFC 4460, and have RFC 4460 as an Informative Reference.
This is addressed in the meantime...
>
>>
>>> 2. I believe that the document could be improved by adding a
>>> operational and manageability considerations section. Such
>> a section
>>> should include information concerning the way the protocol
>> is expected
>>> to be deployed and configured, initial configuration parameters if
>>> relevant, how a SCTP capable network is to be operated and managed,
>>> management entities and models, etc.
>>
>> This type of information IMO would go with the applications
>> that want to use it. There is a standard "recommended" set of
>> parameters but different apps will have different needs. Thus
>> the sigtran suite, for example, might want to have such a
>> document (they may already have this)...
>>
>> Any application might want to describe there "adaption" to
>> SCTP if they feel the standard settings are not appropriate..
>>
>> This is, after all, a protocol description.. what you are
>> asking for is a "deployment" scenaro... and I would never
>> want to see something like this in the actual protocol document..
>>
>> Now, besides all that, we have some ground rules setup for
>> how we were to change 2960. These were that only changes
>> pertinent to 4460 would be applied.... i.e. 4460 scoped the
>> changes to 2960.
>> As such, only things changed in 4460 were open for discussion.. e.g.
>> look you changed X to Y.. but you missed changing X to Y in
>> section Foo.
>
> I believe that we slightly disagree here. IMO a protocol document  
> should
> include manageability and operational considerations, same as it does
> include considerations related to security or congestion  
> management. You
> should not define a protocol in the Internet without proper though  
> from
> the design phase about how it will be installed and deployed, what
> impact it may have on the operations of the networks were it will run,
> and how it will be managed.
>
>  I would recommend considering these aspects. I understand that  
> this is
> a not a new protocol, so I will probably not try to insist too much on
> this point, but note that if this was a new protocol I would have
> certainly made this point during the IESG review.
I'm not sure what kind of information you are missing in the document.
Could you explain what information regarding manageability and
operational considerations for SCTP you need? What do you need for
TCP, for example?
>
>>
>>
>> R
>>
>>
>>
>>
>> --
>> Randall Stewart
>> 803-345-0369 <or> 815-342-5222(cell)
>
> Dan
>
>>
>
>