RE: [midcom] SNMP In The Evaluation

From daemon@optimus.ietf.org Mon Jun 3 14:25:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26346 for ; Mon, 3 Jun 2002 14:25:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21979 for midcom-archive@odin.ietf.org; Mon, 3 Jun 2002 14:26:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21860; Mon, 3 Jun 2002 14:22:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21831 for ; Mon, 3 Jun 2002 14:22:14 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26262 for ; Mon, 3 Jun 2002 14:21:43 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g53ILgf04323; Mon, 3 Jun 2002 13:21:42 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 13:21:28 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3B9B@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "Tom-PT Taylor" , "'Juergen Quittek'" , "'midcom@ietf.org'" Subject: RE: [midcom] SNMP In The Evaluation Date: Mon, 3 Jun 2002 13:21:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20B2B.744B5AF0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20B2B.744B5AF0 Content-Type: text/plain; charset="iso-8859-1" Hi all, I haven't seen any further discussion on this one, but as Editor, I think I have to agree with Tom. Clearly, there exists an inconsistency in the evaluations as far as the Total Compliance versus Partial Compliance. There had been a brief email thread on the difference in classifying between these two and the conclusion had been that if extensions are required then the protocol is partially compliant: http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02083.htm l Thus, I'm going to propose the change to the SNMP evaluation as Tom has suggested unless there is strong opinions suggesting otherwise. I don't believe this changes the author's overall conclusion that SNMP meets the requirements as the MIDCOM protocol with the design of a MIDCOM MIB module. However, it would require changing some of the statements in section 3. I would propose the following: Changing "The SNMP management framework as evaluated matches all specified Midcom requirements". to say something like: "The SNMP management framework meets all the specified Midcom protocol requirements with the design of a MIDCOM MIB module". and then removing the last sentence from that paragraph. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Taylor, Tom-PT [CAR:B602:EXCH] Sent: Thursday, May 30, 2002 8:55 AM To: 'Juergen Quittek'; 'midcom@ietf.org' Subject: RE: [midcom] SNMP In The Evaluation This is a matter of consistent treatment of the protocols in the evaluation. For DIAMETER, for instance, the necessary data types have probably all been defined in Base, but it will be necessary to define the messages containing them. I think you are saying that in the SNMP case you can point to specific object types you can import but it will be necessary to define a new module to provide a context for them. These may not be at the same level of activity, but I think they are sufficiently analogous that both protocols should be classified in the same way. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Thursday, May 30, 2002 8:51 AM To: Taylor, Tom-PT [CAR:B602:EXCH]; 'midcom@ietf.org' Subject: Re: [midcom] SNMP In The Evaluation Tom, --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: > > SNMP fit to requirements is overstated relative to the other > protocols. For consistency, every requirement which refers to > "an appropriate definition of a Midcom MIB module" should be > rated as "partially met". I agree, that the statements are to general. Would you be fine if I provide more concrete arguments, why these requirements are clearly met. This is much more appropriate than moving to partially met. Take for example "2.2.2 Support of multiple Middlebox types". SNMP has several means to do so, starting from the standard sysObjectID indicating the 'kind of box' to managed objects defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, packet filter, ... Also box type specific support by specific managed objects is something which SNMP/SMI was built for. It definitely meets these requirement fully, not partially. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C20B2B.744B5AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] SNMP In The Evaluation

Hi all,

I haven't seen any further discussion on this one, = but as Editor, I think I have to agree with Tom. Clearly, there = exists an inconsistency in the evaluations as far as the Total = Compliance versus Partial Compliance. There had been a brief email = thread on the difference in classifying between these two and the = conclusion had been that if extensions are required then the protocol = is partially compliant:

http://www1.ietf.org/mail-archive/working-groups/midco= m/current/msg02083.html
Thus, I'm going to propose the change to the SNMP = evaluation as Tom has suggested unless there is strong opinions = suggesting otherwise.

I don't believe this changes the author's overall = conclusion that SNMP meets the requirements as the MIDCOM protocol with = the design of a MIDCOM MIB module. However, it would require changing = some of the statements in section 3.

I would propose the following:
Changing
"The SNMP management framework as evaluated = matches all specified Midcom requirements".
to say something like:
"The SNMP management framework meets all the = specified Midcom protocol requirements with the design of a MIDCOM MIB = module".

and then removing the last sentence from that = paragraph.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

-----Original Message-----
From: Taylor, Tom-PT [CAR:B602:EXCH]
Sent: Thursday, May 30, 2002 8:55 AM
To: 'Juergen Quittek'; 'midcom@ietf.org'
Subject: RE: [midcom] SNMP In The Evaluation

This is a matter of consistent treatment of the = protocols in the evaluation.
For DIAMETER, for instance, the necessary data types = have probably all been
defined in Base, but it will be necessary to define = the messages containing
them. I think you are saying that in the SNMP = case you can point to
specific object types you can import but it will be = necessary to define a
new module to provide a context for them. = These may not be at the same
level of activity, but I think they are sufficiently = analogous that both
protocols should be classified in the same = way.

-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: Thursday, May 30, 2002 8:51 AM
To: Taylor, Tom-PT [CAR:B602:EXCH]; = 'midcom@ietf.org'
Subject: Re: [midcom] SNMP In The Evaluation

Tom,

--On 29 May 2002 09:15 -0400 Tom-PT Taylor = wrote:
>
> SNMP fit to requirements is overstated relative = to the other
> protocols. For consistency, every = requirement which refers to
> "an appropriate definition of a Midcom MIB = module" should be
> rated as "partially met".

I agree, that the statements are to general. Would = you be fine
if I provide more concrete arguments, why these = requirements
are clearly met. This is much more appropriate than = moving to
partially met.

Take for example "2.2.2 Support of multiple = Middlebox types".
SNMP has several means to do so, starting from the = standard
sysObjectID indicating the 'kind of box' to managed = objects
defining the type in more general terms, e.g. NAT, = NAT-PT, NAPT,
packet filter, ...
Also box type specific support by specific managed = objects
is something which SNMP/SMI was built for. It = definitely
meets these requirement fully, not partially.

    Juergen
--
Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
>
> Tom Taylor
> taylor@nortelnetworks.com
> Ph. +1 613 736 0961 (ESN 396 1490)
>

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C20B2B.744B5AF0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jun 4 09:48:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28535 for ; Tue, 4 Jun 2002 09:48:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29041 for midcom-archive@odin.ietf.org; Tue, 4 Jun 2002 09:49:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28919; Tue, 4 Jun 2002 09:46:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28891 for ; Tue, 4 Jun 2002 09:46:50 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28442 for ; Tue, 4 Jun 2002 09:46:14 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g54DjxT06620; Tue, 4 Jun 2002 15:45:59 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 15:45:55 +0200 Message-ID: From: "Cedric Aoun" To: "Tom-PT Taylor" , "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Upcoming meeting Date: Tue, 4 Jun 2002 15:45:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20BCE.24086A58" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20BCE.24086A58 Content-Type: text/plain; charset="iso-8859-1" I agree, we never closed on this if I remember correctly we ended the threads by saying that it is up to the Middle Box to deal with policy rule overlaps and policy rule handovers. I didn't see any consensus on this yet. -----Original Message----- From: Taylor, Tom-PT [CAR:B602:EXCH] Sent: 31 May 2002 18:31 To: 'Melinda Shore'; midcom@ietf.org Subject: RE: [midcom] Upcoming meeting We reached a bit of an impasse over the "deterministic result" requirement in our semantic discussion. I can restart discussion on the list, but we may find this discussion needs face-to-face resolution. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Friday, May 31, 2002 11:59 AM To: midcom@ietf.org Subject: [midcom] Upcoming meeting It's time to start thinking about the agenda for the July meeting. On the plate are: 1) pre-midcom: I'm still hoping to get STUN through WG last call before the meeting, but the other thing, which we're currently calling "SPAN," will just be available and should be discussed. 2) midcom: we'll probably be spending most of the meeting on the evaluation document and talking about moving towards producing a protocol. Please let me know if there's anything that needs additional or particular attention. As usual, there will be NO presentations, and new material will be discussed only if there's an extremely compelling reason for doing so. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C20BCE.24086A58 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Upcoming meeting

I agree, we never closed on this if I remember = correctly we ended the threads
by saying that it is up to the Middle Box to deal = with policy rule overlaps and policy rule handovers.
I didn't see any consensus on this yet.

-----Original Message-----
From: Taylor, Tom-PT [CAR:B602:EXCH]
Sent: 31 May 2002 18:31
To: 'Melinda Shore'; midcom@ietf.org
Subject: RE: [midcom] Upcoming meeting

We reached a bit of an impasse over the = "deterministic result" requirement
in our semantic discussion. I can restart = discussion on the list, but we
may find this discussion needs face-to-face = resolution.

-----Original Message-----
From: Melinda Shore [mailto:mshore@cisco.com]
Sent: Friday, May 31, 2002 11:59 AM
To: midcom@ietf.org
Subject: [midcom] Upcoming meeting

It's time to start thinking about the agenda for the = July
meeting. On the plate are:
1) pre-midcom: I'm still hoping to get STUN through = WG last call
   before the meeting, but the other = thing, which we're currently
   calling "SPAN," will just be = available and should be discussed.
2) midcom: we'll probably be spending most of the = meeting on the
   evaluation document and talking about = moving towards producing
   a protocol.

Please let me know if there's anything that needs = additional or
particular attention. As usual, there will be = NO presentations,
and new material will be discussed only if there's = an extremely
compelling reason for doing so.

Melinda

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C20BCE.24086A58-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 6 03:23:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00600 for ; Thu, 6 Jun 2002 03:23:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA10096 for midcom-archive@odin.ietf.org; Thu, 6 Jun 2002 03:24:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09920; Thu, 6 Jun 2002 03:18:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09891 for ; Thu, 6 Jun 2002 03:18:33 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00532 for ; Thu, 6 Jun 2002 03:18:01 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g567Hv889336; Thu, 6 Jun 2002 09:17:57 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA23528; Thu, 6 Jun 2002 09:14:03 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DA2FD3F30F; Thu, 6 Jun 2002 09:14:02 +0200 (CEST) Message-ID: <3CFF0BC5.2090609@ccrle.nec.de> Date: Thu, 06 Jun 2002 09:14:13 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Upcoming meeting References: <5.1.0.14.0.20020531115055.00aa76e0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit The protocol semantics should be a topic as well. Martin Melinda Shore wrote: > It's time to start thinking about the agenda for the July > meeting. On the plate are: > 1) pre-midcom: I'm still hoping to get STUN through WG last call > before the meeting, but the other thing, which we're currently > calling "SPAN," will just be available and should be discussed. > 2) midcom: we'll probably be spending most of the meeting on the > evaluation document and talking about moving towards producing > a protocol. > > Please let me know if there's anything that needs additional or > particular attention. As usual, there will be NO presentations, > and new material will be discussed only if there's an extremely > compelling reason for doing so. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Thu Jun 6 08:30:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09944 for ; Thu, 6 Jun 2002 08:30:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29711 for midcom-archive@odin.ietf.org; Thu, 6 Jun 2002 08:31:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29145; Thu, 6 Jun 2002 08:29:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29114 for ; Thu, 6 Jun 2002 08:29:03 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09782 for ; Thu, 6 Jun 2002 08:28:28 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g56CSRE14138 for ; Thu, 6 Jun 2002 08:28:27 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 08:28:28 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A590@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] Upcoming meeting Date: Thu, 6 Jun 2002 08:28:31 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org In support of that suggestion, I'll submit an I-D with the content of the earlier discussion. -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Thursday, June 06, 2002 3:14 AM To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Upcoming meeting The protocol semantics should be a topic as well. Martin Melinda Shore wrote: > It's time to start thinking about the agenda for the July > meeting. On the plate are: > 1) pre-midcom: I'm still hoping to get STUN through WG last call > before the meeting, but the other thing, which we're currently > calling "SPAN," will just be available and should be discussed. > 2) midcom: we'll probably be spending most of the meeting on the > evaluation document and talking about moving towards producing > a protocol. > > Please let me know if there's anything that needs additional or > particular attention. As usual, there will be NO presentations, > and new material will be discussed only if there's an extremely > compelling reason for doing so. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 6 21:01:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21840 for ; Thu, 6 Jun 2002 21:01:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA12677 for midcom-archive@odin.ietf.org; Thu, 6 Jun 2002 21:01:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12114; Thu, 6 Jun 2002 20:58:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12085 for ; Thu, 6 Jun 2002 20:58:24 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21687 for ; Thu, 6 Jun 2002 20:57:53 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g570w2u24787 for ; Thu, 6 Jun 2002 19:58:02 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 19:57:57 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3BC2@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Thu, 6 Jun 2002 19:57:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20DBE.5C7453B0" Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20DBE.5C7453B0 Content-Type: text/plain; charset="iso-8859-1" Hi all, Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. As a reminder, the remaining schedule for this WG draft is as follows: June 14th Second version of draft available. June 14th-June 21st Mailing list discussion of version 2 of draft. June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available July 26th- Aug (whether another iteration is required for WGLC depends upon the extent of changes, etc.) Aug Draft submitted to IESG Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C20DBE.5C7453B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder: Comments due to list on = draft-ietf-midcom-protocol-eval-00.txt by Monday June 10th, noon = CST

Hi all,

Just a reminder that comments on the protocol = evaluation draft are due by noon on Monday, June 10th. It's = available at:

http://www.ietf.org/internet-drafts/draft-ietf-midcom-= protocol-eval-00.txt

