From daemon@optimus.ietf.org Thu Aug 1 12:55:19 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 MAA07006 for ; Thu, 1 Aug 2002 12:55:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09421 for midcom-archive@odin.ietf.org; Thu, 1 Aug 2002 12:56: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 MAA09316; Thu, 1 Aug 2002 12:51:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09287 for ; Thu, 1 Aug 2002 12:51:48 -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 MAA06847 for ; Thu, 1 Aug 2002 12:50:38 -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 g71GpOD15583; Thu, 1 Aug 2002 11:51:24 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 11:51:10 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7F6@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , midcom Subject: RE: [midcom] Comments on protocol evaluation draft Date: Thu, 1 Aug 2002 11:51:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2397B.A33EAEB0" 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_01C2397B.A33EAEB0 Content-Type: text/plain; charset="iso-8859-1" Jim, Thanks for your comments. I've delayed replying to your email in the hopes that this would generate some additional discussion, but since there has been no responses, and the deadline for feedback on the document is tomorrow (Friday, August 2nd), I thought I would respond with a somewhat constructive suggestion on how to allay some of your concerns. I have some specific responses that I've embedded below, as indicated by [MB], as well as a general proposal to add some specific text to the Overview section describing the intent of Section 3 as follows: Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Wednesday, July 31, 2002 2:36 PM To: midcom Subject: [midcom] Comments on protocol evaluation draft Middlebox experts, Overall, I think this work is great. Mary Barnes should be complimented and thanked for pulling this together. While I have a few small issues with the facts or claims in Sections 1 and 2, my real concern is with Section 3. The concern is not so much with the facts presented there, but with the way they might be interpreted *as presented there*. What the MIDCOM WG has tried to do in this protocol evaluation, and I think largely succeeded in doing, is to compare the frameworks and capabilities of a number of protocols to the MIDCOM requirements and framework (Many of the MIDCOM requirements addressed the matching of MIDCOM and protocol framework elements.). If you look at this on a MIDCOM requirement by requirement (and / or framework element by framework element basis) against the framework elements and protocol capabilities of a single protocol, there are a number of possibilities: - The protocol's framework elements and protocol capabilities match exactly (or extremely close to exactly) the MIDCOM requirement or framework element. GREAT! This is what we were looking and hoping for. - The protocol does not have any framework elements or protocol capabilities that address the MIDCOM requirement or framework element. Not so great, but, again, this is what we were looking (but not hoping) for. - The protocol's framework elements and protocol capabilities somewhat match the MIDCOM requirement or framework element. Here's where I start to have some problems. Where the match is not exact, there's two possibilities (or a combination of them): - In the individual protocol evaluation, a proposal is made to modify or extend the protocol's mandatory framework elements or protocol capabilities, or to modify optional framework elements or protocol capabilities, to match the MIDCOM requirement or framework element. From our perspective, this is good, but it may not be so good to other users of the protocol. If the protocol is single purpose with few users at this time and no guarantee of forward compatibility (e.g., RSIP), modifying the protocol ain't so bad. But if the protocol has other purposes, many users, or the guarantee of forward compatibility, this may not be so good (The implications of "other purposes" and "many users" is hopefully obvious. I'll return to the issue of guaranteed forward compatibility below.). Also, extending the protocol with optional framework elements and capabilities is probably not bad. [MB] My view would be that P+ and P should be used to distinguish between the things that could impact other users of the protocol. For example, extensions that are inline with the general intent of the original protocol, that don't cause any compatibility problems with existing uses of that protocol should be P+. However, if the extensions would impact existing users (i.e. the changes required for MIDCOM also require changes to other users of the protocol), then it should only be a P at the most. [/MB] - Alternately or in combination, a proposal is made to "think about the MIDCOM requirement or framework element in a different way" so that the match is exact or almost so. I think there's quite a bit of this going on in the protocol evaluations. Taken individually, if the proposed change in thinking is not large, this might not be bad. Taken together, if the sum of all such changed thinking for a protocol is not large, this may also be not bad. [MB] My view would be that at most these cases can only be P at most, and perhaps some of them should be Fs. I do agree that some of the evaluations erred on the liberal side. [/MB] But, if taken together the sum of all such proposals for a given protocol is large, then essentially this says that the MIDCOM framework or requirements would need some rather extensive revision to match the protocol's framework and capabilities. That's probably bad. [MB] I still think that the categories of P+ versus P helps from this perspective. [/MB] For both of the above alternatives, the protocol would have been scored as partially matching the MIDCOM requirements. But the distinction between the two alternatives is lost in the scoring, so that the count of the partial matches can not be easily evaluated as being overall good or overall bad. [MB] Per my comments above, I think the intent was for there to be a clear distinction between P and P+ for this purpose. Can you point out some of the specific ones for which you see this problem? I believe that we should all be in agreement on the P+'s. Whether some of the Ps should really be Fs is another point for discussion. [/MB] I didn't go through the exercise (and maybe I should) of marking each partial requirements match as one or the other of the above and counting the number of each alternative for each protocol, but my gut feeling is that we may have a problem here. [MB] Please do go through this exercise. P+ should all clearly be things that don't break other users. [/MB] Returning to the issue of guaranteed forward compatibility, if the proposal is to modify or extend mandatory framework elements or protocol capabilities, or to modify optional elements or capabilities, then all other users of the protocol, or its modified optional elements and capabilities, would have to support the changes that were made to the protocol for MIDCOM. Depending on the size of these changes, this may not be acceptable to the protocols other users. And we probably shouldn't consider these types of changes without those users buying into them. Again, I didn't specifically count the applicable scorings here and maybe I should have, but in this case I don't really think we have much of a problem. Another issue that I have with the whole evaluation is that it did not consider the impact of a protocol's mandatory framework elements and protocol capabilities that are *not* required by MIDCOM. The problem here is that middleboxes and agents / applications may have to support these even though they're not used. If the protocol has another simultaneous use in the middlebox or agent / application, then the impact is not so bad, in fact there may be no impact at all. But if the use of the protocol is its first use in the middlebox or agent / application, then I think we have to seriously consider this potential problem. This problem relates to, but is not exclusive to, library and source code reuse, which in general is desirable. But if the library or source code has a lot of unused capabilities, and the MIDCOM implementer can't (afford to) remove them, then this will place an unnecessary cost on implementations. [MB] I do think that the Diameter evaluation did bring forth this issue, but certainly there was no specific requirement, so it's not captured in the T/P+/P/F totals. However, it is brought out in the textual summary. I do think that some of this is brought out with the proposed changes I posted to the list for the SNMP, MEGACO and COPS descriptions in section 1. [/MB] I have no idea how to evaluate this in advance, but I have a gut feeling we may have a *real* problem here. I am certainly open to ideas on how to evaluate this in advance. But maybe we'll just have to wait for specific protocol proposals to be able to see through this issue. [MB] I don't think your alone in having some concerns about the process that the WG is using, however, per my proposal above, this document is just one piece of information that goes into the overall Protocol decision. This needs to be considered along with the semantic analysis which is underway. We had this discussion right after IETF-53, and the decision was that this document could be worked in parallel with the semantic analysis, but I think there was general agreement that the semantic analysis was an equally (and for some folks) more important part of the overall protocol decision process. [/MB] So, overall, I think the evaluation is good, but I have some issues with how the facts presented, especially the summary counts, may be interpreted. [MB] Per my comments above, the document should be explicit about P+ versus P any specific concerns should be raised. As a minimum, I'm proposing to add the text described above to ensure that the intent of Section 3 is clear. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C2397B.A33EAEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Comments on protocol evaluation draft

Jim,

Thanks for your comments.  I've delayed replying = to your email in the hopes that this would generate some additional = discussion, but since there has been no responses, and the deadline for = feedback on the document is tomorrow (Friday, August 2nd), I thought I = would respond with a somewhat constructive suggestion on how to allay = some of your concerns. I have some specific responses that I've = embedded below, as indicated by [MB], as well as a general proposal to = add some specific text to the Overview section describing the intent of = Section 3 as follows:



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

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: Wednesday, July 31, 2002 2:36 PM
To: midcom
Subject: [midcom] Comments on protocol evaluation = draft


Middlebox experts,

Overall, I think this work is great. Mary Barnes = should be complimented
and thanked for pulling this together.

While I have a few small issues with the facts or = claims in Sections
1 and 2, my real concern is with Section 3. The = concern is not so much
with the facts presented there, but with the way = they might be
interpreted *as presented there*.

What the MIDCOM WG has tried to do in this protocol = evaluation, and I
think largely succeeded in doing, is to compare the = frameworks and
capabilities of a number of protocols to the MIDCOM = requirements and
framework (Many of the MIDCOM requirements addressed = the matching of
MIDCOM and protocol framework elements.). If you = look at this on a MIDCOM
requirement by requirement (and / or framework = element by framework
element basis) against the framework elements and = protocol capabilities
of a single protocol, there are a number of = possibilities:

- The protocol's framework elements and protocol = capabilities match
exactly (or extremely close to exactly) the MIDCOM = requirement or
framework element. GREAT! This is what we were = looking and hoping for.

- The protocol does not have any framework elements = or protocol
capabilities that address the MIDCOM requirement or = framework element.
Not so great, but, again, this is what we were = looking (but not hoping)
for.

- The protocol's framework elements and protocol = capabilities somewhat
match the MIDCOM requirement or framework element. = Here's where I start
to have some problems.

Where the match is not exact, there's two = possibilities (or a
combination of them):

- In the individual protocol evaluation, a proposal = is made to modify
or extend the protocol's mandatory framework = elements or protocol
capabilities, or to modify optional framework = elements or protocol
capabilities, to match the MIDCOM requirement or = framework element.
From our perspective, this is good, but it may not = be so good to other
users of the protocol. If the protocol is single = purpose with few users
at this time and no guarantee of forward = compatibility (e.g., RSIP),
modifying the protocol ain't so bad. But if the = protocol has other
purposes, many users, or the guarantee of forward = compatibility, this
may not be so good (The implications of "other = purposes" and "many
users" is hopefully obvious. I'll return to the = issue of guaranteed
forward compatibility below.). Also, extending the = protocol with
optional framework elements and capabilities is = probably not bad.

[MB] My view would be that P+ and P should be used to = distinguish between the things that could impact other users of the = protocol. For example, extensions that are inline with the general = intent of the original protocol, that don't cause any compatibility = problems with existing uses of that protocol should be P+.  = However, if the extensions would impact existing users (i.e. the = changes required for MIDCOM also require changes to other users of the = protocol), then it should only be a P at the most.

[/MB]

- Alternately or in combination, a proposal is made = to "think about the
MIDCOM requirement or framework element in a = different way" so that the
match is exact or almost so. I think there's quite a = bit of this going
on in the protocol evaluations. Taken individually, = if the proposed
change in thinking is not large, this might not be = bad. Taken together,
if the sum of all such changed thinking for a = protocol is not large,
this may also be not bad.

[MB] My view would be that at most these cases can = only be P at most, and perhaps some of them should be Fs.  I do = agree that some of the evaluations erred on the liberal side.  =

[/MB]

But, if taken together the sum of all such proposals = for a given
protocol is large, then essentially this says that = the MIDCOM framework
or requirements would need some rather extensive = revision to match the
protocol's framework and capabilities. That's = probably bad.
[MB] I still think that the categories of P+ versus = P helps from this perspective. [/MB]

For both of the above alternatives, the protocol = would have been scored
as partially matching the MIDCOM requirements. But = the distinction
between the two alternatives is lost in the scoring, = so that the count of
the partial matches can not be easily evaluated as = being overall good or
overall bad.

[MB] Per my comments above, I think the intent was = for there to be a clear distinction between P and P+ for this = purpose.  Can you point out some of the specific ones for which = you see this problem?  I believe that we should all be in = agreement on the P+'s.  Whether some of the Ps should really be Fs = is another point for discussion.

[/MB]

I didn't go through the exercise (and maybe I should) = of marking each
partial requirements match as one or the other of = the above and
counting the number of each alternative for each = protocol, but my gut
feeling is that we may have a problem here.
[MB] Please do go through this exercise. P+ should = all clearly be things that don't break other users.
[/MB]

Returning to the issue of guaranteed forward = compatibility, if the
proposal is to modify or extend mandatory framework = elements or protocol
capabilities, or to modify optional elements or = capabilities, then all
other users of the protocol, or its modified = optional elements and
capabilities, would have to support the changes that = were made to the
protocol for MIDCOM. Depending on the size of these = changes, this may
not be acceptable to the protocols other users. And = we probably
shouldn't consider these types of changes without = those users buying
into them. Again, I didn't specifically count the = applicable scorings
here and maybe I should have, but in this case I = don't really think we
have much of a problem.

Another issue that I have with the whole evaluation = is that it did not
consider the impact of a protocol's mandatory = framework elements and
protocol capabilities that are *not* required by = MIDCOM. The problem
here is that middleboxes and agents / applications = may have to support
these even though they're not used. If the protocol = has another
simultaneous use in the middlebox or agent / = application, then the
impact is not so bad, in fact there may be no impact = at all. But if
the use of the protocol is its first use in the = middlebox or agent /
application, then I think we have to seriously = consider this potential
problem. This problem relates to, but is not = exclusive to, library and
source code reuse, which in general is desirable. = But if the library or
source code has a lot of unused capabilities, and = the MIDCOM implementer
can't (afford to) remove them, then this will place = an unnecessary cost
on implementations.

[MB] I do think that the Diameter evaluation did = bring forth this issue, but certainly there was no specific = requirement, so it's not captured in the T/P+/P/F totals. However, it = is brought out in the textual summary.  I do think that some of = this is brought out with the proposed changes I posted to the list for = the SNMP, MEGACO and COPS descriptions in section 1.

[/MB]

I have no idea how to evaluate this in advance, but I = have a gut feeling
we may have a *real* problem here. I am certainly = open to ideas on how
to evaluate this in advance. But maybe we'll just = have to wait for
specific protocol proposals to be able to see = through this issue.

[MB] I don't think your alone in having some concerns = about the process that the WG is using, however, per my proposal above, = this document is just one piece of information that goes into the = overall Protocol decision.  This needs to be considered along with = the semantic analysis which is underway.  We had this discussion = right after IETF-53, and the decision was that this document could be = worked in parallel with the semantic analysis, but I think there was = general agreement that the semantic analysis was an equally (and for = some folks) more important part of the overall protocol decision = process.

[/MB]

So, overall, I think the evaluation is good, but I = have some issues with
how the facts presented, especially the summary = counts, may be
interpreted.

[MB] Per my comments above, the document should be = explicit about P+ versus P any specific concerns should be = raised.  As a minimum, I'm proposing to add the text described = above to ensure that the intent of Section 3 is clear.


Comments expected and welcome.

Jim


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

------_=_NextPart_001_01C2397B.A33EAEB0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Aug 1 13:05:12 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 NAA07490 for ; Thu, 1 Aug 2002 13:05:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10518 for midcom-archive@odin.ietf.org; Thu, 1 Aug 2002 13:06: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 NAA10021; Thu, 1 Aug 2002 13:00: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 NAA09921 for ; Thu, 1 Aug 2002 13:00:24 -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 MAA07227 for ; Thu, 1 Aug 2002 12:59:14 -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 g71GxvD20470; Thu, 1 Aug 2002 11:59:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 11:59:43 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C7F7@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Subject: RE: [midcom] Comments on protocol evaluation draft Date: Thu, 1 Aug 2002 11:59:41 -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, Sorry, I hit SEND too soon, before I had added the proposed text (and converted to Plain text): "Section 3 provides a summary of the evaluation. A numerical breakdown of the applicability of the requirements, to the each of the protocols, for the following categories is provided: Fully met, Partially met through the use of extensions, Partially met through other changes to the protocol, or Failing to be met. This summary is not meant to provide a conclusive statement of the suitability of the protocols, but rather to provide information to be considered as input to the protocol decision process." Mary. -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Thursday, August 01, 2002 11:51 AM To: 'James_Renkel@3com.com'; midcom Subject: RE: [midcom] Comments on protocol evaluation draft Jim, Thanks for your comments. I've delayed replying to your email in the hopes that this would generate some additional discussion, but since there has been no responses, and the deadline for feedback on the document is tomorrow (Friday, August 2nd), I thought I would respond with a somewhat constructive suggestion on how to allay some of your concerns. I have some specific responses that I've embedded below, as indicated by [MB], as well as a general proposal to add some specific text to the Overview section describing the intent of Section 3 as follows: Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Wednesday, July 31, 2002 2:36 PM To: midcom Subject: [midcom] Comments on protocol evaluation draft Middlebox experts, Overall, I think this work is great. Mary Barnes should be complimented and thanked for pulling this together. While I have a few small issues with the facts or claims in Sections 1 and 2, my real concern is with Section 3. The concern is not so much with the facts presented there, but with the way they might be interpreted *as presented there*. What the MIDCOM WG has tried to do in this protocol evaluation, and I think largely succeeded in doing, is to compare the frameworks and capabilities of a number of protocols to the MIDCOM requirements and framework (Many of the MIDCOM requirements addressed the matching of MIDCOM and protocol framework elements.). If you look at this on a MIDCOM requirement by requirement (and / or framework element by framework element basis) against the framework elements and protocol capabilities of a single protocol, there are a number of possibilities: - The protocol's framework elements and protocol capabilities match exactly (or extremely close to exactly) the MIDCOM requirement or framework element. GREAT! This is what we were looking and hoping for. - The protocol does not have any framework elements or protocol capabilities that address the MIDCOM requirement or framework element. Not so great, but, again, this is what we were looking (but not hoping) for. - The protocol's framework elements and protocol capabilities somewhat match the MIDCOM requirement or framework element. Here's where I start to have some problems. Where the match is not exact, there's two possibilities (or a combination of them): - In the individual protocol evaluation, a proposal is made to modify or extend the protocol's mandatory framework elements or protocol capabilities, or to modify optional framework elements or protocol capabilities, to match the MIDCOM requirement or framework element. From our perspective, this is good, but it may not be so good to other users of the protocol. If the protocol is single purpose with few users at this time and no guarantee of forward compatibility (e.g., RSIP), modifying the protocol ain't so bad. But if the protocol has other purposes, many users, or the guarantee of forward compatibility, this may not be so good (The implications of "other purposes" and "many users" is hopefully obvious. I'll return to the issue of guaranteed forward compatibility below.). Also, extending the protocol with optional framework elements and capabilities is probably not bad. [MB] My view would be that P+ and P should be used to distinguish between the things that could impact other users of the protocol. For example, extensions that are inline with the general intent of the original protocol, that don't cause any compatibility problems with existing uses of that protocol should be P+. However, if the extensions would impact existing users (i.e. the changes required for MIDCOM also require changes to other users of the protocol), then it should only be a P at the most. [/MB] - Alternately or in combination, a proposal is made to "think about the MIDCOM requirement or framework element in a different way" so that the match is exact or almost so. I think there's quite a bit of this going on in the protocol evaluations. Taken individually, if the proposed change in thinking is not large, this might not be bad. Taken together, if the sum of all such changed thinking for a protocol is not large, this may also be not bad. [MB] My view would be that at most these cases can only be P at most, and perhaps some of them should be Fs. I do agree that some of the evaluations erred on the liberal side. [/MB] But, if taken together the sum of all such proposals for a given protocol is large, then essentially this says that the MIDCOM framework or requirements would need some rather extensive revision to match the protocol's framework and capabilities. That's probably bad. [MB] I still think that the categories of P+ versus P helps from this perspective. [/MB] For both of the above alternatives, the protocol would have been scored as partially matching the MIDCOM requirements. But the distinction between the two alternatives is lost in the scoring, so that the count of the partial matches can not be easily evaluated as being overall good or overall bad. [MB] Per my comments above, I think the intent was for there to be a clear distinction between P and P+ for this purpose. Can you point out some of the specific ones for which you see this problem? I believe that we should all be in agreement on the P+'s. Whether some of the Ps should really be Fs is another point for discussion. [/MB] I didn't go through the exercise (and maybe I should) of marking each partial requirements match as one or the other of the above and counting the number of each alternative for each protocol, but my gut feeling is that we may have a problem here. [MB] Please do go through this exercise. P+ should all clearly be things that don't break other users. [/MB] Returning to the issue of guaranteed forward compatibility, if the proposal is to modify or extend mandatory framework elements or protocol capabilities, or to modify optional elements or capabilities, then all other users of the protocol, or its modified optional elements and capabilities, would have to support the changes that were made to the protocol for MIDCOM. Depending on the size of these changes, this may not be acceptable to the protocols other users. And we probably shouldn't consider these types of changes without those users buying into them. Again, I didn't specifically count the applicable scorings here and maybe I should have, but in this case I don't really think we have much of a problem. Another issue that I have with the whole evaluation is that it did not consider the impact of a protocol's mandatory framework elements and protocol capabilities that are *not* required by MIDCOM. The problem here is that middleboxes and agents / applications may have to support these even though they're not used. If the protocol has another simultaneous use in the middlebox or agent / application, then the impact is not so bad, in fact there may be no impact at all. But if the use of the protocol is its first use in the middlebox or agent / application, then I think we have to seriously consider this potential problem. This problem relates to, but is not exclusive to, library and source code reuse, which in general is desirable. But if the library or source code has a lot of unused capabilities, and the MIDCOM implementer can't (afford to) remove them, then this will place an unnecessary cost on implementations. [MB] I do think that the Diameter evaluation did bring forth this issue, but certainly there was no specific requirement, so it's not captured in the T/P+/P/F totals. However, it is brought out in the textual summary. I do think that some of this is brought out with the proposed changes I posted to the list for the SNMP, MEGACO and COPS descriptions in section 1. [/MB] I have no idea how to evaluate this in advance, but I have a gut feeling we may have a *real* problem here. I am certainly open to ideas on how to evaluate this in advance. But maybe we'll just have to wait for specific protocol proposals to be able to see through this issue. [MB] I don't think your alone in having some concerns about the process that the WG is using, however, per my proposal above, this document is just one piece of information that goes into the overall Protocol decision. This needs to be considered along with the semantic analysis which is underway. We had this discussion right after IETF-53, and the decision was that this document could be worked in parallel with the semantic analysis, but I think there was general agreement that the semantic analysis was an equally (and for some folks) more important part of the overall protocol decision process. [/MB] So, overall, I think the evaluation is good, but I have some issues with how the facts presented, especially the summary counts, may be interpreted. [MB] Per my comments above, the document should be explicit about P+ versus P any specific concerns should be raised. As a minimum, I'm proposing to add the text described above to ensure that the intent of Section 3 is clear. Comments expected and welcome. Jim _______________________________________________ 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 Fri Aug 2 01:04:18 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 BAA29218 for ; Fri, 2 Aug 2002 01:04:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA14758 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 01:05:29 -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 AAA13009; Fri, 2 Aug 2002 00:45:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12978 for ; Fri, 2 Aug 2002 00:45:30 -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 AAA28702 for ; Fri, 2 Aug 2002 00:44:19 -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 g724jVa07144 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 1 Aug 2002 21:45:31 -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 g724jQ221015; Thu, 1 Aug 2002 21:45:26 -0700 (PDT) Subject: RE: [midcom] Comments on protocol evaluation draft To: "Mary Barnes" Cc: "'midcom'" Date: Thu, 1 Aug 2002 23:45:12 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) 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 Mary (and other middlebox experts), Thank you much for your reply. The clarification of the grading system is especially useful. I had a lot of trouble understanding it before, but I think I got it now. Here's what I now understand the grades to mean: T - Compliance to the requirement with the protocol as is P+ - Compliance to the requirement with an extension to the protocol P - Compliance to the requirement with a change, or an extension that impacts existing users of the protocol F - No compliance (even with extension of the protocol???) Some observations on this: - Since all the protocols are extensible and extensions can generally be made, one way or another, to be backward compatible, I'm surprised that we have any P's of F's. :-) - We seem to have lost the concept of how large an extension needs to be made to add a "thing" to the protocol. Is the protocol close to the requirement and just needs a little extension? Or does the protocol have nothing to offer and the thing has to be added completely? I originally thought that was the idea behind the the T, P and F grades ("How much do ya have to change the protocol to satify the requirement? None, a little, and a lot, respectively"), but I guess we evolved from that, assuming that was the original intention. As you suggested, I went back and looked for what I thought were incon- sistencies in P+ and P grades. Once I got started digging, what I wound up doing was quickly reviewing all the scores for consistency with the grading system as I now understand it and the summary information for each protocol's compliance with each requirement as given in the protocol evaluation I-D (BTW, I used the -02 version of the I-D, without any of the changes that have been discussed since it was published.). The grading inconsistencies that I saw fell into 4 categories: 1. The requirement compliance text for the protocol basically said "This can be done with an extension to this protocol" and the grade was a T, instead of a P+ as I believe it should be. I included the closely related "The protocol does not preclude this extension from being made." in this category. 2. The requirement compliance text for the protocol says the protocol has something here but extension is required and can be made with no impact, but graded it as a P instead of a P+. 3. The requirement compliance text for the protocol says the protocol has nothing here but the necessary extension can be made without impact, and graded it as an F instead of a P+. 4. The requirement compliance text for the protocol says the protocol has nothing here but if ya use TLS or IPsec or whatever for security ya get everything, and graded it as a T. In the last case, I'm not sure what the right score is, but I would suggest at most P+, to distinguish these from protocols that have the right thing here without resorting to TLS or IPsec or whatever for security, which I think should get a T grade. (For consistency, I considered grades of F (Honestly given, in my opinion, but I could be wrong.) but the requirement could be fulfilled with TLS or IPsec or whatever for security, hence now graded P+ for consistency, as instances of this case also.) I also found a few other what I believe to be inconsistencies, at least based on the scoring system as I now understand it. Call this category 5. I list the inconsistencies I found at the end of this message, but here's some statistics. Take 'em for whatever ya think they're worth. Out of a total of 135 scores (27 requirements times 5 protocols) I found what I thought were 31 inconsistencies. That's just less than 23%. The number of inconsistencies by category by protocol are: Category SNMP RSIP MEGACO DIAMETER COPS Total -------- ---- ---- ------ -------- ---- ----- 1 1 0 3 3 1 8 2 0 2 0 1 0 3 3 0 4 0 0 0 4 4 0 5 4 5 0 14 5 0 2 0 0 0 2 -- -- -- -- -- -- Total 1 13 7 9 1 31 The resulting adjustments in protocols scores are: Protocol T P+ P F -------- --- --- --- --- SNMP - 1 + 1 RSIP + 2 +10 - 3 - 9 MEGACO - 7 + 7 DIAMETER - 8 + 9 - 1 COPS - 1 + 1 --- --- --- --- Total -15 +28 - 4 - 9 And the resulting protocol scores are: Protocol T P+ P F Total -------- --- --- --- --- ----- SNMP 18 9 0 0 27 RSIP 14 13 0 0 27 MEGACO 13 11 2 1 27 DIAMETER 13 13 1 0 27 COPS 19 6 1 1 27 --- --- --- --- --- Total 77 52 4 2 135 This was done real quick, so there's probably still stuff not right, but now, at least to me, the numbers better match the general feeling I get when reading the I-D. Comments expected and welcome. Jim ================ Inconsistencies I found in the MIDCOM protocol evaluation grades (This was composed with tab stops every 8 characters.) Score Require- ------------------- Inconsistency ment Protocol Was Should be Category -------- -------- --- --------- -------- 2.1.2 RSIP P T 5 2.1.8 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.2.1 RSIP P+ T 5 2.2.2 SNMP T P+ 1 RSIP P P+ 2 MEGACO T P+ 1 DIAMETER T P+ 1 2.2.3 RSIP P P+ 3 2.2.4 MEGACO T P+ 1 DIAMETER T P+ 1 2,2,6 DIAMETER T P+ 1 COPS T P+ 1 2.2.7 RSIP F P+ 3 DIAMETER T P+ 1 2.2.8 RSIP P P+ 2 MEGACO T P+ 1 2.2.9 RSIP F P+ 3 2.2.11 RSIP F P+ 3 2.3.1 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.2 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.3 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.4 RSIP F P+ 4 DIAMETER T P+ 4 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 10:03:27 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 KAA20304 for ; Fri, 2 Aug 2002 10:03:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15930 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 10:04:35 -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 KAA15851; Fri, 2 Aug 2002 10:02:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15820 for ; Fri, 2 Aug 2002 10:02:25 -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 KAA20247 for ; Fri, 2 Aug 2002 10:01:16 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72E0m703945; Fri, 2 Aug 2002 10:00:48 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 10:00:49 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A740@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'James_Renkel@3com.com'" , "Mary Barnes" Cc: "'midcom'" Subject: RE: [midcom] Comments on protocol evaluation draft Date: Fri, 2 Aug 2002 10:00:47 -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 From my point of view you raise two issues I cannot leave unanswered. The first has to do with P+ extensions and your first scoring inconsistency, the second with security. I confess that the need for protocol extensions poses a logical issue: how to treat this need when it affects multiple categories of response. On the one hand, I think it is over-stating things to simply score 1 against each category that depends on the extension. On the other, it is certainly true that, whether you are defining a new MIB, a new DIAMETER application, or a new Megaco package, you imply the need for extra code in both the Agent and the Middlebox above that supplied by the base protocol implementation. I myself would propose adding an evaluation category that specifies the increment to the base protocol implied by its use for MIDCOM. Leaving that aside, any protocol that fails to meet one of the MIDCOM requirements is probably beyond our consideration. On the security issue: you dismiss too quickly those protocols that rely on lower layers for their necessary degree of security. The RFCs specifying these protocols have security sections. The protocol security architecture in each case was arrived at by considering the specific threats that had to be countered in the protocol's domain of application. An architecture that relies on lower layer security is perfectly valid if that meets the requirements for that protocol. What we do have to think about is whether the threats are different for the MIDCOM application from those considered when the candidate protocol was being designed. If so, the security architecture for that protocol may have to be modified to fit MIDCOM application. But the security section of the MIDCOM requirements document reflects the results of the MIDCOM threat analysis. Thus if our candidate protocols, including their specified security architectures, can meet these requirements in a practical way, they must be scored as passing those requirements. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, August 02, 2002 12:45 AM To: Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft Mary (and other middlebox experts), Thank you much for your reply. The clarification of the grading system is especially useful. I had a lot of trouble understanding it before, but I think I got it now. Here's what I now understand the grades to mean: T - Compliance to the requirement with the protocol as is P+ - Compliance to the requirement with an extension to the protocol P - Compliance to the requirement with a change, or an extension that impacts existing users of the protocol F - No compliance (even with extension of the protocol???) Some observations on this: - Since all the protocols are extensible and extensions can generally be made, one way or another, to be backward compatible, I'm surprised that we have any P's of F's. :-) - We seem to have lost the concept of how large an extension needs to be made to add a "thing" to the protocol. Is the protocol close to the requirement and just needs a little extension? Or does the protocol have nothing to offer and the thing has to be added completely? I originally thought that was the idea behind the the T, P and F grades ("How much do ya have to change the protocol to satify the requirement? None, a little, and a lot, respectively"), but I guess we evolved from that, assuming that was the original intention. As you suggested, I went back and looked for what I thought were incon- sistencies in P+ and P grades. Once I got started digging, what I wound up doing was quickly reviewing all the scores for consistency with the grading system as I now understand it and the summary information for each protocol's compliance with each requirement as given in the protocol evaluation I-D (BTW, I used the -02 version of the I-D, without any of the changes that have been discussed since it was published.). The grading inconsistencies that I saw fell into 4 categories: 1. The requirement compliance text for the protocol basically said "This can be done with an extension to this protocol" and the grade was a T, instead of a P+ as I believe it should be. I included the closely related "The protocol does not preclude this extension from being made." in this category. 2. The requirement compliance text for the protocol says the protocol has something here but extension is required and can be made with no impact, but graded it as a P instead of a P+. 3. The requirement compliance text for the protocol says the protocol has nothing here but the necessary extension can be made without impact, and graded it as an F instead of a P+. 4. The requirement compliance text for the protocol says the protocol has nothing here but if ya use TLS or IPsec or whatever for security ya get everything, and graded it as a T. In the last case, I'm not sure what the right score is, but I would suggest at most P+, to distinguish these from protocols that have the right thing here without resorting to TLS or IPsec or whatever for security, which I think should get a T grade. (For consistency, I considered grades of F (Honestly given, in my opinion, but I could be wrong.) but the requirement could be fulfilled with TLS or IPsec or whatever for security, hence now graded P+ for consistency, as instances of this case also.) I also found a few other what I believe to be inconsistencies, at least based on the scoring system as I now understand it. Call this category 5. I list the inconsistencies I found at the end of this message, but here's some statistics. Take 'em for whatever ya think they're worth. Out of a total of 135 scores (27 requirements times 5 protocols) I found what I thought were 31 inconsistencies. That's just less than 23%. The number of inconsistencies by category by protocol are: Category SNMP RSIP MEGACO DIAMETER COPS Total -------- ---- ---- ------ -------- ---- ----- 1 1 0 3 3 1 8 2 0 2 0 1 0 3 3 0 4 0 0 0 4 4 0 5 4 5 0 14 5 0 2 0 0 0 2 -- -- -- -- -- -- Total 1 13 7 9 1 31 The resulting adjustments in protocols scores are: Protocol T P+ P F -------- --- --- --- --- SNMP - 1 + 1 RSIP + 2 +10 - 3 - 9 MEGACO - 7 + 7 DIAMETER - 8 + 9 - 1 COPS - 1 + 1 --- --- --- --- Total -15 +28 - 4 - 9 And the resulting protocol scores are: Protocol T P+ P F Total -------- --- --- --- --- ----- SNMP 18 9 0 0 27 RSIP 14 13 0 0 27 MEGACO 13 11 2 1 27 DIAMETER 13 13 1 0 27 COPS 19 6 1 1 27 --- --- --- --- --- Total 77 52 4 2 135 This was done real quick, so there's probably still stuff not right, but now, at least to me, the numbers better match the general feeling I get when reading the I-D. Comments expected and welcome. Jim ================ Inconsistencies I found in the MIDCOM protocol evaluation grades (This was composed with tab stops every 8 characters.) Score Require- ------------------- Inconsistency ment Protocol Was Should be Category -------- -------- --- --------- -------- 2.1.2 RSIP P T 5 2.1.8 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.2.1 RSIP P+ T 5 2.2.2 SNMP T P+ 1 RSIP P P+ 2 MEGACO T P+ 1 DIAMETER T P+ 1 2.2.3 RSIP P P+ 3 2.2.4 MEGACO T P+ 1 DIAMETER T P+ 1 2,2,6 DIAMETER T P+ 1 COPS T P+ 1 2.2.7 RSIP F P+ 3 DIAMETER T P+ 1 2.2.8 RSIP P P+ 2 MEGACO T P+ 1 2.2.9 RSIP F P+ 3 2.2.11 RSIP F P+ 3 2.3.1 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.2 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.3 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.4 RSIP F P+ 4 DIAMETER T P+ 4 _______________________________________________ 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 Aug 2 10:49:29 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 KAA22422 for ; Fri, 2 Aug 2002 10:49:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18211 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 10:50: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 KAA18164; Fri, 2 Aug 2002 10:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18137 for ; Fri, 2 Aug 2002 10:49:01 -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 KAA22389 for ; Fri, 2 Aug 2002 10:47:52 -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 g72EmdH19736; Fri, 2 Aug 2002 09:48:39 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 09:48:25 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C805@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "Tom-PT Taylor" , "'James_Renkel@3com.com'" Cc: "'midcom'" Subject: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft Date: Fri, 2 Aug 2002 09:48:23 -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 Jim et al, I've not thoroughly reviewed all the proposed changes in detail, but will do so shortly, but I also did want to respond to the Category 4 to which Tom also responded wrt security. We have already discussed and resolved this concern per email discussions based on the -01 version. Refer to: http://www.ietf.org/mail-archive/working-groups/midcom/current/msg02397.html Now, you're also proposing that RSIP be "upgraded" for the security ones that you had scored as Failing to meet compliancy in your analysis. Based upon the text currently in section 2.1.8, 2.3.1, which also applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps. The P+ category would only apply if these changes could be made to RSIP as a natural extension of the protocol with no impact to current users of that protocol (i.e. current users don't make use of the information, and wouldn't be bothered by it being in the messages). There are a many other RSIP scores, many of which were derived from your original analysis, that you're also now proposing changes for: 2.1.2 - The text for this one clearly states that an extension is required. 2.2.1 - The text currently supports the P+ score. 2.2.2 - I think a P+ needs additional text to substantiate that this would be a compatible extension of the protocol (OR we need some text upfront in the RSIP overview describing the extensibility mechanisms defined by RSIP) 2.2.3 - ditto 2.2.7 - I can't quite see how this goes from F to P+; you'll need to provide more text or clarification. 2.2.8 - I think a P+ needs additional text to substantiate that this would be a compatible extension of the protocol 2.2.9 - I don't have a problem with changing this to P. Again, P+ would require additional text to substantiate that this would be a compatible extension of the protocol. 2.2.11 -ditto Upon another quick glance, I think many of the proposed changes for the other protocols are bringing forth issues with other "scores" that we have already discussed (e.g. 2.2.2 for Megaco) Certainly, if there is overwhelming support for your changes, then they can be done, but we've got to have more than one person supporting the change for something that we have previously discussed and I certainly thought had reached concensus on. I won't be responding to each of these that we've already discussed, you can search the email archives, where each has been addressed in a separate email thread. Again, I haven't looked at each in detail, and you may indeed have found some changes which are valid, so I will post separately each of those which I would agree to change provided there is WG concensus (i.e. no negative responses to my proposals). Regards, Mary. -----Original Message----- From: Taylor, Tom-PT [CAR:B602:EXCH] Sent: Friday, August 02, 2002 9:01 AM To: 'James_Renkel@3com.com'; Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft From my point of view you raise two issues I cannot leave unanswered. The first has to do with P+ extensions and your first scoring inconsistency, the second with security. I confess that the need for protocol extensions poses a logical issue: how to treat this need when it affects multiple categories of response. On the one hand, I think it is over-stating things to simply score 1 against each category that depends on the extension. On the other, it is certainly true that, whether you are defining a new MIB, a new DIAMETER application, or a new Megaco package, you imply the need for extra code in both the Agent and the Middlebox above that supplied by the base protocol implementation. I myself would propose adding an evaluation category that specifies the increment to the base protocol implied by its use for MIDCOM. Leaving that aside, any protocol that fails to meet one of the MIDCOM requirements is probably beyond our consideration. On the security issue: you dismiss too quickly those protocols that rely on lower layers for their necessary degree of security. The RFCs specifying these protocols have security sections. The protocol security architecture in each case was arrived at by considering the specific threats that had to be countered in the protocol's domain of application. An architecture that relies on lower layer security is perfectly valid if that meets the requirements for that protocol. What we do have to think about is whether the threats are different for the MIDCOM application from those considered when the candidate protocol was being designed. If so, the security architecture for that protocol may have to be modified to fit MIDCOM application. But the security section of the MIDCOM requirements document reflects the results of the MIDCOM threat analysis. Thus if our candidate protocols, including their specified security architectures, can meet these requirements in a practical way, they must be scored as passing those requirements. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, August 02, 2002 12:45 AM To: Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft Mary (and other middlebox experts), Thank you much for your reply. The clarification of the grading system is especially useful. I had a lot of trouble understanding it before, but I think I got it now. Here's what I now understand the grades to mean: T - Compliance to the requirement with the protocol as is P+ - Compliance to the requirement with an extension to the protocol P - Compliance to the requirement with a change, or an extension that impacts existing users of the protocol F - No compliance (even with extension of the protocol???) Some observations on this: - Since all the protocols are extensible and extensions can generally be made, one way or another, to be backward compatible, I'm surprised that we have any P's of F's. :-) - We seem to have lost the concept of how large an extension needs to be made to add a "thing" to the protocol. Is the protocol close to the requirement and just needs a little extension? Or does the protocol have nothing to offer and the thing has to be added completely? I originally thought that was the idea behind the the T, P and F grades ("How much do ya have to change the protocol to satify the requirement? None, a little, and a lot, respectively"), but I guess we evolved from that, assuming that was the original intention. As you suggested, I went back and looked for what I thought were incon- sistencies in P+ and P grades. Once I got started digging, what I wound up doing was quickly reviewing all the scores for consistency with the grading system as I now understand it and the summary information for each protocol's compliance with each requirement as given in the protocol evaluation I-D (BTW, I used the -02 version of the I-D, without any of the changes that have been discussed since it was published.). The grading inconsistencies that I saw fell into 4 categories: 1. The requirement compliance text for the protocol basically said "This can be done with an extension to this protocol" and the grade was a T, instead of a P+ as I believe it should be. I included the closely related "The protocol does not preclude this extension from being made." in this category. 2. The requirement compliance text for the protocol says the protocol has something here but extension is required and can be made with no impact, but graded it as a P instead of a P+. 3. The requirement compliance text for the protocol says the protocol has nothing here but the necessary extension can be made without impact, and graded it as an F instead of a P+. 4. The requirement compliance text for the protocol says the protocol has nothing here but if ya use TLS or IPsec or whatever for security ya get everything, and graded it as a T. In the last case, I'm not sure what the right score is, but I would suggest at most P+, to distinguish these from protocols that have the right thing here without resorting to TLS or IPsec or whatever for security, which I think should get a T grade. (For consistency, I considered grades of F (Honestly given, in my opinion, but I could be wrong.) but the requirement could be fulfilled with TLS or IPsec or whatever for security, hence now graded P+ for consistency, as instances of this case also.) I also found a few other what I believe to be inconsistencies, at least based on the scoring system as I now understand it. Call this category 5. I list the inconsistencies I found at the end of this message, but here's some statistics. Take 'em for whatever ya think they're worth. Out of a total of 135 scores (27 requirements times 5 protocols) I found what I thought were 31 inconsistencies. That's just less than 23%. The number of inconsistencies by category by protocol are: Category SNMP RSIP MEGACO DIAMETER COPS Total -------- ---- ---- ------ -------- ---- ----- 1 1 0 3 3 1 8 2 0 2 0 1 0 3 3 0 4 0 0 0 4 4 0 5 4 5 0 14 5 0 2 0 0 0 2 -- -- -- -- -- -- Total 1 13 7 9 1 31 The resulting adjustments in protocols scores are: Protocol T P+ P F -------- --- --- --- --- SNMP - 1 + 1 RSIP + 2 +10 - 3 - 9 MEGACO - 7 + 7 DIAMETER - 8 + 9 - 1 COPS - 1 + 1 --- --- --- --- Total -15 +28 - 4 - 9 And the resulting protocol scores are: Protocol T P+ P F Total -------- --- --- --- --- ----- SNMP 18 9 0 0 27 RSIP 14 13 0 0 27 MEGACO 13 11 2 1 27 DIAMETER 13 13 1 0 27 COPS 19 6 1 1 27 --- --- --- --- --- Total 77 52 4 2 135 This was done real quick, so there's probably still stuff not right, but now, at least to me, the numbers better match the general feeling I get when reading the I-D. Comments expected and welcome. Jim ================ Inconsistencies I found in the MIDCOM protocol evaluation grades (This was composed with tab stops every 8 characters.) Score Require- ------------------- Inconsistency ment Protocol Was Should be Category -------- -------- --- --------- -------- 2.1.2 RSIP P T 5 2.1.8 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.2.1 RSIP P+ T 5 2.2.2 SNMP T P+ 1 RSIP P P+ 2 MEGACO T P+ 1 DIAMETER T P+ 1 2.2.3 RSIP P P+ 3 2.2.4 MEGACO T P+ 1 DIAMETER T P+ 1 2,2,6 DIAMETER T P+ 1 COPS T P+ 1 2.2.7 RSIP F P+ 3 DIAMETER T P+ 1 2.2.8 RSIP P P+ 2 MEGACO T P+ 1 2.2.9 RSIP F P+ 3 2.2.11 RSIP F P+ 3 2.3.1 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.2 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.3 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.4 RSIP F P+ 4 DIAMETER T P+ 4 _______________________________________________ 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 Aug 2 11:33:59 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 LAA23927 for ; Fri, 2 Aug 2002 11:33:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21215 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 11:35:08 -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 LAA21150; Fri, 2 Aug 2002 11:33: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 LAA21070 for ; Fri, 2 Aug 2002 11:33:11 -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 LAA23888 for ; Fri, 2 Aug 2002 11:32:01 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72FWZ711796 for ; Fri, 2 Aug 2002 11:32:35 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 11:32:36 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A742@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'midcom@ietf.org'" Date: Fri, 2 Aug 2002 11:32:35 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Semantics Of "Session" 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 the discussion at Yokohama, I gained the impression that people's understanding of the MIDCOM session varied. It did appear from our discussion of rule takeover and rule lifetime that policy rules are created within sessions, but there is no reason for the Middlebox to remember in what session a given rule was created. Is there any semantic content to a MIDCOM session, then, except as a policy context for the Middlebox to use when evaluating requests from the Agent? 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 Fri Aug 2 11:50: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 LAA24387 for ; Fri, 2 Aug 2002 11:50:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21940 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 11:51:35 -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 LAA21791; Fri, 2 Aug 2002 11:46:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21760 for ; Fri, 2 Aug 2002 11:46:52 -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 LAA24256 for ; Fri, 2 Aug 2002 11:45:42 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g72FkMhI024750 for ; Fri, 2 Aug 2002 08:46:22 -0700 (PDT) Received: from localhost.localdomain (ssh-rtp-1.cisco.com [161.44.11.166]) by airborne.cisco.com (Mirapoint) with ESMTP id ABO12891; Fri, 2 Aug 2002 08:46:07 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 500) id BB511E6789; Fri, 2 Aug 2002 11:46:05 -0400 (EDT) Date: Fri, 2 Aug 2002 11:46:05 -0400 From: Scott Brim To: "'midcom@ietf.org'" Subject: Re: [midcom] Semantics Of "Session" Message-ID: <20020802114605.K1465@localhost.localdomain> Mail-Followup-To: Scott Brim , "'midcom@ietf.org'" References: <4D79C746863DD51197690002A52CDA0001E8A742@zcard0kc.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A742@zcard0kc.ca.nortel.com>; from taylor@nortelnetworks.com on Fri, Aug 02, 2002 at 11:32:35AM -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 On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > In the discussion at Yokohama, I gained the impression that people's > understanding of the MIDCOM session varied. It did appear from our > discussion of rule takeover and rule lifetime that policy rules are created > within sessions, but there is no reason for the Middlebox to remember in > what session a given rule was created. > > Is there any semantic content to a MIDCOM session, then, except as a policy > context for the Middlebox to use when evaluating requests from the Agent? During your presentation, and occasionally in others, I would ask myself "what's a session?". There are no semantics that need a session concept. However there needs to be shared state on both ends, including a cookie which can be assigned to rules and used arbitrarily. We can conceive of uses for it today (like 'I'm done with everything with cookie xyzzy'), and there may be more in the future. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 12:03: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 MAA24946 for ; Fri, 2 Aug 2002 12:03:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23556 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 12:04: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 MAA23478; Fri, 2 Aug 2002 12:02:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23450 for ; Fri, 2 Aug 2002 12:02:50 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24905 for ; Fri, 2 Aug 2002 12:01:40 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72G2G019394 for ; Fri, 2 Aug 2002 18:02:16 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <350WMFSW>; Fri, 2 Aug 2002 18:02:15 +0200 Message-ID: From: "Cedric Aoun" To: "Mary Barnes" , "'midcom@ietf.org'" Subject: RE: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNM P - Section 1 .1.1 Date: Fri, 2 Aug 2002 18:02:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A3D.F81617EE" 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_01C23A3D.F81617EE Content-Type: text/plain; charset="iso-8859-1" Mary, I think you should also add that for reliability purposes SNMP is not applicable. SNMPv2 provides reliability of notifications sent from the MB (i.e the SNMP agent) by using INFORM instead of TRAPs as they are not acked. Basically all I'm saying is that for all needs, SNMPv3 is required to meet the current compliancy statements. Cedric -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: 26 July 2002 22:53 To: 'midcom@ietf.org' Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNMP - Section 1 .1.1 Hi all, This is the change that I propose to make to Section 1.1.1, with regards to clarifying the applicability of SNMP as the MIDCOM protocol. Old Text (from draft-ietf-midcom-protocol-eval-02.txt): "The primary advantages of SNMP compared to other protocols evaluated are that it is a mature, well understood protocol currently deployed in various scenarios. In addition, mature toolsets are available for SNMP managers and agents. SNMP is mainly used for monitoring rather than for configuring network nodes, however, thus reducing its applicability to MIDCOM." Proposed New Text: "The primary advantages of SNMP are that it is a mature, well understood protocol currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents. However, several other factors also affect SNMP's applicability as the MIDCOM protocol: - SNMP is mainly used for monitoring rather than for configuring network nodes, and - SNMPv3 is required in order to meet the security requirements." *************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. *************** 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 ------_=_NextPart_001_01C23A3D.F81617EE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] MIDCOM Protocol Evaluation - Proposed changes to = SNMP - Section 1 .1.1

Mary,
I think you should also add that for reliability = purposes SNMP is not applicable.
SNMPv2 provides reliability of notifications sent = from the MB (i.e the SNMP agent) by using INFORM instead of TRAPs as = they are not acked.

Basically all I'm saying is that for all needs, = SNMPv3 is required to meet the current compliancy statements.
Cedric

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH]
Sent: 26 July 2002 22:53
To: 'midcom@ietf.org'
Subject: [midcom] MIDCOM Protocol Evaluation - = Proposed changes to SNMP
- Section 1 .1.1


Hi all,

This is the change that I propose to make to Section = 1.1.1, with regards to
clarifying the applicability of SNMP as the MIDCOM = protocol.

Old Text (from = draft-ietf-midcom-protocol-eval-02.txt):

"The primary advantages of SNMP compared to = other protocols evaluated are
that it is a mature, well understood protocol = currently deployed in various
scenarios. In addition, mature toolsets are = available for SNMP managers and
agents. SNMP is mainly used for monitoring rather = than for configuring
network nodes, however, thus reducing its = applicability to MIDCOM."

Proposed New Text:

"The primary advantages of SNMP are that it is a = mature, well understood
protocol currently deployed in various scenarios, = with mature toolsets
available for SNMP managers and agents. However, = several other factors also
affect SNMP's applicability as the MIDCOM = protocol:
- SNMP is mainly used for monitoring rather than for = configuring network
nodes, and
- SNMPv3 is required in order to meet the security = requirements."

***************
Although comments on the overall document will be = accepted through August
2nd, I would like to request that feedback on this = proposed change be
provided by 6PM CST Tuesday (30 July) so that we can = address any concerns
prior to the 2nd; with no response meaning that the = proposed text is OK.
***************

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

------_=_NextPart_001_01C23A3D.F81617EE-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 12:03:30 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 MAA24982 for ; Fri, 2 Aug 2002 12:03:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23586 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 12:04: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 MAA23532; Fri, 2 Aug 2002 12:03: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 MAA23497 for ; Fri, 2 Aug 2002 12:03:34 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24935 for ; Fri, 2 Aug 2002 12:02:25 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 09:03:04 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Aug 2002 09:03:04 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Aug 2002 09:03:04 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Aug 2002 09:03:03 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Fri, 2 Aug 2002 09:03:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Semantics Of "Session" Date: Fri, 2 Aug 2002 09:03:01 -0700 Message-ID: Thread-Topic: [midcom] Semantics Of "Session" Thread-Index: AcI6O+eeLZF19GR7QuG+R7W4EGITygAAbKCg From: "Christian Huitema" To: "Scott Brim" , X-OriginalArrivalTime: 02 Aug 2002 16:03:08.0404 (UTC) FILETIME=[17F3EB40:01C23A3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA23498 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 > From: Scott Brim [mailto:swb@employees.org] > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > > Is there any semantic content to a MIDCOM session, then, > except as a policy > > context for the Middlebox to use when evaluating requests > from the Agent? > > During your presentation, and occasionally in others, I would > ask myself > "what's a session?". There are no semantics that need a session > concept. However there needs to be shared state on both > ends, including > a cookie which can be assigned to rules and used arbitrarily. We can > conceive of uses for it today (like 'I'm done with everything with > cookie xyzzy'), and there may be more in the future. I don't think we need any concept of a midcom session, and specifically any concept tying the state of the "session" to the validity of rules installed in the meddlebox. A session might be useful as a form of transport & security shortcut, i.e. authenticate the requestor once per session instead of once per transaction, but that is about the only thing that is really needed. Specifically, an agent must be able to install a rule that is supposed to be valid for some lifetime, go off the network, and be confident that the rule is operative. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 13:21: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 NAA27567 for ; Fri, 2 Aug 2002 13:21:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27008 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 13:22:41 -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 NAA26955; Fri, 2 Aug 2002 13:21:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26926 for ; Fri, 2 Aug 2002 13:21:09 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27450 for ; Fri, 2 Aug 2002 13:19:58 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72HKG021687; Fri, 2 Aug 2002 19:20:16 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <350WMF7H>; Fri, 2 Aug 2002 19:20:14 +0200 Message-ID: From: "Cedric Aoun" To: "'Christian Huitema'" , Scott Brim , midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" Date: Fri, 2 Aug 2002 19:20:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A48.DD52AA16" 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_01C23A48.DD52AA16 Content-Type: text/plain; charset="iso-8859-1" I still remember our bar BOF and small meeting that we had in London last year in August, we're we all rejected the notion of a "session" as it meant zillions of things. we all agreed that the notion of session was more a notion of an association relation based on trust and no more (i.e. it is an SA or something similar). The establishment of the association starts with the authorization policy provisioning matching the authorized agents. This should be augmented by having an SA between the Middlebox and the Midcom agent. I agree with Christian, the protocol semantics should not include any form of session information. Cedric -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: 02 August 2002 18:03 To: Scott Brim; midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" > From: Scott Brim [mailto:swb@employees.org] > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > > Is there any semantic content to a MIDCOM session, then, > except as a policy > > context for the Middlebox to use when evaluating requests > from the Agent? > > During your presentation, and occasionally in others, I would > ask myself > "what's a session?". There are no semantics that need a session > concept. However there needs to be shared state on both > ends, including > a cookie which can be assigned to rules and used arbitrarily. We can > conceive of uses for it today (like 'I'm done with everything with > cookie xyzzy'), and there may be more in the future. I don't think we need any concept of a midcom session, and specifically any concept tying the state of the "session" to the validity of rules installed in the meddlebox. A session might be useful as a form of transport & security shortcut, i.e. authenticate the requestor once per session instead of once per transaction, but that is about the only thing that is really needed. Specifically, an agent must be able to install a rule that is supposed to be valid for some lifetime, go off the network, and be confident that the rule is operative. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C23A48.DD52AA16 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Semantics Of "Session"

I still remember our bar BOF and small meeting that = we had in London last year in August, we're we all rejected the notion = of a "session" as it meant zillions of things. we all agreed = that the notion of session was more a notion of an association relation = based on trust and no more (i.e. it is an SA or something = similar).

The establishment of the association starts with the = authorization policy provisioning matching the authorized agents. This = should be augmented by having an SA between the Middlebox and the = Midcom agent.

I agree with Christian, the protocol semantics should = not include any form of session information.
Cedric

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: 02 August 2002 18:03
To: Scott Brim; midcom@ietf.org
Subject: RE: [midcom] Semantics Of = "Session"


> From: Scott Brim [mailto:swb@employees.org]
> On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT = Taylor allegedly wrote:
> > Is there any semantic content to a MIDCOM = session, then,
> except as a policy
> > context for the Middlebox to use when = evaluating requests
> from the Agent? 
>
> During your presentation, and occasionally in = others, I would
> ask myself
> "what's a session?".  There are = no semantics that need a session
> concept.  However there needs to be shared = state on both
> ends, including
> a cookie which can be assigned to rules and = used arbitrarily.  We can
> conceive of uses for it today (like 'I'm done = with everything with
> cookie xyzzy'), and there may be more in the = future.

I don't think we need any concept of a midcom = session, and specifically
any concept tying the state of the = "session" to the validity of rules
installed in the meddlebox. A session might be = useful as a form of
transport & security shortcut, i.e. authenticate = the requestor once per
session instead of once per transaction, but that is = about the only
thing that is really needed. Specifically, an agent = must be able to
install a rule that is supposed to be valid for some = lifetime, go off
the network, and be confident that the rule is = operative.

-- Christian Huitema

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

------_=_NextPart_001_01C23A48.DD52AA16-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 13:32: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 NAA27902 for ; Fri, 2 Aug 2002 13:32:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28142 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 13:33: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 NAA28107; Fri, 2 Aug 2002 13:32:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28079 for ; Fri, 2 Aug 2002 13:32:25 -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 NAA27866 for ; Fri, 2 Aug 2002 13:31:15 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72HVo719415; Fri, 2 Aug 2002 13:31:51 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 13:31:50 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A744@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Cedric Aoun" , "'Christian Huitema'" , Scott Brim , midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" Date: Fri, 2 Aug 2002 13:31:48 -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 Just on your very last point, you go beyond Christian. The framework shows very clearly a formal start of session and end of session exchange. I see no choice but to indicate such exchanges at the semantic level, however they are realized in practice. But we can omit the session identifier from all other information exchanges. -----Original Message----- From: Aoun, Cedric [GOLF:MA01:EXCH] Sent: Friday, August 02, 2002 1:20 PM To: 'Christian Huitema'; Scott Brim; midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" I still remember our bar BOF and small meeting that we had in London last year in August, we're we all rejected the notion of a "session" as it meant zillions of things. we all agreed that the notion of session was more a notion of an association relation based on trust and no more (i.e. it is an SA or something similar). The establishment of the association starts with the authorization policy provisioning matching the authorized agents. This should be augmented by having an SA between the Middlebox and the Midcom agent. I agree with Christian, the protocol semantics should not include any form of session information. Cedric -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: 02 August 2002 18:03 To: Scott Brim; midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" > From: Scott Brim [mailto:swb@employees.org] > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > > Is there any semantic content to a MIDCOM session, then, > except as a policy > > context for the Middlebox to use when evaluating requests > from the Agent? > > During your presentation, and occasionally in others, I would > ask myself > "what's a session?". There are no semantics that need a session > concept. However there needs to be shared state on both > ends, including > a cookie which can be assigned to rules and used arbitrarily. We can > conceive of uses for it today (like 'I'm done with everything with > cookie xyzzy'), and there may be more in the future. I don't think we need any concept of a midcom session, and specifically any concept tying the state of the "session" to the validity of rules installed in the meddlebox. A session might be useful as a form of transport & security shortcut, i.e. authenticate the requestor once per session instead of once per transaction, but that is about the only thing that is really needed. Specifically, an agent must be able to install a rule that is supposed to be valid for some lifetime, go off the network, and be confident that the rule is operative. -- Christian Huitema _______________________________________________ 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 Aug 2 13:41: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 NAA28173 for ; Fri, 2 Aug 2002 13:41:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28619 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 13:42: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 NAA28580; Fri, 2 Aug 2002 13:40: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 NAA28545 for ; Fri, 2 Aug 2002 13:40:51 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28140 for ; Fri, 2 Aug 2002 13:39:40 -0400 (EDT) Received: from airborne.cisco.com (IDENT:mirapoint@airborne.cisco.com [171.71.154.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g72HeK6I029645 for ; Fri, 2 Aug 2002 10:40:20 -0700 (PDT) Received: from localhost.localdomain (ssh-rtp-1.cisco.com [161.44.11.166]) by airborne.cisco.com (Mirapoint) with ESMTP id ABO14508; Fri, 2 Aug 2002 10:40:06 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 500) id 5F6D3E6789; Fri, 2 Aug 2002 13:40:04 -0400 (EDT) Date: Fri, 2 Aug 2002 13:40:04 -0400 From: Scott Brim To: midcom@ietf.org Subject: Re: [midcom] Semantics Of "Session" Message-ID: <20020802134004.O1465@localhost.localdomain> Mail-Followup-To: Scott Brim , midcom@ietf.org References: <4D79C746863DD51197690002A52CDA0001E8A744@zcard0kc.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A744@zcard0kc.ca.nortel.com>; from taylor@nortelnetworks.com on Fri, Aug 02, 2002 at 01:31:48PM -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 On Fri, Aug 02, 2002 01:31:48PM -0400, Tom-PT Taylor allegedly wrote: > > Just on your very last point, you go beyond Christian. The framework shows > very clearly a formal start of session and end of session exchange. I see > no choice but to indicate such exchanges at the semantic level, however they > are realized in practice. But we can omit the session identifier from all > other information exchanges. The Framework was not completely finished imho. There were several ideas in it which hadn't been completely cleaned up. Personally I didn't push for doing so because I thought the requirements were more important, the framework was non-normative, and we wanted to get to the actual protocol. So I would not take the Framework as gospel. Personally I like the "session" identifier, but I wouldn't call it that. ...Scott > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Friday, August 02, 2002 1:20 PM > To: 'Christian Huitema'; Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > I still remember our bar BOF and small meeting that we had in London last > year in August, we're we all rejected the notion of a "session" as it meant > zillions of things. we all agreed that the notion of session was more a > notion of an association relation based on trust and no more (i.e. it is an > SA or something similar). > The establishment of the association starts with the authorization policy > provisioning matching the authorized agents. This should be augmented by > having an SA between the Middlebox and the Midcom agent. > I agree with Christian, the protocol semantics should not include any form > of session information. > Cedric > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 02 August 2002 18:03 > To: Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > > From: Scott Brim [mailto:swb@employees.org] > > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > > > Is there any semantic content to a MIDCOM session, then, > > except as a policy > > > context for the Middlebox to use when evaluating requests > > from the Agent? > > > > During your presentation, and occasionally in others, I would > > ask myself > > "what's a session?". There are no semantics that need a session > > concept. However there needs to be shared state on both > > ends, including > > a cookie which can be assigned to rules and used arbitrarily. We can > > conceive of uses for it today (like 'I'm done with everything with > > cookie xyzzy'), and there may be more in the future. > I don't think we need any concept of a midcom session, and specifically > any concept tying the state of the "session" to the validity of rules > installed in the meddlebox. A session might be useful as a form of > transport & security shortcut, i.e. authenticate the requestor once per > session instead of once per transaction, but that is about the only > thing that is really needed. Specifically, an agent must be able to > install a rule that is supposed to be valid for some lifetime, go off > the network, and be confident that the rule is operative. > -- Christian Huitema > _______________________________________________ > 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 Aug 2 13:57:59 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 NAA28861 for ; Fri, 2 Aug 2002 13:57:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29375 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 13:59: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 NAA29343; Fri, 2 Aug 2002 13:57:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29267 for ; Fri, 2 Aug 2002 13:57:53 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28798 for ; Fri, 2 Aug 2002 13:56:41 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72HvJ022116; Fri, 2 Aug 2002 19:57:19 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <350WMF89>; Fri, 2 Aug 2002 19:57:17 +0200 Message-ID: From: "Cedric Aoun" To: "'Scott Brim'" , midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" Date: Fri, 2 Aug 2002 19:57:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A4E.0AEE2216" 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_01C23A4E.0AEE2216 Content-Type: text/plain; charset="iso-8859-1" I think that the requirement is to be able to have a handoff of policy rules. It is sufficient to have the association of policy rules with the MIDCOM agent that installed them. When the handoff happens another authorized Midcom agent could have ownership of the policy rules, we are discussing what should be the common identifier of all these policy rules (installed by the failed-over agent), the MIDCOM agent ID of the failed-over agent should be sufficient. Don't you agree? Cedric -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: 02 August 2002 19:40 To: midcom@ietf.org Subject: Re: [midcom] Semantics Of "Session" On Fri, Aug 02, 2002 01:31:48PM -0400, Tom-PT Taylor allegedly wrote: > > Just on your very last point, you go beyond Christian. The framework shows > very clearly a formal start of session and end of session exchange. I see > no choice but to indicate such exchanges at the semantic level, however they > are realized in practice. But we can omit the session identifier from all > other information exchanges. The Framework was not completely finished imho. There were several ideas in it which hadn't been completely cleaned up. Personally I didn't push for doing so because I thought the requirements were more important, the framework was non-normative, and we wanted to get to the actual protocol. So I would not take the Framework as gospel. Personally I like the "session" identifier, but I wouldn't call it that. ...Scott > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Friday, August 02, 2002 1:20 PM > To: 'Christian Huitema'; Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > I still remember our bar BOF and small meeting that we had in London last > year in August, we're we all rejected the notion of a "session" as it meant > zillions of things. we all agreed that the notion of session was more a > notion of an association relation based on trust and no more (i.e. it is an > SA or something similar). > The establishment of the association starts with the authorization policy > provisioning matching the authorized agents. This should be augmented by > having an SA between the Middlebox and the Midcom agent. > I agree with Christian, the protocol semantics should not include any form > of session information. > Cedric > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 02 August 2002 18:03 > To: Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > > From: Scott Brim [mailto:swb@employees.org] > > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > > > Is there any semantic content to a MIDCOM session, then, > > except as a policy > > > context for the Middlebox to use when evaluating requests > > from the Agent? > > > > During your presentation, and occasionally in others, I would > > ask myself > > "what's a session?". There are no semantics that need a session > > concept. However there needs to be shared state on both > > ends, including > > a cookie which can be assigned to rules and used arbitrarily. We can > > conceive of uses for it today (like 'I'm done with everything with > > cookie xyzzy'), and there may be more in the future. > I don't think we need any concept of a midcom session, and specifically > any concept tying the state of the "session" to the validity of rules > installed in the meddlebox. A session might be useful as a form of > transport & security shortcut, i.e. authenticate the requestor once per > session instead of once per transaction, but that is about the only > thing that is really needed. Specifically, an agent must be able to > install a rule that is supposed to be valid for some lifetime, go off > the network, and be confident that the rule is operative. > -- Christian Huitema > _______________________________________________ > 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_01C23A4E.0AEE2216 Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Semantics Of "Session"

I think that the requirement is to be able to have a handoff of
policy rules. It is sufficient to have the association of policy rules
with the MIDCOM agent that installed them.
When the handoff happens another authorized Midcom agent could have ownership
of the policy rules, we are discussing what should be the common identifier of
all these policy rules (installed by the failed-over agent), the MIDCOM agent ID
of the failed-over agent should be sufficient. Don't you agree?
Cedric

-----Original Message-----
From: Scott Brim [mailto:swb@employees.org]
Sent: 02 August 2002 19:40
To: midcom@ietf.org
Subject: Re: [midcom] Semantics Of "Session"


On Fri, Aug 02, 2002 01:31:48PM -0400, Tom-PT Taylor allegedly wrote:
>
> Just on your very last point, you go beyond Christian.  The framework shows
> very clearly a formal start of session and end of session exchange.  I see
> no choice but to indicate such exchanges at the semantic level, however they
> are realized in practice.  But we can omit the session identifier from all
> other information exchanges.

The Framework was not completely finished imho.  There were several
ideas in it which hadn't been completely cleaned up.  Personally I
didn't push for doing so because I thought the requirements were more
important, the framework was non-normative, and we wanted to get to the
actual protocol.  So I would not take the Framework as gospel.

Personally I like the "session" identifier, but I wouldn't call it that.

...Scott

> -----Original Message-----
> From: Aoun, Cedric [GOLF:MA01:EXCH]
> Sent: Friday, August 02, 2002 1:20 PM
> To: 'Christian Huitema'; Scott Brim; midcom@ietf.org
> Subject: RE: [midcom] Semantics Of "Session"
>
>
> I still remember our bar BOF and small meeting that we had in London last
> year in August, we're we all rejected the notion of a "session" as it meant
> zillions of things. we all agreed that the notion of session was more a
> notion of an association relation based on trust and no more (i.e. it is an
> SA or something similar).
> The establishment of the association starts with the authorization policy
> provisioning matching the authorized agents. This should be augmented by
> having an SA between the Middlebox and the Midcom agent.
> I agree with Christian, the protocol semantics should not include any form
> of session information.
> Cedric
> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: 02 August 2002 18:03
> To: Scott Brim; midcom@ietf.org
> Subject: RE: [midcom] Semantics Of "Session"
>
>
> > From: Scott Brim [mailto:swb@employees.org]
> > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote:
> > > Is there any semantic content to a MIDCOM session, then,
> > except as a policy
> > > context for the Middlebox to use when evaluating requests
> > from the Agent? 
> >
> > During your presentation, and occasionally in others, I would
> > ask myself
> > "what's a session?".  There are no semantics that need a session
> > concept.  However there needs to be shared state on both
> > ends, including
> > a cookie which can be assigned to rules and used arbitrarily.  We can
> > conceive of uses for it today (like 'I'm done with everything with
> > cookie xyzzy'), and there may be more in the future.
> I don't think we need any concept of a midcom session, and specifically
> any concept tying the state of the "session" to the validity of rules
> installed in the meddlebox. A session might be useful as a form of
> transport & security shortcut, i.e. authenticate the requestor once per
> session instead of once per transaction, but that is about the only
> thing that is really needed. Specifically, an agent must be able to
> install a rule that is supposed to be valid for some lifetime, go off
> the network, and be confident that the rule is operative.
> -- Christian Huitema
> _______________________________________________
> 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_01C23A4E.0AEE2216-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 14:10:28 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 OAA29277 for ; Fri, 2 Aug 2002 14:10:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00618 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 14:11: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 OAA00578; Fri, 2 Aug 2002 14:10: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 OAA00541 for ; Fri, 2 Aug 2002 14:10:28 -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 OAA29243 for ; Fri, 2 Aug 2002 14:09:17 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g72I9t722225; Fri, 2 Aug 2002 14:09:56 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 14:09:55 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A745@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Cedric Aoun" , "'Scott Brim'" , midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" Date: Fri, 2 Aug 2002 14:09:55 -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 When we discussed handoff, or rather, takeover, we agreed we certainly needed the capability. I know Jonathan argued that takeover should be on a per-rule basis, so rules should have globally unique identifiers to make this easy. I had the feeling others accepted this. -----Original Message----- From: Aoun, Cedric [GOLF:MA01:EXCH] Sent: Friday, August 02, 2002 1:57 PM To: 'Scott Brim'; midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" I think that the requirement is to be able to have a handoff of policy rules. It is sufficient to have the association of policy rules with the MIDCOM agent that installed them. When the handoff happens another authorized Midcom agent could have ownership of the policy rules, we are discussing what should be the common identifier of all these policy rules (installed by the failed-over agent), the MIDCOM agent ID of the failed-over agent should be sufficient. Don't you agree? Cedric -----Original Message----- From: Scott Brim [mailto:swb@employees.org] Sent: 02 August 2002 19:40 To: midcom@ietf.org Subject: Re: [midcom] Semantics Of "Session" On Fri, Aug 02, 2002 01:31:48PM -0400, Tom-PT Taylor allegedly wrote: > > Just on your very last point, you go beyond Christian. The framework shows > very clearly a formal start of session and end of session exchange. I see > no choice but to indicate such exchanges at the semantic level, however they > are realized in practice. But we can omit the session identifier from all > other information exchanges. The Framework was not completely finished imho. There were several ideas in it which hadn't been completely cleaned up. Personally I didn't push for doing so because I thought the requirements were more important, the framework was non-normative, and we wanted to get to the actual protocol. So I would not take the Framework as gospel. Personally I like the "session" identifier, but I wouldn't call it that. ...Scott > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Friday, August 02, 2002 1:20 PM > To: 'Christian Huitema'; Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > I still remember our bar BOF and small meeting that we had in London last > year in August, we're we all rejected the notion of a "session" as it meant > zillions of things. we all agreed that the notion of session was more a > notion of an association relation based on trust and no more (i.e. it is an > SA or something similar). > The establishment of the association starts with the authorization policy > provisioning matching the authorized agents. This should be augmented by > having an SA between the Middlebox and the Midcom agent. > I agree with Christian, the protocol semantics should not include any form > of session information. > Cedric > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 02 August 2002 18:03 > To: Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > > From: Scott Brim [mailto:swb@employees.org] > > On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: > > > Is there any semantic content to a MIDCOM session, then, > > except as a policy > > > context for the Middlebox to use when evaluating requests > > from the Agent? > > > > During your presentation, and occasionally in others, I would > > ask myself > > "what's a session?". There are no semantics that need a session > > concept. However there needs to be shared state on both > > ends, including > > a cookie which can be assigned to rules and used arbitrarily. We can > > conceive of uses for it today (like 'I'm done with everything with > > cookie xyzzy'), and there may be more in the future. > I don't think we need any concept of a midcom session, and specifically > any concept tying the state of the "session" to the validity of rules > installed in the meddlebox. A session might be useful as a form of > transport & security shortcut, i.e. authenticate the requestor once per > session instead of once per transaction, but that is about the only > thing that is really needed. Specifically, an agent must be able to > install a rule that is supposed to be valid for some lifetime, go off > the network, and be confident that the rule is operative. > -- Christian Huitema > _______________________________________________ > 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 Aug 2 20:14: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 UAA12352 for ; Fri, 2 Aug 2002 20:14:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17547 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 20:15:24 -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 UAA17526; Fri, 2 Aug 2002 20:14:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17497 for ; Fri, 2 Aug 2002 20:14:13 -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 UAA12342 for ; Fri, 2 Aug 2002 20:13: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 g730DtH14925; Fri, 2 Aug 2002 19:13:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 19:13:41 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C80D@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" Cc: "'midcom'" Subject: RE: [midcom] Comments on protocol evaluation draft Date: Fri, 2 Aug 2002 19:13:40 -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 Jim, I did finally complete a more detailed review of your suggested changes, and I think you've interpreted text, which I've understood to describe how the requirement is met by the specific protocol, to mean that extensions are required to support that functionality and I don't think that's the case for: 2.2.2 SNMP 2.2.4 Megaco 2.2.4 Diameter 2.2.6 Diameter 2.2.6 COPS I think this same applies to 2.2.7 for Diameter, but I think this needs to be reworded as a positive statement, rather than it's current negative form. I'll post the proposed text separately. I think you may have a valid point for 2.2.8 Megaco. I'll start a separate thread on that one. For 2.1.8, Diameter is currently a P and per my email last week, I will be changing this to a P+, so we're also in agreement on what that one should be. This along with my email response this morning should provide complete feedback on how I propose to handle each of your suggested changes. Thanks, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Thursday, August 01, 2002 11:45 PM To: Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft Mary (and other middlebox experts), Thank you much for your reply. The clarification of the grading system is especially useful. I had a lot of trouble understanding it before, but I think I got it now. Here's what I now understand the grades to mean: T - Compliance to the requirement with the protocol as is P+ - Compliance to the requirement with an extension to the protocol P - Compliance to the requirement with a change, or an extension that impacts existing users of the protocol F - No compliance (even with extension of the protocol???) Some observations on this: - Since all the protocols are extensible and extensions can generally be made, one way or another, to be backward compatible, I'm surprised that we have any P's of F's. :-) - We seem to have lost the concept of how large an extension needs to be made to add a "thing" to the protocol. Is the protocol close to the requirement and just needs a little extension? Or does the protocol have nothing to offer and the thing has to be added completely? I originally thought that was the idea behind the the T, P and F grades ("How much do ya have to change the protocol to satify the requirement? None, a little, and a lot, respectively"), but I guess we evolved from that, assuming that was the original intention. As you suggested, I went back and looked for what I thought were incon- sistencies in P+ and P grades. Once I got started digging, what I wound up doing was quickly reviewing all the scores for consistency with the grading system as I now understand it and the summary information for each protocol's compliance with each requirement as given in the protocol evaluation I-D (BTW, I used the -02 version of the I-D, without any of the changes that have been discussed since it was published.). The grading inconsistencies that I saw fell into 4 categories: 1. The requirement compliance text for the protocol basically said "This can be done with an extension to this protocol" and the grade was a T, instead of a P+ as I believe it should be. I included the closely related "The protocol does not preclude this extension from being made." in this category. 2. The requirement compliance text for the protocol says the protocol has something here but extension is required and can be made with no impact, but graded it as a P instead of a P+. 3. The requirement compliance text for the protocol says the protocol has nothing here but the necessary extension can be made without impact, and graded it as an F instead of a P+. 4. The requirement compliance text for the protocol says the protocol has nothing here but if ya use TLS or IPsec or whatever for security ya get everything, and graded it as a T. In the last case, I'm not sure what the right score is, but I would suggest at most P+, to distinguish these from protocols that have the right thing here without resorting to TLS or IPsec or whatever for security, which I think should get a T grade. (For consistency, I considered grades of F (Honestly given, in my opinion, but I could be wrong.) but the requirement could be fulfilled with TLS or IPsec or whatever for security, hence now graded P+ for consistency, as instances of this case also.) I also found a few other what I believe to be inconsistencies, at least based on the scoring system as I now understand it. Call this category 5. I list the inconsistencies I found at the end of this message, but here's some statistics. Take 'em for whatever ya think they're worth. Out of a total of 135 scores (27 requirements times 5 protocols) I found what I thought were 31 inconsistencies. That's just less than 23%. The number of inconsistencies by category by protocol are: Category SNMP RSIP MEGACO DIAMETER COPS Total -------- ---- ---- ------ -------- ---- ----- 1 1 0 3 3 1 8 2 0 2 0 1 0 3 3 0 4 0 0 0 4 4 0 5 4 5 0 14 5 0 2 0 0 0 2 -- -- -- -- -- -- Total 1 13 7 9 1 31 The resulting adjustments in protocols scores are: Protocol T P+ P F -------- --- --- --- --- SNMP - 1 + 1 RSIP + 2 +10 - 3 - 9 MEGACO - 7 + 7 DIAMETER - 8 + 9 - 1 COPS - 1 + 1 --- --- --- --- Total -15 +28 - 4 - 9 And the resulting protocol scores are: Protocol T P+ P F Total -------- --- --- --- --- ----- SNMP 18 9 0 0 27 RSIP 14 13 0 0 27 MEGACO 13 11 2 1 27 DIAMETER 13 13 1 0 27 COPS 19 6 1 1 27 --- --- --- --- --- Total 77 52 4 2 135 This was done real quick, so there's probably still stuff not right, but now, at least to me, the numbers better match the general feeling I get when reading the I-D. Comments expected and welcome. Jim ================ Inconsistencies I found in the MIDCOM protocol evaluation grades (This was composed with tab stops every 8 characters.) Score Require- ------------------- Inconsistency ment Protocol Was Should be Category -------- -------- --- --------- -------- 2.1.2 RSIP P T 5 2.1.8 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.2.1 RSIP P+ T 5 2.2.2 SNMP T P+ 1 RSIP P P+ 2 MEGACO T P+ 1 DIAMETER T P+ 1 2.2.3 RSIP P P+ 3 2.2.4 MEGACO T P+ 1 DIAMETER T P+ 1 2,2,6 DIAMETER T P+ 1 COPS T P+ 1 2.2.7 RSIP F P+ 3 DIAMETER T P+ 1 2.2.8 RSIP P P+ 2 MEGACO T P+ 1 2.2.9 RSIP F P+ 3 2.2.11 RSIP F P+ 3 2.3.1 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.2 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.3 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.4 RSIP F P+ 4 DIAMETER T P+ 4 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 20:21:18 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 UAA12454 for ; Fri, 2 Aug 2002 20:21:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17746 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 20:22: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 UAA17696; Fri, 2 Aug 2002 20:21:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA17669 for ; Fri, 2 Aug 2002 20:21:31 -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 UAA12422 for ; Fri, 2 Aug 2002 20:20:20 -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 g730LFH15163 for ; Fri, 2 Aug 2002 19:21:15 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 19:21:01 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C80E@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom'" Date: Fri, 2 Aug 2002 19:21:01 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol eval: 2.2.7 Diameter - Proposal to reword text for clari fication of Full Compliancy 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, Per my email response to Jim, to clarify that Diameter does meet this reqiurement, I'm proposing to change the Diameter description in 2.2.7 from: "The Diameter protocol as currently defined offers no impediment such an operation." To: "The Diameter protocol, as currently defined, would allow multiple agents to operate on the same ruleset." I would like feedback (positive and/or negative) on this proposed change by COB Monday, August 5th. 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 Aug 2 20:37:30 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 UAA12814 for ; Fri, 2 Aug 2002 20:37:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA18528 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 20:38: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 UAA18503; Fri, 2 Aug 2002 20:37: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 UAA18475 for ; Fri, 2 Aug 2002 20:37:46 -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 UAA12786 for ; Fri, 2 Aug 2002 20:36:35 -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 g730bTH15540 for ; Fri, 2 Aug 2002 19:37:29 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 19:37:15 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C80F@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom'" Cc: "Cedric Aoun" , "Sanjoy Sen" , "Tom-PT Taylor" Date: Fri, 2 Aug 2002 19:37:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A85.E9DF92C0" Subject: [midcom] Protocol eval: 2.2.8 - Megaco - Question as to whether "Transport of filtering rules" is fully supported in current protocol 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_01C23A85.E9DF92C0 Content-Type: text/plain; charset="iso-8859-1" Hi all, Per my email response to Jim, I think this may be a valid proposal to change Megaco from "T" to "P+" for requirement 2.2.8 - Transport of Filtering rules. What do the Megaco experts think on this one (I could not find any previous discussion of this)? I would like feedback (positive and/or negative) on this proposed change by COB Monday, August 5th. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C23A85.E9DF92C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protocol eval: 2.2.8 - Megaco - Question as to whether = "Transport of filtering rules" is fully supported in current = protocol

Hi all,

Per my email response to Jim, I think this may be a = valid proposal to change Megaco from "T" to "P+" = for requirement 2.2.8 - Transport of Filtering rules. 

What do the Megaco experts think on this one (I could = not find any previous discussion of this)?

I would like feedback (positive and/or negative) on = this proposed change by
COB Monday, August 5th.

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



------_=_NextPart_001_01C23A85.E9DF92C0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 20:41:16 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 UAA12886 for ; Fri, 2 Aug 2002 20:41:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA18663 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 20:42: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 UAA18630; Fri, 2 Aug 2002 20:41: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 UAA18603 for ; Fri, 2 Aug 2002 20:41: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 UAA12871 for ; Fri, 2 Aug 2002 20:40:22 -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 g730fHH15597 for ; Fri, 2 Aug 2002 19:41:17 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 19:41:03 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C810@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "Cedric Aoun" , "'midcom@ietf.org'" Subject: RE: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNM P - Section 1 .1.1 Date: Fri, 2 Aug 2002 19:41:02 -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 Cedric, I agree, I propose to change the text as follows: "The primary advantages of SNMP are that it is a mature, well understood protocol currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents. However, several other factors also affect SNMP's applicability as the MIDCOM protocol: - SNMP is mainly used for monitoring rather than for configuring network nodes, and - SNMPv3 is required in order to meet the reliability and security related requirements." Thanks, Mary. -----Original Message----- From: Aoun, Cedric [GOLF:MA01:EXCH] Sent: Friday, August 02, 2002 11:02 AM To: Barnes, Mary [NGC:B602:EXCH]; 'midcom@ietf.org' Subject: RE: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNMP - Section 1 .1.1 Mary, I think you should also add that for reliability purposes SNMP is not applicable. SNMPv2 provides reliability of notifications sent from the MB (i.e the SNMP agent) by using INFORM instead of TRAPs as they are not acked. Basically all I'm saying is that for all needs, SNMPv3 is required to meet the current compliancy statements. Cedric -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: 26 July 2002 22:53 To: 'midcom@ietf.org' Subject: [midcom] MIDCOM Protocol Evaluation - Proposed changes to SNMP - Section 1 .1.1 Hi all, This is the change that I propose to make to Section 1.1.1, with regards to clarifying the applicability of SNMP as the MIDCOM protocol. Old Text (from draft-ietf-midcom-protocol-eval-02.txt): "The primary advantages of SNMP compared to other protocols evaluated are that it is a mature, well understood protocol currently deployed in various scenarios. In addition, mature toolsets are available for SNMP managers and agents. SNMP is mainly used for monitoring rather than for configuring network nodes, however, thus reducing its applicability to MIDCOM." Proposed New Text: "The primary advantages of SNMP are that it is a mature, well understood protocol currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents. However, several other factors also affect SNMP's applicability as the MIDCOM protocol: - SNMP is mainly used for monitoring rather than for configuring network nodes, and - SNMPv3 is required in order to meet the security requirements." *************** Although comments on the overall document will be accepted through August 2nd, I would like to request that feedback on this proposed change be provided by 6PM CST Tuesday (30 July) so that we can address any concerns prior to the 2nd; with no response meaning that the proposed text is OK. *************** 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 2 21:02: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 VAA13311 for ; Fri, 2 Aug 2002 21:02:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA19576 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 21:03: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 VAA19454; Fri, 2 Aug 2002 21:03:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19382 for ; Fri, 2 Aug 2002 21:02:57 -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 VAA13244 for ; Fri, 2 Aug 2002 21:01:46 -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 g7312NH16948; Fri, 2 Aug 2002 20:02:23 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 20:02:09 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C811@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" Cc: "'midcom'" Subject: Deadline of Aug. 5th (was RE: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft Date: Fri, 2 Aug 2002 20:02:08 -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 Jim, Just one final "process" note; I missed putting a deadline for your feedback. If you plan on proposing additional new text which would be required for some of your proposed changes, I would need that text by COB Monday, August 5th, so that we have a day or so to discuss on the list prior to me making the final edits. If you could post each individual requirement in separate emails to the list, that will facilitate my tracking of resolution of the discussion. The Subject line should be similar to the following: Protocol eval: Section x.y.z - Thanks, Mary. -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Friday, August 02, 2002 9:48 AM To: Taylor, Tom-PT [CAR:B602:EXCH]; 'James_Renkel@3com.com' Cc: 'midcom' Subject: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft Jim et al, I've not thoroughly reviewed all the proposed changes in detail, but will do so shortly, but I also did want to respond to the Category 4 to which Tom also responded wrt security. We have already discussed and resolved this concern per email discussions based on the -01 version. Refer to: http://www.ietf.org/mail-archive/working-groups/midcom/current/msg02397.html Now, you're also proposing that RSIP be "upgraded" for the security ones that you had scored as Failing to meet compliancy in your analysis. Based upon the text currently in section 2.1.8, 2.3.1, which also applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps. The P+ category would only apply if these changes could be made to RSIP as a natural extension of the protocol with no impact to current users of that protocol (i.e. current users don't make use of the information, and wouldn't be bothered by it being in the messages). There are a many other RSIP scores, many of which were derived from your original analysis, that you're also now proposing changes for: 2.1.2 - The text for this one clearly states that an extension is required. 2.2.1 - The text currently supports the P+ score. 2.2.2 - I think a P+ needs additional text to substantiate that this would be a compatible extension of the protocol (OR we need some text upfront in the RSIP overview describing the extensibility mechanisms defined by RSIP) 2.2.3 - ditto 2.2.7 - I can't quite see how this goes from F to P+; you'll need to provide more text or clarification. 2.2.8 - I think a P+ needs additional text to substantiate that this would be a compatible extension of the protocol 2.2.9 - I don't have a problem with changing this to P. Again, P+ would require additional text to substantiate that this would be a compatible extension of the protocol. 2.2.11 -ditto Upon another quick glance, I think many of the proposed changes for the other protocols are bringing forth issues with other "scores" that we have already discussed (e.g. 2.2.2 for Megaco) Certainly, if there is overwhelming support for your changes, then they can be done, but we've got to have more than one person supporting the change for something that we have previously discussed and I certainly thought had reached concensus on. I won't be responding to each of these that we've already discussed, you can search the email archives, where each has been addressed in a separate email thread. Again, I haven't looked at each in detail, and you may indeed have found some changes which are valid, so I will post separately each of those which I would agree to change provided there is WG concensus (i.e. no negative responses to my proposals). Regards, Mary. -----Original Message----- From: Taylor, Tom-PT [CAR:B602:EXCH] Sent: Friday, August 02, 2002 9:01 AM To: 'James_Renkel@3com.com'; Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft From my point of view you raise two issues I cannot leave unanswered. The first has to do with P+ extensions and your first scoring inconsistency, the second with security. I confess that the need for protocol extensions poses a logical issue: how to treat this need when it affects multiple categories of response. On the one hand, I think it is over-stating things to simply score 1 against each category that depends on the extension. On the other, it is certainly true that, whether you are defining a new MIB, a new DIAMETER application, or a new Megaco package, you imply the need for extra code in both the Agent and the Middlebox above that supplied by the base protocol implementation. I myself would propose adding an evaluation category that specifies the increment to the base protocol implied by its use for MIDCOM. Leaving that aside, any protocol that fails to meet one of the MIDCOM requirements is probably beyond our consideration. On the security issue: you dismiss too quickly those protocols that rely on lower layers for their necessary degree of security. The RFCs specifying these protocols have security sections. The protocol security architecture in each case was arrived at by considering the specific threats that had to be countered in the protocol's domain of application. An architecture that relies on lower layer security is perfectly valid if that meets the requirements for that protocol. What we do have to think about is whether the threats are different for the MIDCOM application from those considered when the candidate protocol was being designed. If so, the security architecture for that protocol may have to be modified to fit MIDCOM application. But the security section of the MIDCOM requirements document reflects the results of the MIDCOM threat analysis. Thus if our candidate protocols, including their specified security architectures, can meet these requirements in a practical way, they must be scored as passing those requirements. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, August 02, 2002 12:45 AM To: Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft Mary (and other middlebox experts), Thank you much for your reply. The clarification of the grading system is especially useful. I had a lot of trouble understanding it before, but I think I got it now. Here's what I now understand the grades to mean: T - Compliance to the requirement with the protocol as is P+ - Compliance to the requirement with an extension to the protocol P - Compliance to the requirement with a change, or an extension that impacts existing users of the protocol F - No compliance (even with extension of the protocol???) Some observations on this: - Since all the protocols are extensible and extensions can generally be made, one way or another, to be backward compatible, I'm surprised that we have any P's of F's. :-) - We seem to have lost the concept of how large an extension needs to be made to add a "thing" to the protocol. Is the protocol close to the requirement and just needs a little extension? Or does the protocol have nothing to offer and the thing has to be added completely? I originally thought that was the idea behind the the T, P and F grades ("How much do ya have to change the protocol to satify the requirement? None, a little, and a lot, respectively"), but I guess we evolved from that, assuming that was the original intention. As you suggested, I went back and looked for what I thought were incon- sistencies in P+ and P grades. Once I got started digging, what I wound up doing was quickly reviewing all the scores for consistency with the grading system as I now understand it and the summary information for each protocol's compliance with each requirement as given in the protocol evaluation I-D (BTW, I used the -02 version of the I-D, without any of the changes that have been discussed since it was published.). The grading inconsistencies that I saw fell into 4 categories: 1. The requirement compliance text for the protocol basically said "This can be done with an extension to this protocol" and the grade was a T, instead of a P+ as I believe it should be. I included the closely related "The protocol does not preclude this extension from being made." in this category. 2. The requirement compliance text for the protocol says the protocol has something here but extension is required and can be made with no impact, but graded it as a P instead of a P+. 3. The requirement compliance text for the protocol says the protocol has nothing here but the necessary extension can be made without impact, and graded it as an F instead of a P+. 4. The requirement compliance text for the protocol says the protocol has nothing here but if ya use TLS or IPsec or whatever for security ya get everything, and graded it as a T. In the last case, I'm not sure what the right score is, but I would suggest at most P+, to distinguish these from protocols that have the right thing here without resorting to TLS or IPsec or whatever for security, which I think should get a T grade. (For consistency, I considered grades of F (Honestly given, in my opinion, but I could be wrong.) but the requirement could be fulfilled with TLS or IPsec or whatever for security, hence now graded P+ for consistency, as instances of this case also.) I also found a few other what I believe to be inconsistencies, at least based on the scoring system as I now understand it. Call this category 5. I list the inconsistencies I found at the end of this message, but here's some statistics. Take 'em for whatever ya think they're worth. Out of a total of 135 scores (27 requirements times 5 protocols) I found what I thought were 31 inconsistencies. That's just less than 23%. The number of inconsistencies by category by protocol are: Category SNMP RSIP MEGACO DIAMETER COPS Total -------- ---- ---- ------ -------- ---- ----- 1 1 0 3 3 1 8 2 0 2 0 1 0 3 3 0 4 0 0 0 4 4 0 5 4 5 0 14 5 0 2 0 0 0 2 -- -- -- -- -- -- Total 1 13 7 9 1 31 The resulting adjustments in protocols scores are: Protocol T P+ P F -------- --- --- --- --- SNMP - 1 + 1 RSIP + 2 +10 - 3 - 9 MEGACO - 7 + 7 DIAMETER - 8 + 9 - 1 COPS - 1 + 1 --- --- --- --- Total -15 +28 - 4 - 9 And the resulting protocol scores are: Protocol T P+ P F Total -------- --- --- --- --- ----- SNMP 18 9 0 0 27 RSIP 14 13 0 0 27 MEGACO 13 11 2 1 27 DIAMETER 13 13 1 0 27 COPS 19 6 1 1 27 --- --- --- --- --- Total 77 52 4 2 135 This was done real quick, so there's probably still stuff not right, but now, at least to me, the numbers better match the general feeling I get when reading the I-D. Comments expected and welcome. Jim ================ Inconsistencies I found in the MIDCOM protocol evaluation grades (This was composed with tab stops every 8 characters.) Score Require- ------------------- Inconsistency ment Protocol Was Should be Category -------- -------- --- --------- -------- 2.1.2 RSIP P T 5 2.1.8 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.2.1 RSIP P+ T 5 2.2.2 SNMP T P+ 1 RSIP P P+ 2 MEGACO T P+ 1 DIAMETER T P+ 1 2.2.3 RSIP P P+ 3 2.2.4 MEGACO T P+ 1 DIAMETER T P+ 1 2,2,6 DIAMETER T P+ 1 COPS T P+ 1 2.2.7 RSIP F P+ 3 DIAMETER T P+ 1 2.2.8 RSIP P P+ 2 MEGACO T P+ 1 2.2.9 RSIP F P+ 3 2.2.11 RSIP F P+ 3 2.3.1 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.2 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.3 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.4 RSIP F P+ 4 DIAMETER T P+ 4 _______________________________________________ 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 Aug 2 21:54:27 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 VAA14872 for ; Fri, 2 Aug 2002 21:54:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA20786 for midcom-archive@odin.ietf.org; Fri, 2 Aug 2002 21:55: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 VAA20724; Fri, 2 Aug 2002 21:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA20695 for ; Fri, 2 Aug 2002 21:51:31 -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 VAA14691 for ; Fri, 2 Aug 2002 21:50:19 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g731oxQ23381 for ; Fri, 2 Aug 2002 21:50:59 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 21:50:59 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A74B@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Mary Barnes" , "'midcom'" Cc: "Cedric Aoun" , "Sanjoy Sen" Date: Fri, 2 Aug 2002 21:50:59 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Protocol eval: 2.2.8 - Megaco - Question as to whether "Trans port of filtering rules" is fully supported in current protocol 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 Transport of filtering rules in Megaco definitely requires the definition and implementation of a new property, so you could put P+ there. But as I said earlier, we have the problem of assigning the appropriate weight to the requirement to implement an extension to the protocol. -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Friday, August 02, 2002 8:37 PM To: 'midcom' Cc: Aoun, Cedric [GOLF:MA01:EXCH]; Sen, Sanjoy [NGC:B677:EXCH]; Taylor, Tom-PT [CAR:B602:EXCH] Subject: Protocol eval: 2.2.8 - Megaco - Question as to whether "Transport of filtering rules" is fully supported in current protocol Hi all, Per my email response to Jim, I think this may be a valid proposal to change Megaco from "T" to "P+" for requirement 2.2.8 - Transport of Filtering rules. What do the Megaco experts think on this one (I could not find any previous discussion of this)? I would like feedback (positive and/or negative) on this proposed change by COB Monday, August 5th. 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 Sun Aug 4 23:43: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 XAA20547 for ; Sun, 4 Aug 2002 23:43:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA25892 for midcom-archive@odin.ietf.org; Sun, 4 Aug 2002 23:45:08 -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 XAA25849; Sun, 4 Aug 2002 23:42:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA25818 for ; Sun, 4 Aug 2002 23:42:09 -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 XAA20460 for ; Sun, 4 Aug 2002 23:40:57 -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 g753g9a13720 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 4 Aug 2002 20:42:10 -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 g753g4K24221 for ; Sun, 4 Aug 2002 20:42:04 -0700 (PDT) Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft To: "'midcom'" Date: Sun, 4 Aug 2002 22:41:51 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) 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 Mary (and other middlebox experts), I'll respond to your RSIP specific comments in this e-mail, and address general comments separately. My response here assumes the use of the 4 grade grading system that has been agreed to. On 08/02/2002, at 09.48.23 A.M., Mary Barnes wrote, in part: > > Now, you're also proposing that RSIP be "upgraded" for the security > onesthat you had scored as Failing to meet compliancy in your analysis. > Based upon the text currently in section 2.1.8, 2.3.1, which also > applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps. > MEGACO and DIAMETER do not have "native" support for capabilities satisfying these requirements, they depend on operation over, e.g., TLS or IPsec to satisfy them, and they were scored a T. RSIP is no different: no native support; but the cappability can be added by operating over TLS or IPsec; so, it too should be scored a T. All I'm asking for here is consistency of scoring for all the protocols. Additionally, the "native" communications between hosts and RSIP gateways is over tunnels for the data connections. Although not explicitly stated, the preferred operation of the control channel is over that same tunnel. If that tunnel is IPsec, then the control channel is secured. At least with RSIP, the tunnel is already there. At to replacement for the RSIP portions of the text following requirements 2.1.8, and 2.3.1 through 2.3.4, I would suggest: RSIP does not have "native" support for this capability, but the capability can be obtained by operating RSIP over TLS or IPsec. > > The P+ category would only apply if these changes could be made to > RSIP as a natural extension of the protocol with no impact to current > users of that protocol (i.e. current users don't make use of the > information, and wouldn't be bothered by it being in the messages). > If the score for these requirements is not to be T, then .... The first value found in every RSIP message is the version of the protocol being used. RSIP as currently defined is version 1. RSIP, as extended to support the MIDCOM requirements would be version 2. When a host initiates communications with an RSIP gateway / middlebox (The host sends a REGISTER-REQUEST message, and the RSIP gateway / middlebox responds with a REGISTER-RESPONSE if the registration is successful, else an ERROR-RESPONSE.), the host and the RSIP gateway / middlebox would negotiate the version of the RSIP protocol to be used for the session, assuming it is established successfully. I'll give the strongest, most restrictive, least "friendly" version of this negotiation; weaker, less restrictive, more "friendly" versions may be possible. 1. The host sends the REGISTER-REQUEST indicating the version of the protocol that it wishes to use for the session; initially this would presumably be the latest, greatest version of RSIP that it supports; but if it is discovered that that version is not also supported by the RSIP gateway / middlebox, then a lesser version could subsequently be tried; if there is no lesser version supported by the host, then the host and the RSIP gateway / middlebox support no versions in common, and useful communications between them is impossible; 2. If the RSIP gateway / middlebox also supports that version, it continues with processing the request and returns either a REGISTER- RESPONSE or an ERROR-RESPONSE as approriate to the request, but in either case the response's version parameter indicates the version proposed by the host; since the host and RSIP gateway / middlebox both support the same version of RSIP, further useful communication between them is possible. 3. If the RSIP gateway / midldebox does not support the version proposed by the host, it responds with an ERROR-RESPONSE, whose error parameter is set to 106: UNSUPPORTED_RSIP_VERSION and whose version parameter would indicate the greatest version of RSIP less than the proposed version that the RSIP gateway / middlebox *does* support, and the host may try that version or a lesser version that the host supports; if the RSIP gateway / middlebox does not support any version of the protocol less than that proposed, it responds indicating the greatest version it *does* support, indicating that useful communications between them is impossible. This is the traditional "negotiate down" version negotiation scheme. With this scheme the host and the RSIP gateway / middlebox find the greatest version of the protocol that they both support. The implications of this for protocol (re)design are, in the extreme, that each version can be completely different from all other versions so long as the version negotiation mechansims is preserved. Now I would never propose doing that in the extreme, I would try to make new versions as backward compatible as possible on a message by message, parameter by parameter basis. But if ya had to, a new version could be radically different from previous version and still technically be backward compatible. Fortunately, in the case of the adapting RSIP to the MIDCOM requirements, I believe all the extensions are rather natural backward compatible extensions, nothing radical. > > 2.1.2 - The text for this one clearly states that an extension is > required. > This may be a fine point, but the *RSIP framework and semantics* would require an extension, the *protocol* itself would not (BTW, that's what the text for the RSIP evaluation of the requirement says: " ... the RSIP *architecure* could be extended ..." [Emphasis added.]). The extension would be the explicit removal of an unstated (and usually unimplemented!) restriction that an RSIP request must come from the host whose communications would be affected by the request. Or looking at it another way, a given installation's policy may be that RSIP requests must come from the host that is affected. RSIP permits that policy to be enforced, but it also, through it's silent on the matter, allows the opposite policy. I could certainly envision both of these policies with MODCOM, also. So either way ya look at it, the RSIP documentation should be clarified, but no change to the protocol is required. I, being the hard grader that I am and wanting to give the most information on and insight into RSIP as possible, graded this a P. But with the grading system as I now understand it, and for consistency with the way the other protocols were graded, I think that this should be a T. If replacement text is necessary, I would suggest: RSIP allows a client to simultaneously have RSIP sessions with multiple RSIP gateways. > > 2.2.1 - The text currently supports the P+ score. > I scored this a T, which was subsequently lowered to P+, presumably based on the explanation I gave. But if you look carefully at the text I gave, it desribes how the extension mechanism might be used in a number of different ways: defining new messages, parameters, and parameter values; extending existing messages with additional parameters and parameter values, which may be either new or existing; defining a new version number if appropriate. But no backward compatible extension *to the extension mechanism itself* is needed. If an extension to the extension mechanism were needed, then the score should be P+ or P, depending on if the extension to the extension mechanism were backward compatible or not. But since it's not even needed, the score should revert to a T. Additionally, I believe if you compare the facts on extensibility of RSIP to the extensibilities of the other protocols, you would find them the same, although they didn't go into as great a level of detail, and they were scored a T. Perhaps if more specifics were given for the other protocols as were for RSIP, they would also be scored a P or P+. :-) Again, what I'm really looking for here is consistency: with the grading system; and across the protocols. > > 2.2.2 - I think a P+ needs additional text to substantiate that this > would be a compatible extension of the protocol (OR we need some text > upfront in the RSIP overview describing the extensibility mechanisms > defined by RSIP) > 2.2.3 - ditto > Since, in recent semantics discussions, I believe we have agreed that the only ruleset action needed is permit, the statement in the text may be true as it stands. If it is desirable to include some kind of parameter that indicates the type of middlebox being manipulated (NATter, firewall, VPN tunnel switch, etc.), that certainly can added, and in a completely backward compatible way. As I read the text for SNMP and COPS, they seem to imply that they already have this parameter, and therefore deserve a T (But more on this later.). The MEGACO text says multiple middlebox types can be supported when you define the middlebox package for MEGACO, and is scored a T. But an extension to MEGACO (i.e., one or more new packages) is required, so I think this ought to be a P+ (presumably it can be done with backward compatibility). The DIAMETER text says an extension is necessary, and is scored a P, now presumably a P+. But if ya look at the MIDCOM requirements (I'm looking at the -05 draft.), it says under requirement 2.2.2: This states that a the protocol must support rules and actions for a variety of types of middleboxes. According to this as I read it, just having a parameter that distinguishes among types of middleboxes isn't suffucient, ya gotta have rules and actions already defined in the protocol to justify a T score. I don't think this is the case for any of the protocols (Although RSIP probably comes the closest: it does have the notion of rules defined; not actions, but they may not be needed anymore.), so I think the T scores for SNMP and COPS should also be P+. Again, I'm looking for consistency here. All require extension, so all should be graded the same, and I think that's a P+. If the question had simply been "Can ya already distinguish between multiple middlebox types?", then the T scores for SNMP and COPS would be justified. As to 2.2.3, ruleset groups, they can be added compatibly by adding a ruleset identifier parameter to the appropriate RSIP request and response messages. If new operations on rulesets are required beyond those provided by the existing RSIP requests and responses, they can be added compatibly. As to a fuller explanation of the RSIP extension mechanism, I believe that text is already there under requirement 2.2.1. If necessary, maybe that should be moved to the overview (Or a pointer from the overview to the 2.2.1 text could be added.). If we need a fuller or different explanation, let me know and I'll provide it. > > 2.2.7 - I can't quite see how this goes from F to P+; you'll need to > provide more text or clarification. > RSIP ASSIGN_RESPONSEs to successful ASSIGN_REQUESTs include a bindID parameter that uniquely identifies the binding (read "ruleset"). The bindID is specified in subsequent requests, e.g., EXTEND_REQUEST to extend the lease time of a binding, to identify the binding to which the request is to apply. I believe the RSIP specification intended, though never explicitly stated, that further requests on a binding be restricted to the to the host that created the binding; although once again, one might say that that is a matter of installation policy. To clearly satisfy the MIDCOM requirements, the RSIP semantics would be explicitly extended to permit any authorized host to request operations on a binding. As to text to use in the evaluation document, I would suggest: RSIP does not explicitly either permit or preclude an operation on a binding being requested by a host other that the host that created the binding. The RSIP semantics would need to be explicitly extended to permit any authorized host to request operations on a binding. No change to the protocol would be required. BTW, since the "The diameter protocol as currently defined offers no impediment [to] such an operation." and is scored a T, maybe either RSIP should be scored a T or DIAMETER should also be scored a P+? > > 2.2.8 - I think a P+ needs additional text to substantiate that this > would be a compatible extension of the protocol > RSIP would add a new optional enumeration parameter called transportProtocol to the ASSIGN_REQUESTs. If specified, the binding created would apply only to the use of the bound addresses / ports by the specified transport protocol. If not specified, the binding would apply to all use of the bound addresses / ports by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP. BTW, MEGACO is scored a T on this requirement for a package that isn't yet defined. :-( > > 2.2.9 - I don't have a problem with changing this to P. Again, P+ would > require additional text to substantiate that this would be a compatible > extension of the protocol. > 2.2.11 -ditto > RSIP would add a new optional boolean parameter called portOddity to the ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the loacl port's oddity, thus maintaining backward compatibility with the current definition of RSIP. BTW, MEGACO is again scored a T on this requirement for a package that isn't yet defined. :-( Overlapping rulesets may have gone away with recent semantics discussions, but ... RSIP would add a new optional boolean parameter called overlapOK to the ASSIGN_REQUESTs. If specified as TRUE, the binding created may overlap with another existing binding. If not specified (or specified as FALSE), the binding will only be created to not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP. For this requirement, I believe MEGACO was correctly scored as a P+. Whew! I think that addresses all of Mary's response. Commented expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Sun Aug 4 23:51:59 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 XAA20830 for ; Sun, 4 Aug 2002 23:51:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA26240 for midcom-archive@odin.ietf.org; Sun, 4 Aug 2002 23:53: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 XAA26144; Sun, 4 Aug 2002 23:51:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26116 for ; Sun, 4 Aug 2002 23:51:21 -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 XAA20804 for ; Sun, 4 Aug 2002 23:50:09 -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 g753pKa15156 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 4 Aug 2002 20:51:21 -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 g753pFK24727; Sun, 4 Aug 2002 20:51:16 -0700 (PDT) Subject: Re: Deadline of Aug. 5th (was RE: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft To: "Mary Barnes" Cc: "'midcom'" Date: Sun, 4 Aug 2002 22:51:02 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) 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 Mary, Before I saw your last two messages, I sent a single e-mail responding to your first e-mail. I'm travelling tomorrow, but I expect to arrive early enough at my destination that I can respond to the last two e-mails by, say, midnight tomorrow. Jim "Mary Barnes" on 08/02/2002 08:02:08 PM Sent by: "Mary Barnes" To: James Renkel/MW/US/3Com cc: "'midcom'" Subject: Deadline of Aug. 5th (was RE: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft Hi Jim, Just one final "process" note; I missed putting a deadline for your feedback. If you plan on proposing additional new text which would be required for some of your proposed changes, I would need that text by COB Monday, August 5th, so that we have a day or so to discuss on the list prior to me making the final edits. If you could post each individual requirement in separate emails to the list, that will facilitate my tracking of resolution of the discussion. The Subject line should be similar to the following: Protocol eval: Section x.y.z - Thanks, Mary. -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Friday, August 02, 2002 9:48 AM To: Taylor, Tom-PT [CAR:B602:EXCH]; 'James_Renkel@3com.com' Cc: 'midcom' Subject: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft Jim et al, I've not thoroughly reviewed all the proposed changes in detail, but will do so shortly, but I also did want to respond to the Category 4 to which Tom also responded wrt security. We have already discussed and resolved this concern per email discussions based on the -01 version. Refer to: http://www.ietf.org/mail-archive/working-groups/midcom/current/msg02397.html Now, you're also proposing that RSIP be "upgraded" for the security ones that you had scored as Failing to meet compliancy in your analysis. Based upon the text currently in section 2.1.8, 2.3.1, which also applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps. The P+ category would only apply if these changes could be made to RSIP as a natural extension of the protocol with no impact to current users of that protocol (i.e. current users don't make use of the information, and wouldn't be bothered by it being in the messages). There are a many other RSIP scores, many of which were derived from your original analysis, that you're also now proposing changes for: 2.1.2 - The text for this one clearly states that an extension is required. 2.2.1 - The text currently supports the P+ score. 2.2.2 - I think a P+ needs additional text to substantiate that this would be a compatible extension of the protocol (OR we need some text upfront in the RSIP overview describing the extensibility mechanisms defined by RSIP) 2.2.3 - ditto 2.2.7 - I can't quite see how this goes from F to P+; you'll need to provide more text or clarification. 2.2.8 - I think a P+ needs additional text to substantiate that this would be a compatible extension of the protocol 2.2.9 - I don't have a problem with changing this to P. Again, P+ would require additional text to substantiate that this would be a compatible extension of the protocol. 2.2.11 -ditto Upon another quick glance, I think many of the proposed changes for the other protocols are bringing forth issues with other "scores" that we have already discussed (e.g. 2.2.2 for Megaco) Certainly, if there is overwhelming support for your changes, then they can be done, but we've got to have more than one person supporting the change for something that we have previously discussed and I certainly thought had reached concensus on. I won't be responding to each of these that we've already discussed, you can search the email archives, where each has been addressed in a separate email thread. Again, I haven't looked at each in detail, and you may indeed have found some changes which are valid, so I will post separately each of those which I would agree to change provided there is WG concensus (i.e. no negative responses to my proposals). Regards, Mary. -----Original Message----- From: Taylor, Tom-PT [CAR:B602:EXCH] Sent: Friday, August 02, 2002 9:01 AM To: 'James_Renkel@3com.com'; Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft From my point of view you raise two issues I cannot leave unanswered. The first has to do with P+ extensions and your first scoring inconsistency, the second with security. I confess that the need for protocol extensions poses a logical issue: how to treat this need when it affects multiple categories of response. On the one hand, I think it is over-stating things to simply score 1 against each category that depends on the extension. On the other, it is certainly true that, whether you are defining a new MIB, a new DIAMETER application, or a new Megaco package, you imply the need for extra code in both the Agent and the Middlebox above that supplied by the base protocol implementation. I myself would propose adding an evaluation category that specifies the increment to the base protocol implied by its use for MIDCOM. Leaving that aside, any protocol that fails to meet one of the MIDCOM requirements is probably beyond our consideration. On the security issue: you dismiss too quickly those protocols that rely on lower layers for their necessary degree of security. The RFCs specifying these protocols have security sections. The protocol security architecture in each case was arrived at by considering the specific threats that had to be countered in the protocol's domain of application. An architecture that relies on lower layer security is perfectly valid if that meets the requirements for that protocol. What we do have to think about is whether the threats are different for the MIDCOM application from those considered when the candidate protocol was being designed. If so, the security architecture for that protocol may have to be modified to fit MIDCOM application. But the security section of the MIDCOM requirements document reflects the results of the MIDCOM threat analysis. Thus if our candidate protocols, including their specified security architectures, can meet these requirements in a practical way, they must be scored as passing those requirements. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Friday, August 02, 2002 12:45 AM To: Barnes, Mary [NGC:B602:EXCH] Cc: 'midcom' Subject: RE: [midcom] Comments on protocol evaluation draft Mary (and other middlebox experts), Thank you much for your reply. The clarification of the grading system is especially useful. I had a lot of trouble understanding it before, but I think I got it now. Here's what I now understand the grades to mean: T - Compliance to the requirement with the protocol as is P+ - Compliance to the requirement with an extension to the protocol P - Compliance to the requirement with a change, or an extension that impacts existing users of the protocol F - No compliance (even with extension of the protocol???) Some observations on this: - Since all the protocols are extensible and extensions can generally be made, one way or another, to be backward compatible, I'm surprised that we have any P's of F's. :-) - We seem to have lost the concept of how large an extension needs to be made to add a "thing" to the protocol. Is the protocol close to the requirement and just needs a little extension? Or does the protocol have nothing to offer and the thing has to be added completely? I originally thought that was the idea behind the the T, P and F grades ("How much do ya have to change the protocol to satify the requirement? None, a little, and a lot, respectively"), but I guess we evolved from that, assuming that was the original intention. As you suggested, I went back and looked for what I thought were incon- sistencies in P+ and P grades. Once I got started digging, what I wound up doing was quickly reviewing all the scores for consistency with the grading system as I now understand it and the summary information for each protocol's compliance with each requirement as given in the protocol evaluation I-D (BTW, I used the -02 version of the I-D, without any of the changes that have been discussed since it was published.). The grading inconsistencies that I saw fell into 4 categories: 1. The requirement compliance text for the protocol basically said "This can be done with an extension to this protocol" and the grade was a T, instead of a P+ as I believe it should be. I included the closely related "The protocol does not preclude this extension from being made." in this category. 2. The requirement compliance text for the protocol says the protocol has something here but extension is required and can be made with no impact, but graded it as a P instead of a P+. 3. The requirement compliance text for the protocol says the protocol has nothing here but the necessary extension can be made without impact, and graded it as an F instead of a P+. 4. The requirement compliance text for the protocol says the protocol has nothing here but if ya use TLS or IPsec or whatever for security ya get everything, and graded it as a T. In the last case, I'm not sure what the right score is, but I would suggest at most P+, to distinguish these from protocols that have the right thing here without resorting to TLS or IPsec or whatever for security, which I think should get a T grade. (For consistency, I considered grades of F (Honestly given, in my opinion, but I could be wrong.) but the requirement could be fulfilled with TLS or IPsec or whatever for security, hence now graded P+ for consistency, as instances of this case also.) I also found a few other what I believe to be inconsistencies, at least based on the scoring system as I now understand it. Call this category 5. I list the inconsistencies I found at the end of this message, but here's some statistics. Take 'em for whatever ya think they're worth. Out of a total of 135 scores (27 requirements times 5 protocols) I found what I thought were 31 inconsistencies. That's just less than 23%. The number of inconsistencies by category by protocol are: Category SNMP RSIP MEGACO DIAMETER COPS Total -------- ---- ---- ------ -------- ---- ----- 1 1 0 3 3 1 8 2 0 2 0 1 0 3 3 0 4 0 0 0 4 4 0 5 4 5 0 14 5 0 2 0 0 0 2 -- -- -- -- -- -- Total 1 13 7 9 1 31 The resulting adjustments in protocols scores are: Protocol T P+ P F -------- --- --- --- --- SNMP - 1 + 1 RSIP + 2 +10 - 3 - 9 MEGACO - 7 + 7 DIAMETER - 8 + 9 - 1 COPS - 1 + 1 --- --- --- --- Total -15 +28 - 4 - 9 And the resulting protocol scores are: Protocol T P+ P F Total -------- --- --- --- --- ----- SNMP 18 9 0 0 27 RSIP 14 13 0 0 27 MEGACO 13 11 2 1 27 DIAMETER 13 13 1 0 27 COPS 19 6 1 1 27 --- --- --- --- --- Total 77 52 4 2 135 This was done real quick, so there's probably still stuff not right, but now, at least to me, the numbers better match the general feeling I get when reading the I-D. Comments expected and welcome. Jim ================ Inconsistencies I found in the MIDCOM protocol evaluation grades (This was composed with tab stops every 8 characters.) Score Require- ------------------- Inconsistency ment Protocol Was Should be Category -------- -------- --- --------- -------- 2.1.2 RSIP P T 5 2.1.8 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.2.1 RSIP P+ T 5 2.2.2 SNMP T P+ 1 RSIP P P+ 2 MEGACO T P+ 1 DIAMETER T P+ 1 2.2.3 RSIP P P+ 3 2.2.4 MEGACO T P+ 1 DIAMETER T P+ 1 2,2,6 DIAMETER T P+ 1 COPS T P+ 1 2.2.7 RSIP F P+ 3 DIAMETER T P+ 1 2.2.8 RSIP P P+ 2 MEGACO T P+ 1 2.2.9 RSIP F P+ 3 2.2.11 RSIP F P+ 3 2.3.1 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.2 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.3 RSIP F P+ 4 MEGACO T P+ 4 DIAMETER T P+ 4 2.3.4 RSIP F P+ 4 DIAMETER T P+ 4 _______________________________________________ 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 Aug 5 00:36:12 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 AAA21782 for ; Mon, 5 Aug 2002 00:36:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA29323 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 00:37:24 -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 AAA29241; Mon, 5 Aug 2002 00:33: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 AAA29167 for ; Mon, 5 Aug 2002 00:33:13 -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 AAA21725 for ; Mon, 5 Aug 2002 00:32:01 -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 g754XEa20465 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 4 Aug 2002 21:33:15 -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 g754X9K26731 for ; Sun, 4 Aug 2002 21:33:09 -0700 (PDT) To: midcom Date: Sun, 4 Aug 2002 23:32:56 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Comments on protocol evaluation process 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 Middlebox experts, As intimated in several of my recent e-mails to this list, I have a general concern about the protocol evaluation process that we're just finishing. This is beyond any specific issues of what score was given to a protocol for a particular requirement. This concern can perhaps be best expressed as a question. In evaluating these protocols, are we: - trying to get the best insight into and information about the protocols as they exist? or are we - trying to maximize the scores that the protocols receive? I certainly hope that we are trying to do the former, but I fear we are doing the latter. There are two things that cause my fear. The first is the grading system that we are using. After some discussion on the list, the scoring systme that we are now using, as I understand it, is: T - the requirement is satisfied by the protocol as is P+ - the requirement is satisfied when the protocol is extended with a backward compatible extension P - the requirement is satisfied only with a non-backward compatible extension to the protocol F - the requirement can not be met by the protocol, even with an extension (perhaps because the protocol is not extensible) We have a requirement for protocol extensibility, and all the protocols satisfy it. So I don't see how any of these protocols can receive an F score for any other requirement. I mean it's not like middleboxes are made of matter and the protocols of anti-matter so that if ya put them together they explode or something. Since all the protocols were presumably pretty well designed, and extensions can generally be made to be backward compatible, I would be surprised if any scores of P are given. So what we are left with is T and P+. One says the protocol already does something, the other says it can be extended to do so. While this is interesting, this doesn't give the insight to and information about the protocol that I was hoping to get out of this evaluation. I mean, so a protocol gets a P+ score for some requirement. Does that mean that it had nothing, and everything had to be added? Or does it mean that it fell just a smidge short and only a little has to be added? I for one would like to know the difference between these two cases. But the difference is lost with the scoring system we are using. Information of this same kind if further being lost, I believe, by allowing protocols a recieve a T score for a security requirement by saying, "TLS or IPsec provide the capability, so just run the protocol over them." Like all the protocols being extensible, all the protocols can run over TLS or IPsec. But what "native" security capabilities do they have? TLS or IPsec is fine if I need all the security capabilities they offer and I'm willing to pay the price to run them. But what if I don't need all the capabilities they offer or I'm reluctant to pay the price to run them? I'd sure like to know what security I get from a protocol natively, with it running over TLS or IPsec. Equivalently, I'd like to know how much a protocol needs to be extended to get natively a given level of security, just as I'd like to now how much a protocol has to be extended to meet other MIDCOM requifrements. And maybe isn't a protocol that has a particular security capability as a native capability better in some sense than a protocol that has to rely on TLS or IPsec for that capability? I think I'd like to know that. Maybe, at least in this case, that information is contained in the text accompanying the score. But I'd like to see it reflected in the protocols score also. So what to do. Well, what I'd idewally like to see is a protocol evaluation that is scored with this scoring system: T - the requirement is fully satisfied by the protocol as is and without the use of TLS or IPsec P - the requirement is partially met by the protocol as is, without the use of TLS or IPsec F - the requirement is not met by the protocol as is without the use of TLS or IPsec I don't think we should change what we're doing now, or hold it up to add this to it. But, if other folk also think this would be valuable, maybe we should add this later. Comments welcome, expected, and appreciated. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 09:51: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 JAA13110 for ; Mon, 5 Aug 2002 09:51:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03003 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 09:52: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 JAA02947; Mon, 5 Aug 2002 09:50:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02917 for ; Mon, 5 Aug 2002 09:50:32 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12984 for ; Mon, 5 Aug 2002 09:49:17 -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 g75Dms6I008120; Mon, 5 Aug 2002 06:48:54 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AER86178; Mon, 5 Aug 2002 06:44:52 -0700 (PDT) Message-Id: <200208051344.AER86178@mira-sjc5-4.cisco.com> To: James_Renkel@3com.com cc: midcom From: Melinda Shore Subject: Re: [midcom] Comments on protocol evaluation process In-Reply-To: Message from James_Renkel@3com.com of "Sun, 04 Aug 2002 23:32:56 CDT." Date: Mon, 05 Aug 2002 09:46:54 -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 > We have a requirement for protocol extensibility, and all the protocols > satisfy it. So I don't see how any of these protocols can receive an F > score for any other requirement. Just because a protocol is "extensible" doesn't mean that it's arbitrarily extensible or that an extension in a particular direction isn't awkward or unidiomatic. On the scoring system: what we're trying to do is get a rough, general sense of how closely a particular protocol matches the requirements and framework we've established. This process is necessarily not particularly nuanced, and I don't think that's a bad thing, either. After all, one of the first things we're going to have to do is NOT to choose the closest fit, but rather to eliminate the weakest candidates. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 10:06: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 KAA14221 for ; Mon, 5 Aug 2002 10:06:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04423 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 10:07: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 KAA04359; Mon, 5 Aug 2002 10:05:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04326 for ; Mon, 5 Aug 2002 10:04:59 -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 KAA14018 for ; Mon, 5 Aug 2002 10:03:44 -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 g75E4ZH21513 for ; Mon, 5 Aug 2002 09:04:35 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 09:04:21 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A63404@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "Mary Barnes" , "'midcom'" Cc: "Cedric Aoun" , "Tom-PT Taylor" Date: Mon, 5 Aug 2002 09:04:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23C88.FD63CC30" Subject: [midcom] RE: Protocol eval: 2.2.8 - Megaco - Question as to whether "Trans port of filtering rules" is fully supported in current protocol 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_01C23C88.FD63CC30 Content-Type: text/plain; charset="iso-8859-1" The reason why this was made T (in case of Megaco) was because we interpreted this requirement as the ability of the protocol to *transport* rulesets. However, since other evaluaters interpreted the requirement slightly differently, I'm not against the proposed change. -Sanjoy > -----Original Message----- > From: Barnes, Mary [NGC:B602:EXCH] > Sent: Friday, August 02, 2002 7:37 PM > To: 'midcom' > Cc: Aoun, Cedric [GOLF:MA01:EXCH]; Sen, Sanjoy > [NGC:B677:EXCH]; Taylor, > Tom-PT [CAR:B602:EXCH] > Subject: Protocol eval: 2.2.8 - Megaco - Question as to whether > "Transport of filtering rules" is fully supported in current protocol > > > Hi all, > > Per my email response to Jim, I think this may be a valid > proposal to change Megaco from "T" to "P+" for requirement > 2.2.8 - Transport of Filtering rules. > > What do the Megaco experts think on this one (I could not > find any previous discussion of this)? > > I would like feedback (positive and/or negative) on this > proposed change by > COB Monday, August 5th. > > Regards, > Mary H. Barnes > mbarnes@nortelnetworks.com > 972-684-5432 > Wireless 817-703-4806 > > > > ------_=_NextPart_001_01C23C88.FD63CC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Protocol eval: 2.2.8 - Megaco - Question as to whether = "Transport of filtering rules" is fully supported in current = protocol

The reason why this was made T (in case of Megaco) = was because we interpreted this requirement as the ability of the = protocol to *transport* rulesets. However, since other evaluaters = interpreted the requirement slightly differently, I'm not against the = proposed change.

-Sanjoy

> -----Original Message-----
> From: Barnes, Mary [NGC:B602:EXCH]
> Sent: Friday, August 02, 2002 7:37 PM
> To: 'midcom'
> Cc: Aoun, Cedric [GOLF:MA01:EXCH]; Sen, Sanjoy =
> [NGC:B677:EXCH]; Taylor,
> Tom-PT [CAR:B602:EXCH]
> Subject: Protocol eval: 2.2.8 - Megaco - = Question as to whether
> "Transport of filtering rules" is = fully supported in current protocol
>
>
> Hi all,
>
> Per my email response to Jim, I think this may = be a valid
> proposal to change Megaco from "T" to = "P+" for requirement
> 2.2.8 - Transport of Filtering rules.  =
>
> What do the Megaco experts think on this one (I = could not
> find any previous discussion of this)?
>
> I would like feedback (positive and/or = negative) on this
> proposed change by
> COB Monday, August 5th.
>
> Regards,
> Mary H. Barnes
> mbarnes@nortelnetworks.com
> 972-684-5432
> Wireless 817-703-4806
>
>
>
>

------_=_NextPart_001_01C23C88.FD63CC30-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 14:08: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 OAA25220 for ; Mon, 5 Aug 2002 14:08:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19746 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 14:09:50 -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 OAA19639; Mon, 5 Aug 2002 14:08:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19611 for ; Mon, 5 Aug 2002 14:08:29 -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 OAA25187 for ; Mon, 5 Aug 2002 14:07:17 -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 g75I8AH25643; Mon, 5 Aug 2002 13:08:10 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 13:07:55 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C81A@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 13:07:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Protocol Eval - 2.2.8, 2.2.9 and 2.2.11 - RSIP and others (w as RE: Proposed changes to RSIP 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 Hi all, I'm going to respond to a few of these requested changes for RSIP for 2.2.8, 2.2.9 and 2.2.11, and comments on the other protocols, directly inline here. The remainder I am going to post separtely so that they can be tracked more easily, thus, I've deleted most of Jim's original email. Feedback on these proposed changes is requested by noon CST on Tuesday, August 6th. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ---text deleted---- > > 2.2.8 - I think a P+ needs additional text to substantiate that this > would be a compatible extension of the protocol > RSIP would add a new optional enumeration parameter called transportProtocol to the ASSIGN_REQUESTs. If specified, the binding created would apply only to the use of the bound addresses / ports by the specified transport protocol. If not specified, the binding would apply to all use of the bound addresses / ports by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP. [MB] I propose to add the following text (reworded for consistency) to RSIP and change to a P+: "To support this requirement, a new optional enumeration parameter, transportProtocol, can be added to the RSIP ASSIGN_REQUESTs. When the parameter is included, the binding created applies only to the use of the bound addresses and ports, by the specific transportProtocol. When the parameter is not included, the binding applies to the use of all the bound addresses and ports, by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP." [/MB] BTW, MEGACO is scored a T on this requirement for a package that isn't yet defined. :-( [MB] Yes, this was the one issue, that I acknowledged in response to your original email, that I thought was valid, thus I had posted separately and we have agreed to change MEGACO to a P+. [/MB] > > 2.2.9 - I don't have a problem with changing this to P. Again, P+ would > require additional text to substantiate that this would be a compatible > extension of the protocol. > 2.2.11 -ditto > RSIP would add a new optional boolean parameter called portOddity to the ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the loacl port's oddity, thus maintaining backward compatibility with the current definition of RSIP. [MB] I propose to add the following text (reworded for consistency) to RSIP and change to a P+: "To support this requirement, a new optional boolean parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the remote port number of the binding created would have the same oddity as the local port. If the parameter is not specified, or is FALSE, the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP." [/MB] BTW, MEGACO is again scored a T on this requirement for a package that isn't yet defined. :-( [MB] The version of the document that I have already shows Megaco as a P+ for 2.2.9, as well as 2.2.11. [/MB] Overlapping rulesets may have gone away with recent semantics discussions, but ... RSIP would add a new optional boolean parameter called overlapOK to the ASSIGN_REQUESTs. If specified as TRUE, the binding created may overlap with another existing binding. If not specified (or specified as FALSE), the binding will only be created to not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP. [MB] I propose to add the following text (reworded for consistency) to RSIP and change to a P+: "To support this requirement, a new optional boolean parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the binding may overlap with an existing binding. If the parameter is unspecified, or is FALSE, the binding will not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP." [/MB] For this requirement, I believe MEGACO was correctly scored as a P+. Whew! I think that addresses all of Mary's response. Commented expected and welcome. Jim _______________________________________________ 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 Aug 5 14:30:57 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 OAA26041 for ; Mon, 5 Aug 2002 14:30:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21553 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 14:32:08 -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 OAA20885; Mon, 5 Aug 2002 14:29:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20850 for ; Mon, 5 Aug 2002 14:29:45 -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 OAA25868 for ; Mon, 5 Aug 2002 14:28:32 -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 g75ITQH28516; Mon, 5 Aug 2002 13:29:26 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 13:29:11 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C81B@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 13:29:09 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol Eval - 2.2.7 - RSIP (was RE: Proposed changes to RSIP ev aluation ... 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, Per my previous email, I've broken the comments down and will reply to them in separate emails to facilitate my tracking of proposed changes and WG agreement. My comments below: [MB]. WG feedback on this would be appreciated prior to noon CST on Tuesday, August 6th. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ---text deleted---- > > 2.2.7 - I can't quite see how this goes from F to P+; you'll need to > provide more text or clarification. > RSIP ASSIGN_RESPONSEs to successful ASSIGN_REQUESTs include a bindID parameter that uniquely identifies the binding (read "ruleset"). The bindID is specified in subsequent requests, e.g., EXTEND_REQUEST to extend the lease time of a binding, to identify the binding to which the request is to apply. I believe the RSIP specification intended, though never explicitly stated, that further requests on a binding be restricted to the to the host that created the binding; although once again, one might say that that is a matter of installation policy. To clearly satisfy the MIDCOM requirements, the RSIP semantics would be explicitly extended to permit any authorized host to request operations on a binding. As to text to use in the evaluation document, I would suggest: RSIP does not explicitly either permit or preclude an operation on a binding being requested by a host other that the host that created the binding. The RSIP semantics would need to be explicitly extended to permit any authorized host to request operations on a binding. No change to the protocol would be required. [MB] I can see that we could change RSIP to P for this one based upon the text. I think this makes it consistent with the Megaco and COPS evaluations of this requirement. Per my note below, the Diameter issue is being tracked in a separate email thread. I would propose the following re-wording for the text: " RSIP neither explicitly permits nor precludes an operation on a binding by a host that had not originally create the binding. However, to support this requirement, the RSIP semantics must be extended to explicitly permit any authorized host to request operations on a binding; this does not require a change to the protocol." [/MB] BTW, since the "The diameter protocol as currently defined offers no impediment [to] such an operation." and is scored a T, maybe either RSIP should be scored a T or DIAMETER should also be scored a P+? [MB] This is being tracked in a separate email thread per my response to your original email. If you still have concerns that this requirement also has a semantic impact on Diameter, please post them in response to that email thread. [/MB] _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 15:06: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 PAA27860 for ; Mon, 5 Aug 2002 15:06:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23918 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 15:08:06 -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 PAA23704; Mon, 5 Aug 2002 15:03:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23678 for ; Mon, 5 Aug 2002 15:03:41 -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 PAA27688 for ; Mon, 5 Aug 2002 15:02:27 -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 g75J3LH10413; Mon, 5 Aug 2002 14:03:21 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 14:03:06 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C81C@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 14:03:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23CB2.B8B4B110" Subject: [midcom] Protocol Eval - 2.2.1 - RSIP Extensibility - P+ -> T ? ( was RE : Proposed changes to RSIP 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 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_01C23CB2.B8B4B110 Content-Type: text/plain; charset="iso-8859-1" Hi all, Again, text deleted to isolate issue wrt 2.2.1 and again feedback is requested ASAP; ideally by COB on Tuesday, August 6th. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft > > 2.2.1 - The text currently supports the P+ score. > I scored this a T, which was subsequently lowered to P+, presumably based on the explanation I gave. But if you look carefully at the text I gave, it desribes how the extension mechanism might be used in a number of different ways: defining new messages, parameters, and parameter values; extending existing messages with additional parameters and parameter values, which may be either new or existing; defining a new version number if appropriate. [MB] This was lowered to a P+ based upon WG mailing list feedback (from more than one person, actually) on the -00 version of the document; that email suggested further discussion, however, there was none. So, per my summary email for the changes for -01, I made this change (and received no response to that email). For the earlier versions, the process we've been following is that unless folks disagree with what's been posted, I make the proposed change based upon mailing list discussion. Since, ideally, we'd like this version to be ready for WGLC, I'm attempting to provide a complete "heads-up" on the exact content of the new document, so there will be no surprises. What I would propose is to open this again for mailing list discussion, to see if anyone else is in support of changing this to a "T". [/MB] But no backward compatible extension *to the extension mechanism itself* is needed. If an extension to the extension mechanism were needed, then the score should be P+ or P, depending on if the extension to the extension mechanism were backward compatible or not. But since it's not even needed, the score should revert to a T. Additionally, I believe if you compare the facts on extensibility of RSIP to the extensibilities of the other protocols, you would find them the same, although they didn't go into as great a level of detail, and they were scored a T. Perhaps if more specifics were given for the other protocols as were for RSIP, they would also be scored a P or P+. :-) Again, what I'm really looking for here is consistency: with the grading system; and across the protocols. ------_=_NextPart_001_01C23CB2.B8B4B110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protocol Eval - 2.2.1 - RSIP Extensibility - P+ -> T ? ( = was RE: Proposed changes to RSIP evaluation

Hi all,

Again, text deleted to isolate issue wrt 2.2.1 and = again feedback is requested ASAP; ideally by  COB on Tuesday, = August 6th.

Regards,
Mary.

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: Sunday, August 04, 2002 10:42 PM
To: 'midcom'
Subject: Re: Proposed changes to RSIP evaluation = (was RE: [midcom]
Comments on protocol evaluation draft
>
> 2.2.1 - The text currently supports the P+ = score.
>

I scored this a T, which was subsequently lowered to = P+, presumably
based on the explanation I gave. But if you look = carefully at the text
I gave, it desribes how the extension mechanism = might be used in a number
of different ways: defining new messages, = parameters, and parameter
values; extending existing messages with additional = parameters and
parameter values, which may be either new or = existing; defining a new
version number if appropriate.

[MB] This was lowered to a P+ based upon WG mailing = list feedback (from more than one person, actually) on the -00 version = of the document; that email suggested further discussion, however, = there was none.  So, per my summary email for the changes for -01, = I made this change (and received no response to that email). For the = earlier versions, the process we've been following is that unless folks = disagree with what's been posted, I make the proposed change based upon = mailing list discussion. Since, ideally, we'd like this version to be = ready for WGLC, I'm attempting to provide a complete = "heads-up" on the exact content of the new document, so there = will be no surprises. 

What I would propose is to open this again for = mailing list discussion, to see if anyone else is in support of = changing this to a "T".

[/MB]

But no backward compatible extension *to the = extension mechanism itself*
is needed. If an extension to the extension = mechanism were needed, then
the score should be P+ or P, depending on if the = extension to the extension
mechanism were backward compatible or not. But since = it's not even
needed, the score should revert to a T.

Additionally, I believe if you compare the facts on = extensibility of RSIP
to the extensibilities of the other protocols, you = would find them the
same, although they didn't go into as great a level = of detail, and they
were scored a T. Perhaps if more specifics were = given for the other
protocols as were for RSIP, they would also be = scored a P or P+. :-)

Again, what I'm really looking for here is = consistency: with the grading
system; and across the protocols.

------_=_NextPart_001_01C23CB2.B8B4B110-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 15:45:52 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 PAA29151 for ; Mon, 5 Aug 2002 15:45:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25604 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 15:47:04 -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 PAA25469; Mon, 5 Aug 2002 15:42: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 PAA25441 for ; Mon, 5 Aug 2002 15:42:42 -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 PAA29010 for ; Mon, 5 Aug 2002 15:41:29 -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 g75JgOH15710; Mon, 5 Aug 2002 14:42:24 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 14:42:07 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C81F@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 14:41:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol eval: RSIP 2.1.8 and 2.3.1 - 2.3.4 - Security F-> T (was RE: Proposed changes to RSIP 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 Hi all, Given that the RSIP protocol does define the use of IPSEC, I would agree that these could be changed to T. The current text description in section 2.3.1 is fairly informative, do you really want to replace that with the single sentence or do you want the information combined? Also, I did not see any reference to TLS in the RSIP RFCs, so I would propose to just add the reference to IPSec, or perhaps I somehow missed the reference. Note, that this would also require a change to the conclusion. Again, WG feedback (i.e. if you don't agree with changing these to T), should be sent by COB on Tuesday, August 5th. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ---text deleted ----------- > > Now, you're also proposing that RSIP be "upgraded" for the security > onesthat you had scored as Failing to meet compliancy in your analysis. > Based upon the text currently in section 2.1.8, 2.3.1, which also > applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps. > MEGACO and DIAMETER do not have "native" support for capabilities satisfying these requirements, they depend on operation over, e.g., TLS or IPsec to satisfy them, and they were scored a T. RSIP is no different: no native support; but the cappability can be added by operating over TLS or IPsec; so, it too should be scored a T. All I'm asking for here is consistency of scoring for all the protocols. Additionally, the "native" communications between hosts and RSIP gateways is over tunnels for the data connections. Although not explicitly stated, the preferred operation of the control channel is over that same tunnel. If that tunnel is IPsec, then the control channel is secured. At least with RSIP, the tunnel is already there. At to replacement for the RSIP portions of the text following requirements 2.1.8, and 2.3.1 through 2.3.4, I would suggest: RSIP does not have "native" support for this capability, but the capability can be obtained by operating RSIP over TLS or IPsec. > > The P+ category would only apply if these changes could be made to > RSIP as a natural extension of the protocol with no impact to current > users of that protocol (i.e. current users don't make use of the > information, and wouldn't be bothered by it being in the messages). > If the score for these requirements is not to be T, then .... ---Remainder of email thread deleted---- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 15:46: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 PAA29180 for ; Mon, 5 Aug 2002 15:46:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25645 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 15:48: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 PAA24891; Mon, 5 Aug 2002 15:31: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 PAA24853 for ; Mon, 5 Aug 2002 15:31:08 -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 PAA28605 for ; Mon, 5 Aug 2002 15:29: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 g75JTvH14045; Mon, 5 Aug 2002 14:29:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 14:29:42 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C81E@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 14:29:38 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol eval: 2.1.2 - RSIP - P -> T? (was RE: Proposed changes t o RSIP 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 Hi all, My responses to 2.1.2 from Jim's response to email thread. Again, feedback on this is requested from the WG by COB on Tuesday, August 6th. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ----text deleted ----- > > 2.1.2 - The text for this one clearly states that an extension is > required. > This may be a fine point, but the *RSIP framework and semantics* would require an extension, the *protocol* itself would not (BTW, that's what the text for the RSIP evaluation of the requirement says: " ... the RSIP *architecure* could be extended ..." [Emphasis added.]). The extension would be the explicit removal of an unstated (and usually unimplemented!) restriction that an RSIP request must come from the host whose communications would be affected by the request. [MB] Again, this was one that had been discussed on the mailing list. This was lowered to a P+ based upon WG mailing list feedback (from more than one person, actually) on the -00 version of the document. So, per my summary email for the changes for -01 (on June 15th), I made this change (and received no response to that email). What I would propose is to open this again for mailing list discussion, to see if anyone else is in support of changing this to a "T". [/MB] Or looking at it another way, a given installation's policy may be that RSIP requests must come from the host that is affected. RSIP permits that policy to be enforced, but it also, through it's silent on the matter, allows the opposite policy. I could certainly envision both of these policies with MODCOM, also. So either way ya look at it, the RSIP documentation should be clarified, but no change to the protocol is required. I, being the hard grader that I am and wanting to give the most information on and insight into RSIP as possible, graded this a P. But with the grading system as I now understand it, and for consistency with the way the other protocols were graded, I think that this should be a T. If replacement text is necessary, I would suggest: RSIP allows a client to simultaneously have RSIP sessions with multiple RSIP gateways. ----Remainder deleted ----- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 16:55: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 QAA01668 for ; Mon, 5 Aug 2002 16:55:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28784 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 16:56: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 QAA28722; Mon, 5 Aug 2002 16:53: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 QAA28693 for ; Mon, 5 Aug 2002 16:53:03 -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 QAA01512 for ; Mon, 5 Aug 2002 16:51:49 -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 g75KqaH02712; Mon, 5 Aug 2002 15:52:36 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 15:52:21 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C820@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 15:52:19 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol Eval: 2.2.2 - RSIP (was RE: Proposed changes to RSIP ev aluation 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 don't have a problem changing 2.2.2 for RSIP to P+, IFF there is agreement by the WG to change 2.2.1 Extensibility to T for RSIP. However, we've already spent some time debating 2.2.2 for Megaco (refer to the email threads with 2.2.2 in the title) and finally agreeing on T. As well, we've previously discussed SNMP, with agreement that it is a T. And to a lesser extent, there has also been discussion on COPS. Again, I don't think we should revert these previous agreements unless there is additional support to do so. Again, WG feedback by COB Tuesday, August 6th is appreciated. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ---text deleted ----- > > 2.2.2 - I think a P+ needs additional text to substantiate that this > would be a compatible extension of the protocol (OR we need some text > upfront in the RSIP overview describing the extensibility mechanisms > defined by RSIP) > 2.2.3 - ditto > Since, in recent semantics discussions, I believe we have agreed that the only ruleset action needed is permit, the statement in the text may be true as it stands. If it is desirable to include some kind of parameter that indicates the type of middlebox being manipulated (NATter, firewall, VPN tunnel switch, etc.), that certainly can added, and in a completely backward compatible way. As I read the text for SNMP and COPS, they seem to imply that they already have this parameter, and therefore deserve a T (But more on this later.). The MEGACO text says multiple middlebox types can be supported when you define the middlebox package for MEGACO, and is scored a T. But an extension to MEGACO (i.e., one or more new packages) is required, so I think this ought to be a P+ (presumably it can be done with backward compatibility). The DIAMETER text says an extension is necessary, and is scored a P, now presumably a P+. But if ya look at the MIDCOM requirements (I'm looking at the -05 draft.), it says under requirement 2.2.2: This states that a the protocol must support rules and actions for a variety of types of middleboxes. According to this as I read it, just having a parameter that distinguishes among types of middleboxes isn't suffucient, ya gotta have rules and actions already defined in the protocol to justify a T score. I don't think this is the case for any of the protocols (Although RSIP probably comes the closest: it does have the notion of rules defined; not actions, but they may not be needed anymore.), so I think the T scores for SNMP and COPS should also be P+. Again, I'm looking for consistency here. All require extension, so all should be graded the same, and I think that's a P+. If the question had simply been "Can ya already distinguish between multiple middlebox types?", then the T scores for SNMP and COPS would be justified. ---Remaining text deleted ---- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 17:06: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 RAA01976 for ; Mon, 5 Aug 2002 17:06:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00173 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 17:07: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 RAA00098; Mon, 5 Aug 2002 17:06: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 RAA00070 for ; Mon, 5 Aug 2002 17:06:00 -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 RAA01931 for ; Mon, 5 Aug 2002 17:04:45 -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 g75L5dH11533; Mon, 5 Aug 2002 16:05:40 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 16:05:25 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C821@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'James_Renkel@3com.com'" , "'midcom'" Date: Mon, 5 Aug 2002 16:05:22 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol Eval: 2.2.3 - RSIP - F -> P or P+ ( was RE: Proposed cha nges to RSIP 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 Hi all, One note on this one is that Jim's original email ranking from which this thread started was incorrect in that RSIP was indicated to be Failing this requirement, although his category tag was correct: 3. At a minimum, I would agree that it should be changed to a P. Per my original email response to Jim, it needs further substantiation for P+ and in particular, like 2.2.2, I think it can only be changed to a P+ if we get WG concensus on changing 2.2.1 (Extensibility) to T for RSIP. Again, this is open for discussion. To summarize, if no feedback is received by COB August 6th, then I propose to change 2.2.3 to P for RSIP. If we get agreement that 2.2.1 is a T, then I think we can agree to change 2.2.3 to P+, unless I get WG feedback to the contrary. Regards, Mary. P.S. And this is the last of my postings in response to Jim's email, so let me know if you find that I've missed responding individually to something. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ----text deleted ----- > > 2.2.2 - I think a P+ needs additional text to substantiate that this > would be a compatible extension of the protocol (OR we need some text > upfront in the RSIP overview describing the extensibility mechanisms > defined by RSIP) > 2.2.3 - ditto > ----text deleted ----- As to 2.2.3, ruleset groups, they can be added compatibly by adding a ruleset identifier parameter to the appropriate RSIP request and response messages. If new operations on rulesets are required beyond those provided by the existing RSIP requests and responses, they can be added compatibly. As to a fuller explanation of the RSIP extension mechanism, I believe that text is already there under requirement 2.2.1. If necessary, maybe that should be moved to the overview (Or a pointer from the overview to the 2.2.1 text could be added.). If we need a fuller or different explanation, let me know and I'll provide it. ---Remaining text deleted --- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37:34 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 SAA05935 for ; Mon, 5 Aug 2002 18:37:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04530 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38:46 -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 SAA04453; Mon, 5 Aug 2002 18:34: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 SAA04336 for ; Mon, 5 Aug 2002 18:34:33 -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 SAA05783 for ; Mon, 5 Aug 2002 18:33:19 -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 g75MYGT22600 for ; Mon, 5 Aug 2002 15:34:17 -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 g75MYBK17131 for ; Mon, 5 Aug 2002 15:34:11 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 17:04:55 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP can easily be extended to preserve port number oddity when creating bindings. RSIP currently does not guarantee preservation of port number oddity. RSIP would add a new optional boolean parameter called portOddity to the ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the loacl port's oddity, thus maintaining backward compatibility with the current definition of RSIP. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: RSIP can be extended to preserve the port number oddity of a binding by including an optional boolean portOddity parameter on ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37:34 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 SAA05941 for ; Mon, 5 Aug 2002 18:37:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04541 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38:46 -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 SAA04221; Mon, 5 Aug 2002 18:34:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04040 for ; Mon, 5 Aug 2002 18:34:15 -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 SAA05728 for ; Mon, 5 Aug 2002 18:33:02 -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 g75MYET22575 for ; Mon, 5 Aug 2002 15:34:15 -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 g75MY9K17106 for ; Mon, 5 Aug 2002 15:34:10 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 13:28:01 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score 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 Middlebox experts, As I have said in a previous e-mail, RSIP clearly was designed to be extensible. The evaluation text of RSIP for this requirement explains how this works in more detail than the evaluation text for the other protocols. RSIP is currently scored a P+ on this requirement when it should, in my opinion, clearly be a T: it has a degree of extensibility comparable to the other protocols, and they were scored a T. I propose that the score of RSIP for this requirement be changed to T. I don't think there's any need to change the expanatory text. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37:35 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 SAA05963 for ; Mon, 5 Aug 2002 18:37:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04552 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38: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 SAA04128; Mon, 5 Aug 2002 18: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 SAA04033 for ; Mon, 5 Aug 2002 18:34:15 -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 SAA05722 for ; Mon, 5 Aug 2002 18:33:02 -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 g75MYDT22571 for ; Mon, 5 Aug 2002 15:34:14 -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 g75MY9K17098 for ; Mon, 5 Aug 2002 15:34:09 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 13:11:54 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.1.8 and 2.3.1 through 2.3.4 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP's capabiltiies are no different w.r.t.: - mutual authentication (2.1.8) than MEGACO and DIAMETER; - message authentication, confidentiality, and integrity (2.3.1) than MEGACO and DIAMETER; - optional confidentiality protection (2.3.2) than MEGACO and perhaps DIAMETER; - operation across untrusted domains (2.3.3) than MEGACO and DIAMETER; and - mitigation against replay attacks (2.3.4) than perhaps MEGACO and DIAMETER. (The "perhaps" in the above statements indicates that the protocol may have some native capabiltiies in the area.) Those protocols were scored T for those requirements by suggesting that the requirement could be completely satisfied if the protocol were operated over TLS or IPsec. The same is true of RSIP: all these requirements may be completely satisfied by operating RSIP over TLS or IPsec. For consistency of scoring, I propose that the scores of RSIP for these requirements be changed to T, and the RSIP text under these requirements be changed to: RSIP does not have "native" support for this capability, but the capability can be obtained by operating RSIP over TLS or IPsec. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37: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 SAA05991 for ; Mon, 5 Aug 2002 18:37:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04574 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38:50 -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 SAA04134; Mon, 5 Aug 2002 18:34:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04039 for ; Mon, 5 Aug 2002 18:34:15 -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 SAA05727 for ; Mon, 5 Aug 2002 18:33:02 -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 g75MYET22573 for ; Mon, 5 Aug 2002 15:34:14 -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 g75MY9K17101 for ; Mon, 5 Aug 2002 15:34:09 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 16:31:28 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP clearly allows a host to relate to multiple middleboxes. In the interest of providing as much insight into and information about RSIP as possible, I pointed out that, typically, a request for an RSIP operation comes from the host affected by the operation. But requests for operations affecting one host are permitted to come from a second host if that is consistent with local policy. But this in no way affects the ability of an RSIP client to have simultaneous sessions with multiple gateways. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a T. I propose that the score of RSIP for this requirement be changed to T, and the RSIP text under this requirement be changed to: RSIP allows a client to simultaneously have RSIP sessions with multiple RSIP gateways. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37: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 SAA05992 for ; Mon, 5 Aug 2002 18:37:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04580 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38:50 -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 SAA04299; Mon, 5 Aug 2002 18:34: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 SAA04150 for ; Mon, 5 Aug 2002 18:34:21 -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 SAA05736 for ; Mon, 5 Aug 2002 18:33:07 -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 g75MYGT22595 for ; Mon, 5 Aug 2002 15:34:17 -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 g75MYBK17126 for ; Mon, 5 Aug 2002 15:34:11 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 16:51:47 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP implicitly leaves to local policy the legality of operations on a binding by a host other than the one that created it. Although no change to the RSIP syntax is required, the RSIP specification should be clarified on this issue. Perhaps this would be considered a (backward compatible) change to the RSIP semantics. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+ (if not a T). I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: RSIP does not explicitly either permit or preclude an operation on a binding being requested by a host other that the host that created the binding. The RSIP semantics would need to be explicitly extended to permit any authorized host to request operations on a binding. No change to the protocol would be required. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37: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 SAA06029 for ; Mon, 5 Aug 2002 18:37:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04604 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38:52 -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 SAA04331; Mon, 5 Aug 2002 18:34:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04167 for ; Mon, 5 Aug 2002 18:34:22 -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 SAA05739 for ; Mon, 5 Aug 2002 18:33:08 -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 g75MYGT22601 for ; Mon, 5 Aug 2002 15:34:18 -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 g75MYBK17132 for ; Mon, 5 Aug 2002 15:34:11 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 17:26:59 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.11 RSIP - proposal to change score and text 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 Middlebox experts, The MIDOCM requirements require support for overlapping rulesets. But based on recent discussions of semantics, that requirement may be going away. As I have said in a previous e-mail, RSIP can easily be extended to support overlapping rulesets, if that is required, with backward compatibility to existing semantics. RSIP currently does not permit overlapping bindings. RSIP would add a new optional boolean parameter called overlapOK to the ASSIGN_REQUESTs. If specified as TRUE, the binding created may overlap with another existing binding. If not specified (or specified as FALSE), the binding will only be created to not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: RSIP can be extended to permit overlapping bindings by including an optional boolean overlapOK parameter on ASSIGN_REQUESTs. If specified as TRUE, the binding created may overlap with another existing binding. If not specified (or specified as FALSE), the binding will only be created to not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:37: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 SAA06046 for ; Mon, 5 Aug 2002 18:37:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04629 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38:57 -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 SAA04382; Mon, 5 Aug 2002 18:34: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 SAA04202 for ; Mon, 5 Aug 2002 18:34:23 -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 SAA05741 for ; Mon, 5 Aug 2002 18:33:08 -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 g75MYFT22581 for ; Mon, 5 Aug 2002 15:34:15 -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 g75MYAK17114 for ; Mon, 5 Aug 2002 15:34:10 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 16:42:48 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.3 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP clearly may be extended, with backward compatibility, to support ruleset groups. This would be accomplished by having an optional "group" parameter on appropriate requests and responses. On an ASSIGN request the group parameter would indicate the existing group to which the new binding is to be added; if the parameter is omitted, a new group would be created. The response to a successful ASSIGN request would include a group parameter indicating the group to which the binding has been added. By having the group parameter optional on ASSIGN requests with a new group created if not specified, backward compatibility with the existing RSIP semantics is preserved. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: A group parameter, with a default value on requests of create new group to maintain backward compatibility, can be added to appropriate requests and responses. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:47:28 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 SAA06311 for ; Mon, 5 Aug 2002 18:47:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04819 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:48: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 SAA04726; Mon, 5 Aug 2002 18:44: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 SAA04699 for ; Mon, 5 Aug 2002 18:44:37 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06216 for ; Mon, 5 Aug 2002 18:43:23 -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 g75Mi46I001935; Mon, 5 Aug 2002 15:44:04 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES04847; Mon, 5 Aug 2002 15:40:01 -0700 (PDT) Message-Id: <200208052240.AES04847@mira-sjc5-4.cisco.com> To: James_Renkel@3com.com cc: midcom From: Melinda Shore Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text In-Reply-To: Message from James_Renkel@3com.com of "Mon, 05 Aug 2002 16:31:28 CDT." Date: Mon, 05 Aug 2002 18:42:02 -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 propose that the score of RSIP for this requirement be changed to T, > and the RSIP text under this requirement be changed to: > > RSIP allows a client to simultaneously have RSIP sessions with > multiple RSIP gateways. I hope that you'll also provide some text describing the complexity associated with having one "virtual" interface/ address on the host for each middlebox with which it's communicating. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:50:18 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 SAA06537 for ; Mon, 5 Aug 2002 18:50:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04957 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:51: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 SAA04880; Mon, 5 Aug 2002 18:50: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 SAA04845 for ; Mon, 5 Aug 2002 18:50:37 -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 SAA06453 for ; Mon, 5 Aug 2002 18:49: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 g75Mn09V025039; Mon, 5 Aug 2002 15:49:01 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES05035; Mon, 5 Aug 2002 15:45:10 -0700 (PDT) Message-Id: <200208052245.AES05035@mira-sjc5-4.cisco.com> To: James_Renkel@3com.com cc: midcom From: Melinda Shore Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text In-Reply-To: Message from James_Renkel@3com.com of "Mon, 05 Aug 2002 16:51:47 CDT." Date: Mon, 05 Aug 2002 18:47:12 -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 > RSIP does not explicitly either permit or preclude an operation on > a binding being requested by a host other that the host that created > the binding. The RSIP semantics would need to be explicitly extended > to permit any authorized host to request operations on a binding. No > change to the protocol would be required. The problem with this is that it's inconsistent with the loaning-an-address model that RSIP uses. I think it's fair to say that it would be a not insignificant change to the semantics of the RSIP protocol if addresses were to be loanable to more than one endpoint simultaneously. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 18:51:50 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 SAA06575 for ; Mon, 5 Aug 2002 18:51:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05040 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:53:02 -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 SAA05002; Mon, 5 Aug 2002 18:52:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04973 for ; Mon, 5 Aug 2002 18:52:12 -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 SAA06567 for ; Mon, 5 Aug 2002 18:50:58 -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 g75MpZAK020301; Mon, 5 Aug 2002 15:51:35 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES05146; Mon, 5 Aug 2002 15:47:36 -0700 (PDT) Message-Id: <200208052247.AES05146@mira-sjc5-4.cisco.com> To: James_Renkel@3com.com cc: midcom From: Melinda Shore Subject: Re: [midcom] Protocol eval: 2.2.2 RSIP - proposal to change score and text In-Reply-To: Message from James_Renkel@3com.com of "Mon, 05 Aug 2002 13:42:04 CDT." Date: Mon, 05 Aug 2002 18:49:38 -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 > RSIP is currently scored a P on this requirement when it should, in > my opinion, clearly be a P+ or T, depending on whether more actions than > permit are required by the semantics: if more actions than permit are > required, they can be supported with backward compatibility by the addition > of an optional action parameter in appropriate requests, with the default > value of the parameter being permit if it is omitted. I'm hoping that the protocols can be evaluated on the basis of their current defined state, rather than what they might look like after being extended. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 19:25: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 SAA05965 for ; Mon, 5 Aug 2002 18:37:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04563 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38: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 SAA04269; Mon, 5 Aug 2002 18:34:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04107 for ; Mon, 5 Aug 2002 18:34:19 -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 SAA05732 for ; Mon, 5 Aug 2002 18:33:05 -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 g75MYET22579 for ; Mon, 5 Aug 2002 15:34:15 -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 g75MYAK17110 for ; Mon, 5 Aug 2002 15:34:10 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 13:42:04 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.2 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP clearly may be extended, with backward compatibility, to support multiple middlebox types. The differentiation between middlebox types is in the actions that they support on a ruleset. RSIP (implicitly) only supports a permit action, while the MIDCOM requirements require multiple possible actions (Although that may have gone away with recent working group discussions on semantics.). RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+ or T, depending on whether more actions than permit are required by the semantics: if more actions than permit are required, they can be supported with backward compatibility by the addition of an optional action parameter in appropriate requests, with the default value of the parameter being permit if it is omitted. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: If multiple actions beyond RSIP's default "permit" action are required to differentiate between middlebox types, an action parameter, with a default value of "permit" if omitted to maintain backward compatibility, can be added to appropriate requests. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 5 19:25:02 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 SAA05998 for ; Mon, 5 Aug 2002 18:37:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04593 for midcom-archive@odin.ietf.org; Mon, 5 Aug 2002 18:38: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 SAA04408; Mon, 5 Aug 2002 18:34: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 SAA04233 for ; Mon, 5 Aug 2002 18:34:26 -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 SAA05761 for ; Mon, 5 Aug 2002 18:33:12 -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 g75MYGT22593 for ; Mon, 5 Aug 2002 15:34:17 -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 g75MYAK17123 for ; Mon, 5 Aug 2002 15:34:11 -0700 (PDT) To: midcom Date: Mon, 5 Aug 2002 16:58:49 -0500 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.12 (www dot roaringpenguin dot com slash mimedefang) Subject: [midcom] Protocol eval: 2.2.8 RSIP - proposal to change score and text 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 Middlebox experts, As I have said in a previous e-mail, RSIP can easily be extended in a backward compatible manner to restrict the transport protocols that may use a binding. RSIP currently allows all transport protocols to use any binding. RSIP would add a new optional parameter called transportProtocol to the ASSIGN_REQUESTs. If specified, the binding created would apply only to the use of the bound addresses / ports by the specified transport protocol(s). If not specified, the binding would apply to all use of the bound addresses / ports by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: RSIP can be extended to restrict the transport protocols that may use a binding by including an optional transportProtocol parameter on ASSIGN_REQUESTs. If specified, the use of the binding is restricted to the transport protocol specified. If not specified, the binding can be used by all transport protocols, giving backward compatibility with the existing RSIP semantics. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 6 08:34: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 IAA08061 for ; Tue, 6 Aug 2002 08:34:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02684 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 08:35:58 -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 IAA02379; Tue, 6 Aug 2002 08:32:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02350 for ; Tue, 6 Aug 2002 08:32:02 -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 IAA07993 for ; Tue, 6 Aug 2002 08:30:47 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76CV7N04279; Tue, 6 Aug 2002 08:31:07 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 08:31:07 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A757@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'James_Renkel@3com.com'" , midcom Subject: RE: [midcom] Protocol eval: 2.1.8 and 2.3.1 through 2.3.4 RSIP - proposal to change score and text Date: Tue, 6 Aug 2002 08:30: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 I think I would concede your basic point. As I said in a previous E-mail, the appropriate test is the protocol security architecture as defined in the protocol documentation. I find this information in the RSIP framework document (RFC 3102): If an RSIP negotiation protocol is implemented at the application layer, a choice of transport protocol MUST be made. RSIP hosts and gateways may communicate via TCP or UDP. TCP support is required in all RSIP gateways, while UDP support is optional. In RSIP hosts, TCP, UDP, or both may be supported. However, once an RSIP host and gateway have begun communicating using either TCP or UDP, they MAY NOT switch to the other transport protocol. For RSIP implementations and deployments considered in this document, TCP is the recommended transport protocol, because TCP is known to be robust across a wide range of physical media types and traffic loads. It is recommended that all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and (with an anti-replay counter) avoid replay attacks. In order for authentication to be supported, each RSIP host and the RSIP gateway MUST either share a secret key (distributed, for example, by Kerberos) or have a private/public key pair. In the latter case, an entity's public key can be computed over each message and a hash function applied to the result to form the message hash. The RFC protocol document (RFC 3103) steered me back to this. RFC 3103 itself concentrated on the threat of denial of service attacks at the server. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Monday, August 05, 2002 2:12 PM To: midcom Subject: [midcom] Protocol eval: 2.1.8 and 2.3.1 through 2.3.4 RSIP - proposal to change score and text Middlebox experts, As I have said in a previous e-mail, RSIP's capabiltiies are no different w.r.t.: - mutual authentication (2.1.8) than MEGACO and DIAMETER; - message authentication, confidentiality, and integrity (2.3.1) than MEGACO and DIAMETER; - optional confidentiality protection (2.3.2) than MEGACO and perhaps DIAMETER; - operation across untrusted domains (2.3.3) than MEGACO and DIAMETER; and - mitigation against replay attacks (2.3.4) than perhaps MEGACO and DIAMETER. (The "perhaps" in the above statements indicates that the protocol may have some native capabiltiies in the area.) Those protocols were scored T for those requirements by suggesting that the requirement could be completely satisfied if the protocol were operated over TLS or IPsec. The same is true of RSIP: all these requirements may be completely satisfied by operating RSIP over TLS or IPsec. For consistency of scoring, I propose that the scores of RSIP for these requirements be changed to T, and the RSIP text under these requirements be changed to: RSIP does not have "native" support for this capability, but the capability can be obtained by operating RSIP over TLS or IPsec. Comments expected and welcome. Jim _______________________________________________ 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 Tue Aug 6 08:43:15 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 IAA08524 for ; Tue, 6 Aug 2002 08:43:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03063 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 08:44: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 IAA02898; Tue, 6 Aug 2002 08:41: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 IAA02869 for ; Tue, 6 Aug 2002 08:41:20 -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 IAA08386 for ; Tue, 6 Aug 2002 08:40:06 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76CeUL19186; Tue, 6 Aug 2002 08:40:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 08:40:30 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A758@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Mary Barnes" , "'James_Renkel@3com.com'" , "'midcom'" Subject: RE: [midcom] Protocol eval: RSIP 2.1.8 and 2.3.1 - 2.3.4 - Securi ty F-> T (was RE: Proposed changes to RSIP evaluation... Date: Tue, 6 Aug 2002 08:40:21 -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 We come to the same basic conclusion, but I should note that neither RFC 3102 nor RFC 3103 discusses the operation of the RSIP negotiation protocol itself over IPSEC. The extensive discussion in these documents is about the IPSEC transport which RSIP negotiation enables (i.e. the subject matter of the protocol, not the transport of the protocol). -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Monday, August 05, 2002 3:42 PM To: 'James_Renkel@3com.com'; 'midcom' Subject: [midcom] Protocol eval: RSIP 2.1.8 and 2.3.1 - 2.3.4 - Security F-> T (was RE: Proposed changes to RSIP evaluation... Hi all, Given that the RSIP protocol does define the use of IPSEC, I would agree that these could be changed to T. The current text description in section 2.3.1 is fairly informative, do you really want to replace that with the single sentence or do you want the information combined? Also, I did not see any reference to TLS in the RSIP RFCs, so I would propose to just add the reference to IPSec, or perhaps I somehow missed the reference. Note, that this would also require a change to the conclusion. Again, WG feedback (i.e. if you don't agree with changing these to T), should be sent by COB on Tuesday, August 5th. Regards, Mary. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: Sunday, August 04, 2002 10:42 PM To: 'midcom' Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft ---text deleted ----------- > > Now, you're also proposing that RSIP be "upgraded" for the security > onesthat you had scored as Failing to meet compliancy in your analysis. > Based upon the text currently in section 2.1.8, 2.3.1, which also > applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps. > MEGACO and DIAMETER do not have "native" support for capabilities satisfying these requirements, they depend on operation over, e.g., TLS or IPsec to satisfy them, and they were scored a T. RSIP is no different: no native support; but the cappability can be added by operating over TLS or IPsec; so, it too should be scored a T. All I'm asking for here is consistency of scoring for all the protocols. Additionally, the "native" communications between hosts and RSIP gateways is over tunnels for the data connections. Although not explicitly stated, the preferred operation of the control channel is over that same tunnel. If that tunnel is IPsec, then the control channel is secured. At least with RSIP, the tunnel is already there. At to replacement for the RSIP portions of the text following requirements 2.1.8, and 2.3.1 through 2.3.4, I would suggest: RSIP does not have "native" support for this capability, but the capability can be obtained by operating RSIP over TLS or IPsec. > > The P+ category would only apply if these changes could be made to > RSIP as a natural extension of the protocol with no impact to current > users of that protocol (i.e. current users don't make use of the > information, and wouldn't be bothered by it being in the messages). > If the score for these requirements is not to be T, then .... ---Remainder of email thread deleted---- _______________________________________________ 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 Tue Aug 6 12:33: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 MAA17456 for ; Tue, 6 Aug 2002 12:33:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16478 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 12:34: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 MAA16234; Tue, 6 Aug 2002 12:32:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16179 for ; Tue, 6 Aug 2002 12:32:08 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17307 for ; Tue, 6 Aug 2002 12:30:43 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76GUA724757; Tue, 6 Aug 2002 18:30:11 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <350WM6CD>; Tue, 6 Aug 2002 18:30:09 +0200 Message-ID: From: "Cedric Aoun" To: "'James_Renkel@3com.com'" , midcom Subject: RE: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text Date: Tue, 6 Aug 2002 18:30:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D65.876D398E" 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_01C23D65.876D398E Content-Type: text/plain; charset="iso-8859-1" I initially understood the P+ category as the protocol could be extended by using the defined extensibility mechanisms without changing the base protocol messages. This is main difference between P and P+. Other protocols evaluated in this process have MIBs, PIBs, packages etc ... to be extended easily. IMO RSIP fails to meet this requirement as you just stated that RSIP does not guarantee preservation of port number oddity; and it doesn't have easy extensibility tools it requires new messages or new parameters within the base protocol messages.It should actually be an F. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: 06 August 2002 00:05 To: midcom Subject: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text Middlebox experts, As I have said in a previous e-mail, RSIP can easily be extended to preserve port number oddity when creating bindings. RSIP currently does not guarantee preservation of port number oddity. RSIP would add a new optional boolean parameter called portOddity to the ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the loacl port's oddity, thus maintaining backward compatibility with the current definition of RSIP. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: RSIP can be extended to preserve the port number oddity of a binding by including an optional boolean portOddity parameter on ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C23D65.876D398E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change = score and text

I initially understood the P+ category as the = protocol could be extended by using
the defined extensibility mechanisms without = changing the base protocol messages.
This is main difference between P and P+.
Other protocols evaluated in this process have MIBs, = PIBs, packages etc ... to be extended
easily.
IMO RSIP fails to meet this requirement as you just = stated that RSIP does not guarantee
preservation of port number oddity; and it doesn't = have easy extensibility tools it requires
new messages or new parameters within the base = protocol messages.It should actually be an F.

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: 06 August 2002 00:05
To: midcom
Subject: [midcom] Protocol eval: 2.2.9 RSIP - = proposal to change score
and text


Middlebox experts,

As I have said in a previous e-mail, RSIP can easily = be extended to
preserve port number oddity when creating bindings. = RSIP currently does
not guarantee preservation of port number = oddity.

RSIP would add a new optional boolean parameter = called portOddity to the
ASSIGN_REQUESTs. If specified as TRUE, the remote = port number of the
binding created would have the same oddity as the = local port. If not
specified (or specified as FALSE), the remote port's = oddity is independent
of the loacl port's oddity, thus maintaining = backward compatibility with
the current definition of RSIP.

RSIP is currently scored a P on this requirement when = it should, in
my opinion, clearly be a P+.

I propose that the score of RSIP for this requirement = be changed to P+,
and the text changed to:

     RSIP can be extended to = preserve the port number oddity of a
     binding by including an = optional boolean portOddity parameter
     on ASSIGN_REQUESTs. If = specified as TRUE, the remote port number
     of the binding created = would have the same oddity as the local port.
     If not specified (or = specified as FALSE), the remote port's oddity
     is independent of the local = port's oddity, thus maintaining
     backward compatibility with = the current definition of RSIP.


Comments expected and welcome.

Jim


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

------_=_NextPart_001_01C23D65.876D398E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 6 14:19: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 OAA22146 for ; Tue, 6 Aug 2002 14:19:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22607 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:20: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 OAA22507; Tue, 6 Aug 2002 14:17: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 OAA22476 for ; Tue, 6 Aug 2002 14:17:36 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22072 for ; Tue, 6 Aug 2002 14:16:22 -0400 (EDT) Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76IG0728857; Tue, 6 Aug 2002 20:16:01 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <350WM63K>; Tue, 6 Aug 2002 20:15:59 +0200 Message-ID: From: "Cedric Aoun" To: "'James_Renkel@3com.com'" , "'midcom@ietf.org'" Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Date: Tue, 6 Aug 2002 20:16:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D75.24E2FC9E" 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_01C23D75.24E2FC9E Content-Type: text/plain; charset="iso-8859-1" If we want to be honest with other protocol evaluations, I don't see how RSIP's extensibility mechanisms would be graded in the same way as the other evaluated protocols. The other protocols have extensibility mechanisms were the base protocol messages are not always required to be extended to include new parameters (or even to create new messages). The other protocols use a certain "envelop" where the application (in this case Middlebox control) specific properties are contained, this provides a better extension mechanism than the RSIP protocol. IMHO I don't think we should grade RSIP to T, to be fair it has to have a lower grade than the other protocols. Cedric -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: 05 August 2002 20:28 To: midcom Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Middlebox experts, As I have said in a previous e-mail, RSIP clearly was designed to be extensible. The evaluation text of RSIP for this requirement explains how this works in more detail than the evaluation text for the other protocols. RSIP is currently scored a P+ on this requirement when it should, in my opinion, clearly be a T: it has a degree of extensibility comparable to the other protocols, and they were scored a T. I propose that the score of RSIP for this requirement be changed to T. I don't think there's any need to change the expanatory text. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C23D75.24E2FC9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change = score

If we want to be honest with other protocol = evaluations,
I don't see how RSIP's extensibility mechanisms = would be graded in the same
way as the other evaluated protocols.
The other protocols have extensibility mechanisms = were the base protocol messages
are not always required to be extended to include = new parameters (or even to create new messages).
The other protocols use a certain = "envelop" where the application (in this case Middlebox = control)
specific properties are contained, this provides a = better extension mechanism than the RSIP protocol.
IMHO I don't think we should grade RSIP to T, to be = fair it has to have a lower grade than
the other protocols.
Cedric

-----Original Message-----
From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]<= /FONT>
Sent: 05 August 2002 20:28
To: midcom
Subject: [midcom] Protocol eval: 2.2.1 RSIP - = proposal to change score


Middlebox experts,

As I have said in a previous e-mail, RSIP clearly was = designed to be
extensible. The evaluation text of RSIP for this = requirement explains
how this works in more detail than the evaluation = text for the other
protocols.

RSIP is currently scored a P+ on this requirement = when it should, in
my opinion, clearly be a T: it has a degree of = extensibility comparable
to the other protocols, and they were scored a = T.

I propose that the score of RSIP for this requirement = be changed to T.
I don't think there's any need to change the = expanatory text.

Comments expected and welcome.

Jim


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

------_=_NextPart_001_01C23D75.24E2FC9E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 6 14:19:12 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 OAA22162 for ; Tue, 6 Aug 2002 14:19:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22619 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:20: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 OAA22567; Tue, 6 Aug 2002 14:19: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 OAA22536 for ; Tue, 6 Aug 2002 14:19:04 -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 OAA22117 for ; Tue, 6 Aug 2002 14:17:50 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A3159CC80134; Tue, 06 Aug 2002 14:19:01 -0400 Message-ID: <002901c23d75$b5cc2c80$2300000a@BOBP> From: "Bob Penfield" To: "Cedric Aoun" , , "midcom" References: Subject: Re: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text Date: Tue, 6 Aug 2002 14:18: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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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: "Cedric Aoun" To: ; "midcom" > I initially understood the P+ category as the > protocol could be extended by using the defined > extensibility mechanisms without changing the base protocol > messages. This is main difference between P and P+. > Other protocols evaluated in this process have MIBs, > PIBs, packages etc ... to be extended easily. > IMO RSIP fails to meet this requirement as you just stated > that RSIP does not guarantee preservation of port number > oddity; and it doesn't have easy extensibility tools it > requires new messages or new parameters within the > base protocol messages.It should actually be an F. > I'm afraid I have to disagree. The IANA Considerations section of RFC 3103 allows for defining new parameters, error codes, message type codes, etc. There is no need to change the base protocol messages. I see very little difference between defining a new RSIP parameter for port-oddity and a new Megaco property for port-oddity in a new midcom package. Both require new behaviour by the middlebox. > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: 06 August 2002 00:05 > To: midcom > Subject: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score > and text > > > Middlebox experts, > > As I have said in a previous e-mail, RSIP can easily be extended to > preserve port number oddity when creating bindings. RSIP currently does > not guarantee preservation of port number oddity. > > RSIP would add a new optional boolean parameter called portOddity to the > ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the > binding created would have the same oddity as the local port. If not > specified (or specified as FALSE), the remote port's oddity is independent > of the loacl port's oddity, thus maintaining backward compatibility with > the current definition of RSIP. > > RSIP is currently scored a P on this requirement when it should, in > my opinion, clearly be a P+. > > I propose that the score of RSIP for this requirement be changed to P+, > and the text changed to: > > RSIP can be extended to preserve the port number oddity of a > binding by including an optional boolean portOddity parameter > on ASSIGN_REQUESTs. If specified as TRUE, the remote port number > of the binding created would have the same oddity as the local port. > If not specified (or specified as FALSE), the remote port's oddity > is independent of the local port's oddity, thus maintaining > backward compatibility with the current definition of RSIP. > > > Comments expected and welcome. > > Jim > > > _______________________________________________ > 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 Tue Aug 6 14:41: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 OAA23191 for ; Tue, 6 Aug 2002 14:41:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23906 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:43:04 -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 OAA23830; Tue, 6 Aug 2002 14:41: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 OAA23801 for ; Tue, 6 Aug 2002 14:41:46 -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 OAA23092 for ; Tue, 6 Aug 2002 14:40:32 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76IeCo16495; Tue, 6 Aug 2002 14:40:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 14:40:12 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A767@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Cedric Aoun" , "'James_Renkel@3com.com'" , "'midcom@ietf.org'" Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Date: Tue, 6 Aug 2002 14:40:07 -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 To summarize, you are saying that some protocols (most, in fact) have explicit extensibility mechanisms, where others (RSIP in particular) do not. If I were to rank the candidates by readiness for extensibility this is how I would see it. I omit COPS because I'm not familiar with it, and I'm taking risks with RSIP because I'm not really familiar with it either: SNMP (most extensible): extensions require absolutely no change to the protocol itself. DIAMETER: extension mechanism provided, does mean protocol changes, but extensions can be handled by other DIAMETER entities without being understood. (Actually not sure that this property is relevant or useful in the MIDCOM case.) MEGACO: extension mechanism provided, does mean protocol changes, both ends have to understand the extensions. RSIP: no formal extension mechanism; extensions have to be designed into the protocol from scratch. -----Original Message----- From: Aoun, Cedric [GOLF:MA01:EXCH] Sent: Tuesday, August 06, 2002 2:16 PM To: 'James_Renkel@3com.com'; 'midcom@ietf.org' Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score If we want to be honest with other protocol evaluations, I don't see how RSIP's extensibility mechanisms would be graded in the same way as the other evaluated protocols. The other protocols have extensibility mechanisms were the base protocol messages are not always required to be extended to include new parameters (or even to create new messages). The other protocols use a certain "envelop" where the application (in this case Middlebox control) specific properties are contained, this provides a better extension mechanism than the RSIP protocol. IMHO I don't think we should grade RSIP to T, to be fair it has to have a lower grade than the other protocols. Cedric -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: 05 August 2002 20:28 To: midcom Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Middlebox experts, As I have said in a previous e-mail, RSIP clearly was designed to be extensible. The evaluation text of RSIP for this requirement explains how this works in more detail than the evaluation text for the other protocols. RSIP is currently scored a P+ on this requirement when it should, in my opinion, clearly be a T: it has a degree of extensibility comparable to the other protocols, and they were scored a T. I propose that the score of RSIP for this requirement be changed to T. I don't think there's any need to change the expanatory text. Comments expected and welcome. Jim _______________________________________________ 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 Tue Aug 6 14:41:57 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 OAA23207 for ; Tue, 6 Aug 2002 14:41:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23917 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:43: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 OAA23875; Tue, 6 Aug 2002 14:41: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 OAA23845 for ; Tue, 6 Aug 2002 14:41:57 -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 OAA23104 for ; Tue, 6 Aug 2002 14:40:43 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A874972D00BE; Tue, 06 Aug 2002 14:41:56 -0400 Message-ID: <002f01c23d78$e8f8bb20$2300000a@BOBP> From: "Bob Penfield" To: , "Melinda Shore" Cc: "midcom" References: <200208052245.AES05035@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text Date: Tue, 6 Aug 2002 14:41:43 -0400 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 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: "Melinda Shore" > > RSIP does not explicitly either permit or preclude an operation on > > a binding being requested by a host other that the host that created > > the binding. The RSIP semantics would need to be explicitly extended > > to permit any authorized host to request operations on a binding. No > > change to the protocol would be required. > > The problem with this is that it's inconsistent with the > loaning-an-address model that RSIP uses. I think it's fair > to say that it would be a not insignificant change to the > semantics of the RSIP protocol if addresses were to be > loanable to more than one endpoint simultaneously. > I think midcom requires a not insignificant change to the semantics of any protocol we choose. Megaco has the same problem with having multiple agents working on the same termination, and it is rated a P. One essential element of the midcom framework is that a proxy can be the agent (as opposed to the end point). The idea behind 2.2.7 is that multiple proxies are "equivalent". There are still only one pair of endpoints in the communication session being enabled in the middlebox. A "loaned address" is the same as a binding/pinhole. With any midcom protocol, the binding/pinhole is "loaned" to the agent. I'm assuming that we're talking about using the RSIP messages to communicate between the agent and middlebox and that the "rules" instantiated do not define "tunnels", but NAT-bindings and firewall-pinholes. The whole idea of using the proxy-agent was so that endpoint would not have to participate. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 6 14:50:28 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 OAA23766 for ; Tue, 6 Aug 2002 14:50:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24448 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:51:41 -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 OAA24387; Tue, 6 Aug 2002 14:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24360 for ; Tue, 6 Aug 2002 14:49:26 -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 OAA23659 for ; Tue, 6 Aug 2002 14:48:12 -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 g76In8v13981 for ; Tue, 6 Aug 2002 13:49:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 13:48:53 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C843@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom@ietf.org'" Date: Tue, 6 Aug 2002 13:48:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Feedback on proposals for Protocol evaluation changes 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 seen some good discussion on the threads wrt proposed changes to the protocol evaluation and think we've got agreement on 2.1.8 and 2.3.1-2.3.4 and 2.2.7. I just want to let folks know that we had a "race condition" between my postings and Jim's yesterday and his do not take into account mine. So, it would be useful if folks would also read my postings from yesterday, as they provide more explicit proposals for the process for deciding the changes that I would make to the document. The plans are to try to complete the changes this week; however, with discussion continuing through today, it may be early next week. I did originally allow 3 weeks for WGLC, which I think we could reasonably shorten to 2 weeks and thus still remain on target. Per my emails, discussion should end by COB today (Tuesday, Aug. 6th). I will post the conclusions that I derive from the discussions sometime tomorrow. 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 Tue Aug 6 14:53: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 OAA24081 for ; Tue, 6 Aug 2002 14:53:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24641 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:55: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 OAA24550; Tue, 6 Aug 2002 14:53:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24519 for ; Tue, 6 Aug 2002 14:53:01 -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 OAA23908 for ; Tue, 6 Aug 2002 14:51:47 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AB0BE520154; Tue, 06 Aug 2002 14:52:59 -0400 Message-ID: <003901c23d7a$7465ac80$2300000a@BOBP> From: "Bob Penfield" To: , "midcom" References: Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text Date: Tue, 6 Aug 2002 14:52:46 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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: > RSIP is currently scored a P on this requirement when it should, in > my opinion, clearly be a P+ (if not a T). > > I propose that the score of RSIP for this requirement be changed to P+, > and the text changed to: > > RSIP does not explicitly either permit or preclude an operation on > a binding being requested by a host other that the host that created > the binding. The RSIP semantics would need to be explicitly extended > to permit any authorized host to request operations on a binding. No > change to the protocol would be required. > Although it does not explicitly preclude it, it seems to be implied that it is not allowed since the RSIP gateway hands out a client IDs and bind IDs, and there is a BAD_CLIENT_ID and a BAD_BIND_ID whose descriptions state that the client is using IDs that don't belong to it. However, I do see that a new parameter could be added to contain some sort of agent-id that would be used by both clients to operate on the same rule. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 6 14:57: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 OAA24246 for ; Tue, 6 Aug 2002 14:57:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24773 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 14:58:52 -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 OAA24727; Tue, 6 Aug 2002 14:57: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 OAA24703 for ; Tue, 6 Aug 2002 14:57:37 -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 OAA24214 for ; Tue, 6 Aug 2002 14:56:23 -0400 (EDT) Received: from BOBP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AC1E1A850154; Tue, 06 Aug 2002 14:57:34 -0400 Message-ID: <005501c23d7b$1857bc70$2300000a@BOBP> From: "Bob Penfield" To: "Tom-PT Taylor" , "Cedric Aoun" , , References: <4D79C746863DD51197690002A52CDA0001E8A767@zcard0kc.ca.nortel.com> Subject: Re: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Date: Tue, 6 Aug 2002 14:57:21 -0400 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 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 have to note that RSIP does include an extensibility mechanism defined in section 12 of RFC 3103: All of the designations below have been registered by the IANA. - RSIP port number: 4555 - RSIP error codes (see Appendix A). - RSIP message type codes (see Appendix B). - RSIP tunnel types, methods, and flow policies. RSIP parameter values are designated as follows: - 0 Reserved - 1-240 Assigned by IANA - 241-255 Reserved for private use New registrations for the above namespaces are recommended to be allocated via the Specification Required method documented in [RFC2434]. I agree that it is the least extensible, but it is extensible. ----- Original Message ----- From: "Tom-PT Taylor" To: "Cedric Aoun" ; ; Sent: Tuesday, August 06, 2002 2:40 PM Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > > To summarize, you are saying that some protocols (most, in fact) have > explicit extensibility mechanisms, where others (RSIP in particular) do not. > > If I were to rank the candidates by readiness for extensibility this is how > I would see it. I omit COPS because I'm not familiar with it, and I'm > taking risks with RSIP because I'm not really familiar with it either: > > SNMP (most extensible): extensions require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol changes, but > extensions can be handled by other DIAMETER entities without being > understood. (Actually not sure that this property is relevant or useful in > the MIDCOM case.) > > MEGACO: extension mechanism provided, does mean protocol changes, both ends > have to understand the extensions. > > RSIP: no formal extension mechanism; extensions have to be designed into the > protocol from scratch. > > > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Tuesday, August 06, 2002 2:16 PM > To: 'James_Renkel@3com.com'; 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > > > If we want to be honest with other protocol evaluations, > I don't see how RSIP's extensibility mechanisms would be graded in the same > way as the other evaluated protocols. > The other protocols have extensibility mechanisms were the base protocol > messages > are not always required to be extended to include new parameters (or even to > create new messages). > The other protocols use a certain "envelop" where the application (in this > case Middlebox control) > specific properties are contained, this provides a better extension > mechanism than the RSIP protocol. > IMHO I don't think we should grade RSIP to T, to be fair it has to have a > lower grade than > the other protocols. > Cedric > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: 05 August 2002 20:28 > To: midcom > Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > > > Middlebox experts, > As I have said in a previous e-mail, RSIP clearly was designed to be > extensible. The evaluation text of RSIP for this requirement explains > how this works in more detail than the evaluation text for the other > protocols. > RSIP is currently scored a P+ on this requirement when it should, in > my opinion, clearly be a T: it has a degree of extensibility comparable > to the other protocols, and they were scored a T. > I propose that the score of RSIP for this requirement be changed to T. > I don't think there's any need to change the expanatory text. > Comments expected and welcome. > Jim > > > _______________________________________________ > 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 Tue Aug 6 19:01:11 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 TAA02983 for ; Tue, 6 Aug 2002 19:01:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA09834 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 19:02:24 -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 TAA09338; Tue, 6 Aug 2002 19:00:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09252 for ; Tue, 6 Aug 2002 19:00:08 -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 SAA02930 for ; Tue, 6 Aug 2002 18:58:54 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g76MxYU44844; Wed, 7 Aug 2002 00:59:34 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] (unknown [192.168.102.31]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9097859A45; Wed, 7 Aug 2002 00:59:30 +0200 (CEST) Date: Wed, 07 Aug 2002 00:59:28 +0200 From: Juergen Quittek To: Tom-PT Taylor , Cedric Aoun , "'Christian Huitema'" , Scott Brim , midcom@ietf.org Subject: RE: [midcom] Semantics Of "Session" Message-ID: <19582327.1028681967@[192.168.102.31]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A744@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A744@zcard0kc.ca.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 Christian and Cedric, --On 02 August 2002 13:31 -0400 Tom-PT Taylor wrote: > > Just on your very last point, you go beyond Christian. The framework shows > very clearly a formal start of session and end of session exchange. I see > no choice but to indicate such exchanges at the semantic level, however they > are realized in practice. But we can omit the session identifier from all > other information exchanges. In general we could omit session control in the semantics discussion. However, there are some aspects that can nicely be tied to session: - the mutual authentication of agent and middlebox, - the agreement on an encryption method, - the exchange of capabilities, - the authorization check for an agent. All these things can be handled independent of a sessions, but it appears to be reasonable and practical to tie some or all of them to the concept of a session. This allows us to have all of them just once per session and not once per message. Therefore, it makes sense to discuss sessions in the semantics. Still, there is no need to talk about session identifiers in the semantics specification. 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 > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Friday, August 02, 2002 1:20 PM > To: 'Christian Huitema'; Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > > I still remember our bar BOF and small meeting that we had in London last > year in August, we're we all rejected the notion of a "session" as it meant > zillions of things. we all agreed that the notion of session was more a > notion of an association relation based on trust and no more (i.e. it is an > SA or something similar). > The establishment of the association starts with the authorization policy > provisioning matching the authorized agents. This should be augmented by > having an SA between the Middlebox and the Midcom agent. > I agree with Christian, the protocol semantics should not include any form > of session information. > Cedric > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 02 August 2002 18:03 > To: Scott Brim; midcom@ietf.org > Subject: RE: [midcom] Semantics Of "Session" > > >> From: Scott Brim [mailto:swb@employees.org] >> On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: >> > Is there any semantic content to a MIDCOM session, then, >> except as a policy >> > context for the Middlebox to use when evaluating requests >> from the Agent? >> >> During your presentation, and occasionally in others, I would >> ask myself >> "what's a session?". There are no semantics that need a session >> concept. However there needs to be shared state on both >> ends, including >> a cookie which can be assigned to rules and used arbitrarily. We can >> conceive of uses for it today (like 'I'm done with everything with >> cookie xyzzy'), and there may be more in the future. > I don't think we need any concept of a midcom session, and specifically > any concept tying the state of the "session" to the validity of rules > installed in the meddlebox. A session might be useful as a form of > transport & security shortcut, i.e. authenticate the requestor once per > session instead of once per transaction, but that is about the only > thing that is really needed. Specifically, an agent must be able to > install a rule that is supposed to be valid for some lifetime, go off > the network, and be confident that the rule is operative. > -- Christian Huitema > _______________________________________________ > 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 Tue Aug 6 19:13: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 TAA03242 for ; Tue, 6 Aug 2002 19:13:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10237 for midcom-archive@odin.ietf.org; Tue, 6 Aug 2002 19:15:02 -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 TAA10214; Tue, 6 Aug 2002 19:14: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 TAA10184 for ; Tue, 6 Aug 2002 19:14:02 -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 TAA03220 for ; Tue, 6 Aug 2002 19:12:48 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g76NDTN27669 for ; Tue, 6 Aug 2002 19:13:29 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 19:13:30 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A76C@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'midcom@ietf.org'" Date: Tue, 6 Aug 2002 19:13:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Bind and Allow Semantics 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 Juergen and Martin have helped me convince myself that a single Enable Request does not faithfully reproduce the semantics we require, even if it looks elegant for combined NAT and firewall operation. There will be occasions where one needs the Bind for a specific call before the far-end (exterior) address is known. Performing an Enable as I defined it previously would involve wildcarding the far-end address at least momentarily, opening up a larger pinhole than needed. While I was always aware of this, I have finally realized that mandating it in a semantics document would be a falsification of our requirements. One more step toward unifying our semantics drafts ... 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 Wed Aug 7 02:20:36 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 CAA28967 for ; Wed, 7 Aug 2002 02:20:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20595 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:21:50 -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 CAA14157; Wed, 7 Aug 2002 02:16: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 CAA14072 for ; Wed, 7 Aug 2002 02:16:40 -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 CAA23261 for ; Wed, 7 Aug 2002 02:15:25 -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 g776Gfh15031 for ; Tue, 6 Aug 2002 23:16:41 -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 g773c1K00886 for ; Tue, 6 Aug 2002 20:38:01 -0700 (PDT) Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text To: midcom Date: Tue, 6 Aug 2002 21:18:59 -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 Melinda, As I see it, the situation here is no diffrerent for RSIP than for any of the other protocols. Or any different than with any client / server protocol where a client communicates with multiple servers simultaneously. The client is going to have to keep some state for each server that it simultaneously communicates with, which would include, e.g., the TCP socket used to exchange messages with that server. If you're only communicating with one server and ya want something done, well, ya send a request to that one server and it either works or doesn't. If you're communicating with more than one server, ya presumably have to decide in some way or another which server to send the request to. Maybe part of that decision process, even in the case of communicating with only one server, is the possibility that ya ain't yet communicating with the right server, so ya need to open a connection with that server before ya send the request. As I said, I believe all of this is necessary not just with RSIP, but with any of the other protocols. Unless the client library has some kind of automagic, smart request router built into it. But I would think that's a library implementation issue, not a protocol design issue. All of this seems so obvious to me that I'm afraid I misunderstood what you were asking. Did I miss something? It wouldn't be the first time, and it probably won't be the last time, either. :-) Jim Melinda Shore @ietf.org on 08/05/2002 05:42:02 PM Sent by: midcom-admin@ietf.org To: James Renkel/MW/US/3Com cc: midcom Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text > I propose that the score of RSIP for this requirement be changed to T, > and the RSIP text under this requirement be changed to: > > RSIP allows a client to simultaneously have RSIP sessions with > multiple RSIP gateways. I hope that you'll also provide some text describing the complexity associated with having one "virtual" interface/ address on the host for each middlebox with which it's communicating. 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 Wed Aug 7 02:20: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 CAA28981 for ; Wed, 7 Aug 2002 02:20:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20614 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:21:50 -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 CAA14116; Wed, 7 Aug 2002 02:16:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14038 for ; Wed, 7 Aug 2002 02:16:39 -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 CAA23257 for ; Wed, 7 Aug 2002 02:15:24 -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 g776Gch15001 for ; Tue, 6 Aug 2002 23:16:38 -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 g773cBK00953 for ; Tue, 6 Aug 2002 20:38:11 -0700 (PDT) Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text To: midcom Date: Tue, 6 Aug 2002 22:24:56 -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 But whether a given binding "belongs" to a given client or not is a matter of local policy. :-) I don't see the difference between an agent ID and a client ID. I think you can use the existing client ID for whatever use you would put the agent ID to. But I could be wrong. Jim "Bob Penfield" @ietf.org on 08/06/2002 01:52:46 PM Sent by: midcom-admin@ietf.org To: James Renkel/MW/US/3Com, "midcom" cc: Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text ----- Original Message ----- From: > RSIP is currently scored a P on this requirement when it should, in > my opinion, clearly be a P+ (if not a T). > > I propose that the score of RSIP for this requirement be changed to P+, > and the text changed to: > > RSIP does not explicitly either permit or preclude an operation on > a binding being requested by a host other that the host that created > the binding. The RSIP semantics would need to be explicitly extended > to permit any authorized host to request operations on a binding. No > change to the protocol would be required. > Although it does not explicitly preclude it, it seems to be implied that it is not allowed since the RSIP gateway hands out a client IDs and bind IDs, and there is a BAD_CLIENT_ID and a BAD_BIND_ID whose descriptions state that the client is using IDs that don't belong to it. However, I do see that a new parameter could be added to contain some sort of agent-id that would be used by both clients to operate on the same rule. _______________________________________________ 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 Aug 7 02:20: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 CAA29059 for ; Wed, 7 Aug 2002 02:20:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20662 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:21:53 -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 CAA16351; Wed, 7 Aug 2002 02:17: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 CAA16277 for ; Wed, 7 Aug 2002 02:17:17 -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 CAA23678 for ; Wed, 7 Aug 2002 02:15:57 -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 g776HDh15653 for ; Tue, 6 Aug 2002 23:17:13 -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 g773c4K00902 for ; Tue, 6 Aug 2002 20:38:04 -0700 (PDT) Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text To: midcom Date: Tue, 6 Aug 2002 21:30:40 -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 Melinda, The issue here as I see is not with "loaning out addresses": that's an issue for overlapping rulesets. A loaned out address can only be used in more than one ruleset if the rulesets are consistent with each other, i.e., they cause no confusion to the middlebox as it passes, and possibly modifies the addresses in, packets containing the loaned out address. I think inconsistent or conflicting (except possibly for their actions, if we have more than one action) rulesets have to be precluded. I think what we're really talking about here is operations, e.g., extend the lease time, on a ruleset from a client other than the client that created the ruleset. Whether that is permitted or not is a local policy issue, possibly dependent on the identities of the clients involved. I believe RSIP has all the machinery necessary to either allow or not such requests. Jim Melinda Shore @ietf.org on 08/05/2002 05:47:12 PM Sent by: midcom-admin@ietf.org To: James Renkel/MW/US/3Com cc: midcom Subject: Re: [midcom] Protocol eval: 2.2.7 RSIP - proposal to change score and text > RSIP does not explicitly either permit or preclude an operation on > a binding being requested by a host other that the host that created > the binding. The RSIP semantics would need to be explicitly extended > to permit any authorized host to request operations on a binding. No > change to the protocol would be required. The problem with this is that it's inconsistent with the loaning-an-address model that RSIP uses. I think it's fair to say that it would be a not insignificant change to the semantics of the RSIP protocol if addresses were to be loanable to more than one endpoint simultaneously. 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 Wed Aug 7 02:20: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 CAA29105 for ; Wed, 7 Aug 2002 02:20:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20707 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:21: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 CAA16397; Wed, 7 Aug 2002 02:17: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 CAA16331 for ; Wed, 7 Aug 2002 02:17:18 -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 CAA23693 for ; Wed, 7 Aug 2002 02:15:59 -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 g776HGh15705 for ; Tue, 6 Aug 2002 23:17:16 -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 g773c6K00923 for ; Tue, 6 Aug 2002 20:38:06 -0700 (PDT) Subject: RE: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text To: midcom Date: Tue, 6 Aug 2002 21:41:22 -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 Cedric, I, obviously, didn't get that same understanding from the P+ definition. Quoting from the protocol evaluation draft: P+ = Partial Compliance+. Fundamentally meets the requirement through the use of extensions (e.g. packages, additional parameters, etc). That, while it suggests that packages (MIBs, etc.) are permitted, also says additional parmaters, etc., are permitted to be used in extending a protocol to give it a P+ score. I don't think any of the extensions I've proposed violate either the letter or the spirit of this definition. Further, the definition of the P score it says: P = Partial Compliance. Meets some aspect of the requirement, however, the necessary changes require more than an extension and/or are inconsistent with the design intent of the protocol. The design intent of RSIP was clearly to support middleboxes. I'm not sure the same can be said about the design intentions of the other protocols. :-) Jim "Cedric Aoun" on 08/06/2002 11:30:10 AM Sent by: "Cedric Aoun" To: James Renkel/MW/US/3Com, midcom cc: Subject: RE: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text I initially understood the P+ category as the protocol could be extended by using the defined extensibility mechanisms without changing the base protocol messages. This is main difference between P and P+. Other protocols evaluated in this process have MIBs, PIBs, packages etc ... to be extended easily. IMO RSIP fails to meet this requirement as you just stated that RSIP does not guarantee preservation of port number oddity; and it doesn't have easy extensibility tools it requires new messages or new parameters within the base protocol messages.It should actually be an F. -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: 06 August 2002 00:05 To: midcom Subject: [midcom] Protocol eval: 2.2.9 RSIP - proposal to change score and text Middlebox experts, As I have said in a previous e-mail, RSIP can easily be extended to preserve port number oddity when creating bindings. RSIP currently does not guarantee preservation of port number oddity. RSIP would add a new optional boolean parameter called portOddity to the ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the loacl port's oddity, thus maintaining backward compatibility with the current definition of RSIP. RSIP is currently scored a P on this requirement when it should, in my opinion, clearly be a P+. I propose that the score of RSIP for this requirement be changed to P+, and the text changed to: RSIP can be extended to preserve the port number oddity of a binding by including an optional boolean portOddity parameter on ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the binding created would have the same oddity as the local port. If not specified (or specified as FALSE), the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP. Comments expected and welcome. Jim _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom - C.htm _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 02:20: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 CAA29198 for ; Wed, 7 Aug 2002 02:20:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20718 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:21: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 CAA16595; Wed, 7 Aug 2002 02:17:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16562 for ; Wed, 7 Aug 2002 02:17:29 -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 CAA23887 for ; Wed, 7 Aug 2002 02:16:09 -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 g776HPh15885 for ; Tue, 6 Aug 2002 23:17:25 -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 g773cEK00970 for ; Tue, 6 Aug 2002 20:38:15 -0700 (PDT) Subject: Re: [midcom] Protocol eval: 2.2.2 RSIP - proposal to change score and text To: midcom Date: Tue, 6 Aug 2002 22:35:58 -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 Melinda, I share your hope that protocols would be evaluated as defined, not as extended. But the consensus was to include a P+ score that is given based on the protocol after extension. I think that score hides valuable information. Maybe that information is available in the evaluation comments, but I would have liked to see it reflected in the score. The consensus was to include P+, so I am going along with that and trying to get consistent application of it. Jim Melinda Shore @ietf.org on 08/05/2002 05:49:38 PM Sent by: midcom-admin@ietf.org To: James Renkel/MW/US/3Com cc: midcom Subject: Re: [midcom] Protocol eval: 2.2.2 RSIP - proposal to change score and text > RSIP is currently scored a P on this requirement when it should, in > my opinion, clearly be a P+ or T, depending on whether more actions than > permit are required by the semantics: if more actions than permit are > required, they can be supported with backward compatibility by the addition > of an optional action parameter in appropriate requests, with the default > value of the parameter being permit if it is omitted. I'm hoping that the protocols can be evaluated on the basis of their current defined state, rather than what they might look like after being extended. 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 Wed Aug 7 02:20: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 CAA29286 for ; Wed, 7 Aug 2002 02:20:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20729 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:22: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 CAA13524; Wed, 7 Aug 2002 02:16:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13433 for ; Wed, 7 Aug 2002 02:16:29 -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 CAA23108 for ; Wed, 7 Aug 2002 02:15:15 -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 g776GUh14863 for ; Tue, 6 Aug 2002 23:16:30 -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 g773cCK00961 for ; Tue, 6 Aug 2002 20:38:12 -0700 (PDT) Subject: Re: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score To: Date: Tue, 6 Aug 2002 22:29:14 -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 Bob, Thanks for pointing this out. I didn't even think of this last night as I was rushing out responses. Jim "Bob Penfield" @ietf.org on 08/06/2002 01:57:21 PM Sent by: midcom-admin@ietf.org To: "Tom-PT Taylor" , "Cedric Aoun" , James Renkel/MW/US/3Com, cc: Subject: Re: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score I have to note that RSIP does include an extensibility mechanism defined in section 12 of RFC 3103: All of the designations below have been registered by the IANA. - RSIP port number: 4555 - RSIP error codes (see Appendix A). - RSIP message type codes (see Appendix B). - RSIP tunnel types, methods, and flow policies. RSIP parameter values are designated as follows: - 0 Reserved - 1-240 Assigned by IANA - 241-255 Reserved for private use New registrations for the above namespaces are recommended to be allocated via the Specification Required method documented in [RFC2434]. I agree that it is the least extensible, but it is extensible. ----- Original Message ----- From: "Tom-PT Taylor" To: "Cedric Aoun" ; ; Sent: Tuesday, August 06, 2002 2:40 PM Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > > To summarize, you are saying that some protocols (most, in fact) have > explicit extensibility mechanisms, where others (RSIP in particular) do not. > > If I were to rank the candidates by readiness for extensibility this is how > I would see it. I omit COPS because I'm not familiar with it, and I'm > taking risks with RSIP because I'm not really familiar with it either: > > SNMP (most extensible): extensions require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol changes, but > extensions can be handled by other DIAMETER entities without being > understood. (Actually not sure that this property is relevant or useful in > the MIDCOM case.) > > MEGACO: extension mechanism provided, does mean protocol changes, both ends > have to understand the extensions. > > RSIP: no formal extension mechanism; extensions have to be designed into the > protocol from scratch. > > > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Tuesday, August 06, 2002 2:16 PM > To: 'James_Renkel@3com.com'; 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > > > If we want to be honest with other protocol evaluations, > I don't see how RSIP's extensibility mechanisms would be graded in the same > way as the other evaluated protocols. > The other protocols have extensibility mechanisms were the base protocol > messages > are not always required to be extended to include new parameters (or even to > create new messages). > The other protocols use a certain "envelop" where the application (in this > case Middlebox control) > specific properties are contained, this provides a better extension > mechanism than the RSIP protocol. > IMHO I don't think we should grade RSIP to T, to be fair it has to have a > lower grade than > the other protocols. > Cedric > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: 05 August 2002 20:28 > To: midcom > Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > > > Middlebox experts, > As I have said in a previous e-mail, RSIP clearly was designed to be > extensible. The evaluation text of RSIP for this requirement explains > how this works in more detail than the evaluation text for the other > protocols. > RSIP is currently scored a P+ on this requirement when it should, in > my opinion, clearly be a T: it has a degree of extensibility comparable > to the other protocols, and they were scored a T. > I propose that the score of RSIP for this requirement be changed to T. > I don't think there's any need to change the expanatory text. > Comments expected and welcome. > Jim > > > _______________________________________________ > 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 03:10:11 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 CAA28990 for ; Wed, 7 Aug 2002 02:20:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20625 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 02:21:50 -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 CAA14925; Wed, 7 Aug 2002 02:16:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14856 for ; Wed, 7 Aug 2002 02:16:56 -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 CAA23430 for ; Wed, 7 Aug 2002 02:15:41 -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 g776Gvh15303 for ; Tue, 6 Aug 2002 23:16:57 -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 g773c7K00929 for ; Tue, 6 Aug 2002 20:38:07 -0700 (PDT) Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score To: midcom Date: Tue, 6 Aug 2002 22:19:52 -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 Tom & Cedric, The other protocols have a different extension "philosohy" than does RSIP. To extend the others ya design MIBs, packages, etc. Let's call that the "package philosophy". To extend RSIP, ya add messages, add parameters to messages, add new values to parameters, etc. Let's call that the "non-package philosophy". To my mind, they are both perfectly valid extension philosophies. While the package philosophy may be more appropriate than the non- package philosophy in certain situations, I think the opposite is also true. I think the non-package philosophy generally produces smaller, in total size, i.e., the size of of the base plus the size of the extension, protocols and implementations than the package philosophy, while the package phiosophy might produce smaller incremental size, i.e., just the size of the extension. I think that sometimes it might even be the case that the total size using the non-package philosophy could be smaller than just the extension using the package philosophy. Now, if I've already got the base protocol (SNMP, MEGACO, etc.) implementented in the environment to which I want to add middlebox control, then the package philosophy might be preferred. But if I don't already have the base protocol implemented, then I've got to add it before I can even consider adding the extension, and the non-package philosophy might be preferred. Vendors of small SOHO access routers that include firewall or NAT technology have expressed concern to me about the size of, e.g., MEGACO. For SIP phones, I've been told that. e.g., MECAGO isn't even a consideration. But both have successfully implemented RSIP, and have been delighted with it's small size. Of course implementation size is only one factor that needs to be considered: development time; test time; etc. But again, those differ depending on whether I've just got to add the extension or I've got to add the base before I can add the extension. Unfortunately, the analysis isn't as simple as we'd like it to be, and I don't think one analysis can fit all cases. Jim "Tom-PT Taylor" @ietf.org on 08/06/2002 01:40:07 PM Sent by: midcom-admin@ietf.org To: "Cedric Aoun" , James Renkel/MW/US/3Com, "'midcom @ietf.org'" cc: Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score To summarize, you are saying that some protocols (most, in fact) have explicit extensibility mechanisms, where others (RSIP in particular) do not. If I were to rank the candidates by readiness for extensibility this is how I would see it. I omit COPS because I'm not familiar with it, and I'm taking risks with RSIP because I'm not really familiar with it either: SNMP (most extensible): extensions require absolutely no change to the protocol itself. DIAMETER: extension mechanism provided, does mean protocol changes, but extensions can be handled by other DIAMETER entities without being understood. (Actually not sure that this property is relevant or useful in the MIDCOM case.) MEGACO: extension mechanism provided, does mean protocol changes, both ends have to understand the extensions. RSIP: no formal extension mechanism; extensions have to be designed into the protocol from scratch. -----Original Message----- From: Aoun, Cedric [GOLF:MA01:EXCH] Sent: Tuesday, August 06, 2002 2:16 PM To: 'James_Renkel@3com.com'; 'midcom@ietf.org' Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score If we want to be honest with other protocol evaluations, I don't see how RSIP's extensibility mechanisms would be graded in the same way as the other evaluated protocols. The other protocols have extensibility mechanisms were the base protocol messages are not always required to be extended to include new parameters (or even to create new messages). The other protocols use a certain "envelop" where the application (in this case Middlebox control) specific properties are contained, this provides a better extension mechanism than the RSIP protocol. IMHO I don't think we should grade RSIP to T, to be fair it has to have a lower grade than the other protocols. Cedric -----Original Message----- From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] Sent: 05 August 2002 20:28 To: midcom Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Middlebox experts, As I have said in a previous e-mail, RSIP clearly was designed to be extensible. The evaluation text of RSIP for this requirement explains how this works in more detail than the evaluation text for the other protocols. RSIP is currently scored a P+ on this requirement when it should, in my opinion, clearly be a T: it has a degree of extensibility comparable to the other protocols, and they were scored a T. I propose that the score of RSIP for this requirement be changed to T. I don't think there's any need to change the expanatory text. Comments expected and welcome. Jim _______________________________________________ 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 Wed Aug 7 09:00:20 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 JAA16013 for ; Wed, 7 Aug 2002 09:00:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09288 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 09:01: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 IAA08542; Wed, 7 Aug 2002 08:53: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 IAA08517 for ; Wed, 7 Aug 2002 08:53:14 -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 IAA15714 for ; Wed, 7 Aug 2002 08:52:01 -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 g77CqhAK010666; Wed, 7 Aug 2002 05:52:43 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AES52674; Wed, 7 Aug 2002 05:48:44 -0700 (PDT) Message-Id: <200208071248.AES52674@mira-sjc5-4.cisco.com> To: James_Renkel@3com.com cc: midcom From: Melinda Shore Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text In-Reply-To: Message from James_Renkel@3com.com of "Tue, 06 Aug 2002 21:18:59 CDT." Date: Wed, 07 Aug 2002 08:50:42 -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 > From: James_Renkel@3com.com > As I see it, the situation here is no diffrerent for RSIP than for any > of the other protocols. The difference may be in magnitude rather than in kind, but it's certainly there. With a typical client-server implementation you're selecting based on a file descriptor (socket) that has application state associated with it. With RSIP, as I understand your proposal, you've got the additional overhead of a "virtual" network interface for the borrowed address, which pushes more state into the OS or driver as well as the routing tables. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 15:29: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 PAA04916 for ; Wed, 7 Aug 2002 15:29:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02755 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 15:30:58 -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 PAA02272; Wed, 7 Aug 2002 15:29:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02238 for ; Wed, 7 Aug 2002 15:29:07 -0400 (EDT) Received: from jupiter.securelogix.com ([207.193.132.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04839 for ; Wed, 7 Aug 2002 15:27:52 -0400 (EDT) Received: by jupiter with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Aug 2002 14:28:30 -0500 Message-ID: <493BB8BDBB5AD511A7BB00104B62EE280105FE71@jupiter> From: David Oliver To: "'Tom-PT Taylor'" , Cedric Aoun , "'James_Renkel@3com.com'" , "'midcom@ietf.org'" Subject: RE: [midcom] Protocol Eval.: 2.2.1 RSIP - proposal to change scor e Date: Wed, 7 Aug 2002 14:28:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" 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 Perhaps a test of the extensibility of each protocol is to examine how much effort would be needed to change an ideal proxy, or layered implementation, for the protocol to work with the extension. A pragmatic version of this test is to determine how many extensions have been successfully added to the protocol in the past. (A comparable traditional test for reusability of Object Oriented classes is that they have been reused at least three times). SNMP obviously scores highly here, as new standardized and ad hoc MIBs can be, and regularly are, added on top of the basic protocol, without any change to the underlying layers, with extensions generally being transparent, except at the interface, where provision is made dynamically. I cannot comment on the other protocols. Regards, David C. Oliver Principal Engineer SecureLogix Corp Email: mailto:doliver@securelogix.com Tel: +1.210.402.9669 Fax: +1.210.402.6996 -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, August 06, 2002 1:40 PM To: Cedric Aoun; 'James_Renkel@3com.com'; 'midcom@ietf.org' Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score To summarize, you are saying that some protocols (most, in fact) have explicit extensibility mechanisms, where others (RSIP in particular) do not. If I were to rank the candidates by readiness for extensibility this is how I would see it. I omit COPS because I'm not familiar with it, and I'm taking risks with RSIP because I'm not really familiar with it either: SNMP (most extensible): extensions require absolutely no change to the protocol itself. DIAMETER: extension mechanism provided, does mean protocol changes, but extensions can be handled by other DIAMETER entities without being understood. (Actually not sure that this property is relevant or useful in the MIDCOM case.) MEGACO: extension mechanism provided, does mean protocol changes, both ends have to understand the extensions. RSIP: no formal extension mechanism; extensions have to be designed into the protocol from scratch. <...> _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 15:34: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 PAA05235 for ; Wed, 7 Aug 2002 15:34:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03107 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 15:35:54 -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 PAA03065; Wed, 7 Aug 2002 15: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 PAA03034 for ; Wed, 7 Aug 2002 15:34:37 -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 PAA05154 for ; Wed, 7 Aug 2002 15:33:23 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g77JY3r18024; Wed, 7 Aug 2002 15:34:03 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 15:34:03 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387CB5@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "Tom-PT Taylor" , "Cedric Aoun" , "'James_Renkel@3com.com'" , "'midcom@ietf.org'" Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Date: Wed, 7 Aug 2002 15:34:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23E49.619A3FCE" 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_01C23E49.619A3FCE Content-Type: text/plain; charset="iso-8859-1" Tom, since you did not comment on COPS-PR, I will. COPS-PR is comparable to SNMP as it is extensible without any changes to the protocol itself. Exactly like in SNMP where you can create new MIBS, you can create new PIBs for COPS-PR. L-N > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Tuesday, August 06, 2002 2:40 PM > To: Aoun, Cedric [GOLF:MA01:EXCH]; 'James_Renkel@3com.com'; > 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change > score > > > > To summarize, you are saying that some protocols (most, in fact) have > explicit extensibility mechanisms, where others (RSIP in > particular) do not. > > If I were to rank the candidates by readiness for > extensibility this is how > I would see it. I omit COPS because I'm not familiar with it, and I'm > taking risks with RSIP because I'm not really familiar with it either: > > SNMP (most extensible): extensions require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol > changes, but > extensions can be handled by other DIAMETER entities without being > understood. (Actually not sure that this property is > relevant or useful in > the MIDCOM case.) > > MEGACO: extension mechanism provided, does mean protocol > changes, both ends > have to understand the extensions. > > RSIP: no formal extension mechanism; extensions have to be > designed into the > protocol from scratch. > > > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Tuesday, August 06, 2002 2:16 PM > To: 'James_Renkel@3com.com'; 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > If we want to be honest with other protocol evaluations, > I don't see how RSIP's extensibility mechanisms would be > graded in the same > way as the other evaluated protocols. > The other protocols have extensibility mechanisms were the > base protocol > messages > are not always required to be extended to include new > parameters (or even to > create new messages). > The other protocols use a certain "envelop" where the > application (in this > case Middlebox control) > specific properties are contained, this provides a better extension > mechanism than the RSIP protocol. > IMHO I don't think we should grade RSIP to T, to be fair it > has to have a > lower grade than > the other protocols. > Cedric > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: 05 August 2002 20:28 > To: midcom > Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > Middlebox experts, > As I have said in a previous e-mail, RSIP clearly was designed to be > extensible. The evaluation text of RSIP for this requirement explains > how this works in more detail than the evaluation text for the other > protocols. > RSIP is currently scored a P+ on this requirement when it should, in > my opinion, clearly be a T: it has a degree of extensibility > comparable > to the other protocols, and they were scored a T. > I propose that the score of RSIP for this requirement be > changed to T. > I don't think there's any need to change the expanatory text. > Comments expected and welcome. > Jim > > > _______________________________________________ > 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_01C23E49.619A3FCE Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

Tom,

since you did not comment on COPS-PR, I will.
COPS-PR is comparable to SNMP as it is extensible without any changes to
the protocol itself. Exactly like in SNMP where you can create new MIBS, you can
create new PIBs for COPS-PR.

L-N

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B602:EXCH]
> Sent: Tuesday, August 06, 2002 2:40 PM
> To: Aoun, Cedric [GOLF:MA01:EXCH]; 'James_Renkel@3com.com';
> 'midcom@ietf.org'
> Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change
> score
>
>
>
> To summarize, you are saying that some protocols (most, in fact) have
> explicit extensibility mechanisms, where others (RSIP in
> particular) do not.
>
> If I were to rank the candidates by readiness for
> extensibility this is how
> I would see it.  I omit COPS because I'm not familiar with it, and I'm
> taking risks with RSIP because I'm not really familiar with it either:
>
> SNMP (most extensible): extensions require absolutely no change to the
> protocol itself.
>
> DIAMETER: extension mechanism provided, does mean protocol
> changes, but
> extensions can be handled by other DIAMETER entities without being
> understood.  (Actually not sure that this property is
> relevant or useful in
> the MIDCOM case.)
>
> MEGACO: extension mechanism provided, does mean protocol
> changes, both ends
> have to understand the extensions.
>
> RSIP: no formal extension mechanism; extensions have to be
> designed into the
> protocol from scratch.
>
>
> -----Original Message-----
> From: Aoun, Cedric [GOLF:MA01:EXCH]
> Sent: Tuesday, August 06, 2002 2:16 PM
> To: 'James_Renkel@3com.com'; 'midcom@ietf.org'
> Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to
> change score
>
>
> If we want to be honest with other protocol evaluations,
> I don't see how RSIP's extensibility mechanisms would be
> graded in the same
> way as the other evaluated protocols.
> The other protocols have extensibility mechanisms were the
> base protocol
> messages
> are not always required to be extended to include new
> parameters (or even to
> create new messages).
> The other protocols use a certain "envelop" where the
> application (in this
> case Middlebox control)
> specific properties are contained, this provides a better extension
> mechanism than the RSIP protocol.
> IMHO I don't think we should grade RSIP to T, to be fair it
> has to have a
> lower grade than
> the other protocols.
> Cedric
> -----Original Message-----
> From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
> Sent: 05 August 2002 20:28
> To: midcom
> Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to
> change score
>
>
> Middlebox experts,
> As I have said in a previous e-mail, RSIP clearly was designed to be
> extensible. The evaluation text of RSIP for this requirement explains
> how this works in more detail than the evaluation text for the other
> protocols.
> RSIP is currently scored a P+ on this requirement when it should, in
> my opinion, clearly be a T: it has a degree of extensibility
> comparable
> to the other protocols, and they were scored a T.
> I propose that the score of RSIP for this requirement be
> changed to T.
> I don't think there's any need to change the expanatory text.
> Comments expected and welcome.
> Jim
>
>
> _______________________________________________
> 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_01C23E49.619A3FCE-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 15:42: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 PAA05846 for ; Wed, 7 Aug 2002 15:42:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03271 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 15:43:58 -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 PAA03233; Wed, 7 Aug 2002 15:41: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 PAA03202 for ; Wed, 7 Aug 2002 15:41:16 -0400 (EDT) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05691 for ; Wed, 7 Aug 2002 15:40:01 -0400 (EDT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H0H00BF8NW07Y@firewall.wcom.com> for midcom@ietf.org; Wed, 07 Aug 2002 19:38:25 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H0H00201NVJU5@pmismtp02.wcomnet.com>; Wed, 07 Aug 2002 19:38:24 +0000 (GMT) Received: from rccc6131 ([166.35.135.58]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H0H0021UNVROW@pmismtp02.wcomnet.com>; Wed, 07 Aug 2002 19:38:16 +0000 (GMT) Date: Wed, 07 Aug 2002 14:37:40 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score In-reply-to: <9FBD322B7824D511B36900508BF93C9C04387CB5@zcard031.ca.nortel.com> To: "'Louis-Nicolas Hamer'" , "'Tom-PT Taylor'" , "'Cedric Aoun'" , James_Renkel@3com.com, midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002001c23e49$e5724080$3a8723a6@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_809gMWYCZ4/6Sn5LKbDUYA)" 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_809gMWYCZ4/6Sn5LKbDUYA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change scoreI concur with that, but was under the impression that it was a bulkier process/mechansim...I will read more in order to comment further, but what do you think of the comment, valid|not valid? -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas Hamer Sent: Wednesday, August 07, 2002 2:34 PM To: Tom-PT Taylor; Cedric Aoun; 'James_Renkel@3com.com'; 'midcom@ietf.org' Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Tom, since you did not comment on COPS-PR, I will. COPS-PR is comparable to SNMP as it is extensible without any changes to the protocol itself. Exactly like in SNMP where you can create new MIBS, you can create new PIBs for COPS-PR. L-N > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Tuesday, August 06, 2002 2:40 PM > To: Aoun, Cedric [GOLF:MA01:EXCH]; 'James_Renkel@3com.com'; > 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change > score > > > > To summarize, you are saying that some protocols (most, in fact) have > explicit extensibility mechanisms, where others (RSIP in > particular) do not. > > If I were to rank the candidates by readiness for > extensibility this is how > I would see it. I omit COPS because I'm not familiar with it, and I'm > taking risks with RSIP because I'm not really familiar with it either: > > SNMP (most extensible): extensions require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol > changes, but > extensions can be handled by other DIAMETER entities without being > understood. (Actually not sure that this property is > relevant or useful in > the MIDCOM case.) > > MEGACO: extension mechanism provided, does mean protocol > changes, both ends > have to understand the extensions. > > RSIP: no formal extension mechanism; extensions have to be > designed into the > protocol from scratch. > > > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Tuesday, August 06, 2002 2:16 PM > To: 'James_Renkel@3com.com'; 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > If we want to be honest with other protocol evaluations, > I don't see how RSIP's extensibility mechanisms would be > graded in the same > way as the other evaluated protocols. > The other protocols have extensibility mechanisms were the > base protocol > messages > are not always required to be extended to include new > parameters (or even to > create new messages). > The other protocols use a certain "envelop" where the > application (in this > case Middlebox control) > specific properties are contained, this provides a better extension > mechanism than the RSIP protocol. > IMHO I don't think we should grade RSIP to T, to be fair it > has to have a > lower grade than > the other protocols. > Cedric > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: 05 August 2002 20:28 > To: midcom > Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > Middlebox experts, > As I have said in a previous e-mail, RSIP clearly was designed to be > extensible. The evaluation text of RSIP for this requirement explains > how this works in more detail than the evaluation text for the other > protocols. > RSIP is currently scored a P+ on this requirement when it should, in > my opinion, clearly be a T: it has a degree of extensibility > comparable > to the other protocols, and they were scored a T. > I propose that the score of RSIP for this requirement be > changed to T. > I don't think there's any need to change the expanatory text. > Comments expected and welcome. > Jim > > > _______________________________________________ > 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 > --Boundary_(ID_809gMWYCZ4/6Sn5LKbDUYA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change = score
I=20 concur with that, but was under the impression that it was a bulkier=20 process/mechansim...I will read more in order to comment further, but = what do=20 you think of the comment, valid|not valid?
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas=20 Hamer
Sent: Wednesday, August 07, 2002 2:34 PM
To: = Tom-PT=20 Taylor; Cedric Aoun; 'James_Renkel@3com.com';=20 'midcom@ietf.org'
Subject: RE: [midcom] Protocol eval: 2.2.1 = RSIP -=20 proposal to change score

Tom,

since you did not comment on COPS-PR, I will. =
COPS-PR is comparable to SNMP as it is extensible without any = changes=20 to
the protocol itself. Exactly like in SNMP = where you=20 can create new MIBS, you can
create new PIBs = for=20 COPS-PR.

L-N

> -----Original Message-----
>=20 From: Taylor, Tom-PT [CAR:B602:EXCH]
> = Sent:=20 Tuesday, August 06, 2002 2:40 PM
> To: = Aoun, Cedric=20 [GOLF:MA01:EXCH]; 'James_Renkel@3com.com';
>=20 'midcom@ietf.org'
> Subject: RE: [midcom] = Protocol=20 eval: 2.2.1 RSIP - proposal to change
>=20 score
>
>=20
>
> To = summarize, you=20 are saying that some protocols (most, in fact) have
> explicit extensibility mechanisms, where others (RSIP in =
> particular) do not.
>=20
> If I were to rank the candidates by = readiness for=20
> extensibility this is how =
> I would see it.  I omit COPS because I'm not = familiar with=20 it, and I'm
> taking risks with RSIP = because I'm=20 not really familiar with it either:
>=20
> SNMP (most extensible): extensions = require=20 absolutely no change to the
> protocol=20 itself.
>
> = DIAMETER:=20 extension mechanism provided, does mean protocol
>=20 changes, but
> extensions can be handled = by other=20 DIAMETER entities without being
> = understood. =20 (Actually not sure that this property is
> relevant=20 or useful in
> the MIDCOM case.) =
>
> MEGACO: extension = mechanism provided,=20 does mean protocol
> changes, both = ends=20
> have to understand the extensions. =
>
> RSIP: no formal extension = mechanism;=20 extensions have to be
> designed into = the=20
> protocol from scratch.
>=20
>
> = -----Original=20 Message-----
> From: Aoun, Cedric = [GOLF:MA01:EXCH]=20
> Sent: Tuesday, August 06, 2002 2:16 = PM=20
> To: 'James_Renkel@3com.com'; = 'midcom@ietf.org'=20
> Subject: RE: [midcom] Protocol eval: 2.2.1 = RSIP -=20 proposal to
> change score =
>
>
> If we=20 want to be honest with other protocol evaluations,
> I don't see how RSIP's extensibility mechanisms would be =
> graded in the same
>=20 way as the other evaluated protocols.
> = The other=20 protocols have extensibility mechanisms were the
>=20 base protocol
> messages
> are not always required to be extended to include new=20
> parameters (or even to
> create new messages).
> The = other=20 protocols use a certain "envelop" where the
>=20 application (in this
> case Middlebox = control)=20
> specific properties are contained, this = provides=20 a better extension
> mechanism than the = RSIP=20 protocol.
> IMHO I don't think we should = grade RSIP=20 to T, to be fair it
> has to have = a=20
> lower grade than
> the other=20 protocols.
> Cedric
>=20 -----Original Message-----
> From:=20 James_Renkel@3com.com [mailto:James_Renkel@3com.com]=20
> Sent: 05 August 2002 20:28 =
> To: midcom
> Subject: = [midcom] Protocol=20 eval: 2.2.1 RSIP - proposal to
> change = score=20
>
> =
> Middlebox experts,
> As I = have said in=20 a previous e-mail, RSIP clearly was designed to be
> extensible. The evaluation text of RSIP for this = requirement=20 explains
> how this works in more detail = than the=20 evaluation text for the other
> = protocols.=20
> RSIP is currently scored a P+ on this = requirement=20 when it should, in
> my opinion, clearly = be a T: it=20 has a degree of extensibility
> = comparable=20
> to the other protocols, and they were = scored a T.=20
> I propose that the score of RSIP for = this=20 requirement be
> changed to T. =
> I don't think there's any need to change the expanatory = text.=20
> Comments expected and welcome. =
> Jim
>
>=20
> = _______________________________________________=20
> midcom mailing list
>=20 midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom=20
>
>=20 _______________________________________________
>=20 midcom mailing list
> = midcom@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/midcom =
>

--Boundary_(ID_809gMWYCZ4/6Sn5LKbDUYA)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 15: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 PAA05983 for ; Wed, 7 Aug 2002 15:44:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03460 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 15:46:01 -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 PAA03374; Wed, 7 Aug 2002 15:44: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 PAA03301 for ; Wed, 7 Aug 2002 15:44:53 -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 PAA05934 for ; Wed, 7 Aug 2002 15:43:38 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g77JiIr18826; Wed, 7 Aug 2002 15:44:18 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 15:44:18 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387CB6@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "'christopher.a.martin@wcom.com'" , "Tom-PT Taylor" , "Cedric Aoun" , James_Renkel@3com.com, midcom@ietf.org Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Date: Wed, 7 Aug 2002 15:44:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23E4A.8F6CF13E" 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_01C23E4A.8F6CF13E Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Wednesday, August 07, 2002 3:38 PM To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Taylor, Tom-PT [CAR:B602:EXCH]; Aoun, Cedric [GOLF:MA01:EXCH]; James_Renkel@3com.com; midcom@ietf.org Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > I concur with that, but was under the impression that it was a bulkier process/mechansim [Louis-Nicolas Hamer] Why? What gave you this impression. > ...I will read more in order to comment further, but what do you think of the comment, valid|not valid? [Louis-Nicolas Hamer] If you are refering to pibs being a bulkier process, my answer is Not valid. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas Hamer Sent: Wednesday, August 07, 2002 2:34 PM To: Tom-PT Taylor; Cedric Aoun; 'James_Renkel@3com.com'; 'midcom@ietf.org' Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Tom, since you did not comment on COPS-PR, I will. COPS-PR is comparable to SNMP as it is extensible without any changes to the protocol itself. Exactly like in SNMP where you can create new MIBS, you can create new PIBs for COPS-PR. L-N > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Tuesday, August 06, 2002 2:40 PM > To: Aoun, Cedric [GOLF:MA01:EXCH]; 'James_Renkel@3com.com'; > 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change > score > > > > To summarize, you are saying that some protocols (most, in fact) have > explicit extensibility mechanisms, where others (RSIP in > particular) do not. > > If I were to rank the candidates by readiness for > extensibility this is how > I would see it. I omit COPS because I'm not familiar with it, and I'm > taking risks with RSIP because I'm not really familiar with it either: > > SNMP (most extensible): extensions require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol > changes, but > extensions can be handled by other DIAMETER entities without being > understood. (Actually not sure that this property is > relevant or useful in > the MIDCOM case.) > > MEGACO: extension mechanism provided, does mean protocol > changes, both ends > have to understand the extensions. > > RSIP: no formal extension mechanism; extensions have to be > designed into the > protocol from scratch. > > > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Tuesday, August 06, 2002 2:16 PM > To: 'James_Renkel@3com.com'; 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > If we want to be honest with other protocol evaluations, > I don't see how RSIP's extensibility mechanisms would be > graded in the same > way as the other evaluated protocols. > The other protocols have extensibility mechanisms were the > base protocol > messages > are not always required to be extended to include new > parameters (or even to > create new messages). > The other protocols use a certain "envelop" where the > application (in this > case Middlebox control) > specific properties are contained, this provides a better extension > mechanism than the RSIP protocol. > IMHO I don't think we should grade RSIP to T, to be fair it > has to have a > lower grade than > the other protocols. > Cedric > -----Original Message----- > From: James_Renkel@3com.com [ mailto:James_Renkel@3com.com ] > Sent: 05 August 2002 20:28 > To: midcom > Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > Middlebox experts, > As I have said in a previous e-mail, RSIP clearly was designed to be > extensible. The evaluation text of RSIP for this requirement explains > how this works in more detail than the evaluation text for the other > protocols. > RSIP is currently scored a P+ on this requirement when it should, in > my opinion, clearly be a T: it has a degree of extensibility > comparable > to the other protocols, and they were scored a T. > I propose that the score of RSIP for this requirement be > changed to T. > I don't think there's any need to change the expanatory text. > Comments expected and welcome. > Jim > > > _______________________________________________ > 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_01C23E4A.8F6CF13E Content-Type: text/html; charset="iso-8859-1" RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score
-----Original Message-----
From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com]
Sent: Wednesday, August 07, 2002 3:38 PM
To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Taylor, Tom-PT [CAR:B602:EXCH]; Aoun, Cedric [GOLF:MA01:EXCH]; James_Renkel@3com.com; midcom@ietf.org
Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

> I concur with that, but was under the impression that it was a bulkier process/mechansim
[Louis-Nicolas Hamer] Why? What gave you this impression.
 
 > ...I will read more in order to comment further, but what do you think of the comment, valid|not valid?
[Louis-Nicolas Hamer] If you are refering to pibs being a bulkier process, my answer is Not valid. 
-----Original Message-----
From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas Hamer
Sent: Wednesday, August 07, 2002 2:34 PM
To: Tom-PT Taylor; Cedric Aoun; 'James_Renkel@3com.com'; 'midcom@ietf.org'
Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score

Tom,

since you did not comment on COPS-PR, I will.
COPS-PR is comparable to SNMP as it is extensible without any changes to
the protocol itself. Exactly like in SNMP where you can create new MIBS, you can
create new PIBs for COPS-PR.

L-N

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B602:EXCH]
> Sent: Tuesday, August 06, 2002 2:40 PM
> To: Aoun, Cedric [GOLF:MA01:EXCH]; 'James_Renkel@3com.com';
> 'midcom@ietf.org'
> Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change
> score
>
>
>
> To summarize, you are saying that some protocols (most, in fact) have
> explicit extensibility mechanisms, where others (RSIP in
> particular) do not.
>
> If I were to rank the candidates by readiness for
> extensibility this is how
> I would see it.  I omit COPS because I'm not familiar with it, and I'm
> taking risks with RSIP because I'm not really familiar with it either:
>
> SNMP (most extensible): extensions require absolutely no change to the
> protocol itself.
>
> DIAMETER: extension mechanism provided, does mean protocol
> changes, but
> extensions can be handled by other DIAMETER entities without being
> understood.  (Actually not sure that this property is
> relevant or useful in
> the MIDCOM case.)
>
> MEGACO: extension mechanism provided, does mean protocol
> changes, both ends
> have to understand the extensions.
>
> RSIP: no formal extension mechanism; extensions have to be
> designed into the
> protocol from scratch.
>
>
> -----Original Message-----
> From: Aoun, Cedric [GOLF:MA01:EXCH]
> Sent: Tuesday, August 06, 2002 2:16 PM
> To: 'James_Renkel@3com.com'; 'midcom@ietf.org'
> Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to
> change score
>
>
> If we want to be honest with other protocol evaluations,
> I don't see how RSIP's extensibility mechanisms would be
> graded in the same
> way as the other evaluated protocols.
> The other protocols have extensibility mechanisms were the
> base protocol
> messages
> are not always required to be extended to include new
> parameters (or even to
> create new messages).
> The other protocols use a certain "envelop" where the
> application (in this
> case Middlebox control)
> specific properties are contained, this provides a better extension
> mechanism than the RSIP protocol.
> IMHO I don't think we should grade RSIP to T, to be fair it
> has to have a
> lower grade than
> the other protocols.
> Cedric
> -----Original Message-----
> From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]
> Sent: 05 August 2002 20:28
> To: midcom
> Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to
> change score
>
>
> Middlebox experts,
> As I have said in a previous e-mail, RSIP clearly was designed to be
> extensible. The evaluation text of RSIP for this requirement explains
> how this works in more detail than the evaluation text for the other
> protocols.
> RSIP is currently scored a P+ on this requirement when it should, in
> my opinion, clearly be a T: it has a degree of extensibility
> comparable
> to the other protocols, and they were scored a T.
> I propose that the score of RSIP for this requirement be
> changed to T.
> I don't think there's any need to change the expanatory text.
> Comments expected and welcome.
> Jim
>
>
> _______________________________________________
> 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_01C23E4A.8F6CF13E-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 16:04: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 QAA06658 for ; Wed, 7 Aug 2002 16:04:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04463 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 16:05: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 QAA04431; Wed, 7 Aug 2002 16:04: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 QAA04402 for ; Wed, 7 Aug 2002 16:04:02 -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 QAA06549 for ; Wed, 7 Aug 2002 16:02:47 -0400 (EDT) Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H0H00M3JOYYG5@firewall.wcom.com> for midcom@ietf.org; Wed, 07 Aug 2002 20:01:46 +0000 (GMT) Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0H0H00001OYRTC@pmismtp05.wcomnet.com>; Wed, 07 Aug 2002 20:01:40 +0000 (GMT) Received: from rccc6131 ([166.35.135.58]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0H0H00LJKOYRIL@pmismtp05.wcomnet.com>; Wed, 07 Aug 2002 20:01:39 +0000 (GMT) Date: Wed, 07 Aug 2002 15:01:09 -0500 From: "Christopher A. Martin" Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score In-reply-to: <9FBD322B7824D511B36900508BF93C9C04387CB6@zcard031.ca.nortel.com> To: "'Louis-Nicolas Hamer'" , "'Tom-PT Taylor'" , "'Cedric Aoun'" , James_Renkel@3com.com, midcom@ietf.org Reply-to: christopher.a.martin@wcom.com Message-id: <002f01c23e4d$2d0c9b40$3a8723a6@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_nq7yrkZ2Lczp9Kd4BfJw9w)" 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_nq7yrkZ2Lczp9Kd4BfJw9w) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change scoreI am remembering coments to this effect, and would like to refresh on COPS again to verify why...your opinion, being more versed in it than I, was what I was looking for. Thanks. Chris I will continue to review. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas Hamer Sent: Wednesday, August 07, 2002 2:44 PM To: 'christopher.a.martin@wcom.com'; Tom-PT Taylor; Cedric Aoun; James_Renkel@3com.com; midcom@ietf.org Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score -----Original Message----- From: Christopher A. Martin [mailto:christopher.a.martin@wcom.com] Sent: Wednesday, August 07, 2002 3:38 PM To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; Taylor, Tom-PT [CAR:B602:EXCH]; Aoun, Cedric [GOLF:MA01:EXCH]; James_Renkel@3com.com; midcom@ietf.org Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score > I concur with that, but was under the impression that it was a bulkier process/mechansim [Louis-Nicolas Hamer] Why? What gave you this impression. > ...I will read more in order to comment further, but what do you think of the comment, valid|not valid? [Louis-Nicolas Hamer] If you are refering to pibs being a bulkier process, my answer is Not valid. -----Original Message----- From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas Hamer Sent: Wednesday, August 07, 2002 2:34 PM To: Tom-PT Taylor; Cedric Aoun; 'James_Renkel@3com.com'; 'midcom@ietf.org' Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change score Tom, since you did not comment on COPS-PR, I will. COPS-PR is comparable to SNMP as it is extensible without any changes to the protocol itself. Exactly like in SNMP where you can create new MIBS, you can create new PIBs for COPS-PR. L-N > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Tuesday, August 06, 2002 2:40 PM > To: Aoun, Cedric [GOLF:MA01:EXCH]; 'James_Renkel@3com.com'; > 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change > score > > > > To summarize, you are saying that some protocols (most, in fact) have > explicit extensibility mechanisms, where others (RSIP in > particular) do not. > > If I were to rank the candidates by readiness for > extensibility this is how > I would see it. I omit COPS because I'm not familiar with it, and I'm > taking risks with RSIP because I'm not really familiar with it either: > > SNMP (most extensible): extensions require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol > changes, but > extensions can be handled by other DIAMETER entities without being > understood. (Actually not sure that this property is > relevant or useful in > the MIDCOM case.) > > MEGACO: extension mechanism provided, does mean protocol > changes, both ends > have to understand the extensions. > > RSIP: no formal extension mechanism; extensions have to be > designed into the > protocol from scratch. > > > -----Original Message----- > From: Aoun, Cedric [GOLF:MA01:EXCH] > Sent: Tuesday, August 06, 2002 2:16 PM > To: 'James_Renkel@3com.com'; 'midcom@ietf.org' > Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > If we want to be honest with other protocol evaluations, > I don't see how RSIP's extensibility mechanisms would be > graded in the same > way as the other evaluated protocols. > The other protocols have extensibility mechanisms were the > base protocol > messages > are not always required to be extended to include new > parameters (or even to > create new messages). > The other protocols use a certain "envelop" where the > application (in this > case Middlebox control) > specific properties are contained, this provides a better extension > mechanism than the RSIP protocol. > IMHO I don't think we should grade RSIP to T, to be fair it > has to have a > lower grade than > the other protocols. > Cedric > -----Original Message----- > From: James_Renkel@3com.com [mailto:James_Renkel@3com.com] > Sent: 05 August 2002 20:28 > To: midcom > Subject: [midcom] Protocol eval: 2.2.1 RSIP - proposal to > change score > > > Middlebox experts, > As I have said in a previous e-mail, RSIP clearly was designed to be > extensible. The evaluation text of RSIP for this requirement explains > how this works in more detail than the evaluation text for the other > protocols. > RSIP is currently scored a P+ on this requirement when it should, in > my opinion, clearly be a T: it has a degree of extensibility > comparable > to the other protocols, and they were scored a T. > I propose that the score of RSIP for this requirement be > changed to T. > I don't think there's any need to change the expanatory text. > Comments expected and welcome. > Jim > > > _______________________________________________ > 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 > --Boundary_(ID_nq7yrkZ2Lczp9Kd4BfJw9w) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to change = score
I am=20 remembering coments to this effect, and would like to refresh on COPS = again to=20 verify why...your opinion, being more versed in it than I, was what = I was=20 looking for.
 
Thanks.
Chris
 
I will=20 continue to review.
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas=20 Hamer
Sent: Wednesday, August 07, 2002 2:44 PM
To: = 'christopher.a.martin@wcom.com'; Tom-PT Taylor; Cedric Aoun;=20 James_Renkel@3com.com; midcom@ietf.org
Subject: RE: [midcom] = Protocol eval: 2.2.1 RSIP - proposal to change = score

-----Original Message-----
From: Christopher A. = Martin=20 [mailto:christopher.a.martin@wcom.com]
Sent: Wednesday, = August 07,=20 2002 3:38 PM
To: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH]; = Taylor,=20 Tom-PT [CAR:B602:EXCH]; Aoun, Cedric [GOLF:MA01:EXCH];=20 James_Renkel@3com.com; midcom@ietf.org
Subject: RE: = [midcom]=20 Protocol eval: 2.2.1 RSIP - proposal to change=20 score

> I concur with that, = but was=20 under the impression that it was a bulkier = process/mechansim
[Louis-Nicolas=20 Hamer] Why? What gave you this impression.=20
 
 > ...I will read more = in order=20 to comment further, but what do you think of the comment, valid|not=20 valid?
[Louis-Nicolas Hamer] If you are = refering to=20 pibs being a bulkier process, my answer is Not=20 valid. 
-----Original Message-----
From: = midcom-admin@ietf.org=20 [mailto:midcom-admin@ietf.org]On Behalf Of Louis-Nicolas=20 Hamer
Sent: Wednesday, August 07, 2002 2:34 = PM
To:=20 Tom-PT Taylor; Cedric Aoun; 'James_Renkel@3com.com';=20 'midcom@ietf.org'
Subject: RE: [midcom] Protocol eval: = 2.2.1=20 RSIP - proposal to change score

Tom,

since you did not comment on COPS-PR, I = will.=20
COPS-PR is comparable to SNMP as it is = extensible without=20 any changes to
the protocol itself. = Exactly like=20 in SNMP where you can create new MIBS, you can
create new PIBs for COPS-PR.

L-N

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B602:EXCH] =
> Sent: Tuesday, August 06, 2002 2:40 PM =
> To: Aoun, Cedric [GOLF:MA01:EXCH];=20 'James_Renkel@3com.com';
>=20 'midcom@ietf.org'
> Subject: RE: = [midcom]=20 Protocol eval: 2.2.1 RSIP - proposal to change
> score
> =
>
>
> To=20 summarize, you are saying that some protocols (most, in fact) = have=20
> explicit extensibility mechanisms, where = others=20 (RSIP in
> particular) do not. =
>
> If I were to rank the = candidates=20 by readiness for
> extensibility this = is=20 how
> I would see it.  I omit = COPS because=20 I'm not familiar with it, and I'm
> = taking=20 risks with RSIP because I'm not really familiar with it = either:=20
>
> SNMP (most = extensible):=20 extensions require absolutely no change to the
> protocol itself.
> =
> DIAMETER: extension mechanism provided, does mean = protocol=20
> changes, but
>=20 extensions can be handled by other DIAMETER entities without = being=20
> understood.  (Actually not sure that = this=20 property is
> relevant or useful = in=20
> the MIDCOM case.)
>=20
> MEGACO: extension mechanism = provided, does=20 mean protocol
> changes, both = ends=20
> have to understand the extensions. =
>
> RSIP: no formal = extension=20 mechanism; extensions have to be
> = designed=20 into the
> protocol from = scratch.=20
>
> =
> -----Original Message-----
> From:=20 Aoun, Cedric [GOLF:MA01:EXCH]
> Sent: = Tuesday,=20 August 06, 2002 2:16 PM
> To:=20 'James_Renkel@3com.com'; 'midcom@ietf.org'
>=20 Subject: RE: [midcom] Protocol eval: 2.2.1 RSIP - proposal to=20
> change score
>=20
>
> If = we want to be=20 honest with other protocol evaluations,
> I=20 don't see how RSIP's extensibility mechanisms would be =
> graded in the same
> = way as the=20 other evaluated protocols.
> The = other=20 protocols have extensibility mechanisms were the
> base protocol
> = messages=20
> are not always required to be = extended to=20 include new
> parameters (or even = to=20
> create new messages).
>=20 The other protocols use a certain "envelop" where the =
> application (in this
> = case=20 Middlebox control)
> specific = properties are=20 contained, this provides a better extension
>=20 mechanism than the RSIP protocol.
> = IMHO I=20 don't think we should grade RSIP to T, to be fair it =
> has to have a
> lower = grade than=20
> the other protocols. =
> Cedric
> -----Original = Message-----=20
> From: James_Renkel@3com.com [mailto:James_Renkel@3com.com]=20
> Sent: 05 August 2002 20:28 =
> To: midcom
> Subject: = [midcom]=20 Protocol eval: 2.2.1 RSIP - proposal to
>=20 change score
>
>=20
> Middlebox experts,
> As I have said in a previous e-mail, RSIP clearly = was designed=20 to be
> extensible. The evaluation = text of RSIP=20 for this requirement explains
> how = this works=20 in more detail than the evaluation text for the other =
> protocols.
> RSIP is = currently=20 scored a P+ on this requirement when it should, in =
> my opinion, clearly be a T: it has a degree of = extensibility=20
> comparable
> to=20 the other protocols, and they were scored a T.
> I propose that the score of RSIP for this = requirement be=20
> changed to T.
> I=20 don't think there's any need to change the expanatory text.=20
> Comments expected and welcome.=20
> Jim
>=20
>
>=20 _______________________________________________
> midcom mailing list
>=20 midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom=20
>
>=20 _______________________________________________
> midcom mailing list
>=20 midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom =
>=20

--Boundary_(ID_nq7yrkZ2Lczp9Kd4BfJw9w)-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 16:51:27 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 QAA08153 for ; Wed, 7 Aug 2002 16:51:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06453 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 16:52: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 QAA06350; Wed, 7 Aug 2002 16:51:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06323 for ; Wed, 7 Aug 2002 16:51:16 -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 QAA08128 for ; Wed, 7 Aug 2002 16:50:00 -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 g77KorZ11801 for ; Wed, 7 Aug 2002 15:50:53 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 15:50:38 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C84B@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom'" Date: Wed, 7 Aug 2002 15:50:37 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP 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 Hi all, Based upon the responses to Jim's email thread on this topic, I think there is general concensus to change 2.2.1 to T for RSIP. In addition, this thread highlighted a key aspect as to the level or readiness of extensibility with the following summary, which I've liberally copied from Tom's email and added COPS: SNMP and COPS (most extensible): extensions require absolutely no change to the protocol itself. DIAMETER: extension mechanism provided, does mean protocol changes, but extensions can be handled by other DIAMETER entities without being understood. (Actually not sure that this property is relevant or useful in the MIDCOM case.) MEGACO: extension mechanism provided, does mean protocol changes, both ends have to understand the extensions. RSIP: no formal extension mechanism; extensions have to be designed into the protocol from scratch. My proposal to ensure that we capture this aspect of the evaluation and include some text in the conclusion, following the controversial table capturing this information, to highlight that this is key to considering the impact of P+ for a specific protocol. I'll propose specific text when I get down to editting again early tomorrow. Folks that participated in this thread are also welcome to craft the proposed text. Regards, Mary. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 17:00: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 RAA08748 for ; Wed, 7 Aug 2002 17:00:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08847 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 17:01:53 -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 RAA08505; Wed, 7 Aug 2002 17:00: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 RAA08466 for ; Wed, 7 Aug 2002 17:00:44 -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 QAA08692 for ; Wed, 7 Aug 2002 16:59:30 -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 g77L0SZ19756 for ; Wed, 7 Aug 2002 16:00:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 16:00:13 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A6341E@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "Mary Barnes" , "'midcom'" Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ( wa s RE: Proposed changes to RSIP evaluation Date: Wed, 7 Aug 2002 16:00:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23E55.6C5F1C70" 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_01C23E55.6C5F1C70 Content-Type: text/plain Speaking from Megaco perspective, I don't understand why it would be any less extensible than either SNMP or COPS, as packages doesn't need any changes in base protocol. Can somebody educate me on this? -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Wednesday, August 07, 2002 3:51 PM To: 'midcom' Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP evaluation Hi all, Based upon the responses to Jim's email thread on this topic, I think there is general concensus to change 2.2.1 to T for RSIP. In addition, this thread highlighted a key aspect as to the level or readiness of extensibility with the following summary, which I've liberally copied from Tom's email and added COPS: SNMP and COPS (most extensible): extensions require absolutely no change to the protocol itself. DIAMETER: extension mechanism provided, does mean protocol changes, but extensions can be handled by other DIAMETER entities without being understood. (Actually not sure that this property is relevant or useful in the MIDCOM case.) MEGACO: extension mechanism provided, does mean protocol changes, both ends have to understand the extensions. RSIP: no formal extension mechanism; extensions have to be designed into the protocol from scratch. My proposal to ensure that we capture this aspect of the evaluation and include some text in the conclusion, following the controversial table capturing this information, to highlight that this is key to considering the impact of P+ for a specific protocol. I'll propose specific text when I get down to editting again early tomorrow. Folks that participated in this thread are also welcome to craft the proposed text. Regards, Mary. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------_=_NextPart_001_01C23E55.6C5F1C70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - = P+ -> T ? ( wa s RE: Proposed changes to RSIP evaluation

Speaking from Megaco perspective, I don't understand = why it would be any less extensible than either SNMP or COPS, as = packages doesn't need any changes in base protocol. Can somebody = educate me on this?

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH]
Sent: Wednesday, August 07, 2002 3:51 PM
To: 'midcom'
Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP = Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP = evaluation


Hi all,

Based upon the responses to Jim's email thread on = this topic, I think there is general concensus to change 2.2.1 to T for = RSIP. 

In addition, this thread highlighted a key aspect as = to the level or readiness of extensibility with the following summary, = which I've liberally copied from Tom's email and added COPS:

SNMP and COPS (most extensible): extensions require = absolutely no change to the
protocol itself.
 
DIAMETER: extension mechanism provided, does mean = protocol
changes, but extensions can be handled by other = DIAMETER entities without being
understood.  (Actually not sure that this = property is relevant or useful in
the MIDCOM case.)

MEGACO: extension mechanism provided, does mean = protocol changes, both ends
have to understand the extensions.

RSIP: no formal extension mechanism; extensions have = to be designed into the

protocol from scratch. 

My proposal to ensure that we capture this aspect of = the evaluation and include some text in the conclusion, following the = controversial table capturing this information, to highlight that this = is key to considering the impact of P+ for a specific protocol. I'll = propose specific text when I get down to editting again early tomorrow. = Folks that participated in this thread are also welcome to craft the = proposed text.

Regards,
Mary.

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

------_=_NextPart_001_01C23E55.6C5F1C70-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 17:06:02 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 RAA09048 for ; Wed, 7 Aug 2002 17:06:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09072 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 17:07: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 RAA09049; Wed, 7 Aug 2002 17:06: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 RAA09021 for ; Wed, 7 Aug 2002 17:06:16 -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 RAA09028 for ; Wed, 7 Aug 2002 17:05:03 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g77L5kr24742 for ; Wed, 7 Aug 2002 17:05:46 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 17:05:46 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A783@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "Sanjoy Sen" , "Mary Barnes" , "'midcom'" Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ( wa s RE: Proposed changes to RSIP evaluation Date: Wed, 7 Aug 2002 17:05:43 -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 Note that I said protocol changes, not base protocol changes. To add a package in Megaco you have to update your parser to start with, and also be prepared to provide the package name in response to audits. I know the work is similar for a MIB, in a way, but in Megaco the package elements are mixed right in with the other elements of the protocol. -----Original Message----- From: Sen, Sanjoy [NGC:B677:EXCH] Sent: Wednesday, August 07, 2002 5:00 PM To: Barnes, Mary [NGC:B602:EXCH]; 'midcom' Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ( wa s RE: Proposed changes to RSIP evaluation Speaking from Megaco perspective, I don't understand why it would be any less extensible than either SNMP or COPS, as packages doesn't need any changes in base protocol. Can somebody educate me on this? -----Original Message----- From: Barnes, Mary [NGC:B602:EXCH] Sent: Wednesday, August 07, 2002 3:51 PM To: 'midcom' Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP evaluation Hi all, Based upon the responses to Jim's email thread on this topic, I think there is general concensus to change 2.2.1 to T for RSIP. In addition, this thread highlighted a key aspect as to the level or readiness of extensibility with the following summary, which I've liberally copied from Tom's email and added COPS: SNMP and COPS (most extensible): extensions require absolutely no change to the protocol itself. DIAMETER: extension mechanism provided, does mean protocol changes, but extensions can be handled by other DIAMETER entities without being understood. (Actually not sure that this property is relevant or useful in the MIDCOM case.) MEGACO: extension mechanism provided, does mean protocol changes, both ends have to understand the extensions. RSIP: no formal extension mechanism; extensions have to be designed into the protocol from scratch. My proposal to ensure that we capture this aspect of the evaluation and include some text in the conclusion, following the controversial table capturing this information, to highlight that this is key to considering the impact of P+ for a specific protocol. I'll propose specific text when I get down to editting again early tomorrow. Folks that participated in this thread are also welcome to craft the proposed text. Regards, Mary. _______________________________________________ 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 Aug 7 17:22: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 RAA09637 for ; Wed, 7 Aug 2002 17:22:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09513 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 17:23: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 RAA09487; Wed, 7 Aug 2002 17:22:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09412 for ; Wed, 7 Aug 2002 17:22:23 -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 RAA09604 for ; Wed, 7 Aug 2002 17:21:09 -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 g77LM7Z23387 for ; Wed, 7 Aug 2002 16:22:07 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 16:21:52 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A6341F@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "Tom-PT Taylor" , "Mary Barnes" , "'midcom'" Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ( wa s RE: Proposed changes to RSIP evaluation Date: Wed, 7 Aug 2002 16:21:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23E58.6F4AC350" 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_01C23E58.6F4AC350 Content-Type: text/plain > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Wednesday, August 07, 2002 4:06 PM > To: Sen, Sanjoy [NGC:B677:EXCH]; Barnes, Mary > [NGC:B602:EXCH]; 'midcom' > Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP > Extensibility - P + -> T ? ( wa s RE: Proposed changes to > RSIP evaluation > > > > Note that I said protocol changes, not base protocol changes. > To add a package in Megaco you have to update your parser to > start with, and also be prepared to provide the package name > in response to audits. I know the work is similar for a MIB, > in a way, but in Megaco the package elements are mixed right > in with the other elements of the protocol. > I thought so too (that the work is similar for MIB or PIB). I wouldn't consider this (mixed with elements of the protocol) sufficient reason to deem Megaco any less extensible than COPS or SNMP. Thanks, Sanjoy > -----Original Message----- > From: Sen, Sanjoy [NGC:B677:EXCH] > Sent: Wednesday, August 07, 2002 5:00 PM > To: Barnes, Mary [NGC:B602:EXCH]; 'midcom' > Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP > Extensibility - P + -> T ? ( wa s RE: Proposed changes to > RSIP evaluation > > > Speaking from Megaco perspective, I don't understand why it > would be any less extensible than either SNMP or COPS, as > packages doesn't need any changes in base protocol. Can > somebody educate me on this? > > -----Original Message----- > From: Barnes, Mary [NGC:B602:EXCH] > Sent: Wednesday, August 07, 2002 3:51 PM > To: 'midcom' > Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP > Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP > evaluation > > > Hi all, > Based upon the responses to Jim's email thread on this topic, > I think there is general concensus to change 2.2.1 to T for RSIP. > In addition, this thread highlighted a key aspect as to the > level or readiness of extensibility with the following > summary, which I've liberally copied from Tom's email and > added COPS: SNMP and COPS (most extensible): extensions > require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol > changes, but extensions can be handled by other DIAMETER > entities without being > understood. (Actually not sure that this property is > relevant or useful in > the MIDCOM case.) > MEGACO: extension mechanism provided, does mean protocol > changes, both ends > have to understand the extensions. > RSIP: no formal extension mechanism; extensions have to be > designed into the > protocol from scratch. > My proposal to ensure that we capture this aspect of the > evaluation and include some text in the conclusion, following > the controversial table capturing this information, to > highlight that this is key to considering the impact of P+ > for a specific protocol. I'll propose specific text when I > get down to editting again early tomorrow. Folks that > participated in this thread are also welcome to craft the > proposed text. Regards, > Mary. > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C23E58.6F4AC350 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - = P + -> T ? ( wa s RE: Proposed changes to RSIP evaluation

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B602:EXCH]
> Sent: Wednesday, August 07, 2002 4:06 PM
> To: Sen, Sanjoy [NGC:B677:EXCH]; Barnes, Mary =
> [NGC:B602:EXCH]; 'midcom'
> Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 = - RSIP
> Extensibility - P + -> T ? ( wa s RE: = Proposed changes to
> RSIP evaluation
>
>
>
> Note that I said protocol changes, not base = protocol changes.
>  To add a package in Megaco you have to = update your parser to
> start with, and also be prepared to provide the = package name
> in response to audits.  I know the work is = similar for a MIB,
> in a way, but in Megaco the package elements = are mixed right
> in with the other elements of the = protocol.
>

I thought so too (that the work is similar for MIB or = PIB).

I wouldn't consider this (mixed with elements of the = protocol)
sufficient reason to deem Megaco any less extensible = than COPS or SNMP.

Thanks,
Sanjoy


> -----Original Message-----
> From: Sen, Sanjoy [NGC:B677:EXCH]
> Sent: Wednesday, August 07, 2002 5:00 PM
> To: Barnes, Mary [NGC:B602:EXCH]; = 'midcom'
> Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 = - RSIP
> Extensibility - P + -> T ? ( wa s RE: = Proposed changes to
> RSIP evaluation
>
>
> Speaking from Megaco perspective, I don't = understand why it
> would be any less extensible than either SNMP = or COPS, as
> packages doesn't need any changes in base = protocol. Can
> somebody educate me on this?
>
> -----Original Message-----
> From: Barnes, Mary [NGC:B602:EXCH]
> Sent: Wednesday, August 07, 2002 3:51 PM =
> To: 'midcom'
> Subject: [midcom] RE: Protocol Eval - 2.2.1 - = RSIP
> Extensibility - P+ -> T ? ( wa s RE: = Proposed changes to RSIP
> evaluation
>
>
> Hi all,
> Based upon the responses to Jim's email thread = on this topic,
> I think there is general concensus to change = 2.2.1 to T for RSIP. 
> In addition, this thread highlighted a key = aspect as to the
> level or readiness of extensibility with the = following
> summary, which I've liberally copied from Tom's = email and
> added COPS: SNMP and COPS (most extensible): = extensions
> require absolutely no change to the
> protocol itself.
>  
> DIAMETER: extension mechanism provided, does = mean protocol
> changes, but extensions can be handled by other = DIAMETER
> entities without being
> understood.  (Actually not sure that this = property is
> relevant or useful in
> the MIDCOM case.)
> MEGACO: extension mechanism provided, does mean = protocol
> changes, both ends
> have to understand the extensions.
> RSIP: no formal extension mechanism; extensions = have to be
> designed into the
> protocol from scratch. 
> My proposal to ensure that we capture this = aspect of the
> evaluation and include some text in the = conclusion, following
> the controversial table capturing this = information, to
> highlight that this is key to considering the = impact of P+
> for a specific protocol. I'll propose specific = text when I
> get down to editting again early tomorrow. = Folks that
> participated in this thread are also welcome to = craft the
> proposed text. Regards,
> Mary.
> _______________________________________________ =
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom =
>

------_=_NextPart_001_01C23E58.6F4AC350-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Wed Aug 7 22:16: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 WAA17516 for ; Wed, 7 Aug 2002 22:16:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22119 for midcom-archive@odin.ietf.org; Wed, 7 Aug 2002 22:17: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 WAA22037; Wed, 7 Aug 2002 22:12:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22006 for ; Wed, 7 Aug 2002 22:12:15 -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 WAA17452 for ; Wed, 7 Aug 2002 22:11: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 g782CIq09986 for ; Wed, 7 Aug 2002 19:12:18 -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 g782CDG05511 for ; Wed, 7 Aug 2002 19:12:13 -0700 (PDT) Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text To: midcom Date: Wed, 7 Aug 2002 21:03:47 -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 Melinda, Ah, now I understand your comment! The extra overhead that you're talking about is due to the communication between the host and the middlebox being carried by a tunnel. That's true whether the tunnel is a traditional, recognized tunnel type such as IPsec or IP-IP, or "NAT implemented as a tunnel" as I discussed in my I-D earlier this year. That overhead appears in the application host, as opposed to the agent host, and is in addition to the MIDCOM control channel overhead (small, as compared to the tunnel overhead), assuming the MIDCOM client is in the application host. Obviously, if the MIDCOM client is in the agent host, then its small overhead is in that host. But if NAT is supported in the application host by its normal "default gateway forwarding model", there is no additional overhead due to the tunnel. The same comments still apply to the MIDCOM control channel: its small overhead is in whichever host the MIDCOM client is. The cost of the tunnel overhead is offset by some benefits. In some cases the benefits can be realized and are greater than the costs, so it makes sense to use tunnels. In other cases the benefits either can't be realized or are not sufficiently greater than the costs to justify the use of tunnels, so ya don'y use tunnels. You didn't really expect to get something nothing, now did you? :-) Jim Melinda Shore on 08/07/2002 07:50:42 AM Sent by: Melinda Shore To: James Renkel/MW/US/3Com cc: midcom Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text > From: James_Renkel@3com.com > As I see it, the situation here is no diffrerent for RSIP than for any > of the other protocols. The difference may be in magnitude rather than in kind, but it's certainly there. With a typical client-server implementation you're selecting based on a file descriptor (socket) that has application state associated with it. With RSIP, as I understand your proposal, you've got the additional overhead of a "virtual" network interface for the borrowed address, which pushes more state into the OS or driver as well as the routing tables. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Aug 8 11:02:50 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 LAA14923 for ; Thu, 8 Aug 2002 11:02:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07523 for midcom-archive@odin.ietf.org; Thu, 8 Aug 2002 11:04:04 -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 LAA07223; Thu, 8 Aug 2002 11:01:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07194 for ; Thu, 8 Aug 2002 11:01:55 -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 LAA14692 for ; Thu, 8 Aug 2002 11:00:40 -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 g78F1cZ27461 for ; Thu, 8 Aug 2002 10:01:38 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 10:01:24 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C851@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom'" Cc: "Sanjoy Sen" , "Tom-PT Taylor" Subject: Issue CLOSED - Propose alternative text for the Summary/Conclusio n ( was RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ... Date: Thu, 8 Aug 2002 10:01:21 -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, This issue is closed in that RSIP will be considered fully compliant for extensibility, along with all the other protocols. If you still have concerns about what we capture in the conclusion, it would be useful if you would propose summary text that reflects your views. I think we can put together text that appropriately captures these considerations. We could have a statement something like: "In considering the P+ category of compliancy, an important aspect is the mechanism for support of extensibility. The extension mechansim provided by SNMP and COPS-PR using MIBs and PIBs respectively, provides extensions with no impact to the protocol. Diameter extensions require protocol changes, thus has a higher impact, although the extensions can be handled by other Diameter entities without being understood. Megaco's extension mechanisms of packages also requires protocol changes that must be understand by both sending and receiving entities, also being considered higher impact. The RSIP extension mechanism has the largest impact on the existing protocol and is based upon defining the necessary new parameters." If you have concerns about what's communicated by this wording, then please suggest explicit alternative wording by COB today, Thursday, August 8th. As I stated in my email on Tuesday, the plans are still to try to complete the changes this week or early next week at the latest, thus allowing us to start WGLC next week and maintain the schedule of getting the draft to the IESG by early September, at the latest. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 Wireless 817-703-4806 -----Original Message----- From: Sen, Sanjoy [NGC:B677:EXCH] Sent: Wednesday, August 07, 2002 4:22 PM To: Taylor, Tom-PT [CAR:B602:EXCH]; Barnes, Mary [NGC:B602:EXCH]; 'midcom' Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP Extensibility - P + -> T ? ( wa s RE: Proposed changes to RSIP evaluation > -----Original Message----- > From: Taylor, Tom-PT [CAR:B602:EXCH] > Sent: Wednesday, August 07, 2002 4:06 PM > To: Sen, Sanjoy [NGC:B677:EXCH]; Barnes, Mary > [NGC:B602:EXCH]; 'midcom' > Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP > Extensibility - P + -> T ? ( wa s RE: Proposed changes to > RSIP evaluation > > > > Note that I said protocol changes, not base protocol changes. > To add a package in Megaco you have to update your parser to > start with, and also be prepared to provide the package name > in response to audits. I know the work is similar for a MIB, > in a way, but in Megaco the package elements are mixed right > in with the other elements of the protocol. > I thought so too (that the work is similar for MIB or PIB). I wouldn't consider this (mixed with elements of the protocol) sufficient reason to deem Megaco any less extensible than COPS or SNMP. Thanks, Sanjoy > -----Original Message----- > From: Sen, Sanjoy [NGC:B677:EXCH] > Sent: Wednesday, August 07, 2002 5:00 PM > To: Barnes, Mary [NGC:B602:EXCH]; 'midcom' > Subject: RE: [midcom] RE: Protocol Eval - 2.2.1 - RSIP > Extensibility - P + -> T ? ( wa s RE: Proposed changes to > RSIP evaluation > > > Speaking from Megaco perspective, I don't understand why it > would be any less extensible than either SNMP or COPS, as > packages doesn't need any changes in base protocol. Can > somebody educate me on this? > > -----Original Message----- > From: Barnes, Mary [NGC:B602:EXCH] > Sent: Wednesday, August 07, 2002 3:51 PM > To: 'midcom' > Subject: [midcom] RE: Protocol Eval - 2.2.1 - RSIP > Extensibility - P+ -> T ? ( wa s RE: Proposed changes to RSIP > evaluation > > > Hi all, > Based upon the responses to Jim's email thread on this topic, > I think there is general concensus to change 2.2.1 to T for RSIP. > In addition, this thread highlighted a key aspect as to the > level or readiness of extensibility with the following > summary, which I've liberally copied from Tom's email and > added COPS: SNMP and COPS (most extensible): extensions > require absolutely no change to the > protocol itself. > > DIAMETER: extension mechanism provided, does mean protocol > changes, but extensions can be handled by other DIAMETER > entities without being > understood. (Actually not sure that this property is > relevant or useful in > the MIDCOM case.) > MEGACO: extension mechanism provided, does mean protocol > changes, both ends > have to understand the extensions. > RSIP: no formal extension mechanism; extensions have to be > designed into the > protocol from scratch. > My proposal to ensure that we capture this aspect of the > evaluation and include some text in the conclusion, following > the controversial table capturing this information, to > highlight that this is key to considering the impact of P+ > for a specific protocol. I'll propose specific text when I > get down to editting again early tomorrow. Folks that > participated in this thread are also welcome to craft the > proposed text. Regards, > Mary. > _______________________________________________ > 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 Aug 8 17:34: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 RAA27663 for ; Thu, 8 Aug 2002 17:34:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02577 for midcom-archive@odin.ietf.org; Thu, 8 Aug 2002 17:35:29 -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 RAA02516; Thu, 8 Aug 2002 17:32: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 RAA02481 for ; Thu, 8 Aug 2002 17:32:37 -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 RAA27590 for ; Thu, 8 Aug 2002 17:31:21 -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 g78LWEZ11979 for ; Thu, 8 Aug 2002 16:32:14 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 16:31:00 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C85A@zrc2c000.us.nortel.com> From: "Mary Barnes" To: midcom Date: Thu, 8 Aug 2002 16:30:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] Protocol Eval: 2.1.3: RSIP - Editorial correction - T -> P 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 have found an inconsistency that needs to be corrected. There was not agreement to Jim's proposed change for 2.1.2 (from P -> T), however, the description for 2.1.3 for RSIP points back to 2.1.2, yet 2.1.3 currently shows up as a T. I've backtracked and it seems that there was an editorial lapse in the -01 version as 2.1.3 should have also been changed to a P based upon WG discussion in the thread that also centered around 2.1.2. So, I'll be correcting that. Again, since there was not agreement on new text for 2.1.2, I think the existing text remains sufficient for 2.1.2 and 2.1.3 and I'm only making a minor modification by deleting some superfluous text (the "thus" clause in the 3rd sentence). Mary. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 9 13:29: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 NAA04372 for ; Fri, 9 Aug 2002 13:29:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09935 for midcom-archive@odin.ietf.org; Fri, 9 Aug 2002 13:30: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 NAA08992; Fri, 9 Aug 2002 13:05: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 NAA08965 for ; Fri, 9 Aug 2002 13:05:51 -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 NAA03422 for ; Fri, 9 Aug 2002 13:04:35 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79H5JM16674 for ; Fri, 9 Aug 2002 13:05:19 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 13:05:19 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387CED@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: "Mary Barnes" , midcom Date: Fri, 9 Aug 2002 13:05:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FC6.EFF594DE" Subject: [midcom] Protocol Eval 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_01C23FC6.EFF594DE Content-Type: text/plain; charset="iso-8859-1" Mary, All, I've been through the comparison draft (a bit late, sorry) and I feel there is an inconsistency with regards to the COPS evaluation in requirement 2.1.1. Currently, it is put as a F. But I believe a P would be much more appropriate. I re-read the definitions provided for F, P, P+, T and according to the definitions it is clear that P is exactly the case for COPS in 2.1.1. If you read the text for COPS in 2.1.1, it is said that only part of the requirement is not met (the directionality) but nothing prevents us from going around this problem by defining local policies at the PEP. Yes, this would be inconsistent with the COPS framework, but that is exactly what the definition of P is. I believe the same comment applies to Megaco. The draft, as it stand, would be inconsistent since other protocols were graded in-line with the F/P/T/P+ definitions, while COPS and megaco (in 2.1.1) are clearly not. Cheers, L-N ------_=_NextPart_001_01C23FC6.EFF594DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protocol Eval

Mary, All,

I've been through the comparison draft (a bit late, = sorry) and I feel there is an inconsistency
with regards to the COPS evaluation in requirement = 2.1.1.
Currently, it is put as a F. But I believe a P would = be much more appropriate. I re-read the definitions
provided for F, P, P+, T and according to the = definitions it is clear that P is exactly the case for COPS in = 2.1.1.
If you read the text for COPS in 2.1.1, it is said = that only part of the requirement is not met (the = directionality)
but nothing prevents us from going around this = problem by defining local policies at the PEP. Yes, this would = be
inconsistent with the COPS framework, but that is = exactly what the definition of P is.

I believe the same comment applies to Megaco.

The draft, as it stand, would be inconsistent since = other protocols were graded in-line with the F/P/T/P+ = definitions,
while COPS and megaco (in 2.1.1) are clearly = not.

Cheers,
L-N

------_=_NextPart_001_01C23FC6.EFF594DE-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 9 14:02:04 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 OAA05381 for ; Fri, 9 Aug 2002 14:02:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12184 for midcom-archive@odin.ietf.org; Fri, 9 Aug 2002 14:03: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 NAA11012; Fri, 9 Aug 2002 13:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10983 for ; Fri, 9 Aug 2002 13:51:30 -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 NAA05066 for ; Fri, 9 Aug 2002 13:50:14 -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 g79HpD621722 for ; Fri, 9 Aug 2002 12:51:13 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 12:50:58 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C866@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "Louis-Nicolas Hamer" , "'midcom'" Date: Fri, 9 Aug 2002 12:50:55 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Protocol Eval: 2.1.1 - COPS and Megaco: F -> P ? 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 Louis-N, I do agree that this is an inconsistency remaining from when we defined the new category. I don't see an issue with changing both COPS and Megaco to P for 2.1.1. This would require no change to the text for either for 2.1.1. Although, the conclusion will need to be updated; I'll post the proposed text for that shortly. Since we would like this version of the document, that I'm in the midst of completing edits on, to be ready for WGLC, I would like to propose that we make this change. However, as with the RSIP decisions that were made after the original Aug 2nd cutoff, some of which were also this category (i.e. hadn't been revisited since the new category was defined), I'd like to give the WG time to provide any negative feedback on this proposal. Since it's after "normal" working hours for many time zones right now, I'll wait until Monday morning to submit the updated document; that should still keep us on schedule. Any concerns with this proposal should be posted to the mailing list by 9am CST on Monday, August 12th. Regards, Mary. -----Original Message----- From: Hamer, Louis-Nicolas [WDLN2:AN22:EXCH] Sent: Friday, August 09, 2002 12:05 PM To: Barnes, Mary [NGC:B602:EXCH]; midcom Subject: Protocol Eval Mary, All, I've been through the comparison draft (a bit late, sorry) and I feel there is an inconsistency with regards to the COPS evaluation in requirement 2.1.1. Currently, it is put as a F. But I believe a P would be much more appropriate. I re-read the definitions provided for F, P, P+, T and according to the definitions it is clear that P is exactly the case for COPS in 2.1.1. If you read the text for COPS in 2.1.1, it is said that only part of the requirement is not met (the directionality) but nothing prevents us from going around this problem by defining local policies at the PEP. Yes, this would be inconsistent with the COPS framework, but that is exactly what the definition of P is. I believe the same comment applies to Megaco. The draft, as it stand, would be inconsistent since other protocols were graded in-line with the F/P/T/P+ definitions, while COPS and megaco (in 2.1.1) are clearly not. Cheers, L-N _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Fri Aug 9 14:49:23 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 OAA06998 for ; Fri, 9 Aug 2002 14:49:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14831 for midcom-archive@odin.ietf.org; Fri, 9 Aug 2002 14:50:37 -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 OAA14756; Fri, 9 Aug 2002 14:47: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 OAA14727 for ; Fri, 9 Aug 2002 14:47:37 -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 OAA06952 for ; Fri, 9 Aug 2002 14:46:19 -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 g79IlH604993 for ; Fri, 9 Aug 2002 13:47:17 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 13:47:02 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7C868@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'midcom'" Date: Fri, 9 Aug 2002 13:47:01 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [midcom] RE: Protocol Eval: New Conclusion text 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, Per the email wrt 2.1.1 for COPS and Megaco, the following is my new proposed text for the Conclusion. I've gone ahead and shown the entirety of the new conclusion for continuity: The overall statistics with regards to the number of Fully Compliant, Partially Compliant (P+ and P) and Failing Compliancy requirements for each of the protocols is summarized in table 1. T P+ P F ----------------------------------------------------------------- SNMP 19 8 0 0 RSIP 17 7 3 0 Megaco 19 5 3 0 Diameter 21 5 1 0 COPS 20 5 2 0 Table 1: Totals across all Requirements In considering the P+ category of compliancy, an important aspect is the mechanism for support of extensibility. The extension mechanism provided by SNMP and COPS-PR using MIBs and PIBs respectively, provides extensions with no impact to the protocol. Diameter extensions require protocol changes, thus has a higher impact, although the extensions can be handled by other Diameter entities without being understood. Megaco's extension mechanisms of packages also requires protocol changes that must be understand by both sending and receiving entities, also being considered higher impact. The RSIP extension mechanism has the largest impact on the existing protocol and is based upon defining the necessary new parameters. The SNMP management framework meets all the specified MIDCOM protocol requirements with the appropriate design of a MIDCOM MIB module. SNMP is a proven technology with stable and proven development tools, which already provides support for NAT configuration. For matching the security requirements and for the support of requirement 2.1.7, only the most recent version, SNMPv3, is suited. Although, SNMPv3 is not as proven of a technology as SNMPv1 and SNMPv2, the protocol specifications are more mature and have undergone more validation than the other protocols in the evaluation. The applicability of SNMP to the MIDCOM framework has a restriction in that it assumes the MIDCOM PDP is part of the Middlebox. RSIP fully meets many of the MIDCOM requirements. In addition, RSIP requires additions/extensions to meet several of the requirements. RSIP would also require several framework elements to be added to the MIDCOM framework as identified in section 1.2.3. Megaco fully meets most of the key requirements for the MIDCOM Protocol. Additional extensions in the form of new Termination / Package definition (without impacting the base protocol) would be required for MIDCOM to meet several of the requirements. In order to meet the remaining requirements, modeling the underlying Middlebox resources (e.g., filters, policy rules) as separate elements from the Megaco entities might allow the usage of the protocol as-is, satisfying some of the resource access control requirements. The Diameter evaluation indicated a good overall fit with no requirements failing to be met. Some partially met requirements were identified that could be addressed by a new application extension. However, the Diameter architecture may be too heavy for the MIDCOM application and clearly much of the Diameter base is not needed. In addition, Diameter is the only protocol in the evaluation for which the RFCs are not yet published. Other than these reservations, the protocol is a good fit to MIDCOM requirements. The COPS evaluation indicates that the protocol meets the majority of the MIDCOM protocol requirements by using the protocol's native extension techniques, with COPS-PR being explicitly required to meet requirements 2.1.3 and 2.2.3. In order to fully satisfy the one partially met requirement, 2.1.1, the COPS model would need to allow a PDP to establish communication with a PEP. While this is not explicitly prohibited by the COPS model, it would require additions, in the form of local policy, to ensure the proper establishment of an authorized association. ----------------------------------------------- Any concerns with this proposal should be posted to the mailing list by 9am CST on Monday, August 12th. Regards, Mary. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 12 09:59:56 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 JAA22523 for ; Mon, 12 Aug 2002 09:59:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12796 for midcom-archive@odin.ietf.org; Mon, 12 Aug 2002 10:01: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 JAA12343; Mon, 12 Aug 2002 09:59: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 JAA12313 for ; Mon, 12 Aug 2002 09:59:06 -0400 (EDT) Received: from smtp01.go2call.com ([216.52.157.170]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22464 for ; Mon, 12 Aug 2002 09:57:49 -0400 (EDT) Received: from IBMT21 (go2call-107.go2call.com [216.52.157.107]) by smtp01.go2call.com (8.11.6/8.11.6) with SMTP id g7CDwT115828 for ; Mon, 12 Aug 2002 08:58:29 -0500 From: "Ajay K Garg" To: "Midcom" Date: Mon, 12 Aug 2002 08:58:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [midcom] Contribution 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 All, Our company has a way similar to used in MIDCOM protocol. I would like to get more information where we can get some working product information for MIDCOM. Thanks -Ajay _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 13 04:03:36 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 EAA04292 for ; Tue, 13 Aug 2002 04:03:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21509 for midcom-archive@odin.ietf.org; Tue, 13 Aug 2002 04:04:53 -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 EAA21446; Tue, 13 Aug 2002 04:02:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21417 for ; Tue, 13 Aug 2002 04:02:10 -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 EAA04251 for ; Tue, 13 Aug 2002 04:00:47 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7D81VU93507; Tue, 13 Aug 2002 10:01:31 +0200 (CEST) (envelope-from Martin.Stiemerling@ccrle.nec.de) 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 30C8D2D6E8; Tue, 13 Aug 2002 10:01:29 +0200 (CEST) Message-ID: <3D58BD5F.3060500@ccrle.nec.de> Date: Tue, 13 Aug 2002 10:03:43 +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: Ajay K Garg Cc: Midcom Subject: Re: [midcom] Contribution References: 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 Ajay K Garg wrote: > Hi All, > Our company has a way similar to used in MIDCOM protocol. I would like to > get more information where we can get some working product information for > MIDCOM. There is actually no MIDCOM protocol at this point of time and so there can't be a product implementation of the MIDCOM protocol. If you look at the past threads on this list, you will see that the protocol, and related things, are under discussion. Nevertheless it may be that several vendors have their own protocol cast into a middlebox control product. Ask them, please. Martin > > Thanks > -Ajay > > > _______________________________________________ > 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 Tue Aug 13 07:29:29 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 HAA07928 for ; Tue, 13 Aug 2002 07:29:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01555 for midcom-archive@odin.ietf.org; Tue, 13 Aug 2002 07:30: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 HAA01049; Tue, 13 Aug 2002 07:29: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 HAA01019 for ; Tue, 13 Aug 2002 07:29:22 -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 HAA07760; Tue, 13 Aug 2002 07:28:03 -0400 (EDT) Message-Id: <200208131128.HAA07760@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, 13 Aug 2002 07:28:03 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-protocol-eval-03.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 : Middlebox Communications (MIDCOM) Protocol Evaluation Author(s) : M. Barnes Filename : draft-ietf-midcom-protocol-eval-03.txt Pages : 34 Date : 12-Aug-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-03.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-03.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-03.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: <20020812145954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-protocol-eval-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-protocol-eval-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020812145954.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Tue Aug 13 09:24:36 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 JAA11093 for ; Tue, 13 Aug 2002 09:24:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07023 for midcom-archive@odin.ietf.org; Tue, 13 Aug 2002 09:25: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 JAA06844; Tue, 13 Aug 2002 09:24:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06811 for ; Tue, 13 Aug 2002 09:24: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 JAA11031 for ; Tue, 13 Aug 2002 09:22:51 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7DDNXU17788; Tue, 13 Aug 2002 15:23:33 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D01795A813; Tue, 13 Aug 2002 15:23:31 +0200 (CEST) Date: Tue, 13 Aug 2002 15:23:31 +0200 From: Juergen Quittek To: Martin Stiemerling , Ajay K Garg Cc: Midcom Subject: Re: [midcom] Contribution Message-ID: <22082112.1029252211@[192.168.102.164]> In-Reply-To: <3D58BD5F.3060500@ccrle.nec.de> References: <3D58BD5F.3060500@ccrle.nec.de> 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 Ajay, --On 13 August 2002 10:03 +0200 Martin Stiemerling wrote: > Ajay K Garg wrote: >> Hi All, >> Our company has a way similar to used in MIDCOM protocol. It certainly would be helpful for this WG if you could show what you already have in your company. Juergen >> I would like to get more information where we can get some working product >> information for MIDCOM. > > There is actually no MIDCOM protocol at this point of time and so there can't be a product implementation of the MIDCOM protocol. If you look at the past threads on this list, you will see that the protocol, and related things, are under discussion. > Nevertheless it may be that several vendors have their own protocol cast into a middlebox control product. Ask them, please. > > Martin > >> >> Thanks >> -Ajay >> >> >> _______________________________________________ >> 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 Wed Aug 14 11:37:25 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 LAA13790 for ; Wed, 14 Aug 2002 11:37:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06817 for midcom-archive@odin.ietf.org; Wed, 14 Aug 2002 11:38:46 -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 LAA06675; Wed, 14 Aug 2002 11:37: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 LAA06621 for ; Wed, 14 Aug 2002 11:36:58 -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 LAA13754 for ; Wed, 14 Aug 2002 11:35:36 -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 g7EFZcAK022984 for ; Wed, 14 Aug 2002 08:35:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEU38952; Wed, 14 Aug 2002 08:31:36 -0700 (PDT) Message-Id: <200208141531.AEU38952@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 14 Aug 2002 11:33:19 -0400 Subject: [midcom] WG last call, midcom protocol evaluation document 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 to announce the start of working group last call on the midcom protocol evaluation draft (available at http://www.ietf.org/internet-drafts/draft-ietf-midcom-protocol-eval-03.txt). Last call will close on Thursday, August 29 at 5pm EDT. Please send comments to the midcom mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Thu Aug 15 12:16:00 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 MAA03137 for ; Thu, 15 Aug 2002 12:16:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12655 for midcom-archive@odin.ietf.org; Thu, 15 Aug 2002 12:17: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 MAA12562; Thu, 15 Aug 2002 12:15: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 MAA12531 for ; Thu, 15 Aug 2002 12:15:37 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03105 for ; Thu, 15 Aug 2002 12:14:16 -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 g7FGF66I005716 for ; Thu, 15 Aug 2002 09:15:06 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEU73809; Thu, 15 Aug 2002 09:11:05 -0700 (PDT) Message-Id: <200208151611.AEU73809@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 15 Aug 2002 12:12:47 -0400 Subject: [midcom] IETF 54 meeting minutes 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 Minutes of midcom working group at 54th IETF Meeting, Yokohama, Japan Chaired by Melinda Shore (mshore@cisco.com Reported by Spencer Dawkins (sdawkins@cynetanetworks.com), edited by Melinda Shore Status update: * Framework and requirements documents are still in RFC editor's queue * STUN is in last call - please look at it, so we don't have another showstopper. * SPAN design team is stalled with a serious security issue, and the design team may be shut down. We are late with SPAN and very late with STUN. * Two semantics documents need to be reduced to one. MIDCOM Protocol Evaluation: Issues and Plans (Mary Barnes) Five protocols have been evaluated (SNMP, RSIP, MEGACO, DIAMETER, COPS) since last meeting. Evaluation document has been cycled three times since last meeting. COPS-PR (as opposed to COPS) is required to meet two requirements. There is a glaring mismatch between MIDCOM framework and COPS model. MEGACO has a similar problem with implied directionality. With SNMP, SNMPv3 is required to meet security requirements. There are still opportunities to improve the document (read: "glaring errors") - review it on the plane on the way home, OK? We're about two weeks late, on the current forecast (to IESG in September). MIDCOM Semantics (Tom Taylor) We currently have two semantics drafts as candidates for working group document. The two documents differ primarily because one makes simplifying assumptions. Takeover -- is having one agent operate on rules established by another agent really required? What granularity is required? Should there be a formal handoff procedure? Melinda pointed out that there is no requirement for a handoff procedure in the requirements document. The group agreed that there is a need to allow one agent to operate on rules established by another agent. Granularity could be per user (identity) as well as per rule or per session. We need a handle in order to do handoff. We had quasi-consensus a year ago on takeover a year ago, based on the idea that ACLs would be used as required. Is a deterministic outcome required? Perhaps only in the eyes of the administrator (agents can't know this). Rules survive to the end of their lifetime. Is there a requirement to move rules from one group to another? Christian pointed out that when you create a rule, you place an arbitrary identifier on it, and the group is the collection of rules with the same identifier. Is a group timeout required? There was agreement that it is not. Would you ever map an odd port to an even one, or vice versa? The decision was that there is no need. Is DENY actually needed? There was consensus with some dissent that DENY is not needed. A DENY would be needed if midcom were to be used to support device configuration or if it were to be used for intrusion detection/response. It was strongly felt that it would unnecessarily complicate rule processing and that it isn't needed for normal midcom operation, and so the decision was not to include a DENY rule. Is AND required for multiple filters? The group agreed that we don't need multiple filter conditions. What query capabilities are required? Audit for takeover? Wildcarded query filters? Scope issues? Martin said if you have a point-to-point protocol, you can get the status of your rule, but this doesn't work if we have handoff. Cedric replied that this is already handled in the proposal. Martin asked but if we have hundreds of rules, is that what we want returned? Tom asked that if we want this, we need to specify it in the concrete protocol we select. Wildcards and Ranges -- is there any need to support address ranges, port ranges, open-ended pinholes? Jim's RSIP experience says 'yes' to all three questions. Elliot Lear asked whether the document specify wildcards? Melinda thinks this is implicit in the requirements. Elliot said we get into trouble with wildcards and DENYs -- if we have one, we shouldn't have the other. Grace Period and Pre-Notification. This matches DIAMETER's capability. Jim said that RSIP has problems without this. The issue is with agent restarts and recovery, when rules time out during recovery. Atomicity -- are multiple rules applied as a transaction required, to avoid deadlock, etc.? Is there a need to enforce bi-directional mappings? Melinda said that we decided this is a sequence. What about applications like VoIP where we need to be stateful? Tom said this is an application issue, not a middlebox issue, as he recalls the framework document. Jonathan asked what to do if the sender is also NATted and you can't hear them suddenly. Jim said that they've seen this issue in tneir operational experience with RSIP as well. If your rules are too selective, you're swamped trying to keep up with rule changes. One of their customers has an application where there are several servers outside the middlebox, and they're bouncing the call from inside the middlebox around. They really need an 'accept from anybody' to have a prayer of keeping up. said that these need to be separate sessions that need to be grouped together -- that simplifies things. Reconvening after the break, Jiri asked if we really insist on reusing an IETF protocol? Melinda replied that we have a clear mandate from IESG to do so, unless we can prove that no existing protocol works. If you feel strongly, please talk to the ADs. STUN Update (Jonathan Rosenberg) There's a -01 revision that went in just before the cut-off, reflecting comments from WG last call on security. We're not using CMS any more. We need integrity of requests to deal with security problems, and CMS won't help with that. It also won't work with Secur-ID and Kerberos. The new solution is to use server-side authentication in TLS, plus a one-time password, used for HMAC SHA-1 protection of STUN requests. This still doesn't solve the security problem described during working group last call which allows an attacker to launch a denial-of-service attach and spoof the source address, which isn't covered by HMAC because of NATs. There is no way in the known universe to resolve this in a NAT world, and it affects any NAT-friendly protocol that's supposed to be secure. We're hoping that the scope of this problem is limited. The attacker has to be on the path from server to the target. Basically you can DoS on the same LAN, and hijack a 100-megabit stream that the target should be receiving. There's another attack, to receive all packets, that also works. Christian said the only way to solve this problem is by using end-to-end encryption. Jonathan answered that there are heuristics to detect this attack, but not reliably. Eric Rescorla said that we're already vulnerable to people on the same LAN anyway. Christian replied if you are actually receiving the packets, you can just drop them. If you're just a listener, the target still gets them. Eric said that cryptographic signing doesn't protect the important piece of information and asked about removing the HMAC and use a random challenge? Jonathan answered that if you remove the HMAC it's even easier to carry out the attack with a greater scope of exposure. The HMAC-capable attack is a hard timing problem. Christian proposed no security, because security wasn't helping anyway. Security considerations section is much thicker now -- support for TLS is mandated, but Kerberos or SecurID can be used instead. The only open issue is whether this security mechanism is worthwhile. Jiri asked about symmetric NATs. Jonathan said that he ran STUN through the NAT at my house. Christian said symmetric NATs are a relatively small subset of the market. Cullen said that he's seen about 30 versions of NATs, including S/W release numbers. Melinda said that we have one week left in last call and asked for comments ASAP. SPAN Update (Melinda Shore) SPAN works across symmetric NATs and complements STUN. It provides an external Relay with TCP listeners and support for UDP. The focus is on simplicity. The design team missed May 02 milestone and is failing to make progress. We also have a security problem with accepting incoming connection requests that may violate firewall policy. We are enabling listeners behind a firewall -- not just allowing hosts inside the firewall to make outgoing connections, but also allowing them to provide services to people outside the firewall. Jonathan said that STUN is more restrictive than TURN. Christian answered that STUN allows you to receive UDP packets from people you've sent packets to -- and this is still OK. SPAN enables a random sender outside the firewall. Cullen asked if people see the need to allow TCP relays? The answer was yes. He then asked how critical it is to keep from increasing bandwidth utilization. Jonathan asked if we aren't looking at tunnelling UDP over TCP, are we? Dave Oran said as long as the client knows this is happening, the client can adjust. And this should be compressible under existing ROHC schemes, if not, this is a problem. We can add keep-alive traffic -- we might want to consider this. Steve Bellovin is not thrilled with the concept of allowing TCP connections between firewalls. Firewalls are there for a reason, don't subvert them just because we can do so technically. Wrap Up Please look at STUN during last call, and the protocol evaluation document before last call. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 19 20:24: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 UAA18788 for ; Mon, 19 Aug 2002 20:24:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22843 for midcom-archive@odin.ietf.org; Mon, 19 Aug 2002 20:26:08 -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 UAA22627; Mon, 19 Aug 2002 20:15:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21417 for ; Mon, 19 Aug 2002 19:49:21 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18210; Mon, 19 Aug 2002 19:47:56 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g7JNnJd21006; Mon, 19 Aug 2002 16:49:19 -0700 (PDT) Message-Id: <200208192349.g7JNnJd21006@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, midcom@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 19 Aug 2002 16:49:18 -0700 Subject: [midcom] RFC 3303 on Middlebox communication architecture and framework 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 Request for Comments is now available in online RFC libraries. RFC 3303 Title: Middlebox communication architecture and framework Author(s): P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan Status: Informational Date: August 2002 Mailbox: srisuresh@yahoo.com, kuthan@fokus.fhg.de, jdrosen@dynamicsoft.com, amolitor@visi.com, rayhan@ee.ryerson.ca Pages: 34 Characters: 91209 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-midcom-framework-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3303.txt A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group. There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP and H.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic. This document is a product of the Middlebox Communication Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020819164742.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3303 --OtherAccess Content-Type: Message/External-body; name="rfc3303.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020819164742.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From daemon@optimus.ietf.org Mon Aug 19 21:23: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 UAA18789 for ; Mon, 19 Aug 2002 20:24:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22845 for midcom-archive@odin.ietf.org; Mon, 19 Aug 2002 20:26:08 -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 UAA22624; Mon, 19 Aug 2002 20:15:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21488 for ; Mon, 19 Aug 2002 19:51:16 -0400 (EDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18269; Mon, 19 Aug 2002 19:49:52 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g7JNpEd21324; Mon, 19 Aug 2002 16:51:14 -0700 (PDT) Message-Id: <200208192351.g7JNpEd21324@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, midcom@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 19 Aug 2002 16:51:14 -0700 Subject: [midcom] RFC 3304 on Middlebox Communications (midcom) Protocol Requirements 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 Request for Comments is now available in online RFC libraries. RFC 3304 Title: Middlebox Communications (midcom) Protocol Requirements Author(s): R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore Status: Informational Date: August 2002 Mailbox: richard.swale@bt.com, paul.sijben@picopoint.com, philip.mart@marconi.com, sbrim@cisco.com, mshore@cisco.com Pages: 9 Characters: 16187 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-midcom-requirements-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3304.txt This document specifies the requirements that the Middlebox Communication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function. These requirements were developed with a specific focus on network address translation and firewall middleboxes. This document is a product of the Middlebox Communication Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020819164951.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3304 --OtherAccess Content-Type: Message/External-body; name="rfc3304.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020819164951.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 22 05:23:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19495 for ; Thu, 22 Aug 2002 05:23:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M9OOo14422 for midcom-archive@odin.ietf.org; Thu, 22 Aug 2002 05:24:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9MeW13945; Thu, 22 Aug 2002 05:22:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9LBW13916 for ; Thu, 22 Aug 2002 05:21:11 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19372 for ; Thu, 22 Aug 2002 05:19:45 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7M9KfYH007445; Thu, 22 Aug 2002 05:20:41 -0400 (EDT) Message-ID: <3D64ACE7.7020508@dynamicsoft.com> Date: Thu, 22 Aug 2002 05:20:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Midcom Subject: Re: [midcom] STUN update time proposals References: 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [resending as I think this was lost due to ietf.org mail outage] Sorry for the delayed response. "real work" swamped me for a couple weeks. Trying to get my head back above water now. inline. Cullen Jennings wrote: > I was not thinking of the NAT modifying the STUN message. The option > would > be protected by the signature in the STUN response so it would fail if > the > NAT modified it. > > I was imagining a scenario more along the following lines. A large cable > ISP > has a large NAT that NATs all of it's customers. It also is very nice > and > runs a SMTP server and STUN server for all of it's (and only it's) > customers. Additionally, each customer might run a second NAT at their > home > so they can connect multiple computers for the price of one. The ISP > knows > that their large NAT keeps binding up for 5 minutes. They configure this > into their STUN server. This stun server is guaranteed by ACL to only > accept > responses from customers of the ISP that are behind this NAT. > > This helps the client short circuit the times that they need to search > because they can start at 5 minutes and binary divide from there. The > client > can't just blindly use 5 minutes because it has no idea what the NAT in > the > home is and might be less than this. It sounds like what you are suggesting is that the stun server could provide a hint to the client about what it thinks the nat binding lifetime might be. I still have concerns with this. Generally speaking, the model with STUN is that STUN servers are decoupled from the NATs; they don't know where they are, what they are, or what their configuration is. If you want to change this model, it really leads to a different protocol and set of features. After all, why stop at binding lifetimes? Why not "hint" to the client about the type of nat as well? As a scope thing, I'd rather stick with the current model where they are totally decoupled. Related to this, the hints don't help that much since they are just hints. They could easily be wrong, due to inconsistent configuration between the stun server and nat. Also, the stun server can't know for certain that the clients contacting it are coming through the NATs it knows about. Correctness of the hint is therefore strongly coupled with network topology. It seems like it will be very error prone. In any case, there can always be other nats, so it can never be anything more than a starting point in a binary search, not even really a hint about what the overall binding lifetime is amongst all NATs. Thus, the value in the information is actually low, and given the possibility of it being error prone, I am inclined not to include it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 22 05:23:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19513 for ; Thu, 22 Aug 2002 05:23:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M9OSW14434 for midcom-archive@odin.ietf.org; Thu, 22 Aug 2002 05:24:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9N1W13981; Thu, 22 Aug 2002 05:23:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9MUW13939 for ; Thu, 22 Aug 2002 05:22:30 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19396 for ; Thu, 22 Aug 2002 05:21:04 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7M9LWYH007451; Thu, 22 Aug 2002 05:21:33 -0400 (EDT) Message-ID: <3D64AD1B.1000204@dynamicsoft.com> Date: Thu, 22 Aug 2002 05:21:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: midcom@ietf.org, mshore@cisco.com Subject: Re: [midcom] Last call reminder References: <006201c232e9$680dd160$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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [resending as I think this was lost due to ietf.org mail outage] I thought I had responded to this a month back, but searching through the archives found nothing. Turns out I had half responded, and left the unsent mail in my drafts folder. Sorry about that.... Thanks for your comments. Responses inline. Pete Cordell wrote: > Here's some editorial errors I found when skimming through STUN. (I'm > afraid I didn't give it a thorough read.) > > 8.1 (Clarity): If the STUN Shared Secret > Request was used, the key MUST be the {one placed}->{TARGET-OTP} > in a Shared Secret > Response to a Shared Secret Request that had a TARGET-TID equal to > the transaction identifier in the Binding Request. > > It would be nice to re-word this paragraph, but I've tried and it's > difficult! Best I could do is below, but its not much of an > improvement. > > If the STUN Shared Secret > Request was used, the key MUST be the TARGET-OTP from the Shared > Secret response corresponding to a > to a Shared Secret Request containing a TARGET-TID equal to > the transaction identifier of the Binding Request. A bit better. I'll use that. > > 8.2 (Typo): SHOULD {prevent} -> {present} a site certificate ? Fixed. > > 8.2 (Functional): 'The server MUST always return the same TARGET-OTP for > two > requests with the same TARGET-TID.' > > This sounds like a way that an attacker can learn the TARGET-OTP > corresponding to a TARGET-TID. This could be useful in an attack. > Also, stated as is, it does not allow the server to change the key > generation > mechanism (say a master secret) from one month to the next. As we concluded on the list, the server now supplies a username and a target OTP. Thus, this issue is moot. > > > 11.2.6 (Typo): TARGET-TID: Re: 'This MUST be equal to the transaction ID > that will > be used in Binding Requests that contain the shared secret learned > from > the > exchange.' This doesn't seem right. Maybe it should be: > > This MUST be > equal to the transaction ID that will be used in Binding Requests > that {contain}->{are authenticated by} the shared secret learned from > the > exchange. This too is moot with the username parameter. > > > > (General (Clarity): Still think CHANGED-ADDRESS should be CHANGE-ADDRESS > to > ties in more closely with the text 'The fourth attribute is the > CHANGE(D)-ADDRESS attribute. It is present in Binding Responses. It > informs > the client of the source IP address and port that would be used if the > client requested the "change IP" and "change port" behavior.'. I think its fine, since CHANGED-ADDRESS is a noun, where as CHANGE-ADDRESS is a verb. Since we are talking about an address, which is a noun, the current wording seems fine to me. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 22 05:26:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19552 for ; Thu, 22 Aug 2002 05:26:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M9Raq14510 for midcom-archive@odin.ietf.org; Thu, 22 Aug 2002 05:27:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9MmW13960; Thu, 22 Aug 2002 05:22:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9LZW13921 for ; Thu, 22 Aug 2002 05:21:35 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19378 for ; Thu, 22 Aug 2002 05:20:09 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7M9L5YH007448; Thu, 22 Aug 2002 05:21:05 -0400 (EDT) Message-ID: <3D64ACFF.1000807@dynamicsoft.com> Date: Thu, 22 Aug 2002 05:21:03 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield CC: midcom@ietf.org References: <004101c2336c$6b06af80$2300000a@BOBP> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] Re: A few STUN nits Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [resending as I think this was lost due to ietf.org mail outage] Bob Penfield wrote: > In section 8.1, 3rd paragraph, the last sentence says > > "The Binding Error Response is sent to > the source IP address and port the Binding Request came from, and > sent from the source IP address and port the Binding Request was sent > to." > > This sentence is a bit confusing. Should the second "source IP address" > be > "destination" address. Or should the word "source" be dropped in both > places. I think dropping "source" from both places helps clarify. This sentence is just trying to describe the standard symmetric behavior for sending a response packet. > > In section 10.3, 4th paragraph (1st on page 22), it says > > "This request contains a RESPONSE-ADDRESS, which is set to that > mapped > address learned from the previous Binding Response." > > Should "set to that" be "set to the"? Yes. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 22 05:30:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19591 for ; Thu, 22 Aug 2002 05:30:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7M9VIo15176 for midcom-archive@odin.ietf.org; Thu, 22 Aug 2002 05:31:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9T5W14574; Thu, 22 Aug 2002 05:29:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by optimus.ietf.org (8.11.6/8.11.6) with ESMTP id g7M9SGW14543 for ; Thu, 22 Aug 2002 05:28:16 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19568 for ; Thu, 22 Aug 2002 05:26:51 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7M9RlYH007455 for ; Thu, 22 Aug 2002 05:27:47 -0400 (EDT) Message-ID: <3D64AE92.3040008@dynamicsoft.com> Date: Thu, 22 Aug 2002 05:27:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: midcom@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [midcom] update to STUN Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I just posted an update to STUN based on comments received during WGLC. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-midcom-stun-02.txt The changes since -01 include: * removed TARGET-TID * added USERNAME and PASSWORD attributes, which are now handed out by the server in shared secret responses. The username is also placed in binding requests. Specified a minimum lifetime of 10m, maximum of 30m, for these, along with crypto requirements for them. * removed shared secret error response since it was actually never used anywhere * removed the length field from the reason phrase in the ERROR-CODE attribute since its redundant; the length is available from the attribute TLV structure. * updated references; rfc3261 and rfc3303 * spell check * added bit labels to the bitfield figures * nits and typos and minor clarifications based on list comments I believe this is now ready to go off to iesg. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 22 12:29:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01686 for ; Thu, 22 Aug 2002 12:29:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7MGUBW02554 for midcom-archive@odin.ietf.org; Thu, 22 Aug 2002 12:30:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MGPIo01986; Thu, 22 Aug 2002 12:25:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7MGO1o01950 for ; Thu, 22 Aug 2002 12:24:01 -0400 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01482 for ; Thu, 22 Aug 2002 12:22:31 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 22 Aug 2002 09:23:26 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Aug 2002 09:23:26 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 22 Aug 2002 09:23:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 22 Aug 2002 09:23:26 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Thu, 22 Aug 2002 09:23:33 -0700 content-class: urn:content-classes:message Subject: RE: [midcom] STUN update time proposals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Aug 2002 09:23:24 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [midcom] STUN update time proposals Thread-Index: AcJJv+ARC77UczXjScKLmu5y12aR1wAN0oIw From: "Christian Huitema" To: "Jonathan Rosenberg" , "Cullen Jennings" Cc: "Midcom" X-OriginalArrivalTime: 22 Aug 2002 16:23:33.0868 (UTC) FILETIME=[42A5E2C0:01C249F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7MGO1o01951 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > I still have concerns with this. Generally speaking, the model with STUN > is that STUN servers are decoupled from the NATs; they don't know where > they are, what they are, or what their configuration is. If you want to > change this model, it really leads to a different protocol and set of > features. After all, why stop at binding lifetimes? Why not "hint" to > the client about the type of nat as well? As a scope thing, I'd rather > stick with the current model where they are totally decoupled. I agree with Jonathan. We must keep the STUN service simple. The primary usage is to get a mapping shortly before a session, i.e. a period of sustained traffic between two hosts. In that primary usage, the lifetime of the mapping does not matter much: we know by experience that it is always >= 1 minute, i.e. enough for session set-up; we also know that sustained traffic effectively prevents the mapping from disappearing. > Related to this, the hints don't help that much since they are just > hints. They could easily be wrong, due to inconsistent configuration > between the stun server and nat. Also, the stun server can't know for > certain that the clients contacting it are coming through the NATs it > knows about. Correctness of the hint is therefore strongly coupled with > network topology. It seems like it will be very error prone. In any > case, there can always be other nats, so it can never be anything more > than a starting point in a binary search, not even really a hint about > what the overall binding lifetime is amongst all NATs. Thus, the value > in the information is actually low, and given the possibility of it > being error prone, I am inclined not to include it. Yes. If you want to go beyond the simple "map before a session" model, then you must be concerned with the exact binding algorithm used in the NAT. You have to consider corner cases, such as dial-up and ISDN connections, in which the mapping itself can be maintained for a long time, but the connection may be dropped if no traffic is observed for some period, introducing a coupling between the mapping and the amount of traffic in other sessions; when the node dials back, it may or may not come back with the same address. In the case that Cullen mentions, a large cable ISP with a large NAT, the ISP could just as well publish that it adheres to some recommended lifetime guarantee, say 3 minutes. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Aug 23 09:38:42 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06427 for ; Fri, 23 Aug 2002 09:38:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NDddB05609 for midcom-archive@odin.ietf.org; Fri, 23 Aug 2002 09:39:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NDYEo05357; Fri, 23 Aug 2002 09:34:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NDTco04688 for ; Fri, 23 Aug 2002 09:29:38 -0400 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 JAA06049 for ; Fri, 23 Aug 2002 09:28:10 -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 g7NDT5sd026668 for ; Fri, 23 Aug 2002 06:29:05 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEW92291; Fri, 23 Aug 2002 06:25:06 -0700 (PDT) Message-Id: <200208231325.AEW92291@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Fri, 23 Aug 2002 09:29:03 -0400 Subject: [midcom] Moving SPAN along Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We're continuing to fail to make progress on SPAN and we really do need to get serious about moving it along. Pete's draft has received extraordinarily little comment. Please have another look at it and post comments to the mailing list. The URL is http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Aug 23 12:12:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10717 for ; Fri, 23 Aug 2002 12:12:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NGDlV14545 for midcom-archive@odin.ietf.org; Fri, 23 Aug 2002 12:13:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NGCCo14437; Fri, 23 Aug 2002 12:12:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NGBYo14403 for ; Fri, 23 Aug 2002 12:11:34 -0400 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10595 for ; Fri, 23 Aug 2002 12:10:04 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 09:11:00 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Aug 2002 09:11:00 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 23 Aug 2002 09:11:00 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 09:10:59 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Fri, 23 Aug 2002 09:11:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6728.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [midcom] Moving SPAN along Date: Fri, 23 Aug 2002 09:11:03 -0700 Message-ID: Thread-Topic: [midcom] Moving SPAN along Thread-Index: AcJKqrI1f7TBW4etTdaBhOQSWPqXhQAE5hyQ From: "Christian Huitema" To: "Melinda Shore" , X-OriginalArrivalTime: 23 Aug 2002 16:11:00.0050 (UTC) FILETIME=[ABC02320:01C24ABF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7NGBZo14404 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > We're continuing to fail to make progress on SPAN and we > really do need to get serious about moving it along. Pete's > draft has received extraordinarily little comment. Please > have another look at it and post comments to the mailing > list. The URL is > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt. There are a few issues with this draft. A first problem is one of readability: there is a reference diagram, but the draft lacks a "model of operation" section that would help the reader understand the proposed mechanism -- for example, ladder diagrams of the TCP connection set up and UDP connection set up. In the absence of such diagrams, it is hard to quickly understand how the proposed scheme reacts, for example, to network congestion. It is also hard to understand how the service can be integrated with other services, such as SIP. A second problem is one of scope. AFAIK, we already have a solution for UDP, which is STUN. Do we need to standardize another UDP traversal with SPAN? A third problem is the security analysis. SPAN allows hosts located behind a firewall to receive incoming TCP connections, possibly in violation of the firewall policy; the possibilities for hackers are enormous. Yet, this threat is not analyzed in the security section, and no mitigation is proposed. The last problem has to do with the connection model implied by SPAN. While a STUN server can be put up at minimal cost, a SPAN server needs to relay traffic. This is not very attractive, and may well explain the lack of interest in the group. -- Christian Huitema _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Aug 23 16:51:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17296 for ; Fri, 23 Aug 2002 16:51:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7NKq3E27650 for midcom-archive@odin.ietf.org; Fri, 23 Aug 2002 16:52:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NKoVo27583; Fri, 23 Aug 2002 16:50:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7NKmMo27480 for ; Fri, 23 Aug 2002 16:48:22 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17157 for ; Fri, 23 Aug 2002 16:46:50 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7NKlkW4008235; Fri, 23 Aug 2002 13:47:46 -0700 (PDT) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ADV18347; Fri, 23 Aug 2002 13:47:55 -0700 (PDT) From: "Cullen Jennings" To: "Melinda Shore" , Subject: RE: [midcom] Moving SPAN along Date: Mon, 19 Aug 2002 13:47:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200208231325.AEW92291@mira-sjc5-4.cisco.com> Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I have not said much on this draft because it is impossible to know where to start on all the things I see needing changes. However, lets get a few high level issues straitened out before we even look into the draft. 1) The media packets get bigger. G.729 packets have 12 bytes of payload data - any addition to this significantly increases the bandwidth usage of the protocol. If I had any interest in increasing the size of this stuff there are other protocols I could use such as PPP, RSIP whatever. I don't think we should be doing a solution in this WG that increases the size of the media packets being relayed If I did I would go down the path of encapsulated media packets, the IP in IP described with SDP would likely be the route that I would want to take. 2) The arbitrary TCP tunneling stuff eliminates the ability of the FW admin to assert policy - which is something we agreed we would not do 3) This draft is needlessly complex resulting in a more confusing security situation. Cullen ps As a side note, every day we discuss this, more NATs become port restricted so that games will work through them - at times I wonder if something beyond STUN is needed. > -----Original Message----- > From: midcom-admin@ietf.org [mailto:midcom-admin@ietf.org]On Behalf Of > Melinda Shore > Sent: Friday, August 23, 2002 6:29 AM > To: midcom@ietf.org > Subject: [midcom] Moving SPAN along > > > We're continuing to fail to make progress on SPAN and we > really do need to get serious about moving it along. Pete's > draft has received extraordinarily little comment. Please > have another look at it and post comments to the mailing > list. The URL is > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt. > > 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 mailnull@www1.ietf.org Mon Aug 26 08:09:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06898 for ; Mon, 26 Aug 2002 08:09:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QCAaG30531 for midcom-archive@odin.ietf.org; Mon, 26 Aug 2002 08:10:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QC4wo29831; Mon, 26 Aug 2002 08:04:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QBI4o28241 for ; Mon, 26 Aug 2002 07:18:04 -0400 Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05987 for ; Mon, 26 Aug 2002 07:16:29 -0400 (EDT) Received: from host213-122-89-81.in-addr.btopenworld.com ([213.122.89.81] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #8) id 17jHsT-0003te-00; Mon, 26 Aug 2002 12:17:50 +0100 Message-ID: <003d01c24cf2$73b91060$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" , "Melinda Shore" , References: Subject: Re: [midcom] Moving SPAN along Date: Mon, 26 Aug 2002 11:59:28 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian, Thanks for your comments. First of all, let me say that I consider the draft to be a starting point rather than the final word. I think other proposals have failed in this area in the past because they tried to present a finished product. I'm hoping to try and evolve something as a group effort this time so I'm glad that you are raising these issues. Other comments inline... Pete. ----- Original Message ----- From: "Christian Huitema" > > There are a few issues with this draft. A first problem is one of > readability: there is a reference diagram, but the draft lacks a "model > of operation" section that would help the reader understand the proposed > mechanism -- for example, ladder diagrams of the TCP connection set up > and UDP connection set up. In the absence of such diagrams, it is hard > to quickly understand how the proposed scheme reacts, for example, to > network congestion. Sorry about that. It seemed relatively straight forward to me, so I didn't put ladder diagrams in. I'll put some in a new draft. In the mean time, as a hint, the example messages pretty much follow the order in which messages are sent and you should be able to mentally build up ladder diagrams simply by looking at them. > It is also hard to understand how the service can be > integrated with other services, such as SIP. This could go in a future version. However, there are many drafts out there, such as midcom, that have very similar interaction so I figured this was understood. > A second problem is one of scope. AFAIK, we already have a solution for > UDP, which is STUN. Do we need to standardize another UDP traversal with > SPAN? SPAN is intended to handle the symmetric case (+ a few other restricted modes) that are not covered by STUN. > A third problem is the security analysis. SPAN allows hosts located > behind a firewall to receive incoming TCP connections, possibly in > violation of the firewall policy; the possibilities for hackers are > enormous. Yet, this threat is not analyzed in the security section, and > no mitigation is proposed. At first sight this does appear to be a problem. HOWEVER, such connections must be initiated by an internal party. Also, even with outgoing connections there is no guarentee about what you get back. For example, you can get all manner of things with HTTP and POP3. In that light the situation is not a risky as it first appears. However, if it can be shown that this is much worse than the likes of HTTP and POP3, then perhaps we should include ways that will not result in firewall policy being violated. Any suggestions? > The last problem has to do with the connection model implied by SPAN. > While a STUN server can be put up at minimal cost, a SPAN server needs > to relay traffic. This is not very attractive, and may well explain the > lack of interest in the group. I'm glad this is the last problem :-) I think this is a commercial issue rather than a standards issue. In the absence of direct communication, there are people that are prepared to accept indirect communication rather than no communication. I also see this as a stepping stone solution where people can try out technology such as SIP without major infrastructure changes. Without it I think there are many cases where SIP and the like won't take off. So I think it's a case of introducing some local sub-optimality in order to achieve some global optimality. It may be that the IETF decides that it is not bothered with such commercial issues and is prepared to leave such matters to proprietry solutions. Maybe that is something we need to discuss. > > -- Christian Huitema > _______________________________________________ > 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 mailnull@www1.ietf.org Mon Aug 26 08:29:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07176 for ; Mon, 26 Aug 2002 08:29:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7QCUhD31063 for midcom-archive@odin.ietf.org; Mon, 26 Aug 2002 08:30:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QCTEo31007; Mon, 26 Aug 2002 08:29:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7QC6lo29869 for ; Mon, 26 Aug 2002 08:06:47 -0400 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06782 for ; Mon, 26 Aug 2002 08:05:17 -0400 (EDT) Received: from host213-122-134-41.in-addr.btopenworld.com ([213.122.134.41] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 17jIdZ-000786-00; Mon, 26 Aug 2002 13:06:29 +0100 Message-ID: <006401c24cf9$3d099100$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , "Melinda Shore" , References: Subject: Re: [midcom] Moving SPAN along Date: Mon, 26 Aug 2002 12:52:54 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen, Thanks for your comments... Pete. ----- Original Message ----- From: "Cullen Jennings" > > I have not said much on this draft because it is impossible to know where to > start on all the things I see needing changes. At the beginning :-) > However, lets get a few high level issues straitened out before we even look > into the draft. > > 1) The media packets get bigger. G.729 packets have 12 bytes of payload > data - any addition to this significantly increases the bandwidth usage of > the protocol. If I had any interest in increasing the size of this stuff > there are other protocols I could use such as PPP, RSIP whatever. I > don't think we should be doing a solution in this WG that increases the size > of the media packets being relayed If I did I would go down the path > of encapsulated media packets, the IP in IP described with SDP would likely > be the route that I would want to take. By my calculation, the extra 8 bytes of header amounts to about 15% extra traffic. This seems a small amount compared to the 433% overhead introduced by IP/UDP/RTP. I think the header information adds benefit. It's more stateless and more general. But if people are really worried about the overhead, it could be removed. > 2) The arbitrary TCP tunneling stuff eliminates the ability of the FW admin > to assert policy - which is something we agreed we would not do I'm confused. There's no TCP tunnelling in the draft. > 3) This draft is needlessly complex resulting in a more confusing security > situation. A bit of a sweep all statement. Please send in specifics on which bits are needless and we can work out how to remove them. > Cullen > _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Tue Aug 27 15:48:19 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09523 for ; Tue, 27 Aug 2002 15:48:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7RJnNI30552 for midcom-archive@odin.ietf.org; Tue, 27 Aug 2002 15:49:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJlao30438; Tue, 27 Aug 2002 15:47:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGgo28181 for ; Tue, 27 Aug 2002 15:16:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [midcom] Nomcom call for volunteers Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Aug 28 04:55:12 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21147 for ; Wed, 28 Aug 2002 04:55:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7S8uNY14519 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 04:56:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7S8sWo14471; Wed, 28 Aug 2002 04:54:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7S8r6o14431 for ; Wed, 28 Aug 2002 04:53:06 -0400 Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21094 for ; Wed, 28 Aug 2002 04:51:24 -0400 (EDT) Received: from host62-6-94-223.in-addr.btopenworld.com ([62.6.94.223] helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #8) id 17jyZF-0001C3-00; Wed, 28 Aug 2002 09:52:49 +0100 Message-ID: <002301c24e70$908c1b40$0200000a@tkw> From: "Pete Cordell" To: "Cullen Jennings" , "Melinda Shore" , References: Subject: Re: [midcom] Moving SPAN along Date: Wed, 28 Aug 2002 09:53:56 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Cullen Jennings" > 1) The media packets get bigger. G.729 packets have 12 bytes of payload > data - any addition to this significantly increases the bandwidth usage of > the protocol. If I had any interest in increasing the size of this stuff > there are other protocols I could use such as PPP, RSIP whatever. I > don't think we should be doing a solution in this WG that increases the size > of the media packets being relayed If I did I would go down the path > of encapsulated media packets, the IP in IP described with SDP would likely > be the route that I would want to take. As a result of banging numbers into my calculator I forgot to mention in my previous e-mail that IP over IP or PPP over IP typically won't get through NAT, especially NAPT. Even if they could, IP over IP would involve a much greater overhead, and PPP would involve numerous round-trips for negotiation etc. Neither of these are desirable. RSIP doesn't work through many types of NAT, and also is typically implemented as part of the OS rather than the application. The latter creates a dependency on unknown third parties that is not compatible with a short term solution. Pete. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Aug 28 08:05:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25898 for ; Wed, 28 Aug 2002 08:05:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SC6rS23437 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 08:06:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SC2Ao23142; Wed, 28 Aug 2002 08:02:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SBx7o22974 for ; Wed, 28 Aug 2002 07:59:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25005; Wed, 28 Aug 2002 07:57:35 -0400 (EDT) Message-Id: <200208281157.HAA25005@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: Wed, 28 Aug 2002 07:57:34 -0400 Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : STUN - Simple Traversal of UDP Through Network Address Translators Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-ietf-midcom-stun-02.txt Pages : 42 Date : 2002-8-27 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-02.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-stun-02.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-stun-02.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: <2002-8-27144828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144828.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Aug 28 09:44:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29806 for ; Wed, 28 Aug 2002 09:44:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SDjsE29527 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 09:45:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SDhPo29436; Wed, 28 Aug 2002 09:43:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SDgRo29387 for ; Wed, 28 Aug 2002 09:42:27 -0400 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 JAA29642 for ; Wed, 28 Aug 2002 09:40:53 -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 g7SDfqKB027544 for ; Wed, 28 Aug 2002 06:41:52 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEY15009; Wed, 28 Aug 2002 06:37:53 -0700 (PDT) Message-Id: <200208281337.AEY15009@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Subject: Internet-Drafts@ietf.org: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt Date: Wed, 28 Aug 2002 09:41:50 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We're not taking this document through last call again, but because there were some small changes as a result of WG last call I'd like to give you all 24 hours to review this draft and make sure that the changes are consistent with what we discussed before I submit it to the IESG for review. Thanks, Melinda ------- Forwarded Message Date: Wed, 28 Aug 2002 07:57:34 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: midcom@ietf.org Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt - --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 I ETF. Title : STUN - Simple Traversal of UDP Through Network Addres s Translators Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy Filename : draft-ietf-midcom-stun-02.txt Pages : 42 Date : 2002-8-27 Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol that allows applications to discover the presence and types of Network Address Translators (NATs) and firewalls between them and the public Internet. It also provides the ability for applications to determine the public IP addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-02.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-stun-02.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-stun-02.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: <2002-8-27144828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-midcom-stun-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-midcom-stun-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144828.I-D@ietf.org> - --OtherAccess-- - --NextPart-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom ------- End of Forwarded Message _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Aug 28 10:59:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02918 for ; Wed, 28 Aug 2002 10:59:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SF08O01037 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 11:00:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SEtMo00856; Wed, 28 Aug 2002 10:55:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SEsbo00812 for ; Wed, 28 Aug 2002 10:54:37 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02739 for ; Wed, 28 Aug 2002 10:53:04 -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 g7SEs2W4016280; Wed, 28 Aug 2002 07:54:02 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEY16565; Wed, 28 Aug 2002 07:50:02 -0700 (PDT) Message-Id: <200208281450.AEY16565@mira-sjc5-4.cisco.com> To: "Pete Cordell" cc: midcom@ietf.org From: Melinda Shore Subject: Re: [midcom] Moving SPAN along In-Reply-To: Message from "Pete Cordell" of "Wed, 28 Aug 2002 09:53:56 BST." <002301c24e70$908c1b40$0200000a@tkw> Date: Wed, 28 Aug 2002 10:54:00 -0400 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At this point there seems to be very little support for continuing to work on SPAN. The question is whether or not the problem of traversing symmetric NATs is sufficiently compelling. If it is we need to continue; if not we can consider dropping the deliverable. Let's try to resolve this question over the next few days. Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Aug 28 11:08:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03310 for ; Wed, 28 Aug 2002 11:08:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SF9gL02041 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 11:09:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SF8Bo01986; Wed, 28 Aug 2002 11:08:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SF6Lo01311 for ; Wed, 28 Aug 2002 11:06:21 -0400 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 LAA03169 for ; Wed, 28 Aug 2002 11:04: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 g7SF5cmk022176 for ; Wed, 28 Aug 2002 08:05:38 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEY16894; Wed, 28 Aug 2002 08:01:38 -0700 (PDT) Message-Id: <200208281501.AEY16894@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Wed, 28 Aug 2002 11:05:36 -0400 Subject: [midcom] Semantics documents Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We currently have two internet drafts describing what the authors see as the semantics of a midcom protocol. As we move closer to completing the evaluation document (WG last call closes tomorrow) and begin thinking about choosing a base protocol and designing the midcom protocol, the semantics description becomes more pressing. It appears that it's not going to be possible to combine the two drafts into one, and we're going to have to select one. Please take a look at both and try to select one as the basis for a working group document. The decision should revolve around document clarity and utility as the basis for creating an actual protocol. The URLs are: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-01.txt http://www.ietf.org/internet-drafts/draft-taylor-midcom-semantics-00.txt Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Wed Aug 28 11:31:54 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04323 for ; Wed, 28 Aug 2002 11:31:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SFWwl03006 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 11:32:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SFSAo02834; Wed, 28 Aug 2002 11:28:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SFROo02790 for ; Wed, 28 Aug 2002 11:27:24 -0400 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 LAA04101 for ; Wed, 28 Aug 2002 11:25:50 -0400 (EDT) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7SFQKT15791; Wed, 28 Aug 2002 11:26:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 11:26:25 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A80D@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Semantics documents Date: Wed, 28 Aug 2002 11:26:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I have to apologize -- my recent vacation has held up the effort to issue a single document. I, Martin, and Juergen have found ourselves in general agreement that this is possible. Essentially the detailed specification would be theirs, modified to take account of comments received, particularly at the meeting. As I understand it, we would still have a general lead-in which summarizes the implications of the framework and requirements documents, as presented in my draft. Again, this will be modified to fit what follows. -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: Wednesday, August 28, 2002 11:06 AM To: midcom@ietf.org Subject: [midcom] Semantics documents We currently have two internet drafts describing what the authors see as the semantics of a midcom protocol. As we move closer to completing the evaluation document (WG last call closes tomorrow) and begin thinking about choosing a base protocol and designing the midcom protocol, the semantics description becomes more pressing. It appears that it's not going to be possible to combine the two drafts into one, and we're going to have to select one. Please take a look at both and try to select one as the basis for a working group document. The decision should revolve around document clarity and utility as the basis for creating an actual protocol. The URLs are: http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-01.tx t http://www.ietf.org/internet-drafts/draft-taylor-midcom-semantics-00.txt Thanks, 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 mailnull@www1.ietf.org Wed Aug 28 12:15:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07199 for ; Wed, 28 Aug 2002 12:15:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SGGTK06232 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 12:16:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SGEpo06108; Wed, 28 Aug 2002 12:14:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SG1Bo04606 for ; Wed, 28 Aug 2002 12:01:11 -0400 Received: from carbon (carbon.btinternet.com [194.73.73.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06197 for ; Wed, 28 Aug 2002 11:59:36 -0400 (EDT) Received: from host213-122-61-218.in-addr.btopenworld.com ([213.122.61.218] helo=tkw) by carbon with smtp (Exim 3.22 #8) id 17k5Fg-0001HC-00; Wed, 28 Aug 2002 17:01:04 +0100 Message-ID: <005f01c24eac$52b17c20$0200000a@tkw> From: "Pete Cordell" To: , "Melinda Shore" References: <200208281337.AEY15009@mira-sjc5-4.cisco.com> Subject: Re: Internet-Drafts@ietf.org: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt Date: Wed, 28 Aug 2002 17:01:54 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I haven't had a chance to look at it all, but I have some comments on the following bits: It MUST invalidate the username after 30 minutes. ...... While requiring a 10 minute minimum is useful, specifying a 30 minute maximum seems to be getting very close to specifying policy. (Perhaps worryingly) my bank account details are protected by usernames and passwords that have much lower entropy than 128bits, and I probably won't update them for 30 days, let alone 30 minutes. For a client there is no issue with leaving the maximum period open ended. It can do a new Shared Secret Request whenever it wants. The case for the server is slightly more difficult, but all it requires is a new error code: 5: The Binding Request contained an unknown or expired USERNAME attribute. The client should perform a Shared Secret Request to get a new USERNAME and PASSWORD. There is enough text in the existing paragraph to say what is recommended behaviour, so you should be able to safely delete the sentence. e.g.: s/It MUST invalidate the username after 30 minutes.// On a lesser note: The server MUST NOT assign the same password for two different usernames, .... While this is unlikely, it seems an odd requirement. If a hashed master key is used to generate PASSWORDs from USERNAMEs and the master key is periodically changed, it is conceivable that the same PASSWORD might be generated for the different USERNAMEs. This text may be there to cover the case where a server always hands out the same PASSWORD in any period. However, the text following the above sentence ("and the passwords MUST be unguessable. In other words, they MUST be a cryptographically random function of the username.") seems to cover this case. If that is not sufficiently strong, maybe something like the following can be used: The algorithm used by the server to generate PASSWORDs MUST ensure that the probability that the server allocates the same PASSWORD to two different USERNAMEs is vanishingly small. Also... when it comes to closing the TLS connection, from the following sentences there seems to be the chance that the server will be hosting a number of idle connections: The server SHOULD keep the connection open, and let the client close it. The client SHOULD close the connection as soon as it has finished obtaining usernames and passwords. As multiple Binding Requests can use the same shared secret and there's no real benefit for a client to obtain multiple short term secrets, from a server perspective it would be nice to be able to clean up resources ASAP after dishing out a shared secret (makes it more stateless without having to have timers kick in etc.). Therefore maybe the sentences should be changed to: Typically the server SHOULD close the connection once the Shared Secret Response has been sent, but the server MAY keep the connection open, and let the client close it. The client SHOULD close the connection as soon as it has finished obtaining usernames and passwords, but it MUST be resilient to the server closing the connection immediately after the server has sent a response to the first Shared Secret Request. That's all for now. I'll try and read some more soon. It is looking good though. Pete. ----- Original Message ----- From: "Melinda Shore" To: Sent: 28 August 2002 14:41 Subject: Internet-Drafts@ietf.org: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt > We're not taking this document through last call again, but > because there were some small changes as a result of WG last > call I'd like to give you all 24 hours to review this draft > and make sure that the changes are consistent with what we > discussed before I submit it to the IESG for review. > > Thanks, > > Melinda > > ------- Forwarded Message > > Date: Wed, 28 Aug 2002 07:57:34 -0400 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > cc: midcom@ietf.org > Subject: [midcom] I-D ACTION:draft-ietf-midcom-stun-02.txt > > - --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 I > ETF. > > Title : STUN - Simple Traversal of UDP Through Network Addres > s > Translators > Author(s) : J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy > Filename : draft-ietf-midcom-stun-02.txt > Pages : 42 > Date : 2002-8-27 > > Simple Traversal of UDP Through NATs (STUN) is a lightweight protocol > that allows applications to discover the presence and types of > Network Address Translators (NATs) and firewalls between them and the > public Internet. It also provides the ability for applications to > determine the public IP addresses allocated to them by the NAT. STUN > works with many existing NATs, and does not require any special > behavior from them. As a result, it allows a wide variety of > applications to work through existing NAT infrastructure > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-02.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-stun-02.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-stun-02.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: <2002-8-27144828.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-midcom-stun-02.txt > > - --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-midcom-stun-02.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2002-8-27144828.I-D@ietf.org> > > - --OtherAccess-- > > - --NextPart-- > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > > ------- End of Forwarded Message > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Aug 28 12:28:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07724 for ; Wed, 28 Aug 2002 12:28:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SGTch06885 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 12:29:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SGOfo06603; Wed, 28 Aug 2002 12:24:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SGLeo06483 for ; Wed, 28 Aug 2002 12:21:40 -0400 Received: from protactinium.btinternet.com (protactinium.btinternet.com [194.73.73.176]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07417 for ; Wed, 28 Aug 2002 12:20:06 -0400 (EDT) Received: from host213-122-190-125.in-addr.btopenworld.com ([213.122.190.125] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #8) id 17k5ZJ-0005Qm-00; Wed, 28 Aug 2002 17:21:21 +0100 Message-ID: <009b01c24eaf$25634020$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: References: <200208281450.AEY16565@mira-sjc5-4.cisco.com> Subject: Re: [midcom] Moving SPAN along Date: Wed, 28 Aug 2002 17:22:07 +0100 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There is also the issue of providing traversal for TCP. This is however more of an issue for H.323 and other similar protocols (possibly including some IM scenarios) than SIP. Pete. ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: Sent: 28 August 2002 15:54 Subject: Re: [midcom] Moving SPAN along > At this point there seems to be very little support for > continuing to work on SPAN. The question is whether or not > the problem of traversing symmetric NATs is sufficiently > compelling. If it is we need to continue; if not we can > consider dropping the deliverable. Let's try to resolve > this question over the next few days. > > 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 mailnull@www1.ietf.org Wed Aug 28 12:30:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07813 for ; Wed, 28 Aug 2002 12:30:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7SGV7006951 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 12:31:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SGTWo06871; Wed, 28 Aug 2002 12:29:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7SGP1o06616 for ; Wed, 28 Aug 2002 12:25:01 -0400 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 MAA07548 for ; Wed, 28 Aug 2002 12:23:25 -0400 (EDT) Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g7SGO9U56223; Wed, 28 Aug 2002 18:24:09 +0200 (CEST) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1F81754DA6; Wed, 28 Aug 2002 18:24:08 +0200 (CEST) Date: Wed, 28 Aug 2002 18:24:08 +0200 From: Juergen Quittek To: Tom-PT Taylor , "'Melinda Shore'" , midcom@ietf.org Subject: RE: [midcom] Semantics documents Message-ID: <33128616.1030559048@[192.168.102.164]> In-Reply-To: <4D79C746863DD51197690002A52CDA0001E8A80D@zcard0kc.ca.nortel.com> References: <4D79C746863DD51197690002A52CDA0001E8A80D@zcard0kc.ca.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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, We already have a version of the document, which - includes contributions from both documents - considers all the comments and discussions of the last meeting and - is much more elaborated. The document is ready for posting from Martin's and my side. But still Tom needs to review it, because he was out of the office for the last weeks. Juergen --On 28 August 2002 11:26 -0400 Tom-PT Taylor wrote: > > I have to apologize -- my recent vacation has held up the effort to issue a > single document. I, Martin, and Juergen have found ourselves in general > agreement that this is possible. Essentially the detailed specification > would be theirs, modified to take account of comments received, particularly > at the meeting. As I understand it, we would still have a general lead-in > which summarizes the implications of the framework and requirements > documents, as presented in my draft. Again, this will be modified to fit > what follows. > > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Wednesday, August 28, 2002 11:06 AM > To: midcom@ietf.org > Subject: [midcom] Semantics documents > > > We currently have two internet drafts describing what the > authors see as the semantics of a midcom protocol. As we > move closer to completing the evaluation document (WG last > call closes tomorrow) and begin thinking about choosing a > base protocol and designing the midcom protocol, the > semantics description becomes more pressing. > > It appears that it's not going to be possible to combine the > two drafts into one, and we're going to have to select one. > Please take a look at both and try to select one as the > basis for a working group document. The decision should > revolve around document clarity and utility as the basis for > creating an actual protocol. > > The URLs are: > http://www.ietf.org/internet-drafts/draft-stiemerling-midcom-semantics-01.tx > t > http://www.ietf.org/internet-drafts/draft-taylor-midcom-semantics-00.txt > > Thanks, > > 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 mailnull@www1.ietf.org Wed Aug 28 21:43:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27015 for ; Wed, 28 Aug 2002 21:43:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7T1iFJ03912 for midcom-archive@odin.ietf.org; Wed, 28 Aug 2002 21:44:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7T1gao03860; Wed, 28 Aug 2002 21:42:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7T1flo03821 for ; Wed, 28 Aug 2002 21:41:47 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26891 for ; Wed, 28 Aug 2002 21:40:09 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7T1f8YH012674; Wed, 28 Aug 2002 21:41:08 -0400 (EDT) Message-ID: <3D6D7BB3.9060504@dynamicsoft.com> Date: Wed, 28 Aug 2002 21:41:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: Pete Cordell , midcom@ietf.org Subject: Re: [midcom] Moving SPAN along References: <200208281450.AEY16565@mira-sjc5-4.cisco.com> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the problem is important. Note that, you need something in the TURN/SPAN area even for full cone NAT. There are cases where two users are behind a full cone NAT, but the SAME full cone NAT. STUN, in this environment, would require the NAT to receive a packet on the inside, addressed to a public IP corresponding to another one of its bindings. Most NATs apparently do not properly turn the packet around to the private address for the second binding. This case can be detected with STUN, but it cannot be fixed with STUN. -Jonathan R. Melinda Shore wrote: > At this point there seems to be very little support for > continuing to work on SPAN. The question is whether or not > the problem of traversing symmetric NATs is sufficiently > compelling. If it is we need to continue; if not we can > consider dropping the deliverable. Let's try to resolve > this question over the next few days. > > Melinda > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 29 10:41:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24498 for ; Thu, 29 Aug 2002 10:41:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TEgY818088 for midcom-archive@odin.ietf.org; Thu, 29 Aug 2002 10:42:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TEZ2o17262; Thu, 29 Aug 2002 10:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TEVvo17149 for ; Thu, 29 Aug 2002 10:31:57 -0400 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 KAA23992 for ; Thu, 29 Aug 2002 10:30: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 g7TEVL3x005376 for ; Thu, 29 Aug 2002 07:31:21 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEY54395; Thu, 29 Aug 2002 07:27:24 -0700 (PDT) Message-Id: <200208291427.AEY54395@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Thu, 29 Aug 2002 10:31:22 -0400 Subject: [midcom] WG last call for eval document - last day Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a reminder that working group last call for the protocol evaluation document closes today at 5pm EDT. There have been no comments at all, and I'm hoping that's due to the quality of the document rather than lack of interest. If you haven't had an opportunity to look at the draft, please do so and send any comments to the mailing list. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 29 11:21:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26577 for ; Thu, 29 Aug 2002 11:21:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TFMPt20372 for midcom-archive@odin.ietf.org; Thu, 29 Aug 2002 11:22:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TFIAo20158; Thu, 29 Aug 2002 11:18:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TFHoo20129 for ; Thu, 29 Aug 2002 11:17:50 -0400 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26249 for ; Thu, 29 Aug 2002 11:16:16 -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 g7TFGPr09550; Thu, 29 Aug 2002 10:16:25 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 10:16:12 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A634A8@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , Melinda Shore Cc: Pete Cordell , midcom@ietf.org Subject: RE: [midcom] Moving SPAN along Date: Thu, 29 Aug 2002 10:16:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24F6F.02684FF0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C24F6F.02684FF0 Content-Type: text/plain We should be able to solve the problem by using STUN in a peer-to-peer fashion between the endpoints. Suppose client A and B are behind the same NAT. Client A (or B) will send two STUN BIND requests to the public address of B - in one of the STUN BIND requests, the Response-Address field is set to the private address of A. If the two users are behind the same NAT (share the same private realm), then A will receive a response to the BIND request carrying the Response-Address, and may or may not get a response to the other request based on whether the NAT supports loopback or not. Then the IP address can be updated by sending a reINVITE or UPDATE as required. Thoughts? If the idea seems acceptable, we can write up a short ID and submit. Sanjoy > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 28, 2002 8:41 PM > To: Melinda Shore > Cc: Pete Cordell; midcom@ietf.org > Subject: Re: [midcom] Moving SPAN along > > > I think the problem is important. Note that, you need > something in the > TURN/SPAN area even for full cone NAT. There are cases where > two users > are behind a full cone NAT, but the SAME full cone NAT. STUN, in this > environment, would require the NAT to receive a packet on the inside, > addressed to a public IP corresponding to another one of its > bindings. > Most NATs apparently do not properly turn the packet around to the > private address for the second binding. This case can be > detected with > STUN, but it cannot be fixed with STUN. > > -Jonathan R. > > Melinda Shore wrote: > > At this point there seems to be very little support for > continuing to > > work on SPAN. The question is whether or not the problem of > > traversing symmetric NATs is sufficiently compelling. If it is we > > need to continue; if not we can consider dropping the deliverable. > > Let's try to resolve this question over the next few days. > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C24F6F.02684FF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [midcom] Moving SPAN along

We should be able to solve the problem by using STUN = in a peer-to-peer fashion between the endpoints. Suppose client A and B = are behind the same NAT. Client A (or B) will send two STUN BIND = requests to the public address of B - in one of the STUN BIND requests, = the Response-Address field is set to the private address of A. If the = two users are behind the same NAT (share the same private realm), then = A will receive a response to the BIND request carrying the = Response-Address, and may or may not get a response to the other = request based on whether the NAT supports loopback or not.

Then the IP address can be updated by sending a = reINVITE or UPDATE as required.

Thoughts? If the idea seems acceptable, we can write = up a short ID and submit.

Sanjoy

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, August 28, 2002 8:41 PM
> To: Melinda Shore
> Cc: Pete Cordell; midcom@ietf.org
> Subject: Re: [midcom] Moving SPAN along
>
>
> I think the problem is important. Note that, = you need
> something in the
> TURN/SPAN area even for full cone NAT. There = are cases where
> two users
> are behind a full cone NAT, but the SAME full = cone NAT. STUN, in this
> environment, would require the NAT to receive a = packet on the inside,
> addressed to a public IP corresponding to = another one of its
> bindings.
> Most NATs apparently do not properly turn the = packet around to the
> private address for the second binding. This = case can be
> detected with
> STUN, but it cannot be fixed with STUN.
>
> -Jonathan R.
>
> Melinda Shore wrote:
> > At this point there seems to be very = little support for
> continuing to
> > work on SPAN.  The question is = whether or not the problem of
> > traversing symmetric NATs is sufficiently = compelling.  If it is we
> > need to continue; if not we can consider = dropping the deliverable. 
> > Let's try to resolve this question over = the next few days.
> >
> > Melinda
> > = _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
> >
>
>
> --
> Jonathan D. Rosenberg, Ph.D.   &n= bsp;            = 72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C24F6F.02684FF0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 29 12:14:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29141 for ; Thu, 29 Aug 2002 12:14:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TGFP124062 for midcom-archive@odin.ietf.org; Thu, 29 Aug 2002 12:15:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TGB4o23842; Thu, 29 Aug 2002 12:11:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TGARo23796 for ; Thu, 29 Aug 2002 12:10:27 -0400 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28663 for ; Thu, 29 Aug 2002 12:08:52 -0400 (EDT) Received: from host213-122-30-28.in-addr.btopenworld.com ([213.122.30.28] helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #8) id 17kRrO-0002Hj-00; Thu, 29 Aug 2002 17:09:30 +0100 Message-ID: <002501c24f76$b133ea60$0200000a@tkw> From: "Pete Cordell" To: "Sanjoy Sen" , "'Jonathan Rosenberg'" , "Melinda Shore" Cc: References: <933FADF5E673D411B8A30002A5608A0E03A634A8@zrc2c012.us.nortel.com> Subject: Re: [midcom] Moving SPAN along Date: Thu, 29 Aug 2002 17:10:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C24F7E.F5034120" 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 Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C24F7E.F5034120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Moving SPAN alongSanjoy, I think as you've described it, the Bind Request from A won't (normally) = get to B because the path relies on the NAT supporting loopback. You = need something external to the NAT to bounce the STUN Bind Request off = of which sends it to B. Either additional features could be added to = STUN or you could try source routing :-). If you could guarantee that B was running a STUN server, you might be = able to use the fact that you didn't get a response back to either = request to imply that you were behind the same NAT. That seems to = involve a lot of assumptions though. There might be some other permutation that works. One worry though is = that A's request may actually result in B sending packets to C. = Depending on the context of C this may ring some alarm bells. Maybe = that's not so important - still thinking !!! Pete. ----- Original Message -----=20 From: Sanjoy Sen=20 To: 'Jonathan Rosenberg' ; Melinda Shore=20 Cc: Pete Cordell ; midcom@ietf.org=20 Sent: 29 August 2002 16:16 Subject: RE: [midcom] Moving SPAN along We should be able to solve the problem by using STUN in a peer-to-peer = fashion between the endpoints. Suppose client A and B are behind the = same NAT. Client A (or B) will send two STUN BIND requests to the public = address of B - in one of the STUN BIND requests, the Response-Address = field is set to the private address of A. If the two users are behind = the same NAT (share the same private realm), then A will receive a = response to the BIND request carrying the Response-Address, and may or = may not get a response to the other request based on whether the NAT = supports loopback or not.=20 Then the IP address can be updated by sending a reINVITE or UPDATE as = required.=20 Thoughts? If the idea seems acceptable, we can write up a short ID and = submit.=20 Sanjoy=20 > -----Original Message-----=20 > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 > Sent: Wednesday, August 28, 2002 8:41 PM=20 > To: Melinda Shore=20 > Cc: Pete Cordell; midcom@ietf.org=20 > Subject: Re: [midcom] Moving SPAN along=20 >=20 >=20 > I think the problem is important. Note that, you need=20 > something in the=20 > TURN/SPAN area even for full cone NAT. There are cases where=20 > two users=20 > are behind a full cone NAT, but the SAME full cone NAT. STUN, in = this=20 > environment, would require the NAT to receive a packet on the = inside,=20 > addressed to a public IP corresponding to another one of its=20 > bindings.=20 > Most NATs apparently do not properly turn the packet around to the=20 > private address for the second binding. This case can be=20 > detected with=20 > STUN, but it cannot be fixed with STUN.=20 >=20 > -Jonathan R.=20 >=20 > Melinda Shore wrote:=20 > > At this point there seems to be very little support for=20 > continuing to=20 > > work on SPAN. The question is whether or not the problem of=20 > > traversing symmetric NATs is sufficiently compelling. If it is we = > > need to continue; if not we can consider dropping the deliverable. = =20 > > Let's try to resolve this question over the next few days.=20 > >=20 > > Melinda=20 > > _______________________________________________=20 > > midcom mailing list=20 > > midcom@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/midcom=20 > >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.=20 > Chief Scientist First Floor=20 > dynamicsoft East Hanover, NJ 07936=20 > jdrosen@dynamicsoft.com FAX: (973) 952-5050=20 > http://www.jdrosen.net PHONE: (973) 952-5000=20 > http://www.dynamicsoft.com=20 >=20 > _______________________________________________=20 > midcom mailing list=20 > midcom@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/midcom=20 >=20 ------=_NextPart_000_001C_01C24F7E.F5034120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [midcom] Moving SPAN along
Sanjoy,
 
I think as you've described it, the Bind Request = from A won't=20 (normally) get to B because the path relies on the NAT supporting=20 loopback.  You need something external to the NAT to bounce the = STUN Bind=20 Request off of which sends it to B.  Either additional features = could be=20 added to STUN or you could try source routing :-).
 
If you could guarantee that B was running a STUN = server, you=20 might be able to use the fact that you didn't get a response back to = either=20 request to imply that you were behind the same NAT.  That seems to = involve=20 a lot of assumptions though.
 
There might be some other permutation that = works.  One=20 worry though is that A's request may actually result in B sending = packets to=20 C.  Depending on the context of C this may ring some alarm = bells. =20 Maybe that's not so important - still thinking !!!

Pete.
----- Original Message -----
From:=20 Sanjoy Sen
To: 'Jonathan Rosenberg' ; Melinda = Shore
Cc: Pete Cordell ; midcom@ietf.org
Sent: 29 August 2002 = 16:16
Subject: RE: [midcom] Moving = SPAN=20 along

We should be able to solve the problem by using STUN = in a=20 peer-to-peer fashion between the endpoints. Suppose client A and B are = behind=20 the same NAT. Client A (or B) will send two STUN BIND requests to the = public=20 address of B - in one of the STUN BIND requests, the Response-Address = field is=20 set to the private address of A. If the two users are behind the same = NAT=20 (share the same private realm), then A will receive a response to the = BIND=20 request carrying the Response-Address, and may or may not get a = response to=20 the other request based on whether the NAT supports loopback or not.=20

Then the IP address can be updated by sending a = reINVITE or=20 UPDATE as required.

Thoughts? If the idea seems acceptable, we can write = up a=20 short ID and submit.

Sanjoy

> -----Original Message-----
>=20 From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20
> Sent: Wednesday, August 28, 2002 8:41 = PM=20
> To: Melinda Shore
> Cc: Pete=20 Cordell; midcom@ietf.org
> Subject: Re: = [midcom]=20 Moving SPAN along
>
>=20
> I think the problem is important. Note = that, you=20 need
> something in the
> TURN/SPAN area even for full cone NAT. There are cases = where=20
> two users
> are behind=20 a full cone NAT, but the SAME full cone NAT. STUN, in this =
> environment, would require the NAT to receive a packet = on the=20 inside,
> addressed to a public IP = corresponding to=20 another one of its
> bindings. =
> Most NATs apparently do not properly turn the packet = around to the=20
> private address for the second binding. = This case=20 can be
> detected with
>=20 STUN, but it cannot be fixed with STUN.
> =
> -Jonathan R.
>=20
> Melinda Shore wrote:
>=20 > At this point there seems to be very little support for =
> continuing to
> > work = on=20 SPAN.  The question is whether or not the problem of =
> > traversing symmetric NATs is sufficiently = compelling. =20 If it is we
> > need to continue; if = not we can=20 consider dropping the deliverable. 
> >=20 Let's try to resolve this question over the next few days. =
> >
> > Melinda =
> > = _______________________________________________=20
> > midcom mailing list
>=20 > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom =
> >
> =
>
> --
>=20 Jonathan D. Rosenberg,=20 = Ph.D.           &n= bsp;   =20 72 Eagle Rock Ave.
> Chief=20 = Scientist          &nbs= p;            = ;     =20 First Floor
>=20 = dynamicsoft          &n= bsp;           &nb= sp;         =20 East Hanover, NJ 07936
>=20 = jdrosen@dynamicsoft.com        &n= bsp;           =20 FAX:   (973) 952-5050
> http://www.jdrosen.net     &= nbsp;           &n= bsp;   =20 PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>=20
>=20 _______________________________________________
>=20 midcom mailing list
> = midcom@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/midcom =
>

------=_NextPart_000_001C_01C24F7E.F5034120-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 29 13:00:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01833 for ; Thu, 29 Aug 2002 13:00:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TH1tY26306 for midcom-archive@odin.ietf.org; Thu, 29 Aug 2002 13:01:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TGvIo26036; Thu, 29 Aug 2002 12:57:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TGuJo25985 for ; Thu, 29 Aug 2002 12:56:19 -0400 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01404 for ; Thu, 29 Aug 2002 12:54:44 -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 g7TGt8r05516; Thu, 29 Aug 2002 11:55:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 11:54:54 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E03A634AB@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Pete Cordell'" , "'Jonathan Rosenberg'" , Melinda Shore Cc: midcom@ietf.org Subject: RE: [midcom] Moving SPAN along Date: Thu, 29 Aug 2002 11:54:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24F7C.CBE581B0" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C24F7C.CBE581B0 Content-Type: text/plain Pete, Thanks for your comments. Comments inline. -----Original Message----- From: Pete Cordell [mailto:pete@tech-know-ware.com] Sent: Thursday, August 29, 2002 11:10 AM To: Sen, Sanjoy [NGC:B677:EXCH]; 'Jonathan Rosenberg'; Melinda Shore Cc: midcom@ietf.org Subject: Re: [midcom] Moving SPAN along Sanjoy, I think as you've described it, the Bind Request from A won't (normally) get to B because the path relies on the NAT supporting loopback. You need something external to the NAT to bounce the STUN Bind Request off of which sends it to B. Either additional features could be added to STUN or you could try source routing :-). [SS] Didn't want to change the protocol, if not required. If you could guarantee that B was running a STUN server, you might be able to use the fact that you didn't get a response back to either request to imply that you were behind the same NAT. [SS] That's exactly correct. We've banked on the retransmission mechanism in STUN to ensure a reponse if there's a path through the NAT. That seems to involve a lot of assumptions though. There might be some other permutation that works. One worry though is that A's request may actually result in B sending packets to C. Depending on the context of C this may ring some alarm bells. Maybe that's not so important - still thinking !!! [SS] Yes, this can happen if C there're overlapping private addresses between A's and B's realms. C will get an unsolicitated STUN response. But I don't think there's any security risk here. Pete. ----- Original Message ----- From: Sanjoy Sen To: 'Jonathan Rosenberg' ; Melinda Shore Cc: Pete Cordell ; midcom@ietf.org Sent: 29 August 2002 16:16 Subject: RE: [midcom] Moving SPAN along We should be able to solve the problem by using STUN in a peer-to-peer fashion between the endpoints. Suppose client A and B are behind the same NAT. Client A (or B) will send two STUN BIND requests to the public address of B - in one of the STUN BIND requests, the Response-Address field is set to the private address of A. If the two users are behind the same NAT (share the same private realm), then A will receive a response to the BIND request carrying the Response-Address, and may or may not get a response to the other request based on whether the NAT supports loopback or not. Then the IP address can be updated by sending a reINVITE or UPDATE as required. Thoughts? If the idea seems acceptable, we can write up a short ID and submit. Sanjoy > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com ] > Sent: Wednesday, August 28, 2002 8:41 PM > To: Melinda Shore > Cc: Pete Cordell; midcom@ietf.org > Subject: Re: [midcom] Moving SPAN along > > > I think the problem is important. Note that, you need > something in the > TURN/SPAN area even for full cone NAT. There are cases where > two users > are behind a full cone NAT, but the SAME full cone NAT. STUN, in this > environment, would require the NAT to receive a packet on the inside, > addressed to a public IP corresponding to another one of its > bindings. > Most NATs apparently do not properly turn the packet around to the > private address for the second binding. This case can be > detected with > STUN, but it cannot be fixed with STUN. > > -Jonathan R. > > Melinda Shore wrote: > > At this point there seems to be very little support for > continuing to > > work on SPAN. The question is whether or not the problem of > > traversing symmetric NATs is sufficiently compelling. If it is we > > need to continue; if not we can consider dropping the deliverable. > > Let's try to resolve this question over the next few days. > > > > Melinda > > _______________________________________________ > > midcom mailing list > > midcom@ietf.org > > https://www1.ietf.org/mailman/listinfo/midcom > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom > ------_=_NextPart_001_01C24F7C.CBE581B0 Content-Type: text/html Message
Pete, Thanks for your comments. Comments inline.
-----Original Message-----
From: Pete Cordell [mailto:pete@tech-know-ware.com]
Sent: Thursday, August 29, 2002 11:10 AM
To: Sen, Sanjoy [NGC:B677:EXCH]; 'Jonathan Rosenberg'; Melinda Shore
Cc: midcom@ietf.org
Subject: Re: [midcom] Moving SPAN along

Sanjoy,
 
I think as you've described it, the Bind Request from A won't (normally) get to B because the path relies on the NAT supporting loopback.  You need something external to the NAT to bounce the STUN Bind Request off of which sends it to B.  Either additional features could be added to STUN or you could try source routing :-).
[SS] Didn't want to change the protocol, if not required.
 
If you could guarantee that B was running a STUN server, you might be able to use the fact that you didn't get a response back to either request to imply that you were behind the same NAT.  
   
[SS] That's exactly correct. We've banked on the retransmission mechanism in STUN to ensure a reponse if there's a path through the NAT.
 
 That seems to involve a lot of assumptions though.
 
There might be some other permutation that works.  One worry though is that A's request may actually result in B sending packets to C.  Depending on the context of C this may ring some alarm bells.  Maybe that's not so important - still thinking !!! 
[SS] Yes, this can happen if C there're overlapping private addresses between A's and B's realms. C will get an unsolicitated STUN response. But I don't think there's any security risk here.  

Pete.
----- Original Message -----
From: Sanjoy Sen
Sent: 29 August 2002 16:16
Subject: RE: [midcom] Moving SPAN along

We should be able to solve the problem by using STUN in a peer-to-peer fashion between the endpoints. Suppose client A and B are behind the same NAT. Client A (or B) will send two STUN BIND requests to the public address of B - in one of the STUN BIND requests, the Response-Address field is set to the private address of A. If the two users are behind the same NAT (share the same private realm), then A will receive a response to the BIND request carrying the Response-Address, and may or may not get a response to the other request based on whether the NAT supports loopback or not.

Then the IP address can be updated by sending a reINVITE or UPDATE as required.

Thoughts? If the idea seems acceptable, we can write up a short ID and submit.

Sanjoy

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, August 28, 2002 8:41 PM
> To: Melinda Shore
> Cc: Pete Cordell; midcom@ietf.org
> Subject: Re: [midcom] Moving SPAN along
>
>
> I think the problem is important. Note that, you need
> something in the
> TURN/SPAN area even for full cone NAT. There are cases where
> two users
> are behind a full cone NAT, but the SAME full cone NAT. STUN, in this
> environment, would require the NAT to receive a packet on the inside,
> addressed to a public IP corresponding to another one of its
> bindings.
> Most NATs apparently do not properly turn the packet around to the
> private address for the second binding. This case can be
> detected with
> STUN, but it cannot be fixed with STUN.
>
> -Jonathan R.
>
> Melinda Shore wrote:
> > At this point there seems to be very little support for
> continuing to
> > work on SPAN.  The question is whether or not the problem of
> > traversing symmetric NATs is sufficiently compelling.  If it is we
> > need to continue; if not we can consider dropping the deliverable. 
> > Let's try to resolve this question over the next few days.
> >
> > Melinda
> > _______________________________________________
> > midcom mailing list
> > midcom@ietf.org
> > https://www1.ietf.org/mailman/listinfo/midcom
> >
>
>
> --
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> midcom mailing list
> midcom@ietf.org
> https://www1.ietf.org/mailman/listinfo/midcom
>

------_=_NextPart_001_01C24F7C.CBE581B0-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 29 18:30:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13638 for ; Thu, 29 Aug 2002 18:30:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7TMVig10442 for midcom-archive@odin.ietf.org; Thu, 29 Aug 2002 18:31:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TMUCo10380; Thu, 29 Aug 2002 18:30:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7TMTfo10354 for ; Thu, 29 Aug 2002 18:29:41 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13605 for ; Thu, 29 Aug 2002 18:28:04 -0400 (EDT) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7TMSxYH013348; Thu, 29 Aug 2002 18:28:59 -0400 (EDT) Message-ID: <3D6EA02A.2020903@dynamicsoft.com> Date: Thu, 29 Aug 2002 18:28:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sanjoy Sen CC: Melinda Shore , Pete Cordell , midcom@ietf.org Subject: Re: [midcom] Moving SPAN along References: <933FADF5E673D411B8A30002A5608A0E03A634A8@zrc2c012.us.nortel.com> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > We should be able to solve the problem by using STUN in a peer-to-peer > fashion between the endpoints. Suppose client A and B are behind the > same NAT. Client A (or B) will send two STUN BIND requests to the public > address of B - in one of the STUN BIND requests, the Response-Address > field is set to the private address of A. If the two users are behind > the same NAT (share the same private realm), then A will receive a > response to the BIND request carrying the Response-Address, and may or > may not get a response to the other request based on whether the NAT > supports loopback or not. The problem is not the case when two clients are behind the same NAT. There are many ways to detect this, and once you know it, you can use your private addresses. The problem is when you have two clients behind two different NATs, but which share a common "root" NAT on the public Internet. An example is when users A and B both use a cable provider that NATs using a single NAT. Both A and B also have a residential NAT in their house. There is a STUn server in the public network. A and B both allocate public addresses from that server. The NAT in the cable network doesn't do loopback, so A can't send to B's public address, and vice a versa. But, A also can't contact B at B's private address, since they are not in the same address realms. If you can detect this case (which you can), the only resolution I can think of is to resort to a TURN/SPAN server on the public network. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Thu Aug 29 20:13:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16115 for ; Thu, 29 Aug 2002 20:13:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7U0EVa15654 for midcom-archive@odin.ietf.org; Thu, 29 Aug 2002 20:14:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7U0D6o15612; Thu, 29 Aug 2002 20:13:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7U0CAo15591 for ; Thu, 29 Aug 2002 20:12:10 -0400 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16062 for ; Thu, 29 Aug 2002 20:10:33 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7U0Arr10662; Thu, 29 Aug 2002 19:10:53 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 17:10:38 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D203D62A7C@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Jonathan Rosenberg'" , "Sanjoy Sen" Cc: "'Melinda Shore'" , "'Pete Cordell'" , "'midcom@ietf.org'" Subject: RE: [midcom] Moving SPAN along Date: Thu, 29 Aug 2002 17:10:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24FB9.A8CFF902" Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C24FB9.A8CFF902 Content-Type: text/plain > The problem is not the case when two clients are behind the same NAT. > There are many ways to detect this, and once you know it, you can use > your private addresses. Can you expand on the "many ways" to detect this? I can't think of any way that does not require that both end cooperate on this through some standardized mechanism. ------_=_NextPart_001_01C24FB9.A8CFF902 Content-Type: text/html RE: [midcom] Moving SPAN along

> The problem is not the case when two clients are behind the same NAT.
> There are many ways to detect this, and once you know it, you can use
> your private addresses.

Can you expand on the "many ways" to detect this?

I can't think of any way that does not require that both end cooperate on this
through some standardized mechanism.

------_=_NextPart_001_01C24FB9.A8CFF902-- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Aug 30 10:32:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19020 for ; Fri, 30 Aug 2002 10:32:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UEXPx02201 for midcom-archive@odin.ietf.org; Fri, 30 Aug 2002 10:33:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7UESdo01997; Fri, 30 Aug 2002 10:28:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7UERjo01958 for ; Fri, 30 Aug 2002 10:27:45 -0400 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18752 for ; Fri, 30 Aug 2002 10:26:11 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7UEQfYH013600; Fri, 30 Aug 2002 10:26:42 -0400 (EDT) Message-ID: <3D6F80A0.7040903@dynamicsoft.com> Date: Fri, 30 Aug 2002 10:26:40 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: Sanjoy Sen , "'Melinda Shore'" , "'Pete Cordell'" , "'midcom@ietf.org'" Subject: Re: [midcom] Moving SPAN along References: <2F1FC1DEA077D5119FAD00508BCFD6D203D62A7C@zsc3c030.us.nortel.com> 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-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Francois Audet wrote: > > > The problem is not the case when two clients are behind the same NAT. > > There are many ways to detect this, and once you know it, you can use > > your private addresses. > > Can you expand on the "many ways" to detect this? > > I can't think of any way that does not require that both end cooperate > on this > through some standardized mechanism. > Right, it does require a cooperation and standardized protocol. Using STUN between the endpoints is one way. You can use STUN a few different ways, in fact - sent to the private address, to the public address, etc. All of that is really outside the scope of STUN and probably midcom as well, since its a specific usage of STUn by a protocol like SIP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Fri Aug 30 12:46:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25012 for ; Fri, 30 Aug 2002 12:46:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7UGlRk10247 for midcom-archive@odin.ietf.org; Fri, 30 Aug 2002 12:47:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7UGjio10169; Fri, 30 Aug 2002 12:45:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7UGhvo10103 for ; Fri, 30 Aug 2002 12:43:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24878; Fri, 30 Aug 2002 12:42:21 -0400 (EDT) Message-Id: <200208301642.MAA24878@ietf.org> To: IETF-Announce: ; Cc: midcom@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 30 Aug 2002 12:42:20 -0400 Subject: [midcom] Last Call: STUN - Simple Traversal of UDP Through Network Address Translators to Proposed Standard Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Middlebox Communication Working Group to consider STUN - Simple Traversal of UDP Through Network Address Translators as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-9-13. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-02.txt _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From mailnull@www1.ietf.org Sat Aug 31 17:46:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13458 for ; Sat, 31 Aug 2002 17:46:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7VLlNb28073 for midcom-archive@odin.ietf.org; Sat, 31 Aug 2002 17:47:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7VLj4o27998; Sat, 31 Aug 2002 17:45:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7VLfYo27943 for ; Sat, 31 Aug 2002 17:41:34 -0400 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 RAA13271 for ; Sat, 31 Aug 2002 17:39:56 -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 g7VLevKB008828 for ; Sat, 31 Aug 2002 14:40:57 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id AEZ28280; Sat, 31 Aug 2002 14:36:59 -0700 (PDT) Message-Id: <200208312136.AEZ28280@mira-sjc5-4.cisco.com> To: midcom@ietf.org From: Melinda Shore Date: Sat, 31 Aug 2002 17:40:56 -0400 Subject: [midcom] NAT MIB draft Sender: midcom-admin@ietf.org Errors-To: midcom-admin@ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We (midcom) have been asked to take a look at the current draft of the NAT MIB, with an eye towards whether or not the overall approach is reasonable. It's draft-ietf-nat-natmib-04.txt. Thanks, Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom