Subject: [Idr] RE: FSM review - comments on Administrative events 8.1.1 - Urgent [issue 1]

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

Alex:

I urgently need your comments before I process
Tom's comments.  The upcoming mail messages will
have 1 issue per mail message with an issue number.

I cannot resolve the issues because you, or your
AD-Reviewer wish to resolve things different than
the agreed upon text and/or Tom Petch's comments. 

[issue 1] What about the flags?  

	Due to the AD reviewers comments I moved from
	the flag description to the "optional session attribute"
	description in the AD revised.   

	As Tom points out [item #2 below]
	the added text that you liked - he objects to.
	In my mail on Monday, I asked that you and
	Tom come to some agreement on the requested
	resolution of the revisions from the AD-review
	on "flag" description. 

Please comment on your opinion as AD, and the AD-Reviewers
comments on Tom's comments.  We either need to:

	1) Stay with original flag text
	2) Go to the new text and remove any context on the
	   flags. 

Sue 

-----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 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: Mon, 7 Jul 2003 10:42:27 -0400

Alex and Tom:

I do not have a joint resolution on your comments about issue 1.
Without a resolution to issue 1, I am unable to complete
processing of additional issues from the AD-review.

I have included a summary of the current comments on section 8
and the addition of a new 8.1.1.  

Alex:  1) flag issues is outline below - please let me know if
	    if you can recall the context

	 2) Please let me know if your comment below indicates I
	    can ignore the AD-Reviewers comments on the draft
	    indicated below.

	 3) Issues are document in draft-ietf-idr-bgp-issues-00.txt
	    Please refer to these comments for history.
	    Hopefully, your AD reviewers can refer to these 
	    comments when deciding to comment on the draft.

Tom:   1) Is the summary below accurate?

Summary of Issue 1
==================================

1) Normalization [issue 1] 

   Section of comment:  Section 8 - preamble before 8.1.1

   AD comments being resolved:
	
	Comment 1:	

	Where's the description of this flag and how/when is it set? Same for
	others below. Should we have a brief description for each attribute?

	Comment 2:

	Suggestion: to make reading of the FSM description below easier, we
	could "merge" the multiword flag names and normalize them, e.g.
	'perform automatic start flag' to 'PerformAutoStart flag'. 'Passive
	TCP establishment flag' to 'PassiveTCPEstablishment flag',
	'stop_peer_flap' to 'StopPeerFlag'.

   Editors Resolution:
	[Sue Hares: 6/20/03 RE: AD-review comments on draft-ietf-idr-bgp4-20] 
	1) Normalize flags [see fsm_v2.txt - from sue Hares] 
	2) Add text to explain the context of the flags [new section 8.1.1]
	3) Add text at the beginning of text 8.1.2 [was old 8.1.1] 

AD reviewers comments:
=======================
8. BGP Finite State machine

General comment: I would _really_ appreciate more people looking at this
section.

>    The optional Session attributes are listed below. These optional
>    attributes may be supported either per connection or per local sys-
>    tem:
> 
>         1) Delay Open flag

Where's the description of this flag and how/when is it set? Same for
others below. Should we have a brief description for each attribute?

>         2) Open Delay Timer
>         3) Perform automatic start flag
>         4) Perform automatic stop flag
>         5) Passive TCP establishment flag
>         6) Perform BGP peer oscillation damping flag
>            (which will be denoted as stop_peer_flap in text)
>         7) Idle Hold timer
>         8) Perform Collision detect in Established flag
>         9) Accept connections from un-configured peers
>        10) Track TCP state flag
>        11) Send NOTIFICATION without an OPEN flag
> 
Suggestion: to make reading of the FSM description below easier, we
could "merge" the multiword flag names and normalize them, e.g.
'perform automatic start flag' to 'PerformAutoStart flag'. 'Passive
TCP establishment flag' to 'PassiveTCPEstablishment flag',
'stop_peer_flap' to 'StopPeerFlag'.

Tom Petch [from the file: fsm-v2ac.txt  email: 6/30/03

=======================
To explain my beef on normalisation; fine by me but it is the associated changes I think wrong; 
we used to have the word flag 58 times after the unnormalised references and I found that clear.  
We now have normalised references and the word flag only 9 times; sometimes we have the word
 'attribute', sometimes 'optional attribute' sometimes nothing.  Which makes approximately 50
places where the document is less clear, harder to follow - I want that consistency back, 
'flag's (or 'attribute's if you must); without consistency (of reference, of terminology)
I think the document not fit for publication.

But the bigger problem is that much of what I and others have done gets lost because
after we have hammered some detail, eg Open Delay timer, into shape, then along comes
a bigger change, new paragraphs, new layout, normalisation, description of options
and we are back to square one with at least three different ways of saying
the same thing (Open Delay timer, OpenDelayTimer, DelayOpenTimer).  This lack of
consistency I regard as about the biggest crime in a technical reference document;
the more important the technical document, the bigger the crime which is why I pursue it.
(It is as if different sections had been farmed out to different states to produce each
of which then chooses different nomenclature, different style.:-)

Alex comments: [email 7/2/03
title: Re: FSM review  - comments on Administrative events 8.1.1 - Urgent  [issue 1]
================
[issue 1] What about the flags?  
>         description in the AD revised.

sorry, couldn't parse this

>         2) Go to the new text and remove any context on the

I'll leave this up to you.

Alex's comments on 7/02/03
==============================

----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 9:11 PM
To: Susan Hares
Cc: Tom Petch; [email-masked]; [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1 -
Urgent [issue 1]

Susan,

> the agreed upon text and/or Tom Petch's comments. 

if something was explicitly agreed upon, please
let me know which of my comments are affected. I have
no intent to push hard for particular wording choices,
as long as the meaning is clear.

>         description in the AD revised.

sorry, couldn't parse this

>         resolution of the revisions from the AD-review

I would be fine with both set/reset/off and true/false
approaches. Seems a minor issue to me.

>         2) Go to the new text and remove any context on the

I'll leave this up to you.

Alex

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jul 2003 10:42:27 -0400

Alex and Tom:

Summary of Issue 1

	
	Comment 1:	

	Comment 2:

   Editors Resolution:

AD reviewers comments:
=======================

=======================

----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Wednesday, July 02, 2003 9:11 PM
To: Susan Hares
Cc: Tom Petch; [email-masked]; [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1 -
Urgent [issue 1]

Susan,

Alex