Subject: [Idr] issue 6 - Editorial changes to section 8. introduction

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Jul 2003 12:12:43 -0400

Tom:

The three changes are suggested in the text in 8.1 below 

6) issue 6 - 8. Introductory text

issue 6a:  Replace TCP with Tcp for readability
issue 6b:  add Mandatory attributes 
issue 6c:  substitute OPEN for Open 

6a:  I find Tcp much less readable than TCP.  I'd like to get feedback from
      Alex and the working group.  

6b: Mandatory attributes. 

	I thought "required" implied a stronger input than mandatory.
	I will aid the text below if Alex indicates it will speed things through
	the AD-Review: 

   Session attributes required for each connection (Mandatory attributes): 

6c:  Substitute OPEN for open in the text below

  The optional session attributes support different features of the BGP
  functionality that have implications for the BGP FSM state
  transitions.   For example, the DelayOpen optional attribute allows
  the BGP OPEN message to be delayed while waiting for the remote BGP peer
  to send the first OPEN.  Please refer to section 8.1.1 for an explanation
  of the interaction between these optional attributes and the Events
  signaled to the state machine.

Sue

Tom's comments
=============
) issue 6 - 8. Introductory text

issue 6a:  Replace TCP with Tcp for readability
issue 6b:  add Mandatory attributes 
issue 6c:  substitute OPEN for Open 

** double asterisk marks proposed changes

* headers removed
* Appendices, REFERENCES REMOVED
* flag, timer
* TCP OPEN NOTIFY

* maybe one for the RFC editor - the layout is a mix of tab and spaces
  which means a column is not a column when I print it; great for diffing, not for clarity

8. BGP Finite State machine

   This section specifies the BGP operation in terms of a Finite State
   Machine (FSM).  The section falls into 2 parts:

          1) Description of Events for the State machine (Section 8.1)
          2) Description of the FSM (Section 8.2)

   Session Attributes required for each connection **(connection? session?) are: 

** ('Mandatory attributes for each connection are:'   would be better now we have so expanded the optional parts.  Mandatory contrasts with optional in a way required does not - or should we be using RFC language? 'the following attributes MUST be supported for each connection')
 
         1) State
         2) ConnectRetryTimer
         3) HoldTimer
         4) HoldTime
         5) KeepaliveTimer
         6) KeepaliveTime
         7) ConnectRetryCounter
         8) ConnectRetryInitialValue

   The optional Session attributes are listed below. These optional
   attributes may be supported either per connection or per local sys-
   tem:

        1) AcceptConnectionsUnconfiguredPeers
	2) AllowAutomaticStart
	3) AllowAutomaticStop
	4) CollisionDetectEstablishedState
	5) DampPeerOscillations
	6) DelayOpen 
        7) DelayOpenTimer **(OpenDelayTimer)
	8) IdleHoldTimer
        9) PassiveTCPEstablishment

**(replace TCP by Tcp; easier to read and very familiar to those versed in SNMP)

       10) SendNOTIFICATIONwithoutOPEN
**(ditto Notification, Open - I know these are message types and we agreed on capitalisation for them but that should be subservient to clarity) 
       11) TrackTCPState
**(ditto Tcp)
   
  The optional session attributes support different features of the BGP
  functionality that have implications for the BGP FSM state
  transitions.   For example, the DelayOpen optional attribute allows
  the BGP Open **(OPEN -  should be caps here) message to be delayed while waiting for the remote BGP peer
  to send the first OPEN.  Please refer to section 8.1.1 for an explanation
  of the interaction between these optional attributes and the Events
  signaled to the state machine.

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

---

From: Alex Zinin <[email-masked]>
Date: Wed, 2 Jul 2003 18:17:27 -0700

Sue

>       Alex and the working group.  

up to you

>    Session attributes required for each connection (Mandatory attributes): 

Hmmmm... it seemed to me that "required" in that case was not
used in the meaning of being mandatory to implement, but rather
required to describe the protocol logic in the form of FSM.
FSM is an abstraction model, and we spelled out that implementations
do not have to code it exactly the way it is described as long as
externally visible behavior is the same, so I'm not sure saying
those are mandatory makes much sense... I will leave this up to
you, though.

>   signaled to the state machine.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Wed, 2 Jul 2003 18:17:27 -0700

Sue

up to you

Alex