The level of discussion on this draft by members of = the WG has been rather disquieting. The draft is not incredibly = long, with the new material being primarily in the Overview and = Conclusion sections. There are a also few areas which definitely need = discussion and WG feedback which are indicated by [Contributor's note: = blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. = So, please try to set aside 30 minutes and at least review those = portions. The objective is for the draft to be fairly complete and = actually undergoing WGLC by the Yokohama meeting, so comments now are = definitely preferred over during the WG session or after the Yokohama = meeting.

As a reminder, the remaining schedule for this WG = draft is as follows:

June 14th       Second = version of draft available.
June 14th-June 21st Mailing list discussion of = version 2 of draft.
June 28th       Draft = ready for WGLC
July 19th       WGLC = ends
July 26th       = Updated draft based upon WGLC comments available
July 26th- Aug (whether another iteration is = required for WGLC depends upon
          &nb= sp;     the extent of changes, etc.)
Aug     Draft submitted to IESG =

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

------_=_NextPart_001_01C20DBE.5C7453B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 7 10:11:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26959 for ; Fri, 7 Jun 2002 10:11:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29209 for midcom-archive@odin.ietf.org; Fri, 7 Jun 2002 10:11:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28938; Fri, 7 Jun 2002 10:06:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28911 for ; Fri, 7 Jun 2002 10:06:04 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26833 for ; Fri, 7 Jun 2002 10:05:31 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GXC00D019Q9LL@firewall.wcom.com> for midcom@ietf.org; Fri, 7 Jun 2002 14:03:46 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GXC00BLW9Q9UO@firewall.wcom.com>; Fri, 07 Jun 2002 14:03:45 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GXC006019Q7AC@dgismtp01.wcomnet.com>; Fri, 07 Jun 2002 14:03:44 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GXC0052D9PSQL@dgismtp01.wcomnet.com>; Fri, 07 Jun 2002 14:03:29 +0000 (GMT) Date: Fri, 07 Jun 2002 09:03:25 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST In-reply-to: <1B54FA3A2709D51195C800508BF9386A03DE3BC2@zrc2c000.us.nortel.com> To: "'Mary Barnes'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002601c20e2c$18895b00$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lboGXSzpZjy5eMzSqmty4A)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_lboGXSzpZjy5eMzSqmty4A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Reminder: Comments due to list on draft-ietf-midcom-protocol-eval-00.txt by Monday June 10th, noon CSTMary, This is an excellent draft, very focused side by side review of existing potential protocols for possible reuse in this effort. You pulled the WG information together in a great way. The draft offers a very objective comparison that provides the comparison of each with the requirements of MIDCOM and each protocol under review. I will be performing more indepth analysis of the results but believe that you are right on the mark with your results from my first read. I concur with the conclusions which indicate a better fit between SNMP and DIAMETER than the other protocols reviewed, as well as the bulkiness of DIAMETER as opposed to SNMP. You know initially when I saw SNMP listed the first thing that came to mind was the security issues associated with the legacy versions of the protocol, but was glad to see that SNMPv3 was recommended. The maturity, tools, and ease of implementation make this a good fit as outlined in the draft. Typically, due to security concerns, I would not want to permit write operation, or third party control of a firewall or similiar class of middlebox, but if we must go down this path, as MIDCOM is, then the selection/creation of a suitable protocol must be made. The fact that two of the three core security concepts are inlcuded for consideration in this draft also adds to the security of the protocol and future of MIDCOM. The two that I am referring to are of course confidentiality and integrity. Authentication is also key componenet and this is covered as it should be. The third core security concept that we do not cover is availability, which is another item that falls under redundancy/failover and maybe has been disussed in the list, this I am unsure of since I have been absent for some time due to resource issues but will be participating again. I think the review and considerations found in this draft can accelerate this process. I hope that more review and comments are made regarding this draft ASAP. I will certainly give it a closer look over the weekend, but as it stands from my initial review believe it to be very concise. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Mary Barnes Sent: Thursday, June 06, 2002 7:58 PM To: 'midcom@ietf.org' Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Hi all, Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. As a reminder, the remaining schedule for this WG draft is as follows: June 14th Second version of draft available. June 14th-June 21st Mailing list discussion of version 2 of draft. June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available July 26th- Aug (whether another iteration is required for WGLC depends upon the extent of changes, etc.) Aug Draft submitted to IESG Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 --Boundary_(ID_lboGXSzpZjy5eMzSqmty4A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reminder: Comments due to list on = draft-ietf-midcom-protocol-eval-00.txt by Monday June 10th, noon = CST

Mary,

This=20 is an excellent draft, very focused side by side review of existing = potential=20 protocols for possible reuse in this effort. You pulled the WG = information=20 together in a great way.

The draft offers a very objective comparison = that provides the=20 comparison of each with the requirements of MIDCOM and each = protocol=20 under review.

I will=20 be performing more indepth analysis of the results but believe that you = are=20 right on the mark with your results from my first = read.

I=20 concur with the conclusions which indicate a better = fit between SNMP=20 and DIAMETER than the other protocols reviewed, as well as the bulkiness = of=20 DIAMETER as opposed to SNMP.

You=20 know initially when I saw SNMP listed the first thing that came to mind = was the=20 security issues associated with the legacy versions of the protocol, but = was=20 glad to see that SNMPv3 was recommended. The maturity, = tools, and=20 ease of implementation make this a good fit as outlined in the=20 draft.

Typically, due to security concerns, I would not want = to permit=20 write operation, or third party control of a firewall or similiar class = of=20 middlebox, but if we must go down this path, as MIDCOM is, then the = selection/creation of a suitable protocol must be made. =

The=20 fact that two of the three core security concepts are inlcuded for = consideration=20 in this draft also adds to the security of the protocol and future of = MIDCOM.=20 The two that I am referring to are of course confidentiality and = integrity.=20

Authentication is also key = componenet and this=20 is covered as it should be. The third core security concept that we = do not=20 cover is availability, which is another item that falls under=20 redundancy/failover and maybe has been disussed in the list, this I am = unsure of=20 since I have been absent for some time due to resource issues but = will be=20 participating again.

I=20 think the review and considerations found in this draft = can accelerate this=20 process. I hope that more review and comments are made regarding this = draft=20 ASAP. I will certainly give it a closer look over the weekend, but as it = stands=20 from my initial review believe it to be very = concise.

Chris

-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Mary = Barnes
Sent:=20 Thursday, June 06, 2002 7:58 PM
To:=20 'midcom@ietf.org'
Subject: [midcom] Reminder: Comments due = to list=20 on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon=20 CST

Hi all,

Just a reminder that comments on the protocol = evaluation draft=20 are due by noon on Monday, June 10th. It's available = at:

http://www.ietf.org/internet-drafts/draft-ietf-midcom-pro= tocol-eval-00.txt=20

The level of discussion on this draft by members of = the WG has=20 been rather disquieting. The draft is not incredibly long, with = the new=20 material being primarily in the Overview and Conclusion sections. = There are a=20 also few areas which definitely need discussion and WG feedback which = are=20 indicated by [Contributor's note: blah...blah...blah] and [Editor's = note:=20 yadda...yadda...yadda]. So, please try to set aside 30 minutes = and at=20 least review those portions. The objective is for the draft to be = fairly=20 complete and actually undergoing WGLC by the Yokohama meeting, so = comments now=20 are definitely preferred over during the WG session or after the = Yokohama=20 meeting.

As a reminder, the remaining schedule for this WG = draft is as=20 follows:

June 14th       Second = version=20 of draft available.
June 14th-June = 21st Mailing=20 list discussion of version 2 of draft.
June=20 28th       Draft ready for WGLC =
July 19th       WGLC ends=20
July = 26th       Updated=20 draft based upon WGLC comments available
July 26th-=20 Aug (whether another iteration is required for WGLC depends upon=20
          &nbs= p;    =20 the extent of changes, etc.)
Aug     Draft submitted to IESG =

Regards,
Mary H. Barnes=20
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806 =

--Boundary_(ID_lboGXSzpZjy5eMzSqmty4A)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 7 10:37:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28486 for ; Fri, 7 Jun 2002 10:37:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01839 for midcom-archive@odin.ietf.org; Fri, 7 Jun 2002 10:37:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01492; Fri, 7 Jun 2002 10:33:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01450 for ; Fri, 7 Jun 2002 10:33:15 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28272 for ; Fri, 7 Jun 2002 10:32:42 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g57EWhPI010273 for ; Fri, 7 Jun 2002 07:32:43 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEC02621; Fri, 7 Jun 2002 07:29:49 -0700 (PDT) Message-Id: <5.1.0.14.0.20020607103517.0134c440@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jun 2002 10:37:32 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Meeting schedule - FYI Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We've tentatively been scheduled to meet in Yokohama on the evening of Monday, 15 July from 1730-2200. Tentative agendas have in the past proven to be very fluid, and it should not be assumed that this is our final schedule slot. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 7 11:58:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01920 for ; Fri, 7 Jun 2002 11:58:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06550 for midcom-archive@odin.ietf.org; Fri, 7 Jun 2002 11:59:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06265; Fri, 7 Jun 2002 11:54:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06205 for ; Fri, 7 Jun 2002 11:54:34 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01775; Fri, 7 Jun 2002 11:54:02 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g57FriuF005929; Fri, 7 Jun 2002 08:53:44 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEC04593; Fri, 7 Jun 2002 08:51:06 -0700 (PDT) Message-Id: <5.1.0.14.0.20020607115325.0131f9c0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jun 2002 11:58:44 -0400 To: midcom@ietf.org, nsis@ietf.org, midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] RSVP for middlebox communication mailing list Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I've established a mailing list, called "tist", for discussion of the use of RSVP (or an RSVP-like protocol) for middlebox communication. There's an initial protocol proposal at http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt and I'm in the process of putting together a proposed agenda for a BOF at the upcoming meeting. To subscribe, send email to mailer@cisco.com with "subscribe tist" in the body of the message. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 7 12:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02332 for ; Fri, 7 Jun 2002 12:09:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09009 for midcom-archive@odin.ietf.org; Fri, 7 Jun 2002 12:09:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08625; Fri, 7 Jun 2002 12:05:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08595 for ; Fri, 7 Jun 2002 12:05:01 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02161 for ; Fri, 7 Jun 2002 12:04:29 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g57G3GIZ022284 for ; Fri, 7 Jun 2002 09:03:17 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEC04913; Fri, 7 Jun 2002 09:00:22 -0700 (PDT) Message-Id: <5.1.0.14.0.20020607115954.0131e0d0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jun 2002 12:07:59 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Status Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Here's where we are - please read through, as there is a question in the text. 1) Evaluation document: we have a first draft currently under review. *Please* read it carefully with a particular eye for the correctness of the claims being made about each protocol. Let's make every effort to avoid hitting showstoppers in WG last call. 2) Semantics document: Tom Taylor has said that he'll be submitting a draft describing midcom semantics. Although I haven't discussed this with him :-), if there are no objections I'd like to make this a working group document. Are there objections? 3) STUN: the security section of the STUN draft is in the process of being rewritten with a more complete analysis of potential security exposures and a more complete catalog of potential mitigations 4) SPAN: we're waiting for a first draft from the design team. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 7 14:29:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07712 for ; Fri, 7 Jun 2002 14:29:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21009 for midcom-archive@odin.ietf.org; Fri, 7 Jun 2002 14:29:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20902; Fri, 7 Jun 2002 14:25:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20841 for ; Fri, 7 Jun 2002 14:24:59 -0400 (EDT) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07564; Fri, 7 Jun 2002 14:24:27 -0400 (EDT) Received: from jku2.fokus.gmd.de (dhcp226.fokus.gmd.de [195.37.78.226]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g57INrC31156; Fri, 7 Jun 2002 20:23:53 +0200 Message-Id: <5.1.0.14.0.20020607200432.03738008@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Jun 2002 20:16:59 +0200 To: Melinda Shore , midcom@ietf.org, nsis@ietf.org, midcom@ietf.org From: Jiri Kuthan Subject: Re: [midcom] RSVP for middlebox communication mailing list In-Reply-To: <5.1.0.14.0.20020607115325.0131f9c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA20844 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit I think it would be fair to refer to publications which came out with the same idea earlier. -Jiri Utz Roedig, Manuel G�rtz, Martin Karsten, and Ralf Steinmetz. RSVP as Firewall Signalling Protocol. In Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pages 57-62. IEEE, July 2001. http://www.kom.e-technik.tu-darmstadt.de/publications/abstracts/RGKS01-1.html At 05:58 PM 6/7/2002, Melinda Shore wrote: >I've established a mailing list, called "tist", for discussion of >the use of RSVP (or an RSVP-like protocol) for middlebox communication. >There's an initial protocol proposal at >http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt >and I'm in the process of putting together a proposed agenda for >a BOF at the upcoming meeting. > >To subscribe, send email to mailer@cisco.com with "subscribe tist" >in the body of the message. > >Melinda > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 7 15:02:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08909 for ; Fri, 7 Jun 2002 15:02:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23389 for midcom-archive@odin.ietf.org; Fri, 7 Jun 2002 15:03:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22780; Fri, 7 Jun 2002 14:58:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22729 for ; Fri, 7 Jun 2002 14:58:14 -0400 (EDT) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08636; Fri, 7 Jun 2002 14:57:41 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GXC00F01NBGU9@firewall.wcom.com>; Fri, 7 Jun 2002 18:57:16 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GXC00DKTNBGV8@firewall.wcom.com>; Fri, 07 Jun 2002 18:57:16 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GXC00H01NBCNE@pmismtp06.wcomnet.com>; Fri, 07 Jun 2002 18:57:15 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXC00FLPNBDMC@pmismtp06.wcomnet.com>; Fri, 07 Jun 2002 18:57:13 +0000 (GMT) Date: Fri, 07 Jun 2002 13:57:11 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] RSVP for middlebox communication mailing list In-reply-to: <5.1.0.14.0.20020607200432.03738008@mailhost.fokus.gmd.de> To: "'Jiri Kuthan'" , "'Melinda Shore'" , midcom@ietf.org, nsis@ietf.org, midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <000e01c20e55$221362a0$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id OAA22730 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit I agree, and Melinda reminded me of TIST earlier today, I just think that the comparison was very well done and had was very easy reading, these should of course be included as well. Chris -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Jiri Kuthan Sent: Friday, June 07, 2002 1:17 PM To: Melinda Shore; midcom@ietf.org; nsis@ietf.org; midcom@ietf.org Subject: Re: [midcom] RSVP for middlebox communication mailing list I think it would be fair to refer to publications which came out with the same idea earlier. -Jiri Utz Roedig, Manuel G�rtz, Martin Karsten, and Ralf Steinmetz. RSVP as Firewall Signalling Protocol. In Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pages 57-62. IEEE, July 2001. http://www.kom.e-technik.tu-darmstadt.de/publications/abstracts/RGKS01-1.htm l At 05:58 PM 6/7/2002, Melinda Shore wrote: >I've established a mailing list, called "tist", for discussion of >the use of RSVP (or an RSVP-like protocol) for middlebox communication. >There's an initial protocol proposal at >http://search.ietf.org/internet-drafts/draft-shore-tist-prot-00.txt >and I'm in the process of putting together a proposed agenda for >a BOF at the upcoming meeting. > >To subscribe, send email to mailer@cisco.com with "subscribe tist" >in the body of the message. > >Melinda > > >_______________________________________________ >midcom mailing list >midcom@ietf.org >https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jun 10 03:58:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24959 for ; Mon, 10 Jun 2002 03:58:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA12435 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 03:59:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12103; Mon, 10 Jun 2002 03:46:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12073 for ; Mon, 10 Jun 2002 03:46:01 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24766 for ; Mon, 10 Jun 2002 03:45:19 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5A7jGD28643 for ; Mon, 10 Jun 2002 09:45:17 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 09:44:54 +0200 Message-ID: From: "Cedric Aoun" To: "Mary Barnes" , "'midcom@ietf.org'" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Mon, 10 Jun 2002 09:45:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21052.C6680546" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21052.C6680546 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, General comments:=20 There is an inconsistency with the used compliancy method, Tom and you = have=20 actually already mentioned that.In the comments below I will point out = to the requirements where the SNMP compliancy should be changed. I found "=C6" several times in the text instead of "'" it is perhaps = due to CRLF. Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a = PDP. Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification will be based on matching an IP address and port to a certain SNMP = agent. In case more a Middlebox applying NAT is deployed between a Midcom = agent and the Middlebox being controlled by the Midcom agent then the = identification=20 can't be known in advance and therefore can't be provisioned. I think we could find certain network topologies where firewalls are deployed in certain departments and then a NAT + Firewall is deployed at the = network=20 interconnection of the enterprise. In this case all protocols not = having IDs will fail, including SNMP.IMO the requirement is not met by SNMP. Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is = coupled with the application host, it can't be on a separate host. I see as a = failure to meeting the MIDCOM framework, in which we wanted a complete flexible = model where the Midcom agent function could be hosted on any host. This = comment is probably more on the general applicability of RSIP, but since there is = a note on it in 2.1.3 the comment is applicable on the section as well. 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, = this mechanism applies only if the messages have a reply, in case of TRAPs this is not = the case. Therefore IMO this requirement is not met. 2.2.1 Extensibility. I think we should grade differently protocols that = have existing means of extensibility without changing the base protocol messages by = using "objects" as means of extensibility and protocols that achieve extensibility by = adding new messages or parameters in the base protocol to achieve the extensibility. As = such the RSIP protocol requires more work to be extensible and should be graded differently. = I don't know if it fair to put its compliancy to Partially met or Unmet. 2.2.8 Transport of filtering rules SNMP requires a new MIDCOM MIB to meet this requirement, therefore it = is partially compliant as the MIB is not existent RSIP currently couples the filter with the action which is address translation or address and port translation. As we are looking at a model where the filter is decoupled from the action (from a syntax perspective) I think that = RSIP currently fails to meet the requirement. 2.2.9 Mapped port parity SNMP compliance should be partial as it requires the creation of the = MIDCOM MIB 2.2.10 Consecutive range of port numbers SNMP compliance should be partial as it requires the creation of the = MIDCOM MIB 2.2.11 Same as 2.2.10 for the SNMP compliance 3 Conclusion I think that in the SNMP statement the reliability problems should be discussed as their fix is not included in of the shelf stacks and do not apply to = TRAP messages. Similarly the statement on the broad deployment of SNMP doesn't include SNMPv3, this should probably stated as well. Cedric -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH]=20 Sent: 07 June 2002 02:58 To: 'midcom@ietf.org' Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Hi all,=20 Just a reminder that comments on the protocol evaluation draft are due = by noon on Monday, June 10th. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.t= xt=20 The level of discussion on this draft by members of the WG has been = rather disquieting. The draft is not incredibly long, with the new material = being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need discussion and WG feedback which are = indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at = least review those portions. The objective is for the draft to be fairly = complete and actually undergoing WGLC by the Yokohama meeting, so comments now = are definitely preferred over during the WG session or after the Yokohama meeting. =20 As a reminder, the remaining schedule for this WG draft is as follows:=20 June 14th Second version of draft available.=20 June 14th-June 21st Mailing list discussion of version 2 of draft.=20 June 28th Draft ready for WGLC=20 July 19th WGLC ends=20 July 26th Updated draft based upon WGLC comments available=20 July 26th- Aug (whether another iteration is required for WGLC depends = upon=20 the extent of changes, etc.)=20 Aug Draft submitted to IESG=20 Regards,=20 Mary H. Barnes=20 mbarnes@nortelnetworks.com=20 972-684-5432=20 Wireless 817-703-4806=20 =20 ------_=_NextPart_001_01C21052.C6680546 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon = CST

Section 1.1.3 SNMP overview section: the Middle Box = is a PEP and not a PDP.

Section 2.1.2. SNMP doesn't include any Midcom agent = identifiers, the identification
will be based on matching an IP address and = port to a certain SNMP agent.
In case more a Middlebox applying NAT is deployed = between a Midcom agent and
the Middlebox being controlled by the Midcom agent = then the identification
can't be known in advance and therefore can't be = provisioned.
I think we could find certain network topologies = where firewalls are deployed
in certain departments and then a NAT + Firewall is = deployed at the network
interconnection of the enterprise. In this case all = protocols not having IDs
will fail, including SNMP.IMO the requirement is not = met by SNMP.

Section 2.1.2 RSIP compliancy section. In RSIP the = Midcom agent is coupled with
the application host, it can't be on a = separate host. I see as a failure to
meeting the MIDCOM framework, in which we wanted a = complete flexible model
where the Midcom agent function could be hosted on = any host. This comment is
probably more on the general applicability of RSIP, = but since there is a note
on it in 2.1.3 the comment is applicable on the = section as well.

2.2.8 Transport of filtering rules
SNMP requires a new MIDCOM MIB to meet this = requirement, therefore it is partially
compliant as the MIB is not existent

2.2.9 Mapped port parity
SNMP compliance should be partial as it requires the = creation of the MIDCOM MIB

2.2.10 Consecutive range of port numbers
SNMP compliance should be partial as it requires the = creation of the MIDCOM MIB

2.2.11 Same as 2.2.10 for the SNMP compliance

3 Conclusion
I think that in the SNMP statement the reliability = problems should be discussed
as their fix is not included in of the shelf stacks = and do not apply to TRAP messages.
Similarly the statement on the broad deployment of = SNMP doesn't include SNMPv3,
this should probably stated as well.

Cedric

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH]
Sent: 07 June 2002 02:58
To: 'midcom@ietf.org'
Subject: [midcom] Reminder: Comments due to list on = draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon = CST

Hi all,
Just a reminder that comments on the protocol = evaluation draft are due by noon on Monday, June 10th. It's = available at:

http://www.ietf.org/internet-drafts/draft-ietf-midcom-= protocol-eval-00.txt
The level of discussion on this draft by members of = the WG has been rather disquieting. The draft is not incredibly = long, with the new material being primarily in the Overview and = Conclusion sections. There are a also few areas which definitely need = discussion and WG feedback which are indicated by [Contributor's note: = blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. = So, please try to set aside 30 minutes and at least review those = portions. The objective is for the draft to be fairly complete and = actually undergoing WGLC by the Yokohama meeting, so comments now are = definitely preferred over during the WG session or after the Yokohama = meeting.

As a reminder, the remaining schedule for this WG = draft is as follows:
June 14th       Second = version of draft available.
June 14th-June 21st Mailing list discussion of = version 2 of draft.
June 28th       Draft = ready for WGLC
July 19th       WGLC = ends
July 26th       = Updated draft based upon WGLC comments available
July 26th- Aug (whether another iteration is = required for WGLC depends upon
          &nb= sp;     the extent of changes, etc.)
Aug     Draft submitted to IESG =
Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806

------_=_NextPart_001_01C21052.C6680546-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jun 10 09:46:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04148 for ; Mon, 10 Jun 2002 09:46:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03876 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 09:47:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03498; Mon, 10 Jun 2002 09:39:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03449 for ; Mon, 10 Jun 2002 09:39:27 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03806 for ; Mon, 10 Jun 2002 09:38:51 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5ADcC874045; Mon, 10 Jun 2002 15:38:13 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA12527; Mon, 10 Jun 2002 15:34:04 +0200 Date: Mon, 10 Jun 2002 15:34:03 +0200 From: Juergen Quittek To: Mary Barnes , Tom-PT Taylor , "'midcom@ietf.org'" Subject: RE: [midcom] SNMP In The Evaluation Message-ID: <25600781.1023723243@[192.168.102.164]> In-Reply-To: <1B54FA3A2709D51195C800508BF9386A03DE3B9B@zrc2c000.us.nortel.com> References: <1B54FA3A2709D51195C800508BF9386A03DE3B9B@zrc2c000.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Mary, --On 03 June 2002 13:21 -0500 Mary Barnes wrote: > > Hi all, > > I haven't seen any further discussion on this one, but as Editor, I think I have to agree with Tom. Clearly, there exists an inconsistency in the evaluations as far as the Total Compliance versus Partial Compliance. There had been a brief email thread > on the difference in classifying between these two and the conclusion had been that if extensions are required then the protocol is partially compliant: > > http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02083.html > Thus, I'm going to propose the change to the SNMP evaluation as Tom has suggested unless there is strong opinions suggesting otherwise. > > I don't believe this changes the author's overall conclusion that SNMP meets the requirements as the MIDCOM protocol with the design of a MIDCOM MIB module. However, it would require changing some of the statements in section 3. > > I would propose the following: > Changing > "The SNMP management framework as evaluated matches all specified Midcom requirements". > to say something like: > "The SNMP management framework meets all the specified Midcom protocol requirements with the design of a MIDCOM MIB module". I fully agree. Maybe we can even improve phrasing by writing "appropriate design" instead of just "design". Juergen > > and then removing the last sentence from that paragraph. > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 > > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Thursday, May 30, 2002 8:55 AM > To: 'Juergen Quittek'; 'midcom@ietf.org' > Subject: RE: [midcom] SNMP In The Evaluation > > This is a matter of consistent treatment of the protocols in the evaluation. > For DIAMETER, for instance, the necessary data types have probably all been > defined in Base, but it will be necessary to define the messages containing > them. I think you are saying that in the SNMP case you can point to > specific object types you can import but it will be necessary to define a > new module to provide a context for them. These may not be at the same > level of activity, but I think they are sufficiently analogous that both > protocols should be classified in the same way. > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Thursday, May 30, 2002 8:51 AM > To: Taylor, Tom-PT [CAR:B602:EXCH]; 'midcom@ietf.org' > Subject: Re: [midcom] SNMP In The Evaluation > > Tom, > > --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: >> >> SNMP fit to requirements is overstated relative to the other >> protocols. For consistency, every requirement which refers to >> "an appropriate definition of a Midcom MIB module" should be >> rated as "partially met". > > I agree, that the statements are to general. Would you be fine > if I provide more concrete arguments, why these requirements > are clearly met. This is much more appropriate than moving to > partially met. > > Take for example "2.2.2 Support of multiple Middlebox types". > SNMP has several means to do so, starting from the standard > sysObjectID indicating the 'kind of box' to managed objects > defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, > packet filter, ... > Also box type specific support by specific managed objects > is something which SNMP/SMI was built for. It definitely > meets these requirement fully, not partially. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> Tom Taylor >> taylor@nortelnetworks.com >> Ph. +1 613 736 0961 (ESN 396 1490) >> > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jun 10 11:23:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08410 for ; Mon, 10 Jun 2002 11:23:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09102 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 11:24:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08808; Mon, 10 Jun 2002 11:13:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08780 for ; Mon, 10 Jun 2002 11:13:47 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07782 for ; Mon, 10 Jun 2002 11:13:14 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5AFCS882912; Mon, 10 Jun 2002 17:12:28 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA13524; Mon, 10 Jun 2002 17:08:19 +0200 Date: Mon, 10 Jun 2002 17:08:18 +0200 From: Juergen Quittek To: Cedric Aoun , Mary Barnes , "'midcom@ietf.org'" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Message-ID: <31255372.1023728898@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08781 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Cedric, --On 10 June 2002 09:45 +0200 Cedric Aoun wrote: > > Hi Mary, > General comments: > There is an inconsistency with the used compliancy method, Tom and you have > actually already mentioned that.In the comments below I will point out to the > requirements where the SNMP compliancy should be changed. > I found "�" several times in the text instead of "'" it is perhaps due to CRLF. > > Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a PDP. > > Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification > will be based on matching an IP address and port to a certain SNMP agent. > In case more a Middlebox applying NAT is deployed between a Midcom agent and > the Middlebox being controlled by the Midcom agent then the identification > can't be known in advance and therefore can't be provisioned. > I think we could find certain network topologies where firewalls are deployed > in certain departments and then a NAT + Firewall is deployed at the network > interconnection of the enterprise. In this case all protocols not having IDs > will fail, including SNMP.IMO the requirement is not met by SNMP. Did I get you right?: You think you can find some network cofiguration where SNMP cannot support multiple Midcom agents communicating with more than one middlebox simulataneously. But you cannot explain them here and therefore the requirement is not met by SNMP??? SNMP has several features only built in to explicitly support multiple Midcom agents (SNMP managers) within a single stack. Not even multiple instances of the PEP are required, as it is for COPS. > Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is coupled with > the application host, it can't be on a separate host. I see as a failure to > meeting the MIDCOM framework, in which we wanted a complete flexible model > where the Midcom agent function could be hosted on any host. This comment is > probably more on the general applicability of RSIP, but since there is a note > on it in 2.1.3 the comment is applicable on the section as well. > > 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this mechanism > applies only if the messages have a reply, in case of TRAPs this is not the case. > Therefore IMO this requirement is not met. Requirement 2.1.7 says: "The protocol must support unsolicited messages from middlebox to agent ...". How can you say this is not exactly what SNMP notifications are available for? If you require reliability in addition, I suggest the following procedure: 1. add reliability to the requirements 2. state that reliability is not met by SNMP notifications. Please tell me, if I missed a reliability statement. Then we can discuss replacing replace SNMP notifications by reliable SNMP inform messages. I did not mention them yet, because they are not available in SNMPv1, but they are in v2 and v3. In any case SNMP meets the requirement. > 2.2.1 Extensibility. I think we should grade differently protocols that have existing > means of extensibility without changing the base protocol messages by using "objects" > as means of extensibility and protocols that achieve extensibility by adding new messages > or parameters in the base protocol to achieve the extensibility. As such the RSIP protocol > requires more work to be extensible and should be graded differently. I don't know if it > fair to put its compliancy to Partially met or Unmet. > > 2.2.8 Transport of filtering rules > SNMP requires a new MIDCOM MIB to meet this requirement, therefore it is partially > compliant as the MIB is not existent > > RSIP currently couples the filter with the action which is address translation > or address and port translation. As we are looking at a model where the filter > is decoupled from the action (from a syntax perspective) I think that RSIP > currently fails to meet the requirement. > > 2.2.9 Mapped port parity > SNMP compliance should be partial as it requires the creation of the MIDCOM MIB > > 2.2.10 Consecutive range of port numbers > SNMP compliance should be partial as it requires the creation of the MIDCOM MIB > > 2.2.11 Same as 2.2.10 for the SNMP compliance > > 3 Conclusion > I think that in the SNMP statement the reliability problems should be discussed > as their fix is not included in of the shelf stacks and do not apply to TRAP messages. It is available in commercial off-the-shelf implementations as well as in even very simple public domain implementations. > Similarly the statement on the broad deployment of SNMP doesn't include SNMPv3, > this should probably stated as well. Yes, that's right. However, we still should compare SNMPv3 deployment and maturity to COPS, Diameter, Megaco, RSIP deployment. The SNMPv3 RFCs have already achieved draft standard status. > Cedric > > > -----Original Message----- > From: Barnes, Mary [NGC:B602:EXCH] > Sent: 07 June 2002 02:58 > To: 'midcom@ietf.org' > Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST > > Hi all, > Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt > The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need > discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be > fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. > > As a reminder, the remaining schedule for this WG draft is as follows: > June 14th Second version of draft available. > June 14th-June 21st Mailing list discussion of version 2 of draft. > June 28th Draft ready for WGLC > July 19th WGLC ends > July 26th Updated draft based upon WGLC comments available > July 26th- Aug (whether another iteration is required for WGLC depends upon > the extent of changes, etc.) > Aug Draft submitted to IESG > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jun 10 12:11:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10987 for ; Mon, 10 Jun 2002 12:11:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12997 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 12:12:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11044; Mon, 10 Jun 2002 12:00:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10928 for ; Mon, 10 Jun 2002 12:00:12 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10348 for ; Mon, 10 Jun 2002 11:59:37 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5AFxe885361; Mon, 10 Jun 2002 17:59:40 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA13987; Mon, 10 Jun 2002 17:55:32 +0200 Date: Mon, 10 Jun 2002 17:55:31 +0200 From: Juergen Quittek To: Mary Barnes , "'midcom@ietf.org'" Subject: Re: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Message-ID: <34088626.1023731731@[192.168.102.164]> In-Reply-To: <1B54FA3A2709D51195C800508BF9386A03DE3BC2@zrc2c000.us.nortel.com> References: <1B54FA3A2709D51195C800508BF9386A03DE3BC2@zrc2c000.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Mary, Here are my comments. First of all I agree to the statement that where SNMP evaluation depends on a proper MIB module definition, "partially met" should be used. 1.1.3, 2nd paragraph: replace "The roles of entities participating in SNMP communication are called from the manager." by "The roles of entities participating in SNMP communication are called manager and agent." 1.1.3, 3rd paragraph: replace "Although he" by "Although the". 2.1.3 COPS, editor's note I think COPS meets this requirement. For example the RFC 3084 on COPS-PR exlicitly mentions this. 2.1: COPS in general I think it would be helpful to clarify, some COPS restrictions. For example RFC 3084 says: "When a (middlebox) device boots, it opens a COPS connection to its Primary PDP (Midcom agent)." This holds for each agent that wants to send midcom requests to the middlebox. The good point is that agent-PEP associtions survive power-failures. The disadvantage is, that each agent that intends to send midcom requests must be made known to the middlebox by means other than the ones provided by COPS. (Please correct me if I'm wrong.) 2.2.2, SNMP We can replace the very generic phrasing by a more specific one: "SNMP explicilty supports managing different device type with different capabilities. First the managed object called sysObjectID from basic MIB-II (RFC1213) identifies the kind of box. For boxes with varying capabilites, SNMP can check the availability of corresponding MIBs." Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 06 June 2002 19:57 -0500 Mary Barnes wrote: > > Hi all, > > Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt > > The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need > discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be > fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. > > As a reminder, the remaining schedule for this WG draft is as follows: > > June 14th Second version of draft available. > June 14th-June 21st Mailing list discussion of version 2 of draft. > June 28th Draft ready for WGLC > July 19th WGLC ends > July 26th Updated draft based upon WGLC comments available > July 26th- Aug (whether another iteration is required for WGLC depends upon > the extent of changes, etc.) > Aug Draft submitted to IESG > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 15:49:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22092 for ; Mon, 10 Jun 2002 15:48:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25613 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 15:49:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25507; Mon, 10 Jun 2002 15:44:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25476 for ; Mon, 10 Jun 2002 15:44:22 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21859 for ; Mon, 10 Jun 2002 15:43:46 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A19079FE0144; Mon, 10 Jun 2002 15:44:16 -0400 Message-ID: <00f701c210b7$35d97ae0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Juergen Quittek" , "Cedric Aoun" , "Mary Barnes" , References: <31255372.1023728898@[192.168.102.164]> Subject: Re: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Date: Mon, 10 Jun 2002 15:44:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Juergen Quittek" > --On 10 June 2002 09:45 +0200 Cedric Aoun wrote: > > 2.1.7 Reliability in SNMP is achieved by retransmissions > > and timers, this mechanism applies only if the messages > > have a reply, in case of TRAPs this is not the case. > > Therefore IMO this requirement is not met. > > Requirement 2.1.7 says: "The protocol must support unsolicited > messages from middlebox to agent ...". How can you say this > is not exactly what SNMP notifications are available for? > > If you require reliability in addition, I suggest the following procedure: > 1. add reliability to the requirements > 2. state that reliability is not met by SNMP notifications. > > Please tell me, if I missed a reliability statement. Then we can discuss > replacing replace SNMP notifications by reliable SNMP inform messages. > I did not mention them yet, because they are not available in SNMPv1, > but they are in v2 and v3. I think that reliability is covered by the requirement to maintain "known and stable state". What's the point of sending a notification (TRAP) to a midcom agent if there is no mechanism to guarantee that the message gets there. The INFORM messages will need to be used if SNMP is chosen. BTW, we did actually have an explicit requirement for reliability at one point. I think it was deleted because people felt it was covered by the other requirements. cheers, (-:bob _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 16:03:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22806 for ; Mon, 10 Jun 2002 16:03:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26847 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 16:04:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26094; Mon, 10 Jun 2002 15:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26066 for ; Mon, 10 Jun 2002 15:59:16 -0400 (EDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22597 for ; Mon, 10 Jun 2002 15:58:40 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GXI00H01A4H54@firewall.wcom.com> for midcom@ietf.org; Mon, 10 Jun 2002 19:57:53 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GXI00GAAA4HMT@firewall.wcom.com>; Mon, 10 Jun 2002 19:57:53 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GXI00101A4GU9@dgismtp03.wcomnet.com>; Mon, 10 Jun 2002 19:57:52 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GXI00KYDA4FGI@dgismtp03.wcomnet.com>; Mon, 10 Jun 2002 19:57:52 +0000 (GMT) Date: Mon, 10 Jun 2002 14:57:48 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST In-reply-to: To: "'Cedric Aoun'" , "'Mary Barnes'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001201c210b9$190a6120$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RpazCXJi2ADF+zLJgPY+2w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_RpazCXJi2ADF+zLJgPY+2w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST= Inline comments....to Cedric. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf= Of Cedric Aoun Sent: Monday, June 10, 2002 2:45 AM To: Mary Barnes; 'midcom@ietf.org' Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-= midcom- protocol-eval -00.txt by Monday June 10th, noon CST Hi Mary, General comments: There is an inconsistency with the used compliancy method, Tom and = you have actually already mentioned that.In the comments below I will point = out to the requirements where the SNMP compliancy should be changed. I found "=C6" several times in the text instead of "'" it is perhap= s due to CRLF. Section 1.1.3 SNMP overview section: the Middle Box is a PEP and no= t a PDP. [CM] Agree [CM] Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, t= he identification will be based on matching an IP address and port to a certain SNMP= agent. In case more a Middlebox applying NAT is deployed between a Midcom = agent and the Middlebox being controlled by the Midcom agent then the identif= ication can't be known in advance and therefore can't be provisioned. I think we could find certain network topologies where firewalls ar= e deployed in certain departments and then a NAT + Firewall is deployed at the network interconnection of the enterprise. In this case all protocols not h= aving IDs will fail, including SNMP.IMO the requirement is not met by SNMP. [CM] In network topologies containing departmental firewalls, typic= ally it is not topology hiding (NAT) that is being ebforced by the internal firewall, rather access. Usually this is a concern which is implement= ed for the Internet facing firewall, in addition to the possibility of priva= te addres space that may exist internally. But even if it is, this seems= a bit out of scope, since the internal agents may be provisioned on the mid= dlebox as a form of policy, but more often than not these internal firewalls= will not have access to or through the Internet firewall due to security p= olicy. The method to identify the internal middleboxes is probably moot IM= HO due to any number of security policy decisions by the company that we cou= ld come up with all day long, and is an issue which would affect any MIDCOM p= rotocol decided on today with eqaul complexity whether it is an existing prot= ocol, or a completely homegrown brand new protocol. [CM] Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is coupled with the application host, it can't be on a separate host. I see as a f= ailure to meeting the MIDCOM framework, in which we wanted a complete flexibl= e model where the Midcom agent function could be hosted on any host. This c= omment is probably more on the general applicability of RSIP, but since there= is a note on it in 2.1.3 the comment is applicable on the section as well. [CM] As far as I am concerned this [RSIP] is the same as NAT, WRT s= imiliar issues of imbedded IP, and is one of the issues MIDCOM is trying to r= esolve, since I dont believe that adding another agent to every host is the a= nswer to the problem, merely adds another level of complexity to troublesho= ot on the host. [CM] 2.1.7 Reliability in SNMP is achieved by retransmissions and timers= , this mechanism applies only if the messages have a reply, in case of TRAPs this is= not the case. Therefore IMO this requirement is not met. [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact= that a response is not recieved to acknowledge the trap may be low risk due = to the fact that typically traps do not stop until alarm is mitigated. So it= is reliable unless you cant even communicate over the trap path (such as= a WAN link), in which event all protocols would fail this test. [CM] 2.2.1 Extensibility. I think we should grade differently protocols = that have existing means of extensibility without changing the base protocol messages = by using "objects" as means of extensibility and protocols that achieve extensibility = by adding new messages or parameters in the base protocol to achieve the extensibility. As= such the RSIP protocol requires more work to be extensible and should be graded different= ly. I don't know if it fair to put its compliancy to Partially met or Unmet. [CM] Agree with grading suggestion, more discussion could be done h= ere. Also, see my comment above about RSIP. 2.2.8 Transport of filtering rules SNMP requires a new MIDCOM MIB to meet this requirement, therefore = it is partially compliant as the MIB is not existent [CM] This is already stated in the draft, however extensibility is = not difficult with SNMP nothing new to be done but develop the MIB. Agre= e with partially compliant, with the qualifier that this applies to any and = all protocols under evaluation/development. RSIP currently couples the filter with the action which is address translation or address and port translation. As we are looking at a model where= the filter is decoupled from the action (from a syntax perspective) I think th= at RSIP currently fails to meet the requirement. [CM] I would agree, only due to my opinion of RSIP.... :^) [CM] 2.2.9 Mapped port parity SNMP compliance should be partial as it requires the creation of th= e MIDCOM MIB [CM] In this respect all of them fit partial compliance with this a= s far as relating to the MIDCOM protocol. The point made, IMO, was that it = could be done easily with SNMP as this is part of its inherent nature as a management protocol. 2.2.10 Consecutive range of port numbers SNMP compliance should be partial as it requires the creation of th= e MIDCOM MIB [CM] Ditto 2.2.11 Same as 2.2.10 for the SNMP compliance 3 Conclusion I think that in the SNMP statement the reliability problems should = be discussed as their fix is not included in of the shelf stacks and do not appl= y to TRAP messages. Similarly the statement on the broad deployment of SNMP doesn't inc= lude SNMPv3, this should probably stated as well. [CM] Agree, but it should be noted that SNMPv3 is becoming more pre= valent in newer network implementations. Cedric -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: 07 June 2002 02:58 To: 'midcom@ietf.org' Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Hi all, Just a reminder that comments on the protocol evaluation draft are = due by noon on Monday, June 10th. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval= -00.txt The level of discussion on this draft by members of the WG has been= rather disquieting. The draft is not incredibly long, with the new material= being primarily in the Overview and Conclusion sections. There are a also f= ew areas which definitely need discussion and WG feedback which are indi= cated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and a= t least review those portions. The objective is for the draft to be fairly co= mplete and actually undergoing WGLC by the Yokohama meeting, so comments now= are definitely preferred over during the WG session or after the Yokohama meeting. As a reminder, the remaining schedule for this WG draft is as follo= ws: June 14th Second version of draft available. June 14th-June 21st Mailing list discussion of version 2 of draft. June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available July 26th- Aug (whether another iteration is required for WGLC depe= nds upon the extent of changes, etc.) Aug Draft submitted to IESG Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 --Boundary_(ID_RpazCXJi2ADF+zLJgPY+2w) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon = CST

Inline=20 comments....to Cedric.

-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Cedric = Aoun
Sent:=20 Monday, June 10, 2002 2:45 AM
To: Mary Barnes;=20 'midcom@ietf.org'
Subject: RE: [midcom] Reminder: Comments = due to=20 list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, = noon=20 CST

Hi Mary,
General comments: =
There is an inconsistency with the used = compliancy=20 method, Tom and you have
actually already = mentioned=20 that.In the comments below I will point out to the
requirements where the SNMP compliancy should be = changed.=20
I found "=C6" several times in the text instead of = "'" it is=20 perhaps due to CRLF.

Section 1.1.3 SNMP overview section: the Middle Box = is a PEP=20 and not a PDP.

[CM]=20 Agree [CM]

Section 2.1.2. SNMP doesn't include any Midcom agent = identifiers, the identification
will = be based on=20 matching an IP address and port to a certain SNMP agent. =
In case more a Middlebox applying NAT is deployed between a = Midcom=20 agent and
the Middlebox being controlled by = the Midcom=20 agent then the identification
can't be known = in=20 advance and therefore can't be provisioned.
I think we=20 could find certain network topologies where firewalls are = deployed=20
in certain departments and then a NAT + Firewall is = deployed=20 at the network
interconnection of the = enterprise. In=20 this case all protocols not having IDs
will = fail,=20 including SNMP.IMO the requirement is not met by = SNMP.

[CM]=20 In network topologies containing departmental firewalls, = typically it is=20 not topology hiding (NAT) that is being ebforced by the internal=20 firewall, rather access. Usually this is a concern which is = implemented for=20 the Internet facing firewall, in addition to the possibility of = private addres=20 space that may exist internally. But even if it is, this seems a bit = out of=20 scope, since the internal agents may be provisioned on the middlebox = as a form=20 of policy, but more often than not these internal firewalls will not = have=20 access to or through the Internet firewall due to security = policy.=20

The=20 method to identify the internal middleboxes is probably moot IMHO due = to any=20 number of security policy decisions by the company that we could come = up with=20 all day long, and is an issue which would affect any MIDCOM protocol = decided=20 on today with eqaul complexity whether it is an existing protocol, = or a=20 completely homegrown brand new protocol. [CM]

Section 2.1.2 RSIP=20 compliancy section. In RSIP the Midcom agent is coupled with =
the application host, it can't be on a separate host. I = see as a=20 failure to
meeting the MIDCOM framework, in = which we=20 wanted a complete flexible model
where the = Midcom=20 agent function could be hosted on any host. This comment is =
probably more on the general applicability of RSIP, but since = there is=20 a note
on it in 2.1.3 the comment is = applicable on the=20 section as well.

[CM]=20 As far as I am concerned this [RSIP] is the same as NAT, WRT = similiar=20 issues of imbedded IP, and is one of the issues MIDCOM is trying = to=20 resolve, since I dont believe that adding another agent to every host = is the=20 answer to the problem, merely adds another level of complexity to = troubleshoot=20 on the host. [CM]

2.1.7 Reliability in SNMP is achieved by = retransmissions and=20 timers, this mechanism
applies only if the = messages=20 have a reply, in case of TRAPs this is not the case.
Therefore IMO this requirement is not met.

[CM]=20 in 2.1.7 Middlebox can generate unsolicited messages, the = fact that a=20 response is not recieved to acknowledge the trap may be=20 low risk due to the fact that typically traps do not stop until = alarm is=20 mitigated. So it is reliable unless you cant even communicate over the = trap=20 path (such as a WAN link), in which event all protocols would = fail this=20 test. [CM]

2.2.1 = Extensibility. I=20 think we should grade differently protocols that have existing=20
means of extensibility without changing the base = protocol=20 messages by using "objects"
as means of = extensibility=20 and protocols that achieve extensibility by adding new messages =
or parameters in the base protocol to achieve the=20 extensibility. As such the RSIP protocol
requires more=20 work to be extensible and should be graded differently. I don't = know if=20 it
fair to put its compliancy to Partially = met or=20 Unmet.

[CM]=20 Agree with grading suggestion, more discussion could be done here. = Also,=20 see my comment above about RSIP.

2.2.8 Transport of filtering rules
SNMP requires a new MIDCOM MIB to meet this requirement, = therefore it=20 is partially
compliant as the MIB is not=20 existent

[CM]=20 This is already stated in the draft, however extensibility is not = difficult=20 with SNMP nothing new to be done but develop the = MIB. Agree with partially compliant, = with the=20 qualifier that this applies to any and all protocols under=20 evaluation/development.

RSIP currently couples the filter with the action = which is=20 address translation
or address and port = translation.=20 As we are looking at a model where the filter
is=20 decoupled from the action (from a syntax perspective) I think that = RSIP=20
currently fails to meet the = requirement.

[CM] I would agree, only due to my opinion of = RSIP....  =20 :^) [CM]

2.2.9 Mapped port parity
SNMP=20 compliance should be partial as it requires the creation of the MIDCOM = MIB

[CM]=20 In this respect all of them fit partial compliance with this as far=20 as relating to the MIDCOM protocol. The point made, IMO, was that it could be = done easily=20 with SNMP as this is part of its inherent nature as a management=20 protocol.

2.2.10 Consecutive range of port numbers =
SNMP compliance should be partial as it requires the creation = of the=20 MIDCOM MIB

[CM]=20 Ditto

2.2.11 Same as 2.2.10 for the SNMP compliance =

3 Conclusion
I think that = in the SNMP=20 statement the reliability problems should be discussed =
as their fix is not included in of the shelf stacks and do = not apply to=20 TRAP messages.
Similarly the statement on = the broad=20 deployment of SNMP doesn't include SNMPv3,
this should=20 probably stated as well.

[CM] Agree, but it should be noted that SNMPv3 is = becoming more=20 prevalent in newer=20 network implementations.

Cedric=20

-----Original Message-----
From:=20 Barnes, Mary [NGC:B602:EXCH]
Sent: 07 June = 2002=20 02:58
To: 'midcom@ietf.org'
Subject: [midcom] Reminder: Comments due to list on=20 draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon=20 CST

Hi all,
Just a reminder = that comments=20 on the protocol evaluation draft are due by noon on Monday, June = 10th. =20 It's available at:

http://www.ietf.org/internet-drafts/draft-ietf-midcom-pro= tocol-eval-00.txt=20
The level of discussion on this draft by = members of=20 the WG has been rather disquieting. The draft is not incredibly = long,=20 with the new material being primarily in the Overview and Conclusion = sections.=20 There are a also few areas which definitely need discussion and WG = feedback=20 which are indicated by [Contributor's note: blah...blah...blah] and = [Editor's=20 note: yadda...yadda...yadda]. So, please try to set aside 30 = minutes and=20 at least review those portions. The objective is for the draft to be = fairly=20 complete and actually undergoing WGLC by the Yokohama meeting, so = comments now=20 are definitely preferred over during the WG session or after the = Yokohama=20 meeting.

As a reminder, the remaining schedule for this WG = draft is as=20 follows:
June = 14th      =20 Second version of draft available.
June = 14th-June=20 21st Mailing list discussion of version 2 of draft. =
June 28th       Draft ready for = WGLC=20
July = 19th       WGLC=20 ends
July = 26th      =20 Updated draft based upon WGLC comments available
July=20 26th- Aug (whether another iteration is required for WGLC depends upon =
          &nbs= p;    =20 the extent of changes, etc.)
Aug     Draft submitted to IESG =
Regards,
Mary H. Barnes =
mbarnes@nortelnetworks.com
972-684-5432=20
Wireless 817-703-4806
=20

