hi, Robert

Yes, I agree Jamal's suggestion.

>
>Simply put: if the association appears in the MIB, then it= means it
>is in the UP state. If it is not in the MIB, then it is n= ot in the
>UP state.
>

Agree. MIB should simply contain the UP stat information. But i am

not sure we really need remove the ESTABLISH stat,

About the Number of ForCES messages sent/received, I suggest

separated count the number of HBmsg and LFBmsg.

So maybe we need a new mib draft now :->

cheers,

xiaoyi

------=_Part_87170_27365549.1148484017235-- 2006 Message-Id: Date: Tue, 23 May 2006 20:18:25 +0200 From: Robert Haas Subject: Protocol draft terminology about association states MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi All, I found that the terminology used for describing the association state=20 in the protocol draft is still a bit confusing. Let me know what you thin= k. Post-association phase is defined in Section 3 as: "The period of time during which an FE knows which CE is to control it=20 and vice versa. This includes the time during which the CE and FE are=20 establishing communication with one another". So the post-association phase seems to end after the Association Setup=20 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=20 phase where configuration/initialization/bootup of the TML and PL layer=20 happens, and the association phase where the ForCES protocol operates to=20 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=20 Post-association phase: Association Setup, Established, and Lost. It says that the Association Setup Stage does not end after the CE sends=20 its Association Setup Response but instead after the FE has received its=20 initial configuration from the CE. This discrepancy is a bit confusing,=20 I think. Also, I find it confusing that the Post-Association phase contains a=20 stage named "Association Setup". Using the word "Post" usually means=20 that the Association is already there, no ? So there should be no more=20 association to setup, maybe some initial configuration. To clarify this, we could define three phases: Pre-association,=20 Association (a short transition that only includes the Association Setup=20 message exchange), and Post-Association (the Association Setup and=20 Established stages contained in the Post-Association phase could be=20 renamed to: Configuration Setup, ... for instance). What do you think ? In the ForCES MIB, I view an association as UP as soon as the CE has=20 sent its Association Setup Response that accepts the FE. Is this=20 acceptable ? Regards, --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2006 Message-Id: Date: Tue, 23 May 2006 17:29:06 +0200 From: Robert Haas Subject: Re: LC for the MIB draft Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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:=20 > =20 >> 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 >> >> =20 > > Ok, sneaked a few cycles and reviewed it. Comments: > > - I think we need at least two traps:=20 > one for FEs joining and another for their departure/association-loss > > =20 Agreed. So we could have 2 traps: entered UP state, and left UP state.=20 I'll post the changes to the MIB. > - Section 4 and section 5:=20 > 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. > =20 True. Given that we introduce the two traps above I propose to get rid=20 of the DOWN state. Faulty FEs that keep resetting their association can=20 be tracked instead by monitoring the traps they generate. Also, I suggest to remove the ESTABLISHING state. This state was defined=20 as a transient state between the time the CE has sent the Association=20 Setup Response message and until the time a message is received from the=20 FE. But no it does not seem to be very useful to distinguish this from=20 the UP state. So the association will be considered UP as soon as the CE=20 sends the Association Setup Response message. Simply put: if the association appears in the MIB, then it means it is=20 in the UP state. If it is not in the MIB, then it is not in the UP state. > 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 whe= n > 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. > =20 OK. > - forcesAssociationUptime is a little misleading for the noun it is > supposed to represent. It reads almost like the relative time since > established state. A better name would be forcesAssociationEstablished > =20 Now that there is only an UP state there is no confusion anymore. > - in regards to the messages received/sent stats; i think it would be > more useful to have a bit more fine-graining, at the moment we have: > forcesAssociationMsgReceived and forcesAssociationMsgSent > If we could just distinguish how many of those are heartbeats vs other > LFBs, i think it would provide better read if someone was debugging > the state of the NE using SNMP. If you could have: > forcesMsgHBReceived, forcesMsgHBSent, > forcesMsgLFBsReceived,forcesMsgLFBsSent=20 > You could put the above in one struct and call it "Associationstats". > =20 OK, makes sense. > BTW, it should be explicitly stated that these stats are from the CEs > point of view (since sent/received have implied direction). > =20 Agreed. > - I did not review the MIB definition for any sytantic issues, i trust > you did run it through some tool etc. > > =20 Yes I did. > Overall, there is no configuration of any sort allowed via SNMP; while > i am fine with that - is it design intent? > > =20 It is the intent. If needed, we'll extend the MIB later. But for now I=20 don't see the need. > cheers, > jamal Thanks, -Robert > --=20 > Dr. Robert R. Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~= rha 2006 Message-Id: Date: Tue, 16 May 2006 11:58:56 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LC for the MIB draft Comments: To: Robert Haas Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 established state. A better name would be forcesAssociationEstablished - in regards to the messages received/sent stats; i think it would be more useful to have a bit more fine-graining, at the moment we have: forcesAssociationMsgReceived and forcesAssociationMsgSent If we could just distinguish how many of those are heartbeats vs other LFBs, i think it would provide better read if someone was debugging the state of the NE using SNMP. If you could have: forcesMsgHBReceived, forcesMsgHBSent, forcesMsgLFBsReceived,forcesMsgLFBsSent You could put the above in one struct and call it "Associationstats". BTW, it should be explicitly stated that these stats are from the CEs point of view (since sent/received have implied direction). - I did not review the MIB definition for any sytantic issues, i trust you did run it through some tool etc. Overall, there is no configuration of any sort allowed via SNMP; while i am fine with that - is it design intent? cheers, jamal 2006 Message-Id: Date: Fri, 12 May 2006 10:32:47 +0200 From: Patrick Droz Organization: IBM Research Division Subject: LC for the MIB draft MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090609060807040000060309" This is a cryptographically signed message in MIME format. --------------ms090609060807040000060309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------ms090609060807040000060309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6jCC BSwwggSVoAMCAQICEDhxwVOTyOj0nx4MTQ30ZkMwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykg MTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4XDTAzMDUwNjAwMDAwMFoXDTA4MDUwNTIzNTk1 OVowgfkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1h Y2hpbmVzIENvcnBvcmF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwMzEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANVnrTXdoH79V2HWnacXy7mjjSNcnOi3Z+cXSBh9uSDhCLAUUeuvoHub uA5ImrJI5k/dA+Q0L+WNzR7OZr4TRpw3DOksYS/0o+RZ5+luJ7ltXcdVgsHU6qqHDpvF1hAe gqpNz670JVVfUs4ThC1AafMIBHwmJbqFG4Iy39OH37oBAgMBAAGjggHpMIIB5TASBgNVHRMB Af8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8v Y3JsLnZlcmlzaWduLmNvbS9wY2EyLWcyLmNybDALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEB BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEyNzAdBgNV HQ4EFgQUkcFzsHPV2ZJ0Z80b8VEUNDG2LFowgegGA1UdIwSB4DCB3aGBx6SBxDCBwTELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1 YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShj KSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmuCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAA4GBAAgYBRMDGzUl8C495yDmyE78QHSxQjkpKbJ61i0GkSYGUmkRYc3czKUlkV3s dHWe28su0SRO8HKhXzfUdR2D2n6UixORmR/tobmuxlkfwqHWDvNVuJD0iCV1e2cXT9qf38vM zMiC55lQmnCoUfTg131ovM/V1EI2aT181HWu/pM8MIIFWTCCBMKgAwIBAgIQJSBAG0BqCBRf YEFUSgK+mTANBgkqhkiG9w0BAQQFADCB+TELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVy bmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0wNTA5MTMwMDAwMDBaFw0wNjA5MTMyMzU5NTlaMIGFMS4wLAYDVQQKFCVJbnRl cm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnAuMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBFAkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzY/XBh1oeyjfCK5XtJf8 x4gwxYZE2Fdv28a2WVGy71OyQm1G9T2npUUH2AE4ywrZmOXeZ4o1kltzBwZ8p1gA9e9YAyue 49wzt6nd/4pWlg9S2uVNL7tckQ9sb7RLbBEywjpXPI7a6OqPUjh9NPNva8SzaDDr9X7kuooR fKjdqw8CAwEAAaOCAlIwggJOMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMGYGA1UdHwRfMF0w W6BZoFeGVWh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0ludGVybmF0aW9uYWxCdXNp bmVzc01hY2hpbmVzQ29ycENvcnBvcmF0ZUNJTy9MYXRlc3RDUkwwggEpBgNVHSAEggEgMIIB HDCCARgGC2CGSAGG+EUBBxcCMIIBBzArBggrBgEFBQcCARYfaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYS1rcjCB1wYIKwYBBQUHAgIwgcoagcdOb3RpY2UgVGV4dD1OT1RJQ0U6IFBy aXZhdGUga2V5IG1heSBiZSByZWNvdmVyZWQgYnkgVmVyaVNpZ24ncyBjdXN0b21lciB3aG8g bWF5IGJlIGFibGUgdG8gZGVjcnlwdCBtZXNzYWdlcyB5b3Ugc2VuZCB0byBjZXJ0aWZpY2F0 ZSBob2xkZXIuICBVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyMB8GA1UdIwQYMBaAFJHBc7Bz1dmSdGfNG/FRFDQxtixaMB0GA1Ud DgQWBBT1SwvrAN7a2KY54Zg5FdemL/4+QDAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOgFAwS ZHJvQHp1cmljaC5pYm0uY29tMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBglg hkgBhvhCAQEEBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAajRRbaYOGmyMgkHnwcEJIZsBSZbv O3uZO6weMCnPim/YUrYz8QIuyTYzV32bH1k0QhOnjSeHlUKxQBiSnyRmu/4lVvTOckqpUM3T sQibi+vQR/bOdP/CqC6n8MY55X74949PjFkX0Qdd5W5C1IkMTe6UOABFUDfvv19S22JebB0w ggVZMIIEwqADAgECAhAlIEAbQGoIFF9gQVRKAr6ZMA0GCSqGSIb3DQEBBAUAMIH5MQswCQYD VQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jw b3JhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDMxMDAuBgNV BAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEkMCIGA1UEAxMb SUJNIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MDkxMzAwMDAwMFoXDTA2MDkxMzIz NTk1OVowgYUxLjAsBgNVBAoUJUludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29y cC4xFTATBgNVBAMTDFBhdHJpY2sgRHJvejEZMBcGCgmSJomT8ixkAQEUCTMzMTkwMzg0ODEh MB8GCSqGSIb3DQEJARYSZHJvQHp1cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDNj9cGHWh7KN8Irle0l/zHiDDFhkTYV2/bxrZZUbLvU7JCbUb1PaelRQfYATjL CtmY5d5nijWSW3MHBnynWAD171gDK57j3DO3qd3/ilaWD1La5U0vu1yRD2xvtEtsETLCOlc8 jtro6o9SOH00829rxLNoMOv1fuS6ihF8qN2rDwIDAQABo4ICUjCCAk4wCQYDVR0TBAIwADAL BgNVHQ8EBAMCBaAwZgYDVR0fBF8wXTBboFmgV4ZVaHR0cDovL29uc2l0ZWNybC52ZXJpc2ln bi5jb20vSW50ZXJuYXRpb25hbEJ1c2luZXNzTWFjaGluZXNDb3JwQ29ycG9yYXRlQ0lPL0xh dGVzdENSTDCCASkGA1UdIASCASAwggEcMIIBGAYLYIZIAYb4RQEHFwIwggEHMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMIHXBggrBgEFBQcCAjCByhqB x05vdGljZSBUZXh0PU5PVElDRTogUHJpdmF0ZSBrZXkgbWF5IGJlIHJlY292ZXJlZCBieSBW ZXJpU2lnbidzIGN1c3RvbWVyIHdobyBtYXkgYmUgYWJsZSB0byBkZWNyeXB0IG1lc3NhZ2Vz IHlvdSBzZW5kIHRvIGNlcnRpZmljYXRlIGhvbGRlci4gIFVzZSBpcyBzdWJqZWN0IHRvIHRl cm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwHwYDVR0jBBgwFoAUkcFz sHPV2ZJ0Z80b8VEUNDG2LFowHQYDVR0OBBYEFPVLC+sA3trYpjnhmDkV16Yv/j5AMC0GA1Ud EQQmMCSgIgYKKwYBBAGCNxQCA6AUDBJkcm9AenVyaWNoLmlibS5jb20wHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMBEGCWCGSAGG+EIBAQQEAwIFoDANBgkqhkiG9w0BAQQFAAOB gQBqNFFtpg4abIyCQefBwQkhmwFJlu87e5k7rB4wKc+Kb9hStjPxAi7JNjNXfZsfWTRCE6eN J4eVQrFAGJKfJGa7/iVW9M5ySqlQzdOxCJuL69BH9s50/8KoLqfwxjnlfvj3j0+MWRfRB13l bkLUiQxN7pQ4AEVQN++/X1LbYl5sHTGCBLcwggSzAgEBMIIBDjCB+TELMAkGA1UEBhMCVVMx NDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAzMTAwLgYDVQQLEydDbGFz cyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eQIQJSBAG0BqCBRfYEFUSgK+mTAJBgUrDgMCGgUAoIIC/TAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MTIwODMyNDda MCMGCSqGSIb3DQEJBDEWBBRIsKpWEhYFcL24c2uveB4iQgL7PTBSBgkqhkiG9w0BCQ8xRTBD MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDCCASEGCSsGAQQBgjcQBDGCARIwggEOMIH5MQswCQYDVQQGEwJVUzE0 MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDMxMDAuBgNVBAsTJ0NsYXNz IDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEkMCIGA1UEAxMbSUJNIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5AhAlIEAbQGoIFF9gQVRKAr6ZMIIBIwYLKoZIhvcNAQkQAgsx ggESoIIBDjCB+TELMAkGA1UEBhMCVVMxNDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5l c3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTAzMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExJDAiBgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQJSBAG0BqCBRf YEFUSgK+mTANBgkqhkiG9w0BAQEFAASBgMteupdw0L2btXRWT/CiEG6QzEgag5HZCSqi5Z7I P8TmOQ7A+o1Ha7cTLD0lLwVvpCeoPdhEnWIOxftRrfV0X0G6aBPLpfTStjX38ODkjhS9SC9z FmMvC8c6nTBfS0g47c2bgyuy9xrFMWG0QAStnOqaiwMBVj8i+ojq3sKuruJdAAAAAAAA --------------ms090609060807040000060309-- 2006 Message-Id: Date: Tue, 9 May 2006 10:56:01 +0200 From: Robert Haas Subject: draft-ietf-forces-mib-01 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I recently updated the ForCES MIB draft with a few small editorial=20 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, --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2006 Message-Id: Date: Wed, 3 May 2006 16:16:32 -0700 From: "Putzolu, David" Subject: FW: Request for IESG review & publication of draft-ietf-forces-protocol-08.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The routing directorate is now using the PROTO process in handling new protocol submissions to the IESG,=20 defined in draft-ietf-proto-wgchair-doc-shepherding-06.txt. =20 Per the PROTO requirements, please find below the write-up=20 that was submitted to the shepherding AD (Russ Housley)=20 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@vigilsec.com'; 'iesg-secretary@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 (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Which chair is the WG Chair Shepherd for this document? Yes, the chairs have reviewed this draft and believe it is ready to forward to the IESG for publication. Both chairs will shepherd the document. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? This document has been fully reviewed by all key WG members and was reviewed for the routing directorate by Sue Hares. No concerns. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, internationalization, XML, etc.)? The membership of the ForCES WG includes a sufficiently broad range of expertise that many of these areas have been reasonably looked at.=20 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. There are no specific areas of serious concern with this document. There is a normative dependency which will keep this draft in the RFC editor's queue pending publication on the ForCES Model draft, which we expect to submit to the IESG shortly. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document is the result of a merger of several proposals from competing design teams and represents a good WG consensus. Many individuals with varying interests provided feedback into this draft. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. (It should be separate email because this questionnaire will be entered into the tracker). There are no known threats of appeal or extreme discontent at this time. Technical discussions did become rather passionate while this draft was still in process. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html). Boilerplate checks are not enough; this check needs to be thorough. This document has been checked against the ID-nits. 1.h) Has the document split its references into normative and informative? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publication). If the normative references are behind, what is the strategy for their completion? On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. The references are split up. There is one normative reference to an ID (FE-MODEL), which is a companion document that specifies a model that the protocol used in this document "carries" over the wire. It is expected that the FE-MODEL document will be entering IETF last call soon and until it completes it, this document will remain at the last stage of the RFC editor queue. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol messages, the specification also defines the framework, the mechanisms, and the Transport Mapping Layer (TML) requirements for ForCES protocol. * Working Group Summary This document derives from three different protocol proposals from different design teams that participated in the ForCES working group. Representatives from each of the design teams agreed to a merged proposal that became this draft. There is good consensus about most of the draft. There was significant contention within the merged design team that drove the draft through several iterations, but at this time there are no significant open objections.=20 * Protocol Quality + Are there existing implementations of the protocol? There are at least four different implementations of this protocol (Znyx, Intel CP-PDK, ZJGSU, and by the University of Patras in Greece). + Have a significant number of vendors indicated they plan to implement the specification? Several vendors have indicated interest but there are no products announced using this protocol at this time. + Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)? Sue Hares reviewed this document for the routing directorate and provided feedback that was incorporated into the draft.=20