Subject: Re: version control (M2PA)

From: Tom George <[email-masked]>
Date: Fri, 03 Aug 2001 17:45:39 -0500

It was suggested that I add the version control and extensibility text
since there is similar information in the other drafts. 

Thanks for the flow chart. I will look it over.

dell cooper wrote:
> 
> hi,
>  this is to ask that we are in draft stage not in
> stable stage so what is the need of version control as
> described in section 4.1.8 of draft03.
> 
> as far as backward compatibility is concern that
> should be after RFC stage
> 
> and i am atteching a document file which shows link
> alignment as described in draft 03
> 
> dell
  [...]

-- 
* Tom George        972-519-3168         [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Mon, 6 Aug 2001 13:11:45 +0530

regarding the version control i have few points to raise

1. t there is no such version control procedure mentioned in other UA's
(which TOM mentioned in his mail
"It was suggested that I add the version control and extensibility text
since there is similar information in the other drafts.
")

2. as we are mentioning the expiry date for each draft give us clear indication
that draft must not be backward compatible

3.i think this is having less advantage than disadvantage as an implementation
point of view

thanks and regards
manish

---

---

From: [email-masked]
Date: Mon, 6 Aug 2001 15:14:50 +0530

Hi,

In the same context:
Are these requirements placed on the protocol rather than an implemention?, i.e
the protocol
should be  designed and modified so as to meet these requirements instead of an
implementation ensuring it.
From an implementation point of view i find them very difficult to implement if
not infeasible.
Sec 4.1.8 says
"In particular, it is recommended that for future modifications to this
protocol:

- Any newer version should be able to process the messages from a
  lower version.

- A newer version of M2PA should refrain from sending messages to an
  older version of M2PA messages that the older version cannot
  process.

- If an older version of M2PA receives a message that it cannot
  process, it should discard the message.

- In cases where different processing is done in two versions for the
  same format of a message, then the newer version should contain
  procedures to recognize this and handle it appropriately.

In case a newer version of M2PA is incompatible with an older version,
the newer version should recognize this and prevent the alignment of
the link."

If these are recommendations to be considered for protocol changes(A)
in future, then it is ok although i don't think such a guideline exist for other
 SIGTRAN protocols in draft stage.
I think these statements should be removed.

regards
Harsh

[email-masked] on 08/06/2001 01:11:45 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Harsh Bhondwe/HSS)

Subject:  Re: version control (M2PA)

thanks and regards
manish

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Joyce Archibald <[email-masked]>
Date: Mon, 06 Aug 2001 11:15:58 +0100

Perhaps it should be pointed out that there is no intention to control
draft versions. 

When M2PA becomes an RFC it will be Version 1.0. 

The version control will only come into effect when/if changes or
additions are required to the standard. In which case the new version
would be M2PA Version 2.0 and would be required to be backwards
compatible with version 1.0.

Regards,
Joyce

[email-masked] wrote:
> You are currently subscribed to sigtran as: [email-masked]

-- 
==================================================================
Joyce Archibald, TSD R&D,    | Phone:    +44 (0) 131 3317521
Agilent Technologies UK Ltd  | Telnet:   313 2521 
South Queensferry,           | Mailstop: SQFRD3A
EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

---

---

From: Tom George <[email-masked]>
Date: Mon, 06 Aug 2001 08:39:07 -0500

Comments below....

[email-masked] wrote:
> since there is similar information in the other drafts.")

See M2UA section 4.3.3.3  M2UA Version Control
    M3UA section 4.2.3.1.1 M3UA Version Control

Both contain this statement: 
"A node upgraded to a newer version should support the older 
versions used on other nodes it is communicating with. "

I provided more detail, but the concept is the same.

> that draft must not be backward compatible

Joyce Archibald is correct. The RFC version is "version 1". A subsequent
M2PA RFC, if any, would be called "version 2". 

---

---

From: Tom George <[email-masked]>
Date: Mon, 06 Aug 2001 08:44:50 -0500

> implementation ensuring it.

Yes, that is correct. It is a recommendation that if a version 2 is
written, the M2PA protocol should be modified in such a way that version
2 is compatible with version 1. 

  [...] 
  [...]

See my other message about this. 

---