--Boundary_(ID_RpazCXJi2ADF+zLJgPY+2w)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 16:07:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23001 for ; Mon, 10 Jun 2002 16:07:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27034 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 16:08:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26814; Mon, 10 Jun 2002 16:03:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26729 for ; Mon, 10 Jun 2002 16:03:35 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22728 for ; Mon, 10 Jun 2002 16:02:59 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AK2sHs021633; Mon, 10 Jun 2002 13:02:54 -0700 (PDT) Received: from SBRIM-W2K.cisco.com (sjc-vpn3-103.cisco.com [10.21.64.103]) by airborne.cisco.com (Mirapoint) with ESMTP id ABG12982; Mon, 10 Jun 2002 13:02:38 -0700 (PDT) X-Mailer: emacs 21.1.1 (via feedmail 11-beta-1 I); VM 7.01 under Emacs 21.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15621.1510.767000.286218@gargle.gargle.HOWL> Date: Mon, 10 Jun 2002 16:02:46 -0400 From: Scott Brim To: "Bob Penfield" Cc: "Juergen Quittek" , "Cedric Aoun" , "Mary Barnes" , Subject: Re: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST In-Reply-To: <00f701c210b7$35d97ae0$2300000a@acmepacket.com> References: <31255372.1023728898@[192.168.102.164]> <00f701c210b7$35d97ae0$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit On 10 Jun 2002 at 15:44 -0400, Bob Penfield allegedly wrote: > BTW, we did actually have an explicit requirement for reliability at one > point. I think it was deleted because people felt it was covered by the > other requirements. iirc we couldn't agree on how, and to what degree, that reliability would be achieved. I think it got folded into Christian's wording, that the state of the middlebox must be deterministic. ...Scott _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 16:15:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23248 for ; Mon, 10 Jun 2002 16:15:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27275 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 16:16:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27168; Mon, 10 Jun 2002 16:11:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27138 for ; Mon, 10 Jun 2002 16:11:32 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23095 for ; Mon, 10 Jun 2002 16:10:58 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AKA9D14988; Mon, 10 Jun 2002 16:10:10 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Jun 2002 16:10:09 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5B5@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'christopher.a.martin@wcom.com'" , "Cedric Aoun" , "Mary Barnes" , midcom@ietf.org Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Mon, 10 Jun 2002 16:09:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org One point caught my eye, about alarms. See below. -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Monday, June 10, 2002 3:58 PM [... snip]] 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this mechanism applies only if the messages have a reply, in case of TRAPs this is not the case. Therefore IMO this requirement is not met. [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact that a response is not recieved to acknowledge the trap may be low risk due to the fact that typically traps do not stop until alarm is mitigated. So it is reliable unless you cant even communicate over the trap path (such as a WAN link), in which event all protocols would fail this test. [CM] [PTT] Middlebox notifications won't necessarily have the flavour of alarms. I would hate to find that someone has to clear an alarm every time such a notification occurs. [snip] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 16:21:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23483 for ; Mon, 10 Jun 2002 16:21:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27519 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 16:22:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27375; Mon, 10 Jun 2002 16:17:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27337 for ; Mon, 10 Jun 2002 16:17:45 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23305 for ; Mon, 10 Jun 2002 16:17:11 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GXI00E01B0MZG@firewall.wcom.com> for midcom@ietf.org; Mon, 10 Jun 2002 20:17:10 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GXI00DIDB0LI9@firewall.wcom.com>; Mon, 10 Jun 2002 20:17:09 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GXI00101B09PZ@dgismtp02.wcomnet.com>; Mon, 10 Jun 2002 20:17:09 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GXI00080B04D9@dgismtp02.wcomnet.com>; Mon, 10 Jun 2002 20:16:52 +0000 (GMT) Date: Mon, 10 Jun 2002 15:16:49 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST In-reply-to: <4D79C746863DD51197690002A52CDA0001E8A5B5@zcard0kc.ca.nortel.com> To: "'Tom-PT Taylor'" , "'Cedric Aoun'" , "'Mary Barnes'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001a01c210bb$c15fb940$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Agree....it is usually due to an event that a trap is sent out ... alarm may have been a poor choice of word. Can you tell I used to fight lots o fires.... :^) What types of traps do we think may be used by a middlebox? -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Monday, June 10, 2002 3:10 PM To: 'christopher.a.martin@wcom.com'; Cedric Aoun; Mary Barnes; midcom@ietf.org Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST One point caught my eye, about alarms. See below. -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Monday, June 10, 2002 3:58 PM [... snip]] 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this mechanism applies only if the messages have a reply, in case of TRAPs this is not the case. Therefore IMO this requirement is not met. [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact that a response is not recieved to acknowledge the trap may be low risk due to the fact that typically traps do not stop until alarm is mitigated. So it is reliable unless you cant even communicate over the trap path (such as a WAN link), in which event all protocols would fail this test. [CM] [PTT] Middlebox notifications won't necessarily have the flavour of alarms. I would hate to find that someone has to clear an alarm every time such a notification occurs. [snip] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 16:26:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23663 for ; Mon, 10 Jun 2002 16:26:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27709 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 16:27:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27579; Mon, 10 Jun 2002 16:23:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27548 for ; Mon, 10 Jun 2002 16:23:08 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23519 for ; Mon, 10 Jun 2002 16:22:34 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AA6AFA36014C; Mon, 10 Jun 2002 16:22:02 -0400 Message-ID: <00fd01c210bc$7aec5580$2300000a@acmepacket.com> From: "Bob Penfield" To: "Juergen Quittek" , "Mary Barnes" , "Tom-PT Taylor" , References: <1B54FA3A2709D51195C800508BF9386A03DE3B9B@zrc2c000.us.nortel.com> <25600781.1023723243@[192.168.102.164]> Subject: Re: [midcom] SNMP In The Evaluation Date: Mon, 10 Jun 2002 16:22:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit To be fair, the other protocols require extensions in order to comply to some of the requirements. For example, MEGACO requires the definition of a new Package to support MIDCOM. Do we need another category besides Total, Partial, and Failed compliance for those requirements that are easily covered by the extensibility already built into the protocol? (e.g a new Package for MEGACO, or a new MIB for SNMP). cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Juergen Quittek" To: "Mary Barnes" ; "Tom-PT Taylor" ; Sent: Monday, June 10, 2002 9:34 AM Subject: RE: [midcom] SNMP In The Evaluation > Mary, > > --On 03 June 2002 13:21 -0500 Mary Barnes wrote: > > > > > Hi all, > > > > I haven't seen any further discussion on this one, but as Editor, I think I have to agree with Tom. Clearly, there exists an inconsistency in the evaluations as far as the Total Compliance versus Partial Compliance. There had been a brief email thread > > on the difference in classifying between these two and the conclusion had been that if extensions are required then the protocol is partially compliant: > > > > http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02083.htm l > > Thus, I'm going to propose the change to the SNMP evaluation as Tom has suggested unless there is strong opinions suggesting otherwise. > > > > I don't believe this changes the author's overall conclusion that SNMP meets the requirements as the MIDCOM protocol with the design of a MIDCOM MIB module. However, it would require changing some of the statements in section 3. > > > > I would propose the following: > > Changing > > "The SNMP management framework as evaluated matches all specified Midcom requirements". > > to say something like: > > "The SNMP management framework meets all the specified Midcom protocol requirements with the design of a MIDCOM MIB module". > > I fully agree. > > Maybe we can even improve phrasing by writing "appropriate design" > instead of just "design". > > Juergen > > > > > and then removing the last sentence from that paragraph. > > > > Regards, > > Mary H. Barnes > > mbarnes@nortelnetworks.com > > 972-684-5432 > > Wireless 817-703-4806 > > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B602:EXCH] > > Sent: Thursday, May 30, 2002 8:55 AM > > To: 'Juergen Quittek'; 'midcom@ietf.org' > > Subject: RE: [midcom] SNMP In The Evaluation > > > > This is a matter of consistent treatment of the protocols in the evaluation. > > For DIAMETER, for instance, the necessary data types have probably all been > > defined in Base, but it will be necessary to define the messages containing > > them. I think you are saying that in the SNMP case you can point to > > specific object types you can import but it will be necessary to define a > > new module to provide a context for them. These may not be at the same > > level of activity, but I think they are sufficiently analogous that both > > protocols should be classified in the same way. > > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > Sent: Thursday, May 30, 2002 8:51 AM > > To: Taylor, Tom-PT [CAR:B602:EXCH]; 'midcom@ietf.org' > > Subject: Re: [midcom] SNMP In The Evaluation > > > > Tom, > > > > --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: > >> > >> SNMP fit to requirements is overstated relative to the other > >> protocols. For consistency, every requirement which refers to > >> "an appropriate definition of a Midcom MIB module" should be > >> rated as "partially met". > > > > I agree, that the statements are to general. Would you be fine > > if I provide more concrete arguments, why these requirements > > are clearly met. This is much more appropriate than moving to > > partially met. > > > > Take for example "2.2.2 Support of multiple Middlebox types". > > SNMP has several means to do so, starting from the standard > > sysObjectID indicating the 'kind of box' to managed objects > > defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, > > packet filter, ... > > Also box type specific support by specific managed objects > > is something which SNMP/SMI was built for. It definitely > > meets these requirement fully, not partially. > > > > Juergen > > -- > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> > >> Tom Taylor > >> taylor@nortelnetworks.com > >> Ph. +1 613 736 0961 (ESN 396 1490) > >> > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 17:06:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25470 for ; Mon, 10 Jun 2002 17:06:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00549 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 17:05:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00126; Mon, 10 Jun 2002 17:00:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00089 for ; Mon, 10 Jun 2002 17:00:42 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25303 for ; Mon, 10 Jun 2002 17:00:07 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A373318C014E; Mon, 10 Jun 2002 17:00:35 -0400 Message-ID: <013301c210c1$db11bae0$2300000a@acmepacket.com> From: "Bob Penfield" To: , "'Tom-PT Taylor'" , "'Cedric Aoun'" , "'Mary Barnes'" , References: <001a01c210bb$c15fb940$20e123a6@mcit.com> Subject: Re: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Mon, 10 Jun 2002 17:00:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christopher A. Martin" > Agree....it is usually due to an event that a trap is sent out ... alarm may > have been a poor choice of word. > > Can you tell I used to fight lots o fires.... :^) > > What types of traps do we think may be used by a middlebox? > I think asyncronous notifications will include things that affect state in the midcom agent (e.g. the middlebox just removed a ruleset that expired) and are things that the application will need to take action on (e.g. sending BYE for SIP sessions). > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, June 10, 2002 3:10 PM > To: 'christopher.a.martin@wcom.com'; Cedric Aoun; Mary Barnes; > midcom@ietf.org > Subject: RE: [midcom] Reminder: Comments due to list on > draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST > > > > One point caught my eye, about alarms. See below. > > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Monday, June 10, 2002 3:58 PM > > [... snip]] > > 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this > mechanism > applies only if the messages have a reply, in case of TRAPs this is not the > case. > Therefore IMO this requirement is not met. > > [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact that a > response is not recieved to acknowledge the trap may be low risk due to the > fact that typically traps do not stop until alarm is mitigated. So it is > reliable unless you cant even communicate over the trap path (such as a WAN > link), in which event all protocols would fail this test. [CM] > > [PTT] Middlebox notifications won't necessarily have the flavour of alarms. > I would hate to find that someone has to clear an alarm every time such a > notification occurs. > > [snip] > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 17:14:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25921 for ; Mon, 10 Jun 2002 17:14:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA01010 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 17:15:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00875; Mon, 10 Jun 2002 17:10:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00847 for ; Mon, 10 Jun 2002 17:10:44 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25798 for ; Mon, 10 Jun 2002 17:10:09 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GXI00D01DDV78@firewall.wcom.com> for midcom@ietf.org; Mon, 10 Jun 2002 21:08:19 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GXI00C9GDDU8X@firewall.wcom.com>; Mon, 10 Jun 2002 21:08:18 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0GXI00B01DDQIA@dgismtp04.wcomnet.com>; Mon, 10 Jun 2002 21:08:18 +0000 (GMT) Received: from rccc6131 ([166.35.225.32]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0GXI009CLDDSK8@dgismtp04.wcomnet.com>; Mon, 10 Jun 2002 21:08:16 +0000 (GMT) Date: Mon, 10 Jun 2002 16:08:12 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST In-reply-to: <013301c210c1$db11bae0$2300000a@acmepacket.com> To: "'Bob Penfield'" , "'Tom-PT Taylor'" , "'Cedric Aoun'" , "'Mary Barnes'" , midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <001f01c210c2$ef3939c0$20e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Good point, I would like to see us develop more of these examples as part of this exercise since this will be required for any protocol selected. Anyone agree|disagree? -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Monday, June 10, 2002 4:01 PM To: christopher.a.martin@wcom.com; 'Tom-PT Taylor'; 'Cedric Aoun'; 'Mary Barnes'; midcom@ietf.org Subject: Re: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST ----- Original Message ----- From: "Christopher A. Martin" > Agree....it is usually due to an event that a trap is sent out ... alarm may > have been a poor choice of word. > > Can you tell I used to fight lots o fires.... :^) > > What types of traps do we think may be used by a middlebox? > I think asyncronous notifications will include things that affect state in the midcom agent (e.g. the middlebox just removed a ruleset that expired) and are things that the application will need to take action on (e.g. sending BYE for SIP sessions). > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, June 10, 2002 3:10 PM > To: 'christopher.a.martin@wcom.com'; Cedric Aoun; Mary Barnes; > midcom@ietf.org > Subject: RE: [midcom] Reminder: Comments due to list on > draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST > > > > One point caught my eye, about alarms. See below. > > -----Original Message----- > From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] > Sent: Monday, June 10, 2002 3:58 PM > > [... snip]] > > 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this > mechanism > applies only if the messages have a reply, in case of TRAPs this is not the > case. > Therefore IMO this requirement is not met. > > [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact that a > response is not recieved to acknowledge the trap may be low risk due to the > fact that typically traps do not stop until alarm is mitigated. So it is > reliable unless you cant even communicate over the trap path (such as a WAN > link), in which event all protocols would fail this test. [CM] > > [PTT] Middlebox notifications won't necessarily have the flavour of alarms. > I would hate to find that someone has to clear an alarm every time such a > notification occurs. > > [snip] > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Mon Jun 10 17:58:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27369 for ; Mon, 10 Jun 2002 17:58:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02912 for midcom-archive@odin.ietf.org; Mon, 10 Jun 2002 17:58:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02773; Mon, 10 Jun 2002 17:54:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02742 for ; Mon, 10 Jun 2002 17:54:00 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27215 for ; Mon, 10 Jun 2002 17:53:25 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AFF63266012A; Mon, 10 Jun 2002 17:53:58 -0400 Message-ID: <001501c210c9$4d8aad00$2300000a@acmepacket.com> From: "Bob Penfield" To: References: <1B54FA3A2709D51195C800508BF9386A03DE3B9B@zrc2c000.us.nortel.com> <25600781.1023723243@[192.168.102.164]> <00fd01c210bc$7aec5580$2300000a@acmepacket.com> Date: Mon, 10 Jun 2002 17:53:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [midcom] Megaco In The Evaluation Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit The evaluation of Megaco mentions Contexts (which can be used to group related Terminations) in the intro, but they are not mentioned anywhere else in the document. I think Contexts go a long way toward satisfying requirements 2.2.2 (multiple middlebox action types) and 2.2.3 (Ruleset groups). In particular, section 2.2.3 mentions the policy model described in Appendix C as the answer for the requirement, but claims Total compliance. The use of Contexts for grouping would be totally compliant. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jun 11 05:47:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16866 for ; Tue, 11 Jun 2002 05:47:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12190 for midcom-archive@odin.ietf.org; Tue, 11 Jun 2002 05:47:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12077; Tue, 11 Jun 2002 05:42:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11986 for ; Tue, 11 Jun 2002 05:42:11 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16800 for ; Tue, 11 Jun 2002 05:41:11 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5B9euG06123; Tue, 11 Jun 2002 11:40:56 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 11:40:49 +0200 Message-ID: From: "Cedric Aoun" To: "'Juergen Quittek'" , "Mary Barnes" , "'midcom@ietf.org'" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Tue, 11 Jun 2002 11:40:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2112C.1691C8A2" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2112C.1691C8A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen, Please see my comments below. Thanks. Cedric -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: 10 June 2002 17:08 To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary [NGC:B602:EXCH]; 'midcom@ietf.org' Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Cedric, --On 10 June 2002 09:45 +0200 Cedric Aoun = wrote: > > Hi Mary, > General comments: > There is an inconsistency with the used compliancy method, Tom and = you have > actually already mentioned that.In the comments below I will point = out to the > requirements where the SNMP compliancy should be changed. > I found "=C6" several times in the text instead of "'" it is perhaps = due to CRLF. > > Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not = a PDP. > > Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification > will be based on matching an IP address and port to a certain SNMP = agent. > In case more a Middlebox applying NAT is deployed between a Midcom = agent and > the Middlebox being controlled by the Midcom agent then the = identification > can't be known in advance and therefore can't be provisioned. > I think we could find certain network topologies where firewalls are deployed > in certain departments and then a NAT + Firewall is deployed at the network > interconnection of the enterprise. In this case all protocols not = having IDs > will fail, including SNMP.IMO the requirement is not met by SNMP. Did I get you right?: You think you can find some network cofiguration = where SNMP cannot support multiple Midcom agents communicating with more than = one middlebox simulataneously. But you cannot explain them here and = therefore the requirement is not met by SNMP??? SNMP agents uses a particular port number to receive messages forgot if = it was 161 or 162. In case we have a topology with FW - NAT FW/=09 How can the SNMP manager control the FW Middleboxes? If it can't rely = to the same port the SNMP messages are sent from?THe problem I'm talking about is MICOM NAT traversal problems. In addition if we don't have the assymetric port usage, we have the identification problem that could=20 be solved with static bind but this is pretty ugly. The ID problem is that since we don't discover Middlebox (in the = current architecture), the Midcom agent is supposed to know them how will you identify them = without using IP address + port (since there is no ID in the SNMP messages), this implicitly requires to use static binds = in the network scenario shown above. SNMP has several features only built in to explicitly support multiple Midcom agents (SNMP managers) within a single stack. Not even multiple instances of the PEP are required, as it is for COPS. > Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is = coupled with > the application host, it can't be on a separate host. I see as a = failure to > meeting the MIDCOM framework, in which we wanted a complete flexible = model > where the Midcom agent function could be hosted on any host. This = comment is > probably more on the general applicability of RSIP, but since there = is a note > on it in 2.1.3 the comment is applicable on the section as well. > > 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, = this mechanism > applies only if the messages have a reply, in case of TRAPs this is = not the case. > Therefore IMO this requirement is not met. Requirement 2.1.7 says: "The protocol must support unsolicited messages = from middlebox to agent ...". How can you say this is not exactly what SNMP notifications are available for? If you require reliability in addition, I suggest the following = procedure: 1. add reliability to the requirements 2. state that reliability is not met by SNMP notifications. Please tell me, if I missed a reliability statement. Then we can = discuss replacing replace SNMP notifications by reliable SNMP inform messages. I did not mention them yet, because they are not available in SNMPv1, but they are in v2 and v3. In any case SNMP meets the requirement. The reliability requirements are hidden behind the deterministic = behavior requirement. We had initially a bunch of mother hood and applepie requirements that included explicitly reliability, but were taken out. Perhaps we need to add them again in the requirements. > 2.2.1 Extensibility. I think we should grade differently protocols = that have existing > means of extensibility without changing the base protocol messages by using "objects" > as means of extensibility and protocols that achieve extensibility by adding new messages > or parameters in the base protocol to achieve the extensibility. As = such the RSIP protocol > requires more work to be extensible and should be graded = differently. I don't know if it > fair to put its compliancy to Partially met or Unmet. > > 2.2.8 Transport of filtering rules > SNMP requires a new MIDCOM MIB to meet this requirement, therefore it = is partially > compliant as the MIB is not existent > > RSIP currently couples the filter with the action which is address translation > or address and port translation. As we are looking at a model where = the filter > is decoupled from the action (from a syntax perspective) I think that = RSIP > currently fails to meet the requirement. > > 2.2.9 Mapped port parity > SNMP compliance should be partial as it requires the creation of the MIDCOM MIB > > 2.2.10 Consecutive range of port numbers > SNMP compliance should be partial as it requires the creation of the MIDCOM MIB > > 2.2.11 Same as 2.2.10 for the SNMP compliance > > 3 Conclusion > I think that in the SNMP statement the reliability problems should be discussed > as their fix is not included in of the shelf stacks and do not apply = to TRAP messages. It is available in commercial off-the-shelf implementations as well as = in even very simple public domain implementations. > Similarly the statement on the broad deployment of SNMP doesn't = include SNMPv3, > this should probably stated as well. Yes, that's right. However, we still should compare SNMPv3 deployment and maturity to COPS, Diameter, Megaco, RSIP deployment. The SNMPv3 RFCs have already achieved draft standard status. Agreed > Cedric > > > -----Original Message----- > From: Barnes, Mary [NGC:B602:EXCH] > Sent: 07 June 2002 02:58 > To: 'midcom@ietf.org' > Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST > > Hi all, > Just a reminder that comments on the protocol evaluation draft are = due by noon on Monday, June 10th. It's available at: > > = http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.t= xt > The level of discussion on this draft by members of the WG has been = rather disquieting. The draft is not incredibly long, with the new material = being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need > discussion and WG feedback which are indicated by [Contributor's = note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, = please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be > fairly complete and actually undergoing WGLC by the Yokohama meeting, = so comments now are definitely preferred over during the WG session or = after the Yokohama meeting. > > As a reminder, the remaining schedule for this WG draft is as = follows: > June 14th Second version of draft available. > June 14th-June 21st Mailing list discussion of version 2 of draft. > June 28th Draft ready for WGLC > July 19th WGLC ends > July 26th Updated draft based upon WGLC comments available > July 26th- Aug (whether another iteration is required for WGLC = depends upon > the extent of changes, etc.) > Aug Draft submitted to IESG > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 > ------_=_NextPart_001_01C2112C.1691C8A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon = CST

Juergen,
Please see my comments below.
Thanks.
Cedric
-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: 10 June 2002 17:08
To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary = [NGC:B602:EXCH];
'midcom@ietf.org'
Subject: RE: [midcom] Reminder: Comments due to list = on
draft-ietf-midcom- protocol-eval -00.txt by Monday = June 10th, noon CST

Cedric,

--On 10 June 2002 09:45 +0200 Cedric Aoun = <cedric.aoun@nortelnetworks.com> wrote:

>
> Hi Mary,
> General comments:
> There is an inconsistency with the used = compliancy method, Tom and you have
> actually already mentioned that.In the comments = below I will point out to the
> requirements where the SNMP compliancy should = be changed.
> I found "=C6" several times in the = text instead of "'" it is perhaps due to CRLF.
>
> Section 1.1.3 SNMP overview section: the Middle = Box is a PEP and not a PDP.
>
> Section 2.1.2. SNMP doesn't include any Midcom = agent identifiers, the identification
> will be based on matching an IP address = and port to a certain SNMP agent.
> In case more a Middlebox applying NAT is = deployed between a Midcom agent and
> the Middlebox being controlled by the Midcom = agent then the identification
> can't be known in advance and therefore can't = be provisioned.
> I think we could find certain network = topologies where firewalls are deployed
> in certain departments and then a NAT + = Firewall is deployed at the network
> interconnection of the enterprise. In this case = all protocols not having IDs
> will fail, including SNMP.IMO the requirement = is not met by SNMP.

Did I get you right?: You think you can find some = network cofiguration where
SNMP cannot support multiple Midcom agents = communicating with more than one
middlebox simulataneously. But you cannot explain = them here and therefore
the requirement is not met by SNMP???

<CA>
SNMP agents uses a particular port number to receive = messages forgot if it was 161 or 162.
In case we have a topology with FW - NAT
= = = = = FW/
How can the SNMP manager control the FW Middleboxes? = If it can't rely to the same port
the SNMP messages are sent from?THe problem I'm = talking about is
MICOM NAT traversal problems.
In addition if we don't have the assymetric port = usage, we have the identification problem that could
be solved with static bind but this is pretty = ugly.
The ID problem is that since we don't discover = Middlebox (in the current architecture),
the Midcom agent is supposed to know them how will = you identify them without using IP address + port (since there is = no
ID in the SNMP messages), this implicitly requires = to use static binds in the network scenario shown above.

</CA>

SNMP has several features only built in to explicitly = support multiple
Midcom agents (SNMP managers) within a single stack. = Not even multiple
instances of the PEP are required, as it is for = COPS.

> Section 2.1.2 RSIP compliancy section. In RSIP = the Midcom agent is coupled with
> the application host, it can't be on a = separate host. I see as a failure to
> meeting the MIDCOM framework, in which we = wanted a complete flexible model
> where the Midcom agent function could be hosted = on any host. This comment is
> probably more on the general applicability of = RSIP, but since there is a note
> on it in 2.1.3 the comment is applicable on the = section as well.
>
> 2.1.7 Reliability in SNMP is achieved by = retransmissions and timers, this mechanism
> applies only if the messages have a reply, in = case of TRAPs this is not the case.
> Therefore IMO this requirement is not = met.

Requirement 2.1.7 says: "The protocol must = support unsolicited messages from
middlebox to agent ...". How can you say this = is not exactly what SNMP
notifications are available for?

If you require reliability in addition, I suggest the = following procedure:
1. add reliability to the requirements
2. state that reliability is not met by SNMP = notifications.

Please tell me, if I missed a reliability statement. = Then we can discuss
replacing replace SNMP notifications by reliable = SNMP inform messages.
I did not mention them yet, because they are not = available in SNMPv1,
but they are in v2 and v3.

In any case SNMP meets the requirement.

<CA>
The reliability requirements are hidden behind the = deterministic behavior requirement.
We had initially a bunch of mother hood and applepie = requirements that included explicitly reliability,
but were taken out.
Perhaps we need to add them again in the = requirements.
</CA>

> 2.2.1 Extensibility. I think we should grade = differently protocols that have existing
> means of extensibility without changing the = base protocol messages by using "objects"
> as means of extensibility and protocols that = achieve extensibility by adding new messages
> or parameters in the base protocol to achieve = the extensibility. As such the RSIP protocol
> requires more work to be extensible and = should be graded differently. I don't know if it
> fair to put its compliancy to Partially met or = Unmet.
>
> 2.2.8 Transport of filtering rules
> SNMP requires a new MIDCOM MIB to meet this = requirement, therefore it is partially
> compliant as the MIB is not existent
>
> RSIP currently couples the filter with the = action which is address translation
> or address and port translation. As we are = looking at a model where the filter
> is decoupled from the action (from a syntax = perspective) I think that RSIP
> currently fails to meet the requirement.
>
> 2.2.9 Mapped port parity
> SNMP compliance should be partial as it = requires the creation of the MIDCOM MIB
>
> 2.2.10 Consecutive range of port numbers
> SNMP compliance should be partial as it = requires the creation of the MIDCOM MIB
>
> 2.2.11 Same as 2.2.10 for the SNMP = compliance
>
> 3 Conclusion
> I think that in the SNMP statement the = reliability problems should be discussed
> as their fix is not included in of the shelf = stacks and do not apply to TRAP messages.

It is available in commercial off-the-shelf = implementations as well as in
even very simple public domain = implementations.

> Similarly the statement on the broad deployment = of SNMP doesn't include SNMPv3,
> this should probably stated as well.

Yes, that's right. However, we still should compare = SNMPv3
deployment and maturity to COPS, Diameter, Megaco, = RSIP deployment.
The SNMPv3 RFCs have already achieved draft standard = status.

<CA>
Agreed
</CA>

> Cedric
>
>
> -----Original Message-----
> From: Barnes, Mary [NGC:B602:EXCH]
> Sent: 07 June 2002 02:58
> To: 'midcom@ietf.org'
> Subject: [midcom] Reminder: Comments due to = list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, = noon CST

>
> Hi all,
> Just a reminder that comments on the protocol = evaluation draft are due by noon on Monday, June 10th. It's = available at:

>
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-= protocol-eval-00.txt
> The level of discussion on this draft by = members of the WG has been rather disquieting. The draft is not = incredibly long, with the new material being primarily in the Overview = and Conclusion sections. There are a also few areas which definitely = need

> discussion and WG feedback which are indicated = by [Contributor's note: blah...blah...blah] and [Editor's note: = yadda...yadda...yadda]. So, please try to set aside 30 minutes = and at least review those portions. The objective is for the draft to = be

> fairly complete and actually undergoing WGLC by = the Yokohama meeting, so comments now are definitely preferred over = during the WG session or after the Yokohama meeting.

>
> As a reminder, the remaining schedule for this = WG draft is as follows:
> June 14th       = Second version of draft available.
> June 14th-June 21st Mailing list = discussion of version 2 of draft.
> June 28th       = Draft ready for WGLC
> July 19th       = WGLC ends
> July 26th       = Updated draft based upon WGLC comments available
> July 26th- Aug (whether another iteration is = required for WGLC depends upon
>          = ;       the extent of changes, = etc.)
> Aug     Draft submitted to = IESG
> Regards,
> Mary H. Barnes
> mbarnes@nortelnetworks.com
> 972-684-5432
> Wireless 817-703-4806
>

------_=_NextPart_001_01C2112C.1691C8A2-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jun 11 06:11:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17179 for ; Tue, 11 Jun 2002 06:11:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13392 for midcom-archive@odin.ietf.org; Tue, 11 Jun 2002 06:11:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13210; Tue, 11 Jun 2002 06:06:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13181 for ; Tue, 11 Jun 2002 06:06:24 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17121 for ; Tue, 11 Jun 2002 06:05:38 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BA5eg27729 for ; Tue, 11 Jun 2002 12:05:40 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 12:05:33 +0200 Message-ID: From: "Cedric Aoun" To: "'christopher.a.martin@wcom.com'" , "Mary Barnes" , midcom@ietf.org Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Tue, 11 Jun 2002 12:05:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2112F.8BB791D6" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2112F.8BB791D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin, [CM] In network topologies containing departmental firewalls, typically = it is not topology hiding (NAT) that is being enforced by the internal firewall, rather access. Usually this is a concern which is implemented = for the Internet facing firewall, in addition to the possibility of private address space that may exist internally. But even if it is, this seems = a bit out of scope, since the internal agents may be provisioned on the = middlebox as a form of policy, but more often than not these internal firewalls = will not have access to or through the Internet firewall due to security = policy.=20 I was discussing usage of packet filtering in Firewalls in the = discussed network topology. As the SNMP agent receive messages on a different = port than the one used to send messages, we have serious problem when the = SNMP agent is behind a NAT. In case the Midcom agent is within the enterprise then this issue is no longer relevant. Cedric -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: 10 June 2002 21:58 To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary [NGC:B602:EXCH]; midcom@ietf.org Subject: RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Inline comments....to Cedric. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Cedric Aoun Sent: Monday, June 10, 2002 2:45 AM To: Mary Barnes; 'midcom@ietf.org' Subject: RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Hi Mary,=20 General comments:=20 There is an inconsistency with the used compliancy method, Tom and you = have=20 actually already mentioned that.In the comments below I will point out = to the=20 requirements where the SNMP compliancy should be changed.=20 I found "=C6" several times in the text instead of "'" it is perhaps = due to CRLF.=20 Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a = PDP. [CM] Agree [CM] Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification=20 will be based on matching an IP address and port to a certain SNMP = agent.=20 In case more a Middlebox applying NAT is deployed between a Midcom = agent and the Middlebox being controlled by the Midcom agent then the = identification=20 can't be known in advance and therefore can't be provisioned.=20 I think we could find certain network topologies where firewalls are deployed=20 in certain departments and then a NAT + Firewall is deployed at the = network=20 interconnection of the enterprise. In this case all protocols not = having IDs will fail, including SNMP.IMO the requirement is not met by SNMP. =20 [CM] In network topologies containing departmental firewalls, typically = it is not topology hiding (NAT) that is being ebforced by the internal firewall, rather access. Usually this is a concern which is implemented = for the Internet facing firewall, in addition to the possibility of private addres space that may exist internally. But even if it is, this seems a = bit out of scope, since the internal agents may be provisioned on the = middlebox as a form of policy, but more often than not these internal firewalls = will not have access to or through the Internet firewall due to security = policy.=20 The method to identify the internal middleboxes is probably moot IMHO = due to any number of security policy decisions by the company that we could = come up with all day long, and is an issue which would affect any MIDCOM = protocol decided on today with eqaul complexity whether it is an existing = protocol, or a completely homegrown brand new protocol. [CM] Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is = coupled with=20 the application host, it can't be on a separate host. I see as a = failure to meeting the MIDCOM framework, in which we wanted a complete flexible = model=20 where the Midcom agent function could be hosted on any host. This = comment is probably more on the general applicability of RSIP, but since there is = a note=20 on it in 2.1.3 the comment is applicable on the section as well. =20 [CM] As far as I am concerned this [RSIP] is the same as NAT, WRT = similiar issues of imbedded IP, and is one of the issues MIDCOM is trying to = resolve, since I dont believe that adding another agent to every host is the = answer to the problem, merely adds another level of complexity to troubleshoot = on the host. [CM] 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, = this mechanism=20 applies only if the messages have a reply, in case of TRAPs this is not = the case.=20 Therefore IMO this requirement is not met. =20 [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact = that a response is not recieved to acknowledge the trap may be low risk due to = the fact that typically traps do not stop until alarm is mitigated. So it = is reliable unless you cant even communicate over the trap path (such as a = WAN link), in which event all protocols would fail this test. [CM] 2.2.1 Extensibility. I think we should grade differently protocols that = have existing=20 means of extensibility without changing the base protocol messages by = using "objects"=20 as means of extensibility and protocols that achieve extensibility by = adding new messages=20 or parameters in the base protocol to achieve the extensibility. As = such the RSIP protocol=20 requires more work to be extensible and should be graded differently. = I don't know if it=20 fair to put its compliancy to Partially met or Unmet. =20 [CM] Agree with grading suggestion, more discussion could be done here. Also, see my comment above about RSIP.=20 2.2.8 Transport of filtering rules=20 SNMP requires a new MIDCOM MIB to meet this requirement, therefore it = is partially=20 compliant as the MIB is not existent =20 [CM] This is already stated in the draft, however extensibility is not difficult with SNMP nothing new to be done but develop the MIB. Agree = with partially compliant, with the qualifier that this applies to any and = all protocols under evaluation/development. RSIP currently couples the filter with the action which is address translation=20 or address and port translation. As we are looking at a model where the filter=20 is decoupled from the action (from a syntax perspective) I think that = RSIP=20 currently fails to meet the requirement. =20 [CM] I would agree, only due to my opinion of RSIP.... :^) [CM]=20 2.2.9 Mapped port parity=20 SNMP compliance should be partial as it requires the creation of the = MIDCOM MIB =20 [CM] In this respect all of them fit partial compliance with this as = far as relating to the MIDCOM protocol. The point made, IMO, was that it could = be done easily with SNMP as this is part of its inherent nature as a = management protocol. 2.2.10 Consecutive range of port numbers=20 SNMP compliance should be partial as it requires the creation of the = MIDCOM MIB =20 [CM] Ditto=20 2.2.11 Same as 2.2.10 for the SNMP compliance=20 3 Conclusion=20 I think that in the SNMP statement the reliability problems should be discussed=20 as their fix is not included in of the shelf stacks and do not apply to = TRAP messages.=20 Similarly the statement on the broad deployment of SNMP doesn't include SNMPv3,=20 this should probably stated as well.=20 [CM] Agree, but it should be noted that SNMPv3 is becoming more = prevalent in newer network implementations.=20 =20 Cedric=20 -----Original Message-----=20 From: Barnes, Mary [NGC:B602:EXCH]=20 Sent: 07 June 2002 02:58=20 To: 'midcom@ietf.org'=20 Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Hi all,=20 Just a reminder that comments on the protocol evaluation draft are due = by noon on Monday, June 10th. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.t= xt=20 The level of discussion on this draft by members of the WG has been = rather disquieting. The draft is not incredibly long, with the new material = being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need discussion and WG feedback which are = indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at = least review those portions. The objective is for the draft to be fairly = complete and actually undergoing WGLC by the Yokohama meeting, so comments now = are definitely preferred over during the WG session or after the Yokohama meeting. =20 As a reminder, the remaining schedule for this WG draft is as follows:=20 June 14th Second version of draft available.=20 June 14th-June 21st Mailing list discussion of version 2 of draft.=20 June 28th Draft ready for WGLC=20 July 19th WGLC ends=20 July 26th Updated draft based upon WGLC comments available=20 July 26th- Aug (whether another iteration is required for WGLC depends = upon=20 the extent of changes, etc.)=20 Aug Draft submitted to IESG=20 Regards,=20 Mary H. Barnes=20 mbarnes@nortelnetworks.com=20 972-684-5432=20 Wireless 817-703-4806=20 =20 ------_=_NextPart_001_01C2112F.8BB791D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon = CST

Martin,

[CM] In network topologies containing departmental = firewalls, typically it is not topology hiding (NAT) that is being = enforced by the internal firewall, rather access. Usually this is a = concern which is implemented for the Internet facing firewall, in = addition to the possibility of private address space that may exist = internally. But even if it is, this seems a bit out of scope, since the = internal agents may be provisioned on the middlebox as a form of = policy, but more often than not these internal firewalls will not have = access to or through the Internet firewall due to security policy. =

<CA>
I was discussing usage of packet filtering in = Firewalls in the discussed network topology. As the SNMP agent receive = messages on a different port than the one used to send messages, we = have serious problem when the SNMP agent is behind a NAT.

In case the Midcom agent is within the enterprise = then this issue is no longer relevant.
</CA>

Cedric
-----Original Message-----
From: Christopher A. Martin [mailto:christopher.a.marti= n@wcom.com]
Sent: 10 June 2002 21:58
To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary = [NGC:B602:EXCH]; midcom@ietf.org
Subject: RE: [midcom] Reminder: Comments due to list = on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon = CST

Inline comments....to Cedric.
-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]O= n Behalf Of Cedric Aoun
Sent: Monday, June 10, 2002 2:45 AM
To: Mary Barnes; 'midcom@ietf.org'
Subject: RE: [midcom] Reminder: Comments due to list = on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon = CST

Hi Mary,
General comments:
There is an inconsistency with the used compliancy = method, Tom and you have
actually already mentioned that.In the comments = below I will point out to the
requirements where the SNMP compliancy should be = changed.
I found "=C6" several times in the text = instead of "'" it is perhaps due to CRLF.
Section 1.1.3 SNMP overview section: the Middle Box = is a PEP and not a PDP.
[CM] Agree [CM]
Section 2.1.2. SNMP doesn't include any Midcom agent = identifiers, the identification
will be based on matching an IP address and = port to a certain SNMP agent.
In case more a Middlebox applying NAT is deployed = between a Midcom agent and
the Middlebox being controlled by the Midcom agent = then the identification
can't be known in advance and therefore can't be = provisioned.
I think we could find certain network topologies = where firewalls are deployed
in certain departments and then a NAT + Firewall is = deployed at the network
interconnection of the enterprise. In this case all = protocols not having IDs
will fail, including SNMP.IMO the requirement is not = met by SNMP.
[CM] In network topologies containing departmental = firewalls, typically it is not topology hiding (NAT) that is being = ebforced by the internal firewall, rather access. Usually this is a = concern which is implemented for the Internet facing firewall, in = addition to the possibility of private addres space that may exist = internally. But even if it is, this seems a bit out of scope, since the = internal agents may be provisioned on the middlebox as a form of = policy, but more often than not these internal firewalls will not have = access to or through the Internet firewall due to security policy. =

The method to identify the internal middleboxes is = probably moot IMHO due to any number of security policy decisions by = the company that we could come up with all day long, and is an issue = which would affect any MIDCOM protocol decided on today with eqaul = complexity whether it is an existing protocol, or a completely = homegrown brand new protocol. [CM]

Section 2.1.2 RSIP compliancy section. In RSIP = the Midcom agent is coupled with
the application host, it can't be on a = separate host. I see as a failure to
meeting the MIDCOM framework, in which we wanted a = complete flexible model
where the Midcom agent function could be hosted on = any host. This comment is
probably more on the general applicability of RSIP, = but since there is a note
on it in 2.1.3 the comment is applicable on the = section as well.
[CM] As far as I am concerned this [RSIP] is the = same as NAT, WRT similiar issues of imbedded IP, and is one of the = issues MIDCOM is trying to resolve, since I dont believe that adding = another agent to every host is the answer to the problem, merely adds = another level of complexity to troubleshoot on the host. = [CM]

2.1.7 Reliability in SNMP is achieved by = retransmissions and timers, this mechanism
applies only if the messages have a reply, in case = of TRAPs this is not the case.
Therefore IMO this requirement is not met. =
[CM] in 2.1.7 Middlebox can generate unsolicited = messages, the fact that a response is not recieved to acknowledge the = trap may be low risk due to the fact that typically traps do not stop = until alarm is mitigated. So it is reliable unless you cant even = communicate over the trap path (such as a WAN link), in which event all = protocols would fail this test. [CM]

2.2.1 Extensibility. I think we should grade = differently protocols that have existing
means of extensibility without changing the base = protocol messages by using "objects"
as means of extensibility and protocols that achieve = extensibility by adding new messages
or parameters in the base protocol to achieve the = extensibility. As such the RSIP protocol
requires more work to be extensible and should = be graded differently. I don't know if it
fair to put its compliancy to Partially met or = Unmet.
[CM] Agree with grading suggestion, more discussion = could be done here. Also, see my comment above about RSIP.
2.2.8 Transport of filtering rules
SNMP requires a new MIDCOM MIB to meet this = requirement, therefore it is partially
compliant as the MIB is not existent
[CM] This is already stated in the draft, however = extensibility is not difficult with SNMP nothing new to be done but = develop the MIB. Agree with partially compliant, with the = qualifier that this applies to any and all protocols under = evaluation/development.

RSIP currently couples the filter with the action = which is address translation
or address and port translation. As we are looking = at a model where the filter
is decoupled from the action (from a syntax = perspective) I think that RSIP
currently fails to meet the requirement. =
[CM] I would agree, only due to my opinion of = RSIP.... :^) [CM]
2.2.9 Mapped port parity
SNMP compliance should be partial as it requires the = creation of the MIDCOM MIB
[CM] In this respect all of them fit partial = compliance with this as far as relating to the MIDCOM protocol. The = point made, IMO, was that it could be done easily with SNMP as this is = part of its inherent nature as a management protocol.

