Subject: [Idr] RE: FSM review - Tom's Comments [issue 4]

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Jul 2003 09:54:01 -0400

Tom:

I'm sending out issues that need to be resolved.
You correctly observed that the AD-Comments 
"re-worked" some carefully worked text in the
FSM.  I am going to use an issue format for your
comments and the AD's comments.

[issue 4] 

4) Values of flags [issue 4] 

depend on: resolution of issue 1

Tom's comments: 

Likewise with the Value of flags; 
this is now defined to be True or False; fine except that most of the existing
text uses set, not set or reset so there are changes required to the existing text.

Sue's response:

I believe this issue to be linked to:
	Issue 1 - Flags or no Flags
	Issue 2 - values of flags [True/False] 

I believe the timers or attributes are the only things set or reset.

Sue Hares

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Monday, June 30, 2003 1:01 PM
To: Susan Hares; Alex Zinin
Cc: [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1

Sue

I am not clear that you have received the comments I sent, plus
attached corrections, last Thursday, which I sent, in the way of
e-mail, before I received your Wednesday lunchtime e-mail.

I think there are some basic unresolved questions which make it
premature to focus on the detail.

8.2.1.3 was a good summary but is now inconsistent with 8.1,
unacceptably so for me; needs changing.

1)Session was binned as I understood it by Yakov last October,
connection being the correct term.

2) We may only still have flags and timers but ....  The new 8.1 turns
the flags into Boolean variables, whether or not you use that term.
They always have a value, True or False.  Therefore, we can no longer
talk of set, not set, off or reset; these terms are meaningless.  We
have to talk in terms of these attributes (if that is the right term)
having the value True or False.   Or else get rid of all your text on
True or False :-)

3)  Timers in the base document are xxxTime in seconds and xxxTimer
which starts, stops is reset etc.  We should, unless you have a cogent
argument otherwise, use the same for optional timers and currently we
do not - ever  We have no clear way of indicating that an optional
timer is implemented.  We can have a xxxTime in second representing
the initial or default value but need something more to say this is or
is not implemented.  Should each optional timer have a True/False to
indicate presence or absence?  If this is xxxTimer, we then need a
third term in the actions, where xxxTimeyyy is started or stopped.  We
don't yet need a fourth term to denote the current value of this thing
but we could do so the way we are expanding this section.

4) Is 'connection attributes' the right term for however many types of
objects we have?  Depends on the resolution of 3)

Turning to your proposed new paragraph in 8.1.2, no, not ok.  We need
to resolve the issues of optional whatevers first and document that in
8.1, reword and move 8.2.1.3 in there right at the start and use the
principles we have documented there as the basis to decide what is
right and what is wrong for the lesser sections such a Admin or TCP or
other groups of etc,  only then can we satisfactorily document the
settablility, MIBability etc.

I resend my e-mail of last Thursday separately just in case it fell
into some spam trap.

Tom Petch
[email-masked]
+(44) 192 575 3018
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Tom Petch <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Date: 30 June 2003 15:15
Subject: RE: FSM review - comments on Administrative events 8.1.1

Alex and Tom:

Suggested changed text in 8.1.2 -- please approve as AD reviewers.

AD comments:

> 8.1.2 Administrative Events
>
>
>    Please note that only Event 1 (manual start) and Event 2 (manual
>    stop) are mandatory administrative events. All other
administrative
>    events are optional (Events 3-8).   Each event below has a name,
>    definition, status (mandatory or optional), and what optional
session
>    attributes SHOULD be set at each stage.

Can we make it clear whether these settings are the conditions under
which a given event is considered valid, or actions when an even is
seen?

Also, if those are the conditions, what should be done when the
settings are different?

==========

Text Resolution:

8.1.2 Administrative Events

   An administrative event is an event in which the operator interface
   and BGP Policy engine signal the BGP finite state machine to start
   or stop the BGP state machine.  The basic start and stop indication
   are augmented by optional session attributes to signal a certain
   type of start or stop mechanism to the BGP FSM. An example of this
   combination is event 5:
AutomaticStart_with_PassiveTCPEstablishment.
   With this event, the BGP implementation signals to the BGP FSM
   that the implementation is using an Automatic Start with option
   to use a Passive TCP Establishment.  The Passive TCP establishment
   signals that this BGP FSM will wait for the remote side to start
   the TCP establishment.

   Please note that only Event 1 (manual start) and Event 2 (manual
   stop) are mandatory administrative events. All other administrative
   events are optional (Events 3-8).   Each event below has a name,
   definition, status (mandatory or optional), and what optional
session
   attributes SHOULD be set at each stage.

   The settings of optional session attributes may be implied by some
   implementations and not settable by external operator. Section
8.2.1.5
   describes these implied settings of the optional session
attributes.
   The administrative states described below may also be implied
   by some implementations and not directly settable by an external
   operator.  Section 8.2.1.4 describes these implied states further.

       Event1: ManualStart

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Jul 2003 09:54:01 -0400

Tom:

[issue 4] 

Tom's comments: 

Sue's response:

Sue Hares

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Monday, June 30, 2003 1:01 PM
To: Susan Hares; Alex Zinin
Cc: [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1

Sue

Tom Petch
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Tom Petch <[email-masked]>; [email-masked]

Alex and Tom:

administrative
session

==========

Text Resolution:

       Event1: ManualStart