headers
Hormuzd Khosravi | 3 Jun 2005 09:20

[issue43] Editorial- change GET to SET in section 6.5

New submission from Hormuzd Khosravi <hormuzd.m.khosravi <at> intel.com>:

In sections 6.5.1, 6.5.2, the figures show GET command being used in Config 
messages. This should be changed to SET in both sub-sections.

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 62
nosy: hormuzdk
priority: Must fix
status: Text proposed
title: Editorial- change GET to SET in section 6.5

___________________________________________________
Forces issue tracker <tracker-forces <at> mip4.org>
<http://www.mip4.org/issues/tracker/forces/issue43>
___________________________________________________
Permalink | Reply | 1 comment |
headers
Weiming Wang | 3 Jun 2005 16:35
Picon

Re: [issue30] Event subscription

Not sure if this issue can be closed by leaving it for model team to decide. Actually it does not relate to the
protocol  specification very much.

Weiming
----- Original Message ----- 
From: "Avri Doria" <tracker-forces <at> mip4.org>
To: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Monday, May 23, 2005 2:29 AM
Subject: [issue30] Event subscription


New submission from Avri Doria <avri <at> acm.org>:

6.7

   Editorial Note:  There is an argument that it is preferable to have
                    all events subscribable.

----------
category: Technical
draft: draft-ietf-forces-protocol
messages: 47
nosy: avri
priority: Must fix
status: No discussion
title: Event subscription

___________________________________________________
Forces issue tracker <tracker-forces <at> mip4.org>
<http://www.mip4.org/issues/tracker/forces/issue30>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Weiming Wang | 3 Jun 2005 16:39
Picon

Re: [issue31] Necessity of Notification Response Message

My thought is if we decide not to have a uniformly formated ACK message in the protocol messages, we may need
such event notification response message.

thanks,
Weiming
----- Original Message ----- 
From: "Avri Doria" <tracker-forces <at> mip4.org>

New submission from Avri Doria <avri <at> acm.org>:

6.7.2

  Editorial Note:  There is a debate on whether the Event
                       Notification Response Message is necessary or
                       not.  The pro for it is some event notification
                       senders may be interested in knowing if receivers
                       have had success/unsuccess receptions of the
                       events or not.  An alternative to generate such
                       response is for the protocol to define a
                       universal ACK message so that it can act as
                       responses for any types of messages as well as
                       the event notification messages, when the message
                       senders are interested in knowing whether the
                       messages have been successfully received or not
                       (different from the responses for the message
                       processing results).

----------
category: Technical
draft: draft-ietf-forces-protocol
(Continue reading)

Permalink | Reply | 0 comments |
headers
Weiming Wang | 3 Jun 2005 16:45
Picon

Re: [issue36] Note: - FE and CE Failover


----- Original Message ----- 
From: "Avri Doria" <tracker-forces <at> mip4.org>

New submission from Avri Doria <avri <at> acm.org>:

6.2.1

      *  Current version of the FE model
      *  FE unicast ID
      *  FE multicast ID(s) (list)
      *  Association Expiry Timer
      *  Heartbeat Interval
      *  Primary CE
      *  FE failover and restart policy
      *  CE failover and restart policy
         Note:  Is there a difference between the CE and FE failover
                policies?

[Weiming] CE failover policy tells how FE acts if it finds the CE fails, while FE failover and restart policy
tells how FE should act to restart from a failover state.  

----------
category: Editorial
draft: draft-ietf-forces-protocol
messages: 54
nosy: avri
priority: Must fix
status: No discussion
title: Note: - FE and CE Failover
(Continue reading)

Permalink | Reply | 0 comments |
headers
Weiming Wang | 3 Jun 2005 16:50
Picon

Re: [issue37] TBD - FE Protocol Attributes

It seems we need to first decide "who should define the LFBs like FE-LFB, FE-protocol-LFB, this protocol
document or elsewhere"  before trying to decide this issue.

thanks,
Weiming
----- Original Message ----- 
From: "Avri Doria" <tracker-forces <at> mip4.org>
To: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Monday, May 23, 2005 2:50 AM
Subject: [issue37] TBD - FE Protocol Attributes


New submission from Avri Doria <avri <at> acm.org>:

6.2.1

   o  FE Protocol attributes (can be read and set):
      *  Current version of the ForCES protocol