2.2.10 Consecutive range of port numbers
SNMP compliance should be partial as it requires the = creation of the MIDCOM MIB
[CM] Ditto
2.2.11 Same as 2.2.10 for the SNMP compliance =
3 Conclusion
I think that in the SNMP statement the reliability = problems should be discussed
as their fix is not included in of the shelf stacks = and do not apply to TRAP messages.
Similarly the statement on the broad deployment of = SNMP doesn't include SNMPv3,
this should probably stated as well.
[CM] Agree, but it should be noted that SNMPv3 is = becoming more prevalent in newer network implementations.

Cedric

Hi all,
Just a reminder that comments on the protocol = evaluation draft are due by noon on Monday, June 10th. It's = available at:

------_=_NextPart_001_01C2112F.8BB791D6-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Jun 11 16:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10943 for ; Tue, 11 Jun 2002 16:21:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16456 for midcom-archive@odin.ietf.org; Tue, 11 Jun 2002 16:22:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16239; Tue, 11 Jun 2002 16:11:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16208 for ; Tue, 11 Jun 2002 16:11:17 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10595 for ; Tue, 11 Jun 2002 16:10:41 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BKAim23080; Tue, 11 Jun 2002 16:10:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 16:10:45 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5CC@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Bob Penfield'" , midcom@ietf.org Subject: RE: [midcom] Megaco In The Evaluation Date: Tue, 11 Jun 2002 16:10:42 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org You are probably right. Contexts are definitely a grouping mechanism, and if you want to clear down all the rules in a group at once a wildcarded Subtract does the job nicely. The one point that has made me hesitant is that in Megaco the Context implies flows between its contained terminations. We would have to discard this connotation for MIDCOM. -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Monday, June 10, 2002 5:54 PM To: midcom@ietf.org Subject: [midcom] Megaco In The Evaluation The evaluation of Megaco mentions Contexts (which can be used to group related Terminations) in the intro, but they are not mentioned anywhere else in the document. I think Contexts go a long way toward satisfying requirements 2.2.2 (multiple middlebox action types) and 2.2.3 (Ruleset groups). In particular, section 2.2.3 mentions the policy model described in Appendix C as the answer for the requirement, but claims Total compliance. The use of Contexts for grouping would be totally compliant. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Jun 12 21:10:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18231 for ; Wed, 12 Jun 2002 21:10:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07940 for midcom-archive@odin.ietf.org; Wed, 12 Jun 2002 21:11:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07882; Wed, 12 Jun 2002 21:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07853 for ; Wed, 12 Jun 2002 21:09:07 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18182 for ; Wed, 12 Jun 2002 21:08:31 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5D18ak22166; Wed, 12 Jun 2002 20:08:36 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 20:08:22 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C603@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Bob Penfield'" , Juergen Quittek , "Tom-PT Taylor" , midcom@ietf.org Subject: RE: [midcom] SNMP In The Evaluation Date: Wed, 12 Jun 2002 20:08:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21276.CFC17C00" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C21276.CFC17C00 Content-Type: text/plain; charset="iso-8859-1" Bob et al, I think Tom's point was that MEGACO, COPS and DIAMETER defined the compliancy to be Partial where extensions were required. I've not seen anyone else express an opinion either way, but I don't have a problem adding another category. I do feel that the current text sufficiently covers the level of "Partial Compliancy" and there are very few Partials that aren't extension/package/MIB flavored. However, a new category does add a sufficient level of differentiation that could be useful. So, I'll propose P+ for those that are partially compliant that could be made compliant with extensions, packages, MIBs,etc. and a P- for those that require more significant changes to the protocol. I do plan to get the updated document out before CoB this Friday, so if you have any concerns with this proposal, please bring them to the list within the next 24 hours. Thanks, Mary. -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Monday, June 10, 2002 3:22 PM To: Juergen Quittek; Barnes, Mary [NGC:B602:EXCH]; Taylor, Tom-PT [CAR:B602:EXCH]; midcom@ietf.org Subject: Re: [midcom] SNMP In The Evaluation To be fair, the other protocols require extensions in order to comply to some of the requirements. For example, MEGACO requires the definition of a new Package to support MIDCOM. Do we need another category besides Total, Partial, and Failed compliance for those requirements that are easily covered by the extensibility already built into the protocol? (e.g a new Package for MEGACO, or a new MIB for SNMP). cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Juergen Quittek" To: "Mary Barnes" ; "Tom-PT Taylor" ; Sent: Monday, June 10, 2002 9:34 AM Subject: RE: [midcom] SNMP In The Evaluation > Mary, > > --On 03 June 2002 13:21 -0500 Mary Barnes wrote: > > > > > Hi all, > > > > I haven't seen any further discussion on this one, but as Editor, I think I have to agree with Tom. Clearly, there exists an inconsistency in the evaluations as far as the Total Compliance versus Partial Compliance. There had been a brief email thread > > on the difference in classifying between these two and the conclusion had been that if extensions are required then the protocol is partially compliant: > > > > http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02083.htm l > > Thus, I'm going to propose the change to the SNMP evaluation as Tom has suggested unless there is strong opinions suggesting otherwise. > > > > I don't believe this changes the author's overall conclusion that SNMP meets the requirements as the MIDCOM protocol with the design of a MIDCOM MIB module. However, it would require changing some of the statements in section 3. > > > > I would propose the following: > > Changing > > "The SNMP management framework as evaluated matches all specified Midcom requirements". > > to say something like: > > "The SNMP management framework meets all the specified Midcom protocol requirements with the design of a MIDCOM MIB module". > > I fully agree. > > Maybe we can even improve phrasing by writing "appropriate design" > instead of just "design". > > Juergen > > > > > and then removing the last sentence from that paragraph. > > > > Regards, > > Mary H. Barnes > > mbarnes@nortelnetworks.com > > 972-684-5432 > > Wireless 817-703-4806 > > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B602:EXCH] > > Sent: Thursday, May 30, 2002 8:55 AM > > To: 'Juergen Quittek'; 'midcom@ietf.org' > > Subject: RE: [midcom] SNMP In The Evaluation > > > > This is a matter of consistent treatment of the protocols in the evaluation. > > For DIAMETER, for instance, the necessary data types have probably all been > > defined in Base, but it will be necessary to define the messages containing > > them. I think you are saying that in the SNMP case you can point to > > specific object types you can import but it will be necessary to define a > > new module to provide a context for them. These may not be at the same > > level of activity, but I think they are sufficiently analogous that both > > protocols should be classified in the same way. > > > > -----Original Message----- > > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > > Sent: Thursday, May 30, 2002 8:51 AM > > To: Taylor, Tom-PT [CAR:B602:EXCH]; 'midcom@ietf.org' > > Subject: Re: [midcom] SNMP In The Evaluation > > > > Tom, > > > > --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: > >> > >> SNMP fit to requirements is overstated relative to the other > >> protocols. For consistency, every requirement which refers to > >> "an appropriate definition of a Midcom MIB module" should be > >> rated as "partially met". > > > > I agree, that the statements are to general. Would you be fine > > if I provide more concrete arguments, why these requirements > > are clearly met. This is much more appropriate than moving to > > partially met. > > > > Take for example "2.2.2 Support of multiple Middlebox types". > > SNMP has several means to do so, starting from the standard > > sysObjectID indicating the 'kind of box' to managed objects > > defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, > > packet filter, ... > > Also box type specific support by specific managed objects > > is something which SNMP/SMI was built for. It definitely > > meets these requirement fully, not partially. > > > > Juergen > > -- > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> > >> Tom Taylor > >> taylor@nortelnetworks.com > >> Ph. +1 613 736 0961 (ESN 396 1490) > >> > > > > > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C21276.CFC17C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] SNMP In The Evaluation

Bob et al,

I think Tom's point was that MEGACO, COPS and = DIAMETER defined the compliancy to be Partial where extensions were = required. I've not seen anyone else express an opinion either = way, but I don't have a problem adding another category. I do feel that = the current text sufficiently covers the level of "Partial = Compliancy" and there are very few Partials that aren't = extension/package/MIB flavored. However, a new category does add = a sufficient level of differentiation that could be useful. So, = I'll propose P+ for those that are partially compliant that could be = made compliant with extensions, packages, MIBs,etc. and a P- for those = that require more significant changes to the protocol. I do plan = to get the updated document out before CoB this Friday, so if you have = any concerns with this proposal, please bring them to the list within = the next 24 hours.

Thanks,
Mary.

