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

["Romascanu, Dan \(Dan\)" <[e-mail]>]

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. 

> 
> > 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.

> 
> 
> R
> 
> 
> 
> 
> --
> Randall Stewart
> 803-345-0369 <or> 815-342-5222(cell)

Dan

>