Doria (co-editor)         Expires April 4, 2005                [Page 31]

Internet-Draft                   ForCES                     October 2004


      *  Current version of the FE model
      *  FE unicast ID
      *  FE multicast ID(s) (list)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel M. Halpern | 3 Jun 2005 20:28

Re: [issue37] TBD - FE Protocol Attributes

A reasonable question.

My current take is that the FE LFB should come with the model document, and 
the FE-protocol LFB should be defined by the protocol document.
However, this is something on which reasonable people can easily differ, 
and I am open to alternatives.

Yours,
Joel

At 10:50 AM 6/3/2005, Weiming Wang wrote:
>It seems we need to first decide "who should define the LFBs like FE-LFB, 
>FE-protocol-LFB, this protocol document or elsewhere"  before trying to 
>decide this issue.
>
>thanks,
>Weiming
Permalink | Reply | 0 comments |
headers
Joel M. Halpern | 3 Jun 2005 20:27

Re: [issue30] Event subscription

My current inclination is that the definition of an event identifies the 
subscription point, that all events are subscribable, and that by default 
all subscriptions are off.
This creates a clean, simple, understandable, operting mode.

The assumption that lead me to this is simply that without a CE there is no 
point in a notification, and if there is a CE, he can determine what he 
wants to register for.  Any race condition is handled by the CE getting the 
information he needs about current state.

Yours,
Joel

At 10:35 AM 6/3/2005, Weiming Wang wrote:
>Not sure if this issue can be closed by leaving it for model team to 
>decide. Actually it does not relate to the protocol  specification very much.
>
>Weiming
>----- Original Message -----
>From: "Avri Doria" <tracker-forces <at> mip4.org>
>To: <FORCES <at> PEACH.EASE.LSOFT.COM>
>Sent: Monday, May 23, 2005 2:29 AM
>Subject: [issue30] Event subscription
>
>
>New submission from Avri Doria <avri <at> acm.org>:
>
>6.7
>
>    Editorial Note:  There is an argument that it is preferable to have
(Continue reading)

Permalink | Reply | 0 comments |
headers
Putzolu, David | 3 Jun 2005 20:39
Picon
Favicon

Re: [issue37] TBD - FE Protocol Attributes

(hat off)

The approach you propose Joel makes sense to me technically, and it is
also a nice partitioning of the work :)

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern
Sent: Friday, June 03, 2005 11:29 AM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes

A reasonable question.

My current take is that the FE LFB should come with the model document,
and 
the FE-protocol LFB should be defined by the protocol document.
However, this is something on which reasonable people can easily differ,

and I am open to alternatives.

Yours,
Joel

At 10:50 AM 6/3/2005, Weiming Wang wrote:
>It seems we need to first decide "who should define the LFBs like
FE-LFB, 
>FE-protocol-LFB, this protocol document or elsewhere"  before trying to
(Continue reading)

Permalink | Reply | 9 comments |
headers
Wang,Weiming | 6 Jun 2005 09:15
Picon

Re: [issue37] TBD - FE Protocol Attributes

Joel, David, and Robert,

I have some thoughts, some by my experience with GRMP:
1. Defining things like LFB attributes in details in the protocol docuement will
really leads the document to a comlex one.
2. Currently, we may be a little far away from accurately defining these
attributes.
3. Therefore, will eventually bottleneck the protocol document from going to
last call.

I actually incline to strip all that are related to LFB definitions from current
protocol docuement, while only leaving it for open discussion later that
"whether they go to model document or to a specific one for LFB definitions used
by protocol" .

Thanks,
Weiming
----- Original Message -----
From: "Putzolu, David" <david.putzolu <at> intel.com>

(hat off)

The approach you propose Joel makes sense to me technically, and it is
also a nice partitioning of the work :)

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jamal Hadi Salim | 6 Jun 2005 14:55

Re: [issue30] Event subscription

Hi Weiming,

On Fri, 2005-03-06 at 22:35 +0800, Weiming Wang wrote:
> Not sure if this issue can be closed by leaving it for model team to decide. 
> Actually it does not relate to the protocol  specification very much.

The protocol has to provide the semantics to allow for events.
Why do you say "it does not relate to the protocol"?

cheers,
jamal
Permalink | Reply | 1 comment |

Gmane