-----Original Message-----
From: Bob Penfield [mailto:bpenfield@acmepacket.com= ]
Sent: Monday, June 10, 2002 3:22 PM
To: Juergen Quittek; Barnes, Mary [NGC:B602:EXCH]; = Taylor, Tom-PT
[CAR:B602:EXCH]; midcom@ietf.org
Subject: Re: [midcom] SNMP In The Evaluation

To be fair, the other protocols require extensions in = order to comply to
some of the requirements. For example, MEGACO = requires the definition of a
new Package to support MIDCOM. Do we need another = category besides Total,
Partial, and Failed compliance for those = requirements that are easily
covered by the extensibility already built into the = protocol? (e.g a new
Package for MEGACO, or a new MIB for SNMP).

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Juergen Quittek" = <quittek@ccrle.nec.de>
To: "Mary Barnes" = <mbarnes@nortelnetworks.com>; "Tom-PT Taylor"
<taylor@nortelnetworks.com>; = <midcom@ietf.org>
Sent: Monday, June 10, 2002 9:34 AM
Subject: RE: [midcom] SNMP In The Evaluation

> Mary,
>
> --On 03 June 2002 13:21 -0500 Mary Barnes = <mbarnes@nortelnetworks.com>
wrote:
>
> >
> > Hi all,
> >
> > I haven't seen any further discussion on = this one, but as Editor, I
think I have to agree with Tom. Clearly, there = exists an inconsistency in
the evaluations as far as the Total Compliance = versus Partial Compliance.
There had been a brief email thread
> > on the difference in classifying between = these two and the conclusion
had been that if extensions are required then the = protocol is partially
compliant:
> >
> >
http://www1.ietf.org/mail-archive/working-groups/midco= m/current/msg02083.htm
l
> > Thus, I'm going to propose the change to = the SNMP evaluation as Tom has
suggested unless there is strong opinions suggesting = otherwise.
> >
> > I don't believe this changes the author's = overall conclusion that SNMP
meets the requirements as the MIDCOM protocol with = the design of a MIDCOM
MIB module. However, it would require changing some = of the statements in
section 3.
> >
> > I would propose the following:
> > Changing
> > "The SNMP management framework as = evaluated matches all specified Midcom
requirements".
> > to say something like:
> > "The SNMP management framework meets = all the specified Midcom protocol
requirements with the design of a MIDCOM MIB = module".
>
> I fully agree.
>
> Maybe we can even improve phrasing by writing = "appropriate design"
> instead of just "design".
>
>     Juergen
>
> >
> > and then removing the last sentence from = that paragraph.
> >
> > Regards,
> > Mary H. Barnes
> > mbarnes@nortelnetworks.com
> > 972-684-5432
> > Wireless 817-703-4806
> >
> > -----Original Message-----
> > From: Taylor, Tom-PT = [CAR:B602:EXCH]
> > Sent: Thursday, May 30, 2002 8:55 = AM
> > To: 'Juergen Quittek'; = 'midcom@ietf.org'
> > Subject: RE: [midcom] SNMP In The = Evaluation
> >
> > This is a matter of consistent treatment = of the protocols in the
evaluation.
> > For DIAMETER, for instance, the necessary = data types have probably all
been
> > defined in Base, but it will be necessary = to define the messages
containing
> > them. I think you are saying that in = the SNMP case you can point to
> > specific object types you can import but = it will be necessary to define
a
> > new module to provide a context for = them. These may not be at the same
> > level of activity, but I think they are = sufficiently analogous that both
> > protocols should be classified in the same = way.
> >
> > -----Original Message-----
> > From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
> > Sent: Thursday, May 30, 2002 8:51 = AM
> > To: Taylor, Tom-PT [CAR:B602:EXCH]; = 'midcom@ietf.org'
> > Subject: Re: [midcom] SNMP In The = Evaluation
> >
> > Tom,
> >
> > --On 29 May 2002 09:15 -0400 Tom-PT Taylor = wrote:
> >>
> >> SNMP fit to requirements is overstated = relative to the other
> >> protocols. For consistency, = every requirement which refers to
> >> "an appropriate definition of a = Midcom MIB module" should be
> >> rated as "partially = met".
> >
> > I agree, that the statements are to = general. Would you be fine
> > if I provide more concrete arguments, why = these requirements
> > are clearly met. This is much more = appropriate than moving to
> > partially met.
> >
> > Take for example "2.2.2 Support of = multiple Middlebox types".
> > SNMP has several means to do so, starting = from the standard
> > sysObjectID indicating the 'kind of box' = to managed objects
> > defining the type in more general terms, = e.g. NAT, NAT-PT, NAPT,
> > packet filter, ...
> > Also box type specific support by specific = managed objects
> > is something which SNMP/SMI was built for. = It definitely
> > meets these requirement fully, not = partially.
> >
> >     Juergen
> > --
> > Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
> > NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
> > Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
> >>
> >> Tom Taylor
> >> taylor@nortelnetworks.com
> >> Ph. +1 613 736 0961 (ESN 396 = 1490)
> >>
> >
> >
> > = _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
>
>
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C21276.CFC17C00-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 14 05:21:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23412 for ; Fri, 14 Jun 2002 05:21:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29529 for midcom-archive@odin.ietf.org; Fri, 14 Jun 2002 05:21:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29486; Fri, 14 Jun 2002 05:19:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29457 for ; Fri, 14 Jun 2002 05:19:27 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23379 for ; Fri, 14 Jun 2002 05:18:49 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5E9It866752; Fri, 14 Jun 2002 11:18:55 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA28584; Fri, 14 Jun 2002 11:14:33 +0200 Date: Fri, 14 Jun 2002 11:14:32 +0200 From: Juergen Quittek To: Mary Barnes , "'Bob Penfield'" , Tom-PT Taylor , midcom@ietf.org Subject: RE: [midcom] SNMP In The Evaluation Message-ID: <7777873.1024053272@[192.168.102.164]> In-Reply-To: <1B54FA3A2709D51195C800508BF9386A05A7C603@zrc2c000.us.nortel.com> References: <1B54FA3A2709D51195C800508BF9386A05A7C603@zrc2c000.us.nortel.com> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Mary, I support your proposal. The differentiation between two kinds of partial compliancy make the evaluation much clearer. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 12 June 2002 20:08 -0500 Mary Barnes wrote: > > Bob et al, > > I think Tom's point was that MEGACO, COPS and DIAMETER defined the compliancy to be Partial where extensions were required. I've not seen anyone else express an opinion either way, but I don't have a problem adding another category. I do feel that the > current text sufficiently covers the level of "Partial Compliancy" and there are very few Partials that aren't extension/package/MIB flavored. However, a new category does add a sufficient level of differentiation that could be useful. So, I'll > propose P+ for those that are partially compliant that could be made compliant with extensions, packages, MIBs,etc. and a P- for those that require more significant changes to the protocol. I do plan to get the updated document out before CoB this > Friday, so if you have any concerns with this proposal, please bring them to the list within the next 24 hours. > > Thanks, > Mary. > > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Monday, June 10, 2002 3:22 PM > To: Juergen Quittek; Barnes, Mary [NGC:B602:EXCH]; Taylor, Tom-PT > [CAR:B602:EXCH]; midcom@ietf.org > Subject: Re: [midcom] SNMP In The Evaluation > > To be fair, the other protocols require extensions in order to comply to > some of the requirements. For example, MEGACO requires the definition of a > new Package to support MIDCOM. Do we need another category besides Total, > Partial, and Failed compliance for those requirements that are easily > covered by the extensibility already built into the protocol? (e.g a new > Package for MEGACO, or a new MIB for SNMP). > > cheers, > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Mary Barnes" ; "Tom-PT Taylor" > ; > Sent: Monday, June 10, 2002 9:34 AM > Subject: RE: [midcom] SNMP In The Evaluation > >> Mary, >> >> --On 03 June 2002 13:21 -0500 Mary Barnes > wrote: >> >> > >> > Hi all, >> > >> > I haven't seen any further discussion on this one, but as Editor, I > think I have to agree with Tom. Clearly, there exists an inconsistency in > the evaluations as far as the Total Compliance versus Partial Compliance. > There had been a brief email thread >> > on the difference in classifying between these two and the conclusion > had been that if extensions are required then the protocol is partially > compliant: >> > >> > > http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02083.htm > l >> > Thus, I'm going to propose the change to the SNMP evaluation as Tom has > suggested unless there is strong opinions suggesting otherwise. >> > >> > I don't believe this changes the author's overall conclusion that SNMP > meets the requirements as the MIDCOM protocol with the design of a MIDCOM > MIB module. However, it would require changing some of the statements in > section 3. >> > >> > I would propose the following: >> > Changing >> > "The SNMP management framework as evaluated matches all specified Midcom > requirements". >> > to say something like: >> > "The SNMP management framework meets all the specified Midcom protocol > requirements with the design of a MIDCOM MIB module". >> >> I fully agree. >> >> Maybe we can even improve phrasing by writing "appropriate design" >> instead of just "design". >> >> Juergen >> >> > >> > and then removing the last sentence from that paragraph. >> > >> > Regards, >> > Mary H. Barnes >> > mbarnes@nortelnetworks.com >> > 972-684-5432 >> > Wireless 817-703-4806 >> > >> > -----Original Message----- >> > From: Taylor, Tom-PT [CAR:B602:EXCH] >> > Sent: Thursday, May 30, 2002 8:55 AM >> > To: 'Juergen Quittek'; 'midcom@ietf.org' >> > Subject: RE: [midcom] SNMP In The Evaluation >> > >> > This is a matter of consistent treatment of the protocols in the > evaluation. >> > For DIAMETER, for instance, the necessary data types have probably all > been >> > defined in Base, but it will be necessary to define the messages > containing >> > them. I think you are saying that in the SNMP case you can point to >> > specific object types you can import but it will be necessary to define > a >> > new module to provide a context for them. These may not be at the same >> > level of activity, but I think they are sufficiently analogous that both >> > protocols should be classified in the same way. >> > >> > -----Original Message----- >> > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> > Sent: Thursday, May 30, 2002 8:51 AM >> > To: Taylor, Tom-PT [CAR:B602:EXCH]; 'midcom@ietf.org' >> > Subject: Re: [midcom] SNMP In The Evaluation >> > >> > Tom, >> > >> > --On 29 May 2002 09:15 -0400 Tom-PT Taylor wrote: >> >> >> >> SNMP fit to requirements is overstated relative to the other >> >> protocols. For consistency, every requirement which refers to >> >> "an appropriate definition of a Midcom MIB module" should be >> >> rated as "partially met". >> > >> > I agree, that the statements are to general. Would you be fine >> > if I provide more concrete arguments, why these requirements >> > are clearly met. This is much more appropriate than moving to >> > partially met. >> > >> > Take for example "2.2.2 Support of multiple Middlebox types". >> > SNMP has several means to do so, starting from the standard >> > sysObjectID indicating the 'kind of box' to managed objects >> > defining the type in more general terms, e.g. NAT, NAT-PT, NAPT, >> > packet filter, ... >> > Also box type specific support by specific managed objects >> > is something which SNMP/SMI was built for. It definitely >> > meets these requirement fully, not partially. >> > >> > Juergen >> > -- >> > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> >> >> Tom Taylor >> >> taylor@nortelnetworks.com >> >> Ph. +1 613 736 0961 (ESN 396 1490) >> >> >> > >> > >> > _______________________________________________ >> > midcom mailing list >> > midcom@ietf.org >> > https://www1.ietf.org/mailman/listinfo/midcom >> >> >> >> _______________________________________________ >> midcom mailing list >> midcom@ietf.org >> https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 14 05:47:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23623 for ; Fri, 14 Jun 2002 05:47:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00894 for midcom-archive@odin.ietf.org; Fri, 14 Jun 2002 05:48:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00797; Fri, 14 Jun 2002 05:46:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00770 for ; Fri, 14 Jun 2002 05:46:28 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23596 for ; Fri, 14 Jun 2002 05:45:50 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5E9jv868791; Fri, 14 Jun 2002 11:45:57 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA28926; Fri, 14 Jun 2002 11:41:35 +0200 Date: Fri, 14 Jun 2002 11:41:34 +0200 From: Juergen Quittek To: Cedric Aoun , Mary Barnes , "'midcom@ietf.org'" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Message-ID: <9399325.1024054894@[192.168.102.164]> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA00771 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Cedric, Please see my comments inline. Regards, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 11 June 2002 11:40 +0200 Cedric Aoun wrote: > > Juergen, > Please see my comments below. > Thanks. > Cedric > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: 10 June 2002 17:08 > To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary [NGC:B602:EXCH]; > 'midcom@ietf.org' > Subject: RE: [midcom] Reminder: Comments due to list on > draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST > > Cedric, > > --On 10 June 2002 09:45 +0200 Cedric Aoun wrote: > >> >> Hi Mary, >> General comments: >> There is an inconsistency with the used compliancy method, Tom and you have >> actually already mentioned that.In the comments below I will point out to the >> requirements where the SNMP compliancy should be changed. >> I found "�" several times in the text instead of "'" it is perhaps due to CRLF. >> >> Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a PDP. >> >> Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification >> will be based on matching an IP address and port to a certain SNMP agent. >> In case more a Middlebox applying NAT is deployed between a Midcom agent and >> the Middlebox being controlled by the Midcom agent then the identification >> can't be known in advance and therefore can't be provisioned. >> I think we could find certain network topologies where firewalls are deployed >> in certain departments and then a NAT + Firewall is deployed at the network >> interconnection of the enterprise. In this case all protocols not having IDs >> will fail, including SNMP.IMO the requirement is not met by SNMP. > > Did I get you right?: You think you can find some network cofiguration where > SNMP cannot support multiple Midcom agents communicating with more than one > middlebox simulataneously. But you cannot explain them here and therefore > the requirement is not met by SNMP??? > > > SNMP agents uses a particular port number to receive messages forgot if it was 161 or 162. Standard is using 161 for receiving get/set messages and 162 for receiving traps. But you can use any available port number, if you like. > In case we have a topology with FW - NAT > FW/ > How can the SNMP manager control the FW Middleboxes? If it can't rely to the same port > the SNMP messages are sent from?THe problem I'm talking about is > MICOM NAT traversal problems. Well, I assume that the NAT in your example is midcom-capable (otherwise the scenario would be very strange). But then you can use midcom to configure the NAT properly in a way that it uses the same port numbers for both directions. So if you first use MIDCOM to configure the NAT in front of you, you can then use midcom to configure the FW behind the NAT without any problem. > In addition if we don't have the assymetric port usage, we have the identification problem that could > be solved with static bind but this is pretty ugly. Yes, but isn't this what midcom is for. > The ID problem is that since we don't discover Middlebox (in the current architecture), > the Midcom agent is supposed to know them how will you identify them without using IP address + port (since there is no > ID in the SNMP messages), this implicitly requires to use static binds in the network scenario shown above. I share your concern about missing middlebox discovery in general. However, in many concrete sceanrios you want to restrict midcom agents to control middleboxes from within the protected network only. Then discovery might be of less importance, because on the administration side, knowledge about all middleboxes should be available. > > > SNMP has several features only built in to explicitly support multiple > Midcom agents (SNMP managers) within a single stack. Not even multiple > instances of the PEP are required, as it is for COPS. > >> Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is coupled with >> the application host, it can't be on a separate host. I see as a failure to >> meeting the MIDCOM framework, in which we wanted a complete flexible model >> where the Midcom agent function could be hosted on any host. This comment is >> probably more on the general applicability of RSIP, but since there is a note >> on it in 2.1.3 the comment is applicable on the section as well. >> >> 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this mechanism >> applies only if the messages have a reply, in case of TRAPs this is not the case. >> Therefore IMO this requirement is not met. > > Requirement 2.1.7 says: "The protocol must support unsolicited messages from > middlebox to agent ...". How can you say this is not exactly what SNMP > notifications are available for? > > If you require reliability in addition, I suggest the following procedure: > 1. add reliability to the requirements > 2. state that reliability is not met by SNMP notifications. > > Please tell me, if I missed a reliability statement. Then we can discuss > replacing replace SNMP notifications by reliable SNMP inform messages. > I did not mention them yet, because they are not available in SNMPv1, > but they are in v2 and v3. > > In any case SNMP meets the requirement. > > > The reliability requirements are hidden behind the deterministic behavior requirement. > We had initially a bunch of mother hood and applepie requirements that included explicitly reliability, > but were taken out. > Perhaps we need to add them again in the requirements. If this was the intention, the reuqirements are not well phrased. After carefully reading them I assumed that deterministic behavior is requested only with respect to overlapping rules and multiple agents. So rephrasing seems to be a good idea. It is preferable to clearly state individual requirements compared to coding everything into a minimal number of words, even if then some requirements repeat phrases several times. Anyway, I have a general concern about deterministic behavior. Some way, it can easily get by policy control of the middlebox. If we have policy control of how to handle overlapping rules, we cannot change these policies during operation of the middlebox, because otherwise the behavior of the box would be non-deterministic from the affected agent's point of view. Juergen > > >> 2.2.1 Extensibility. I think we should grade differently protocols that have existing >> means of extensibility without changing the base protocol messages by using "objects" >> as means of extensibility and protocols that achieve extensibility by adding new messages >> or parameters in the base protocol to achieve the extensibility. As such the RSIP protocol >> requires more work to be extensible and should be graded differently. I don't know if it >> fair to put its compliancy to Partially met or Unmet. >> >> 2.2.8 Transport of filtering rules >> SNMP requires a new MIDCOM MIB to meet this requirement, therefore it is partially >> compliant as the MIB is not existent >> >> RSIP currently couples the filter with the action which is address translation >> or address and port translation. As we are looking at a model where the filter >> is decoupled from the action (from a syntax perspective) I think that RSIP >> currently fails to meet the requirement. >> >> 2.2.9 Mapped port parity >> SNMP compliance should be partial as it requires the creation of the MIDCOM MIB >> >> 2.2.10 Consecutive range of port numbers >> SNMP compliance should be partial as it requires the creation of the MIDCOM MIB >> >> 2.2.11 Same as 2.2.10 for the SNMP compliance >> >> 3 Conclusion >> I think that in the SNMP statement the reliability problems should be discussed >> as their fix is not included in of the shelf stacks and do not apply to TRAP messages. > > It is available in commercial off-the-shelf implementations as well as in > even very simple public domain implementations. > >> Similarly the statement on the broad deployment of SNMP doesn't include SNMPv3, >> this should probably stated as well. > > Yes, that's right. However, we still should compare SNMPv3 > deployment and maturity to COPS, Diameter, Megaco, RSIP deployment. > The SNMPv3 RFCs have already achieved draft standard status. > > > Agreed > > >> Cedric >> >> >> -----Original Message----- >> From: Barnes, Mary [NGC:B602:EXCH] >> Sent: 07 June 2002 02:58 >> To: 'midcom@ietf.org' >> Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST > >> >> Hi all, >> Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: > >> >> http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt >> The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need > >> discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be > >> fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. > >> >> As a reminder, the remaining schedule for this WG draft is as follows: >> June 14th Second version of draft available. >> June 14th-June 21st Mailing list discussion of version 2 of draft. >> June 28th Draft ready for WGLC >> July 19th WGLC ends >> July 26th Updated draft based upon WGLC comments available >> July 26th- Aug (whether another iteration is required for WGLC depends upon >> the extent of changes, etc.) >> Aug Draft submitted to IESG >> Regards, >> Mary H. Barnes >> mbarnes@nortelnetworks.com >> 972-684-5432 >> Wireless 817-703-4806 >> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 14 11:25:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03381 for ; Fri, 14 Jun 2002 11:25:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17626 for midcom-archive@odin.ietf.org; Fri, 14 Jun 2002 11:26:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17491; Fri, 14 Jun 2002 11:23:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17462 for ; Fri, 14 Jun 2002 11:23:58 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03227 for ; Fri, 14 Jun 2002 11:23:18 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5EFNP890539; Fri, 14 Jun 2002 17:23:25 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA00376; Fri, 14 Jun 2002 17:19:02 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6515B41571; Fri, 14 Jun 2002 17:19:02 +0200 (CEST) Message-ID: <3D0A0968.1060502@ccrle.nec.de> Date: Fri, 14 Jun 2002 17:19:04 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020305 X-Accept-Language: en-us MIME-Version: 1.0 To: midcom@ietf.org Cc: Juergen Quittek Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] MIDCOM Protocol Semantics Draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Hi, Juergen and I have posted an internet draft with respect to MIDCOM protocol semantics. Until the draft is in the I-D directory, a copy is available at this server: http://diana.zam.fh-koeln.de/~mstiemerling/draft-stiemerling-midcom-semantics-00.txt Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 14 11:43:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03957 for ; Fri, 14 Jun 2002 11:43:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18661 for midcom-archive@odin.ietf.org; Fri, 14 Jun 2002 11:44:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18516; Fri, 14 Jun 2002 11:42:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18487 for ; Fri, 14 Jun 2002 11:42:21 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03904 for ; Fri, 14 Jun 2002 11:41:41 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5EFfeM13585; Fri, 14 Jun 2002 11:41:40 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Jun 2002 11:41:41 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A5F3@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Martin Stiemerling'" , midcom@ietf.org Cc: Juergen Quittek Subject: RE: [midcom] MIDCOM Protocol Semantics Draft Date: Fri, 14 Jun 2002 11:41:38 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org I'll have a look and see if there is stuff I should fold into mine. It's almost ready. -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Friday, June 14, 2002 11:19 AM To: midcom@ietf.org Cc: Juergen Quittek Subject: [midcom] MIDCOM Protocol Semantics Draft Hi, Juergen and I have posted an internet draft with respect to MIDCOM protocol semantics. Until the draft is in the I-D directory, a copy is available at this server: http://diana.zam.fh-koeln.de/~mstiemerling/draft-stiemerling-midcom-semantic s-00.txt Martin -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 14 12:09:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04660 for ; Fri, 14 Jun 2002 12:09:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21293 for midcom-archive@odin.ietf.org; Fri, 14 Jun 2002 12:10:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21184; Fri, 14 Jun 2002 12:07:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21158 for ; Fri, 14 Jun 2002 12:07:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04610 for ; Fri, 14 Jun 2002 12:06:54 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5EG6rHs003923; Fri, 14 Jun 2002 09:06:53 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AED82196; Fri, 14 Jun 2002 09:03:58 -0700 (PDT) Message-Id: <5.1.0.14.0.20020614120948.01331ec0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Jun 2002 12:11:37 -0400 To: "Tom-PT Taylor" , "'Martin Stiemerling'" , midcom@ietf.org From: Melinda Shore Subject: RE: [midcom] MIDCOM Protocol Semantics Draft Cc: Juergen Quittek In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A5F3@zcard0kc.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 11:41 AM 6/14/02 -0400, Tom-PT Taylor wrote: >I'll have a look and see if there is stuff I should fold into mine. It's >almost ready. At this point we don't have consensus about a semantics working group document. Since the two may diverge substantially I think at this point we need to take a look at both documents and see just how different they might be - it may not be possible to fold them together. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Jun 15 01:37:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24589 for ; Sat, 15 Jun 2002 01:37:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA04195 for midcom-archive@odin.ietf.org; Sat, 15 Jun 2002 01:38:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03887; Sat, 15 Jun 2002 01:33:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03859 for ; Sat, 15 Jun 2002 01:33:19 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24483 for ; Sat, 15 Jun 2002 01:32:42 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5F5X1s25232 for ; Sat, 15 Jun 2002 00:33:01 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 00:32:48 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C623@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Sat, 15 Jun 2002 00:32:48 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] One week to review: Updated version of MIDCOM Protocol evaluation draft submitted Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, I've just submitted an updated version of the MIDCOM Protocol evaluation draft. Until it's available in the draft repository, it can be obtained from: http://home.attbi.com/~mbarnes42/IETF/draft-ietf-midcom-protocol-eval-01.txt I will be following up with replies to several of the email threads to summarize how the issues raised have been handled, but I did want to bring the most major change to your attention. Another category of compliancy classification has been added and several of the items have been re-classified. P+ is now used for those protocols that can easily be extended to support the requirement and to differentiate these partial compliancies from those that require larger changes which may not necessarily be compatible with the protocol's design. This addition seemed to resolve many of the issues raised on the list and also allowed classification of some requirements for which we did not achieve WG concensus on P vs. T. In addition, I'd like to summarize 3 remaining issues which are denoted by 2 Editor's notes and one Contributor's note in the document which require some consideration/discussion: 1) There seems to be some confusion about the SNMP evaluation in that the SNMP Agent is defined to be the MIDCOM PDP (versus the PEP). However, text in section 1.1.3 seems to imply that the SNMP evaluation is based on the MIDCOM PDP being in the Middlebox. If this is indeed the implication, we need to add a statement to that affect. 2) There had been an issue raised with regards to the application of Megaco VMG's to MIDCOM (req. 2.1.2). This has been changed from a P/T to a P+. If everyone is okay with that, I'll just remove the Editor's note. 3) Several of the protocols encountered issues with 2.2.7 (Multiple agents acting on the same ruleset), with the RSIP evaluation indicating that it may be impossible to satisfy this requirement along with the deterministic and security requirements and RSIP has Failed this requirement. Only the SNMP evaluation provides a concrete explanation of how the protocol can meet this requirement. I know there was lots of discussion around this topic during development of the requirements and around the semantic analysis, so I don't anticipate we can resolve it for the evaluation. However, I think the issue that should be resolved is the evaluations against this one are inconsistent with RSIP failing, MEGACO and COPS being partically compliant, and DIAMETER and SNMP being Fully Compliant. In addition, I think it might be useful to include a mention of this issue in the conclusion. The plans for completing the next round of updates are as follows: June 14th-June 21st Mailing list discussion of -01 version of draft. June 24th (noon CST) Cutoff for input to -02 version. June 28th Updated Draft (-02) Available. The plans are for this version of the draft be ready for WGLC (pending WG chair approval), with discussion of any remaining open issues in Yokohama. Note that these dates have to remain fairly firm as the cutoff for Internet drafts for Yokohama is July 1st. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Jun 15 01:37:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24612 for ; Sat, 15 Jun 2002 01:37:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA04209 for midcom-archive@odin.ietf.org; Sat, 15 Jun 2002 01:38:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03940; Sat, 15 Jun 2002 01:34:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03913 for ; Sat, 15 Jun 2002 01:34:17 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24521 for ; Sat, 15 Jun 2002 01:33:39 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5F5Xws25236; Sat, 15 Jun 2002 00:33:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 00:33:45 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C624@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'christopher.a.martin@wcom.com'" , "Cedric Aoun" , midcom@ietf.org Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Sat, 15 Jun 2002 00:33:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, I've chosen this email out of the thread to respond to how I've dealt with most of the issues raised in the latest version (-01) of the document [MB]. I think that other than the issue that we've already resolved wrt to the further clarifications needed for Partial Compliancy (ala P+ and P), that this thread covers all the requirements for which issues were raised. Mary. -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Monday, June 10, 2002 2:58 PM To: Aoun, Cedric [QPD:MA01:EXCH]; Barnes, Mary [NGC:B602:EXCH]; midcom@ietf.org Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Inline comments....to Cedric. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Cedric Aoun Sent: Monday, June 10, 2002 2:45 AM To: Mary Barnes; 'midcom@ietf.org' Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Hi Mary, General comments: There is an inconsistency with the used compliancy method, Tom and you have actually already mentioned that.In the comments below I will point out to the requirements where the SNMP compliancy should be changed. I found "�" several times in the text instead of "'" it is perhaps due to CRLF. [MB] Okay, I think I have fixed all those, however, I won't know for sure until after it gets into the repository. As I do have a hardcopy of what I submitted and don't see those on my version. It is a result of the source program that I used to create the document. Section 1.1.3 SNMP overview section: the Middle Box is a PEP and not a PDP. [CM] Agree [CM] [MB] I also agree with this statement and I think I do see your point. I've added an Editor's note as I'm thinking that the intent of the SNMP model was that the MIDCOM PDP was part of the Middlebox and perhaps rather than equate the SNMP agent to the MIDCOM PDP, it should be equated to the Middlebox (or as you say the SNMP agent should be defined as the MIDCOM PEP, although this term is not defined in the framework as such). Section 2.1.2. SNMP doesn't include any Midcom agent identifiers, the identification will be based on matching an IP address and port to a certain SNMP agent. In case more a Middlebox applying NAT is deployed between a Midcom agent and the Middlebox being controlled by the Midcom agent then the identification can't be known in advance and therefore can't be provisioned. I think we could find certain network topologies where firewalls are deployed in certain departments and then a NAT + Firewall is deployed at the network interconnection of the enterprise. In this case all protocols not having IDs will fail, including SNMP.IMO the requirement is not met by SNMP. [CM] In network topologies containing departmental firewalls, typically it is not topology hiding (NAT) that is being ebforced by the internal firewall, rather access. Usually this is a concern which is implemented for the Internet facing firewall, in addition to the possibility of private addres space that may exist internally. But even if it is, this seems a bit out of scope, since the internal agents may be provisioned on the middlebox as a form of policy, but more often than not these internal firewalls will not have access to or through the Internet firewall due to security policy. The method to identify the internal middleboxes is probably moot IMHO due to any number of security policy decisions by the company that we could come up with all day long, and is an issue which would affect any MIDCOM protocol decided on today with eqaul complexity whether it is an existing protocol, or a completely homegrown brand new protocol. [CM] [MB]I have reworded this as Juergen's response to this on Tuesday indicates that he is referring to "multiple MIDCOM agents (SNMP Managers) communicating with more than one middlebox simultaneously", so I believe the wording should be changed from: "An SNMP manager can communicate simultaneously with several SNMP agents." To: "An SNMP manager can communicate simultaneously with several Middleboxes." Note, that this proposal is related to the issue raised in section 1.1.3 for the SNMP overview and the fundamental mapping of SNMP Agent to MIDCOM PDP, whereas the discussion seems to be that the SNMP Agent should map to the MIDCOM PEP or the Middlebox OR it needs to be explicitly spelled out that the MIDCOM PDP using SNMP is inherently part of the Middlebox (which is allowed per the framework, so it's just something which requires clarification). Section 2.1.2 RSIP compliancy section. In RSIP the Midcom agent is coupled with the application host, it can't be on a separate host. I see as a failure to meeting the MIDCOM framework, in which we wanted a complete flexible model where the Midcom agent function could be hosted on any host. This comment is probably more on the general applicability of RSIP, but since there is a note on it in 2.1.3 the comment is applicable on the section as well. [CM] As far as I am concerned this [RSIP] is the same as NAT, WRT similiar issues of imbedded IP, and is one of the issues MIDCOM is trying to resolve, since I dont believe that adding another agent to every host is the answer to the problem, merely adds another level of complexity to troubleshoot on the host. [CM] [MB] I think this point is consistent with the contributor's note, so I've changed this one to a P and modified the text somewhat. 2.1.7 Reliability in SNMP is achieved by retransmissions and timers, this mechanism applies only if the messages have a reply, in case of TRAPs this is not the case. Therefore IMO this requirement is not met. [CM] in 2.1.7 Middlebox can generate unsolicited messages, the fact that a response is not recieved to acknowledge the trap may be low risk due to the fact that typically traps do not stop until alarm is mitigated. So it is reliable unless you cant even communicate over the trap path (such as a WAN link), in which event all protocols would fail this test. [CM] [MB] Based upon another email thread, I have reworded this to indicate that for SNMPv3 INFORMs could be used, thus the concern wrt to replies could be met. 2.2.1 Extensibility. I think we should grade differently protocols that have existing means of extensibility without changing the base protocol messages by using "objects" as means of extensibility and protocols that achieve extensibility by adding new messages or parameters in the base protocol to achieve the extensibility. As such the RSIP protocol requires more work to be extensible and should be graded differently. I don't know if it fair to put its compliancy to Partially met or Unmet. [CM] Agree with grading suggestion, more discussion could be done here. Also, see my comment above about RSIP. [MB] This one is resolved by the addition of the new category of P+ which is used for the protocols which easily allow the necessary modifications for MIDCOM via extensions, packages, etc. 2.2.8 Transport of filtering rules SNMP requires a new MIDCOM MIB to meet this requirement, therefore it is partially compliant as the MIB is not existent [CM] This is already stated in the draft, however extensibility is not difficult with SNMP nothing new to be done but develop the MIB. Agree with partially compliant, with the qualifier that this applies to any and all protocols under evaluation/development. RSIP currently couples the filter with the action which is address translation or address and port translation. As we are looking at a model where the filter is decoupled from the action (from a syntax perspective) I think that RSIP currently fails to meet the requirement. [CM] I would agree, only due to my opinion of RSIP.... :^) [CM] [MB] Resolved with P+ category for SNMP, DIAMETER and COPS, leaving RSIP as a P (which is consistent with the manner in which Megaco dealt with 2.2.7.) 2.2.9 Mapped port parity SNMP compliance should be partial as it requires the creation of the MIDCOM MIB [CM] In this respect all of them fit partial compliance with this as far as relating to the MIDCOM protocol. The point made, IMO, was that it could be done easily with SNMP as this is part of its inherent nature as a management protocol.P [MB] Resolved with P+ category. 2.2.10 Consecutive range of port numbers SNMP compliance should be partial as it requires the creation of the MIDCOM MIB [CM] Ditto [MB] Resolved with P+ category. 2.2.11 Same as 2.2.10 for the SNMP compliance [MB] Resolved with P+ category. 3 Conclusion I think that in the SNMP statement the reliability problems should be discussed as their fix is not included in of the shelf stacks and do not apply to TRAP messages. Similarly the statement on the broad deployment of SNMP doesn't include SNMPv3, this should probably stated as well. [CM] Agree, but it should be noted that SNMPv3 is becoming more prevalent in newer network implementations. [MB] I've added a reference to the need to use SNMPv3 for problems other than security and updated the conclusion to indicate this. There is an explicit reference to TRAP with regards to the resolution for 2.1.7. Cedric -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: 07 June 2002 02:58 To: 'midcom@ietf.org' Subject: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Hi all, Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. As a reminder, the remaining schedule for this WG draft is as follows: June 14th Second version of draft available. June 14th-June 21st Mailing list discussion of version 2 of draft. June 28th Draft ready for WGLC July 19th WGLC ends July 26th Updated draft based upon WGLC comments available July 26th- Aug (whether another iteration is required for WGLC depends upon the extent of changes, etc.) Aug Draft submitted to IESG Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Jun 15 01:38:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24634 for ; Sat, 15 Jun 2002 01:38:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA04228 for midcom-archive@odin.ietf.org; Sat, 15 Jun 2002 01:39:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04120; Sat, 15 Jun 2002 01:34:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04005 for ; Sat, 15 Jun 2002 01:34:33 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24532 for ; Sat, 15 Jun 2002 01:33:55 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5F5Y4s25240; Sat, 15 Jun 2002 00:34:04 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 00:33:51 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C625@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Juergen Quittek'" , "Elwyn Davies" , "'midcom@ietf.org'" Subject: RE: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-pro tocol-eval-00 .txt Date: Sat, 15 Jun 2002 00:33:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2142E.3B322B70" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2142E.3B322B70 Content-Type: text/plain; charset="iso-8859-1" Hi all, Just a few notes (as indicated by [MB] on how the issues raised here are handled in the updated -01 draft): Mary. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Thursday, May 30, 2002 1:44 PM To: Davies, Elwyn [HAL02:0S00:EXCH]; 'midcom@ietf.org' Subject: Re: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-protocol-eval-00 .txt Hi Elwyn, Thank you for your comments. Please see my answers below. --On 30 May 2002 14:48 +0100 Elwyn Davies wrote: > > Hi. > > Some thoughts on the SNMP evaluation part: > - There are more areas than just security where only SNMPv3 > can meet the requirements. Which areas? Do you mean the two you mention below (INFORMS, not extensively tested)? [MB] Per the comment wrt 2.1.7, I did update the conclusion to reflect that SNMPv3 is required for more than the security requirements. > - The very simple and unextendable semantics of the SNMP > protocol (just GET/SET/INFORM verbs) may be found to be > restrictive for the mechanisms needed for Midcom. I don't think so. Can you give an example? I agree that this restriction might become a bit inconvenient, but I do not see any requirement that is not met because of it. > - SNMP message transport uses UDP when IP protocols are used > (ie essentially always). This means that message delivery > is unreliable which has some knock on effects: > - The Midcom protocol would have to achieve reliability for > itself above the SNMP layer Typically an SNMP stack includes some reliability mechanisms "above" SNMP for exactly solving this problem. Is it intentional, that there is no reliability requirement for the midcom protocol? > - The Midcom protocol would have to be constructed to be > be idempotent with respect to the MIB Module which > implements the Midcom communication, because > acknowledgements are just as unreliable as original > messages. This means that any of the commands could be > executed more than once as a result of retransmissions > before an acknowledgement gets through. Yes, this is a typical problem with SNMP. However, typically it is solved case by case. Most cases can be solved by a good MIB module design that considers this fact. The remaining cases have to be covered by the SNMP agent implementation at the midcom server. > - TRAP messages cannot be realistically used to for the > midbox -> agent direction as they are unacknowledged > - Instead need to use acknowledged INFORMs available > only in v3. I disagree. I think that unacknowledged v2 notifications are sufficient (and meet the requirements). Of course INFORMs are more desirable. [MB] I have updated requirement 2.1.7 to indicated that INFORMs are more desirable. Let me know if there is an implicit need for TRAP for other requirements, thus I would need to update those, as well. > Versions 1 and 2 of SNMP have not been used for > configuration purposes (only GET/TRAP verbs used) because > of obvious concerns about security: Network managers may > have qualms about SNMPv3 until it has been extensively tested, > which might slow up the deployment of Midcom if it uses SNMPv3. Just compare deployment and testing of SNMPv3 to the other protocols that have been suggested. It might turn out to be the one with the most practical experience. [MB] I have updated the conclusion with regards to SNMPv3. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Regards, > Elwyn Davies > ---------------------------------------------------------------------------- ------ > > Elwyn B Davies > > Routing and Addressing Strategy Prime > Portfolio Integration Solutions Ready > > Nortel Networks plc Email: elwynd@nortelnetworks.com > Harlow Laboratories ESN 6-742-5498 > London Road, Harlow, Direct Line +44-1279-405498 > Essex, CM17 9NA, UK Fax +44-1279-402047 > Registered Office: Maidenhead Office Park, Westacott Way, > Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH > ---------------------------------------------------------------------------- > This message may contain information proprietary to Nortel Networks plc so any > unauthorised disclosure, copying or distribution of its contents is strictly prohibited. > ---------------------------------------------------------------------------- > "The Folly is mostly mine" > and the opinions are mine and not those of my employer. > ============================================================================ ====== > > > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C2142E.3B322B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Comments on SNMP evaluation in = draft-ietf-midcom-protocol-eval-00 .txt

Hi all,

Just a few notes (as indicated by [MB] on how the = issues raised here are handled in the updated -01 draft):

Mary.

-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: Thursday, May 30, 2002 1:44 PM
To: Davies, Elwyn [HAL02:0S00:EXCH]; = 'midcom@ietf.org'
Subject: Re: [midcom] Comments on SNMP evaluation = in
draft-ietf-midcom-protocol-eval-00 .txt

Hi Elwyn,

Thank you for your comments. Please see my answers = below.

--On 30 May 2002 14:48 +0100 Elwyn Davies = wrote:

>
> Hi.
>
> Some thoughts on the SNMP evaluation = part:
> - There are more areas than just security where = only SNMPv3
> can meet the requirements.

Which areas? Do you mean the two you mention below = (INFORMS,
not extensively tested)?

[MB] Per the comment wrt 2.1.7, I did update the = conclusion to reflect that SNMPv3 is required for more than the = security requirements.

> - The very simple and unextendable semantics of = the SNMP
> protocol (just GET/SET/INFORM = verbs) may be found to be
> restrictive for the mechanisms = needed for Midcom.

I don't think so. Can you give an example?

I agree that this restriction might become a = bit
inconvenient, but I do not see any requirement = that
is not met because of it.

> - SNMP message transport uses UDP when IP = protocols are used
>   (ie essentially always). This = means that message delivery
>   is unreliable which has some knock = on effects:
>   - The Midcom protocol would have to = achieve reliability for
>     itself above the SNMP = layer

Typically an SNMP stack includes some reliability = mechanisms
"above" SNMP for exactly solving this = problem.

Is it intentional, that there is no reliability = requirement
for the midcom protocol?

>   - The Midcom protocol would have to = be constructed to be
>     be idempotent with = respect to the MIB Module which
>     implements the Midcom = communication, because
>     acknowledgements are = just as unreliable as original
>     messages. This means = that any of the commands could be
>     executed more than once = as a result of retransmissions
>     before an = acknowledgement gets through.

Yes, this is a typical problem with SNMP. However, = typically
it is solved case by case. Most cases can be solved = by a good
MIB module design that considers this fact. The = remaining cases
have to be covered by the SNMP agent implementation = at the
midcom server.

>   - TRAP messages cannot be = realistically used to for the
>     midbox -> agent = direction as they are unacknowledged
>     - Instead need to use = acknowledged INFORMs available
>     only in v3.

I disagree. I think that unacknowledged v2 = notifications
are sufficient (and meet the requirements). Of = course INFORMs
are more desirable.

[MB] I have updated requirement 2.1.7 to indicated = that INFORMs are more desirable. Let me know if there is an implicit = need for TRAP for other requirements, thus I would need to update = those, as well.

> Versions 1 and 2 of SNMP have not been used = for
> configuration purposes (only GET/TRAP verbs = used) because
> of obvious concerns about security: = Network managers may
> have qualms about SNMPv3 until it has been = extensively tested,
> which might slow up the deployment of Midcom if = it uses SNMPv3.

Just compare deployment and testing of SNMPv3 to the = other
protocols that have been suggested. It might turn = out to be the
one with the most practical experience.

[MB] I have updated the conclusion with regards to = SNMPv3.

> Regards,
> Elwyn Davies
> = ------------------------------------------------------------------------= ----------
>
> Elwyn B Davies
>
>         = Routing and Addressing Strategy Prime
>         = Portfolio = Integration          &= nbsp;        Solutions Ready
>
>         = Nortel Networks = plc           &nb= sp;         Email: = elwynd@nortelnetworks.com
>         = Harlow = Laboratories          =             =        = ESN           &nb= sp;         6-742-5498
>         = London Road, = Harlow,           = ;         Direct = Line           &n= bsp; +44-1279-405498
>         = Essex, CM17 9NA, = UK           &nbs= p;         = Fax           &nb= sp;         = +44-1279-402047
>         = Registered = Office:           = ;           = Maidenhead Office Park, Westacott Way,
>         = Company No. = 3937799           = ;          Maidenhead, = Berkshire, SSL6 3QH
> = ------------------------------------------------------------------------= ----
> This message may contain information = proprietary to Nortel Networks plc so any
> unauthorised disclosure, copying or = distribution of its contents is strictly prohibited.
> = ------------------------------------------------------------------------= ----
> "The Folly is mostly mine"
> and the opinions are mine and not those of my = employer.
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom

------_=_NextPart_001_01C2142E.3B322B70-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Jun 15 01:38:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24651 for ; Sat, 15 Jun 2002 01:38:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA04242 for midcom-archive@odin.ietf.org; Sat, 15 Jun 2002 01:39:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04133; Sat, 15 Jun 2002 01:34:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04012 for ; Sat, 15 Jun 2002 01:34:34 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24534 for ; Sat, 15 Jun 2002 01:33:56 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5F5Y9s25244; Sat, 15 Jun 2002 00:34:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 00:33:56 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C626@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Juergen Quittek'" , "'midcom@ietf.org'" Subject: RE: [midcom] Reminder: Comments due to list on draft-ietf-midcom- protocol-eval -00.txt by Monday June 10th, noon CST Date: Sat, 15 Jun 2002 00:33:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2142E.3E475AB0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2142E.3E475AB0 Content-Type: text/plain; charset="iso-8859-1" Hi all, Just a follow-up on how these comments were handled in the updated document, responses indicated by [MB] below: Mary. -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de] Sent: Monday, June 10, 2002 10:56 AM To: Barnes, Mary [NGC:B602:EXCH]; 'midcom@ietf.org' Subject: Re: [midcom] Reminder: Comments due to list on draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon CST Mary, Here are my comments. First of all I agree to the statement that where SNMP evaluation depends on a proper MIB module definition, "partially met" should be used. 1.1.3, 2nd paragraph: replace "The roles of entities participating in SNMP communication are called from the manager." by "The roles of entities participating in SNMP communication are called manager and agent." [MB] Done. 1.1.3, 3rd paragraph: replace "Although he" by "Although the". [MB] Done. 2.1.3 COPS, editor's note I think COPS meets this requirement. For example the RFC 3084 on COPS-PR exlicitly mentions this. [MB] Removed Editor's note and reworded the text to be consistent with this being supported per RFC 3084: Changed the word "prohibit" to "preclude" and removed "However". 2.1: COPS in general I think it would be helpful to clarify, some COPS restrictions. For example RFC 3084 says: "When a (middlebox) device boots, it opens a COPS connection to its Primary PDP (Midcom agent)." This holds for each agent that wants to send midcom requests to the middlebox. The good point is that agent-PEP associtions survive power-failures. The disadvantage is, that each agent that intends to send midcom requests must be made known to the middlebox by means other than the ones provided by COPS. (Please correct me if I'm wrong.) [MB] There's been no changes as a result of this since there was no list response to this specific comment. If folks would like to see this restriction added, then propose explicit text to the list and highlight whether this restriction applies to a specific requirement. If it doesn't, then overall I can't see the need to add anything to the document to address this. 2.2.2, SNMP We can replace the very generic phrasing by a more specific one: "SNMP explicilty supports managing different device type with different capabilities. First the managed object called sysObjectID from basic MIB-II (RFC1213) identifies the kind of box. For boxes with varying capabilites, SNMP can check the availability of corresponding MIBs." [MB] Done. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 06 June 2002 19:57 -0500 Mary Barnes wrote: > > Hi all, > > Just a reminder that comments on the protocol evaluation draft are due by noon on Monday, June 10th. It's available at: > > http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-00.txt > > The level of discussion on this draft by members of the WG has been rather disquieting. The draft is not incredibly long, with the new material being primarily in the Overview and Conclusion sections. There are a also few areas which definitely need > discussion and WG feedback which are indicated by [Contributor's note: blah...blah...blah] and [Editor's note: yadda...yadda...yadda]. So, please try to set aside 30 minutes and at least review those portions. The objective is for the draft to be > fairly complete and actually undergoing WGLC by the Yokohama meeting, so comments now are definitely preferred over during the WG session or after the Yokohama meeting. > > As a reminder, the remaining schedule for this WG draft is as follows: > > June 14th Second version of draft available. > June 14th-June 21st Mailing list discussion of version 2 of draft. > June 28th Draft ready for WGLC > July 19th WGLC ends > July 26th Updated draft based upon WGLC comments available > July 26th- Aug (whether another iteration is required for WGLC depends upon > the extent of changes, etc.) > Aug Draft submitted to IESG > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 > > ------_=_NextPart_001_01C2142E.3E475AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Reminder: Comments due to list on = draft-ietf-midcom-protocol-eval -00.txt by Monday June 10th, noon = CST

Hi all,

Just a follow-up on how these comments were handled = in the updated document, responses indicated by [MB] below:

Mary.

-----Original Message-----
From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
Sent: Monday, June 10, 2002 10:56 AM
To: Barnes, Mary [NGC:B602:EXCH]; = 'midcom@ietf.org'
Subject: Re: [midcom] Reminder: Comments due to list = on
draft-ietf-midcom-protocol-eval -00.txt by Monday = June 10th, noon CST

Mary,

Here are my comments.

First of all I agree to the statement that where SNMP = evaluation
depends on a proper MIB module definition, = "partially met" should
be used.

1.1.3, 2nd paragraph:
replace "The roles of entities = participating in SNMP
communication are called from the = manager."
by "The roles of entities participating = in SNMP
communication are called manager and = agent."

[MB] Done.

1.1.3, 3rd paragraph:
replace "Although he" by = "Although the".

[MB] Done.

2.1.3 COPS, editor's note
I think COPS meets this requirement. For = example the
RFC 3084 on COPS-PR exlicitly mentions = this.

[MB] Removed Editor's note and reworded the text to = be consistent with this being supported per RFC 3084: Changed the word = "prohibit" to "preclude" and removed = "However".

2.1: COPS in general
I think it would be helpful to clarify, some = COPS
restrictions. For example RFC 3084 says: = "When a
(middlebox) device boots, it opens a COPS = connection
to its Primary PDP (Midcom agent)." This = holds for
each agent that wants to send midcom requests = to the
middlebox. The good point is that agent-PEP = associtions
survive power-failures. The disadvantage is, = that each
agent that intends to send midcom requests = must be made
known to the middlebox by means other than = the ones provided
by COPS.
(Please correct me if I'm wrong.)

[MB] There's been no changes as a result of this = since there was no list response to this specific comment. If = folks would like to see this restriction added, then propose explicit = text to the list and highlight whether this restriction applies to a = specific requirement. If it doesn't, then overall I can't see the = need to add anything to the document to address this.

2.2.2, SNMP
We can replace the very generic phrasing by a = more specific
one:
"SNMP explicilty supports managing = different device type
with different capabilities. First the = managed object called
sysObjectID from basic MIB-II (RFC1213) = identifies the
kind of box. For boxes with varying = capabilites, SNMP can
check the availability of corresponding = MIBs."

[MB] Done.

--On 06 June 2002 19:57 -0500 Mary Barnes = wrote:
>
> Hi all,
>
> Just a reminder that comments on the protocol = evaluation draft are due by noon on Monday, June 10th. It's = available at:

>
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-= protocol-eval-00.txt
>
> The level of discussion on this draft by = members of the WG has been rather disquieting. The draft is not = incredibly long, with the new material being primarily in the Overview = and Conclusion sections. There are a also few areas which definitely = need

> fairly complete and actually undergoing WGLC by = the Yokohama meeting, so comments now are definitely preferred over = during the WG session or after the Yokohama meeting.

>
> As a reminder, the remaining schedule for this = WG draft is as follows:
>
> June 14th       = Second version of draft available.
> June 14th-June 21st Mailing list = discussion of version 2 of draft.
> June 28th       = Draft ready for WGLC
> July 19th       = WGLC ends
> July 26th       = Updated draft based upon WGLC comments available
> July 26th- Aug (whether another iteration is = required for WGLC depends upon
>          = ;       the extent of changes, = etc.)
> Aug     Draft submitted to = IESG
>
> Regards,
> Mary H. Barnes
> mbarnes@nortelnetworks.com
> 972-684-5432
> Wireless 817-703-4806
>
>

------_=_NextPart_001_01C2142E.3E475AB0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sat Jun 15 15:54:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13953 for ; Sat, 15 Jun 2002 15:54:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02503 for midcom-archive@odin.ietf.org; Sat, 15 Jun 2002 15:54:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02372; Sat, 15 Jun 2002 15:50:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02346 for ; Sat, 15 Jun 2002 15:50:55 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13922 for ; Sat, 15 Jun 2002 15:50:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5FJoHr27230 for ; Sat, 15 Jun 2002 15:50:18 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 15:50:01 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A600@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'midcom@ietf.org'" Date: Sat, 15 Jun 2002 15:50:02 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] draft-taylor-midcom-semantics-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org draft-taylor-midcom-semantics-00.txt has been submitted. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Jun 17 07:35:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26842 for ; Mon, 17 Jun 2002 07:35:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07902 for midcom-archive@odin.ietf.org; Mon, 17 Jun 2002 07:36:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07609; Mon, 17 Jun 2002 07:32:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07578 for ; Mon, 17 Jun 2002 07:32:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26651; Mon, 17 Jun 2002 07:32:11 -0400 (EDT) Message-Id: <200206171132.HAA26651@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 17 Jun 2002 07:32:11 -0400 Subject: [midcom] I-D ACTION:draft-stiemerling-midcom-semantics-00.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIDCOM Protocol Semantics Author(s) : M. Stiemerling, J. Quittek Filename : draft-stiemerling-midcom-semantics-00.txt Pages : 21 Date : 14-Jun-02 This memo discusses semantics for a Middlebox Communication (midcom) protocol, without specifing the concrete syntax or any transport protocol. The intention of this memo is to give input to the discussion on midcom protocol semantics and to provide background material for protocol evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stiemerling-midcom-semantics-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stiemerling-midcom-semantics-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020614131319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stiemerling-midcom-semantics-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stiemerling-midcom-semantics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020614131319.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Tue Jun 18 07:28:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13085 for ; Tue, 18 Jun 2002 07:28:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05216 for midcom-archive@odin.ietf.org; Tue, 18 Jun 2002 07:29:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05027; Tue, 18 Jun 2002 07:27:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04971 for ; Tue, 18 Jun 2002 07:27:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12891; Tue, 18 Jun 2002 07:26:54 -0400 (EDT) Message-Id: <200206181126.HAA12891@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: midcom@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 18 Jun 2002 07:26:53 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-01.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Middlebox Communication Working Group of the IETF. Title : MIDCOM Protocol Evaluation Template Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-01.txt Pages : 34 Date : 17-Jun-02 This document provides an evaluation of the applicability of SNMP, RSIP, MEGACO, DIAMETER and COPS as the MIDCOM protocol. A summary of each of the proposed protocols against the MIDCOM requirements and MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-midcom-protocol-eval-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-midcom-protocol-eval-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020617142642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020617142642.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 20 09:38:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29574 for ; Thu, 20 Jun 2002 09:38:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21924 for midcom-archive@odin.ietf.org; Thu, 20 Jun 2002 09:39:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21780; Thu, 20 Jun 2002 09:36:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21749 for ; Thu, 20 Jun 2002 09:36:05 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29435 for ; Thu, 20 Jun 2002 09:35:24 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5KDZ7uF007856 for ; Thu, 20 Jun 2002 06:35:07 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEF17185; Thu, 20 Jun 2002 06:32:36 -0700 (PDT) Message-Id: <5.1.0.14.0.20020620093453.013488f0@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Jun 2002 09:40:28 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Semantics proposals Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org We now have two documents describing proposed semantics for the to-be-defined midcom protocol. They are: http://search.ietf.org/internet-drafts/draft-taylor-midcom-semantics-00.txt http://search.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-00.txt We need to decide whether one or the other is a better match for how we want the protocol to behave, or if the documents can be folded together. Please have a look at the documents and post your thoughts to the mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 20 10:12:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00783 for ; Thu, 20 Jun 2002 10:12:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24261 for midcom-archive@odin.ietf.org; Thu, 20 Jun 2002 10:12:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23870; Thu, 20 Jun 2002 10:05:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23839 for ; Thu, 20 Jun 2002 10:05:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00552 for ; Thu, 20 Jun 2002 10:05:12 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g5KE5LPI017161 for ; Thu, 20 Jun 2002 07:05:21 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEF17626; Thu, 20 Jun 2002 07:01:13 -0700 (PDT) Message-Id: <5.1.0.14.0.20020620100427.01324180@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Jun 2002 10:09:05 -0400 To: midcom@ietf.org From: Melinda Shore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [midcom] Protocol evaluation discussion Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org That is to say, there hasn't been any since the revision of the document was posted. It's my suspicion that not everybody agrees with everything that's in it, but unless they speak up we won't know. Is this document ready for WG last call? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 20 10:33:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01550 for ; Thu, 20 Jun 2002 10:33:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25681 for midcom-archive@odin.ietf.org; Thu, 20 Jun 2002 10:33:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25099; Thu, 20 Jun 2002 10:29:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25057 for ; Thu, 20 Jun 2002 10:29:46 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01399 for ; Thu, 20 Jun 2002 10:29:04 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5KETDK24130; Thu, 20 Jun 2002 16:29:13 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA04111; Thu, 20 Jun 2002 16:24:30 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5F38E3DB53; Thu, 20 Jun 2002 16:24:29 +0200 (CEST) Message-ID: <3D11E59B.7060308@ccrle.nec.de> Date: Thu, 20 Jun 2002 16:24:27 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Protocol evaluation discussion References: <5.1.0.14.0.20020620100427.01324180@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I hope that the cut-off for the discussions on the evaluation draft is on monday? Martin Melinda Shore wrote: > That is to say, there hasn't been any since the revision > of the document was posted. It's my suspicion that not > everybody agrees with everything that's in it, but unless > they speak up we won't know. Is this document ready for > WG last call? > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 20 11:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03737 for ; Thu, 20 Jun 2002 11:44:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00624 for midcom-archive@odin.ietf.org; Thu, 20 Jun 2002 11:45:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00471; Thu, 20 Jun 2002 11:42:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00440 for ; Thu, 20 Jun 2002 11:42:03 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03660 for ; Thu, 20 Jun 2002 11:41:20 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g5KFeguF026785; Thu, 20 Jun 2002 08:40:42 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEF19626; Thu, 20 Jun 2002 08:38:10 -0700 (PDT) Message-Id: <5.1.0.14.0.20020620114500.01342d90@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Jun 2002 11:46:01 -0400 To: Martin Stiemerling From: Melinda Shore Subject: Re: [midcom] Protocol evaluation discussion Cc: midcom@ietf.org In-Reply-To: <3D11E59B.7060308@ccrle.nec.de> References: <5.1.0.14.0.20020620100427.01324180@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org At 04:24 PM 6/20/02 +0200, Martin Stiemerling wrote: >I hope that the cut-off for the discussions on the evaluation draft is on monday? I think it would be more correct to say that it's Monday-ish. Any issues that remain unresolved on Monday would need to be closed before discussion would be ended. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Jun 20 12:50:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06340 for ; Thu, 20 Jun 2002 12:50:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05884 for midcom-archive@odin.ietf.org; Thu, 20 Jun 2002 12:51:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05743; Thu, 20 Jun 2002 12:49:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05703 for ; Thu, 20 Jun 2002 12:49:43 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06164 for ; Thu, 20 Jun 2002 12:49:02 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5KGj8S29187; Thu, 20 Jun 2002 11:45:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 11:44:54 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C64E@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Melinda Shore'" , Martin Stiemerling Cc: midcom@ietf.org Subject: RE: [midcom] Protocol evaluation discussion Date: Thu, 20 Jun 2002 11:44:53 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Hi all, Yes, we have the cutoff for mailing list discussion to complete at noon on Monday, June 24th. We can certainly continue discussion a bit beyond that to resolve the issues, but if we want to get another rev of the draft out prior to Yokohama, it must be submitted by noon EST on July 1st. Thus, as Melinda suggests we should really be discussing things now and should be able to close off at least the issues identified in the email: http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02331.htm l Regards, Mary. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Thursday, June 20, 2002 10:46 AM To: Martin Stiemerling Cc: midcom@ietf.org Subject: Re: [midcom] Protocol evaluation discussion At 04:24 PM 6/20/02 +0200, Martin Stiemerling wrote: >I hope that the cut-off for the discussions on the evaluation draft is on monday? I think it would be more correct to say that it's Monday-ish. Any issues that remain unresolved on Monday would need to be closed before discussion would be ended. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Jun 21 06:19:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06223 for ; Fri, 21 Jun 2002 06:19:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02616 for midcom-archive@odin.ietf.org; Fri, 21 Jun 2002 06:20:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02209; Fri, 21 Jun 2002 06:18:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02138 for ; Fri, 21 Jun 2002 06:18:14 -0400 (EDT) Received: from protactinium.btinternet.com (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06158 for ; Fri, 21 Jun 2002 06:17:28 -0400 (EDT) Received: from host62-6-98-51.in-addr.btopenworld.com ([62.6.98.51] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #8) id 17LLUV-0006gp-00; Fri, 21 Jun 2002 11:18:07 +0100 Message-ID: <005f01c2190d$31e42620$0200000a@tkw> From: "Pete Cordell" To: Cc: "Mary Barnes" Date: Fri, 21 Jun 2002 11:18:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] SNMP - using as a transport layer? Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit I'm not expert on SNMP, so this may not be a valid comment, but I'll ask it anyway... A number of comments in the evaluation document indicate that SNMP is compliant subject to a suitable MIB being defined (P+). I'm just wondering if in those instances we would not just be using SNMP effectively as a transport layer for conveying opaque data (which is what SNMP is essentially about). I guess SNMP offers versioning, security and a format for parameters. But something like TLS (or IPSec) would offer security and specifying versioning and parameter formats isn't that hard. I'm just wondering then if SNMP is offering as much as it first appears !!! Regards, Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Jun 21 10:41:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15130 for ; Fri, 21 Jun 2002 10:41:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14874 for midcom-archive@odin.ietf.org; Fri, 21 Jun 2002 10:42:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14717; Fri, 21 Jun 2002 10:39:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14687 for ; Fri, 21 Jun 2002 10:39:38 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15004 for ; Fri, 21 Jun 2002 10:38:56 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g5LEb4K80110; Fri, 21 Jun 2002 16:37:04 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA16794; Fri, 21 Jun 2002 16:32:16 +0200 Received: from ccrle.nec.de (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 13FC71B975; Fri, 21 Jun 2002 16:32:16 +0200 (CEST) Message-ID: <3D1338F1.7000302@ccrle.nec.de> Date: Fri, 21 Jun 2002 16:32:17 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell Cc: midcom@ietf.org, Mary Barnes Subject: Re: [midcom] SNMP - using as a transport layer? References: <005f01c2190d$31e42620$0200000a@tkw> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 7bit Pete Cordell wrote: > I'm not expert on SNMP, so this may not be a valid comment, but I'll ask it > anyway... > > A number of comments in the evaluation document indicate that SNMP is > compliant subject to a suitable MIB being defined (P+). > > I'm just wondering if in those instances we would not just be using SNMP > effectively as a transport layer for conveying opaque data (which is what > SNMP is essentially about). What about MEGACO? You have to define a MIDCOM package (in contrast to a SNMP MIB) , so this is another transport layer protocol? In my opinion MEGACO and SNMP do offer more than just a simple "transport layer like" service. > > I guess SNMP offers versioning, security and a format for parameters. But > something like TLS (or IPSec) would offer security and specifying versioning > and parameter formats isn't that hard. > > I'm just wondering then if SNMP is offering as much as it first appears !!! Discusssions on this mailing list showed that you are not the only one wondering. Is it really that surprising? SNMP is a management protocol that is successfully used for more than a decade and it is built into most of today's IP devices. Why do you assume it would not be very well suited for performing management tasks? Regards Juergen and Martin _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Jun 21 12:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20836 for ; Fri, 21 Jun 2002 12:27:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22336 for midcom-archive@odin.ietf.org; Fri, 21 Jun 2002 12:28:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22284; Fri, 21 Jun 2002 12:26:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22257 for ; Fri, 21 Jun 2002 12:26:42 -0400 (EDT) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20775 for ; Fri, 21 Jun 2002 12:26:00 -0400 (EDT) From: James_Renkel@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5LGQYj05464 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Fri, 21 Jun 2002 09:26:35 -0700 (PDT) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5LGQVI25705; Fri, 21 Jun 2002 09:26:31 -0700 (PDT) Subject: Re: [midcom] SNMP - using as a transport layer? To: Martin Stiemerling Cc: Pete Cordell , midcom@ietf.org, Mary Barnes Date: Fri, 21 Jun 2002 11:26:02 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org On 06/21/2002, at 09:32:17 A.M., Martin Steirmerling wrote, in part: > SNMP is a management protocol that is successfully used for > more than a decade and it is built into most of today's > IP devices. I *WISH* my home gateway / router had SNMP for management. My experience is that most of these devices, which are, IMHO, one of the largest populations of devices that are MIDCOM "candidates", use HTTP rather than SNMP for management. > Why do you assume it would not be very well suited for > performing management tasks? I guess I don't see MIDCOM's use between applications / agents and middleboxes as a management activity, more of an operational activity. The issue to my mind here is do we: a) take an existing protocol that has the basic transport, security, etc., requirements satisfied but has no capabilities for middlebox operation, and add those; or b) take an existing protocol that has middlebox operational capabilities but does not completely satisfy the secutiry requirements, and beef up the security. It seems to me that the latter is a more appropriate course of action for this group. But I could be wrong. :-) Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Jun 21 13:14:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22769 for ; Fri, 21 Jun 2002 13:14:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25769 for midcom-archive@odin.ietf.org; Fri, 21 Jun 2002 13:14:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25681; Fri, 21 Jun 2002 13:13:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25651 for ; Fri, 21 Jun 2002 13:13:04 -0400 (EDT) Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22706 for ; Fri, 21 Jun 2002 13:12:22 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5LH10227562; Fri, 21 Jun 2002 13:01:00 -0400 (EDT) Message-Id: <200206211701.g5LH10227562@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: James_Renkel@3com.com cc: Martin Stiemerling , Pete Cordell , midcom@ietf.org, Mary Barnes Subject: Re: [midcom] SNMP - using as a transport layer? In-reply-to: (Your message of "Fri, 21 Jun 2002 11:26:02 CDT.") Date: Fri, 21 Jun 2002 13:01:00 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org > I *WISH* my home gateway / router had SNMP for management. My experience > is that most of these devices, which are, IMHO, one of the largest > populations of devices that are MIDCOM "candidates", use HTTP rather > than SNMP for management. MIDCOM isn't going to solve any problems for home networks anyway. The best that can be hoped for is for MIDCOM to solve problems for the few server apps that can afford to add MIDCOM support. The only way to solve the problem in general is to get rid of NATs. It's important to not lose sight of this. Keith _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Jun 21 13:45:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24107 for ; Fri, 21 Jun 2002 13:45:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27706 for midcom-archive@odin.ietf.org; Fri, 21 Jun 2002 13:46:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27668; Fri, 21 Jun 2002 13:45:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27639 for ; Fri, 21 Jun 2002 13:44:59 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24045 for ; Fri, 21 Jun 2002 13:44:17 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28447 for ; Fri, 21 Jun 2002 13:43:10 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28428 for ; Fri, 21 Jun 2002 13:43:10 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [midcom] SNMP - using as a transport layer? Date: Fri, 21 Jun 2002 11:44:57 -0600 Message-ID: Thread-Topic: [midcom] SNMP - using as a transport layer? Thread-Index: AcIZR7PmL/oSLr8SRJyDzAXpeMNQBAAAwPMQ From: "Zmolek, Andrew (Andrew)" To: "Keith Moore" , Cc: "Martin Stiemerling" , "Pete Cordell" , , "Mary Barnes" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA27640 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: midcom@ietf.org Content-Transfer-Encoding: 8bit Keith Moore asserts: > The only way to solve the problem in general is to get rid of NATs. > It's important to not lose sight of this. It's a stretch to suggest that simple expulsion is the only way to skin the NAT cat. But it should be acknowledged that it remains politically incorrect in the IETF to suggest solutions that condone any long-term model for address domain traversal, whether between v4 address realms directly or with one or more v6 realms. While it would appear that the market has already made a decision on the issue or address domain traversal in general, the IETF community at large does not concede that point. In fact, there is a great deal of activism aimed at reversing the market decision on the grounds of technical purity. As unrealistic as this might be, this is the political environment in which we must work. But midcom is just one recent example of how this political appeasement affects the technical engineering which was once the hallmark of the IETF. Groups like geopriv and opes and ieprep are also burdened with the misfortune of having chosen a technical problem encumbered by well-meaning political activism around issues like privacy and the fabled "end-to-end" principle, both of which trump existing, demonstrated market needs partially satisfied by proprietary or external solutions. So let's not loose sight of the fact that political activism, not fundamental engineering, is the primary constraint in play. Those who miss this point have already wasted many man-hours on workable solutions that happen to be politically unacceptable here. Not that there's anything wrong with that :-) --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 sip:zmolek@avaya.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@ns.ietf.org Fri Jun 21 13:52:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24455 for ; Fri, 21 Jun 2002 13:52:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27923 for midcom-archive@odin.ietf.org; Fri, 21 Jun 2002 13:53:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27853; Fri, 21 Jun 2002 13:50:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27824 for ; Fri, 21 Jun 2002 13:50:33 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24264 for ; Fri, 21 Jun 2002 13:49:50 -0400 (EDT) Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g5LHnvBW000463; Fri, 21 Jun 2002 10:49:57 -0700 (PDT) Received: from spandex.cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEF55054; Fri, 21 Jun 2002 10:47:04 -0700 (PDT) Message-Id: <5.1.0.14.0.20020621135411.00aafe50@localhost> X-Sender: mshore@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Jun 2002 13:54:52 -0400 To: "Zmolek, Andrew (Andrew)" From: Melinda Shore Subject: RE: [midcom] SNMP - using as a transport layer? Cc: