FW: Request for IESG review & publication of draft-ietf-forces-protocol-08.txt

All,

The routing directorate is now using the PROTO process
in handling new protocol submissions to the IESG, 
defined in draft-ietf-proto-wgchair-doc-shepherding-06.txt.   
Per the PROTO requirements, please find below the write-up 
that was submitted to the shepherding AD (Russ Housley) 
and the iesg-secretary as part of submitting this draft as an RFC.

If you have any comments or questions about this process or
write-up, please let Patrick and I know.

-David Putzolu
Co-chair, ForCES WG

_____________________________________________
To: 'housley <at> vigilsec.com'; 'iesg-secretary <at> ietf.org'
Subject: Request for IESG review & publication of
draft-ietf-forces-protocol-08.txt

Russ & iesg-secretary, per
draft-ietf-proto-wgchair-doc-shepherding-06.txt, please find below the
PROTO write-up for draft-ietf-forces-protocol-08.txt, which we are
requesting IESG review of for publication as a standards track RFC.

Regards,
David Putzolu & Patrick Droz
Co-Chairs, IETF ForCES Working Group

1.a) Have the chairs personally reviewed this version of the Internet

draft-ietf-forces-mib-01

Hi all,
I recently updated the ForCES MIB draft with a few small editorial 
things. I propose that the chairs do a working group last call on it now.

http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-01.txt

Regards,
--

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha

LC for the MIB draft

David and I would like to initiate Last Call on the MIB draft
starting today and ending in 2 weeks from now. Please do
review and comment on the draft:
http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-01.txt

Regards,
The chairs

Re: LC for the MIB draft

On Fri, 2006-12-05 at 10:32 +0200, Patrick Droz wrote: 
> David and I would like to initiate Last Call on the MIB draft
> starting today and ending in 2 weeks from now. Please do
> review and comment on the draft:
> http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-01.txt
> 

Ok, sneaked a few cycles and reviewed it. Comments:

- I think we need at least two traps: 
one for FEs joining and another for their departure/association-loss

- Section 4 and section 5: 
I dont see the need for the DOWN state. In the current protocol rev we
decided that a re-joining FE starts from scratch. In fact we cant say
with certainty that an FEID you see a second time is guaranteed to be
the same one you saw in the last association.
The above means, in addition to removing references to DOWN from the
doc, you get rid of any attribute that records transitions related to
establishing state {forcesAssociationTransitionEstablishing,}

- Related: If you keep the two states, then the timestamps of interest
are when the FE entered establishing state(state creation time) and when
it entered the UP state. The former which could  be described as "time
when FE entered establishing state" would make sense to replace
"time when association appeared in MIB". I think the name
forcesAssociationCreated is still fine.

- forcesAssociationUptime is a little misleading for the noun it is
supposed to represent. It reads almost like the relative time since

Re: LC for the MIB draft

Jamal,
Thanks for the useful comments, please see below.

Jamal Hadi Salim wrote:
> On Fri, 2006-12-05 at 10:32 +0200, Patrick Droz wrote: 
>   
>> David and I would like to initiate Last Call on the MIB draft
>> starting today and ending in 2 weeks from now. Please do
>> review and comment on the draft:
>> http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-01.txt
>>
>>     
>
> Ok, sneaked a few cycles and reviewed it. Comments:
>
> - I think we need at least two traps: 
> one for FEs joining and another for their departure/association-loss
>
>   
Agreed. So we could have 2 traps: entered UP state, and left UP state. 
I'll post the changes to the MIB.

> - Section 4 and section 5: 
> I dont see the need for the DOWN state. In the current protocol rev we
> decided that a re-joining FE starts from scratch. In fact we cant say
> with certainty that an FEID you see a second time is guaranteed to be
> the same one you saw in the last association.
>   
True. Given that we introduce the two traps above I propose to get rid 
of the DOWN state. Faulty FEs that keep resetting their association can 

Protocol draft terminology about association states

Hi All,
I found that the terminology used for describing the association state 
in the protocol draft is still a bit confusing. Let me know what you think.

Post-association phase is defined in Section 3 as:
"The period of time during which an FE knows which CE is to control it 
and vice versa. This includes the time during which the CE and FE are 
establishing communication with one another".
So the post-association phase seems to end after the Association Setup 
messages have been exchanged. I don't think this is what we mean.

Later on in Section 4.2 we write:
"ForCES, in relation to NEs, involves two phases: the Pre-Association 
phase where configuration/initialization/bootup of the TML and PL layer 
happens, and the association phase where the ForCES protocol operates to 
manipulate the parameters of the FEs".
Here we should replace "association" by Post-association.

Then in Section 4.2.2 we define in more details the three stages in the 
Post-association phase: Association Setup, Established, and Lost.
It says that the Association Setup Stage does not end after the CE sends 
its Association Setup Response but instead after the FE has received its 
initial configuration from the CE. This discrepancy is a bit confusing, 
I think.

Also, I find it confusing that the Post-Association phase contains a 
stage named "Association Setup". Using the word "Post" usually means 
that the Association is already there, no ? So there should be no more 
association to setup, maybe some initial configuration.

Re: LC for the MIB draft

Re: Protocol draft terminology about association states

Re: LC for the MIB draft

Re: Protocol draft terminology about association states