Subject: Issue CLOSED - Propose alternative text for the Summary/Conclusio n ( was RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ...

From: "Mary Barnes" <[email-masked]>
Date: Thu, 8 Aug 2002 10:01:21 -0500

Hi all,

This issue is closed in that RSIP will be considered fully compliant for
extensibility, along with all the other protocols.  If you still have
concerns about what we capture in the conclusion, it would be useful if you
would propose summary text that reflects your views.  I think we can put
together text that appropriately captures these considerations.  We could
have a statement something like:

"In considering the P+ category of compliancy, an important aspect is the
mechanism for support of extensibility. The extension mechansim provided by
SNMP and COPS-PR using MIBs and PIBs respectively, provides extensions with
no impact to the protocol.  Diameter extensions require protocol changes,
thus has a higher impact, although the extensions can be handled by other
Diameter entities without being understood.  Megaco's extension mechanisms
of packages also requires protocol changes that must be understand by both
sending and receiving entities, also being considered higher impact. The
RSIP extension mechanism has the largest impact on the existing protocol and
is based upon defining the necessary new parameters."

If you have concerns about what's communicated by this wording, then please
suggest explicit alternative wording by COB today, Thursday, August 8th.  As
I stated in my email on Tuesday, the plans are still to try to complete the
changes this week or early next week at the latest, thus allowing us to
start WGLC next week and maintain the schedule of getting the draft to the
IESG by early September, at the latest.

Regards,
Mary H. Barnes
[email-masked]
972-684-5432
Wireless 817-703-4806

-----Original Message-----
From: Sen, Sanjoy [NGC:B677:EXCH] 
Sent: Wednesday, August 07, 2002 4:22 PM
To: Taylor, Tom-PT [CAR:B602:EXCH]; Barnes, Mary [NGC:B602:EXCH];
'midcom'
Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P
+ -> T ? ( wa s RE: Proposed changes to RSIP evaluation

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B602:EXCH] 
> Sent: Wednesday, August 07, 2002 4:06 PM
> To: Sen, Sanjoy [NGC:B677:EXCH]; Barnes, Mary 
> [NGC:B602:EXCH]; 'midcom'
> Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP 
> Extensibility - P + -> T ? ( wa s RE: Proposed changes to 
> RSIP evaluation
> 
> 
> 
> Note that I said protocol changes, not base protocol changes. 
>  To add a package in Megaco you have to update your parser to 
> start with, and also be prepared to provide the package name 
> in response to audits.  I know the work is similar for a MIB, 
> in a way, but in Megaco the package elements are mixed right 
> in with the other elements of the protocol.
> 

I thought so too (that the work is similar for MIB or PIB). 

I wouldn't consider this (mixed with elements of the protocol)
sufficient reason to deem Megaco any less extensible than COPS or SNMP.

Thanks,
Sanjoy

> -----Original Message-----
> From: Sen, Sanjoy [NGC:B677:EXCH] 
> Sent: Wednesday, August 07, 2002 5:00 PM
> To: Barnes, Mary [NGC:B602:EXCH]; 'midcom'
> Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP 
> Extensibility - P + -> T ? ( wa s RE: Proposed changes to 
> RSIP evaluation
> 
> 
> Speaking from Megaco perspective, I don't understand why it 
> would be any less extensible than either SNMP or COPS, as 
> packages doesn't need any changes in base protocol. Can 
> somebody educate me on this? 
> 
> -----Original Message----- 
> From: Barnes, Mary [NGC:B602:EXCH] 
> Sent: Wednesday, August 07, 2002 3:51 PM 
> To: 'midcom' 
> Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP 
> Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP 
> evaluation
> 
> 
> Hi all, 
> Based upon the responses to Jim's email thread on this topic, 
> I think there is general concensus to change 2.2.1 to T for RSIP.  
> In addition, this thread highlighted a key aspect as to the 
> level or readiness of extensibility with the following 
> summary, which I've liberally copied from Tom's email and 
> added COPS: SNMP and COPS (most extensible): extensions 
> require absolutely no change to the 
> protocol itself. 
>   
> DIAMETER: extension mechanism provided, does mean protocol 
> changes, but extensions can be handled by other DIAMETER 
> entities without being 
> understood.  (Actually not sure that this property is 
> relevant or useful in 
> the MIDCOM case.) 
> MEGACO: extension mechanism provided, does mean protocol 
> changes, both ends 
> have to understand the extensions. 
> RSIP: no formal extension mechanism; extensions have to be 
> designed into the 
> protocol from scratch.  
> My proposal to ensure that we capture this aspect of the 
> evaluation and include some text in the conclusion, following 
> the controversial table capturing this information, to 
> highlight that this is key to considering the impact of P+ 
> for a specific protocol. I'll propose specific text when I 
> get down to editting again early tomorrow. Folks that 
> participated in this thread are also welcome to craft the 
> proposed text. Regards, 
> Mary. 
> _______________________________________________ 
> midcom mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/midcom 
> 

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom