Subject: Re: [secdir] SecDir review of draft-ietf-sipping-v6-transition-05

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Jul 2007 11:14:47 -0500

Tobias Gondrom wrote:
> Hello,
> 
> Sam Weiler informed me that this draft will be on telechat this week.
> 
> I did not receive any answer from the authors to my review of this 
> document as part of the security directorate review process, three 
> weeks ago.
> 
> Please consider my comments as formal COMMENTS in the IESG 
> evaluation.
> 
> And at the discretion of the AD: #2 and #4 could/should be seen as a
>  DISCUSS.

Tobias: Thanks for your time in reviewing the draft, and
apologies for not getting back to you earlier.  We did get your
original review dated June 28th, but with business travel and other
summer plans, it was a bit of a logistical problem to have the
authors sync up on addressing your review until recently.  As it
happens, I was about to send a reply to your review today.

Your first comment was related to a spelling error; that will
be fixed.

Your second comment was as follows:
> 2. section 4.3: I can not understand why this is a MAY and not at 
> least a SHOULD (or MUST): Once the answerer has generated an answer 
> following the ICE procedures, both user agents MAY perform the 
> connectivity checks specified by ICE.
> 
> Would recommend to use at least SHOULD instead of MAY in this 
> statement. Maybe good would even be a MUST???

We've decided to reword that sentence as shown below.  Because
we are mandating/recommending the use of ICE, we simply say do
what ICE wants you to do.

OLD:
    both user agents MAY perform the connectivity checks
    specified by ICE.

NEW:
    both user agents perform the connectivity checks as
    specified by ICE.

The third comments was:
> 3. section 7 security consideration:
> 
> This section refers to sec considerations in other documents, stating
>  that those cover threats and countermeasures adequately, namely 
> references [6], [7] and [2]
> 
> [2] is ok, but [6] and [7] are still work in progress, so it must be 
> especially taken care of by the WG chai7 12:17:22 -0400
Date: Mon, 16 Jul 2007 11:14:47 -0500
From: "Vijay K. Gurbani" <[email-masked]>
To: Tobias Gondrom <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked],
	[email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked]
Subject: Re: [secdir]  SecDir review of draft-ietf-sipping-v6-transition-05

Tobias Gondrom wrote:
> Hello,
> 
> Sam Weiler informed me that this draft will be on telechat this week.
> 
> I did not receive any answer from the authors to my review of this 
> document as part of the security directorate review process, three 
> weeks ago.
> 
> Please consider my comments as formal COMMENTS in the IESG 
> evaluation.
> 
> And at the discretion of the AD: #2 and #4 could/should be seen as a
>  DISCUSS.

Tobias: Thanks for your time in reviewing the draft, and
apologies for not getting back to you earlier.  We did get your
original review dated June 28th, but with business travel and other
summer plans, it was a bit of a logistical problem to have the
authors sync up on addressing your review until recently.  As it
happens, I was about to send a reply to your review today.

Your first comment was related to a spelling error; that will
be fixed.

Your second comment was as follows:
> 2. section 4.3: I can not understand why this is a MAY and not at 
> least a SHOULD (or MUST): Once the answerer has generated an answer 
> following the ICE procedures, both user agents MAY perform the 
> connectivity checks specified by ICE.
> 
> Would recommend to use at least SHOULD instead of MAY in this 
> statement. Maybe good would even be a MUST???

We've decided to reword that sentence as shown below.  Because
we are mandating/recommending the use of ICE, we simply say do
what ICE wants you to do.

OLD:
    both user agents MAY perform the connectivity checks
    specified by ICE.

NEW:
    both user agents perform the connectivity checks as
    specified by ICE.

The third comments was:
> 3. section 7 security consideration:
> 
> This section refers to sec considerations in other documents, stating
>  that those cover threats and countermeasures adequately, namely 
> references [6], [7] and [2]
> 
> [2] is ok, but [6] and [7] are still work in progress, so it must be 
> especially taken care of by the WG chai7 12:17:22 -0400
Date: Mon, 16 Jul 2007 11:14:47 -0500
From: "Vijay K. Gurbani" <[email-masked]>
To: Tobias Gondrom <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked],
	[email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked]
Subject: Re: [secdir]  SecDir review of draft-ietf-sipping-v6-transition-05

Tobias Gondrom wrote:
> Hello,
> 
> Sam Weiler informed me that this draft will be on telechat this week.
> 
> I did not receive any answer from the authors to my review of this 
> document as part of the security directorate review process, three 
> weeks ago.
> 
> Please consider my comments as formal COMMENTS in the IESG 
> evaluation.
> 
> And at the discretion of the AD: #2 and #4 could/should be seen as a
>  DISCUSS.

Tobias: Thanks for your time in reviewing the draft, and
apologies for not getting back to you earlier.  We did get your
original review dated June 28th, but with business travel and other
summer plans, it was a bit of a logistical problem to have the
authors sync up on addressing your review until recently.  As it
happens, I was about to send a reply to your review today.

Your first comment was related to a spelling error; that will
be fixed.

Your second comment was as follows:
> 2. section 4.3: I can not understand why this is a MAY and not at 
> least a SHOULD (or MUST): Once the answerer has generated an answer 
> following the ICE procedures, both user agents MAY perform the 
> connectivity checks specified by ICE.
> 
> Would recommend to use at least SHOULD instead of MAY in this 
> statement. Maybe good would even be a MUST???

We've decided to reword that sentence as shown below.  Because
we are mandating/recommending the use of ICE, we simply say do
what ICE wants you to do.

OLD:
    both user agents MAY perform the connectivity checks
    specified by ICE.

NEW:
    both user agents perform the connectivity checks as
    specified by ICE.

The third comments was:
> 3. section 7 security consideration:
> 
> This section refers to sec considerations in other documents, stating
>  that those cover threats and countermeasures adequately, namely 
> references [6], [7] and [2]
> 
> [2] is ok, but [6] and [7] are still work in progress, so it must be 
> especially taken care of by the WG chai7 12:17:22 -0400
Date: Mon, 16 Jul 2007 11:14:47 -0500
From: "Vijay K. Gurbani" <[email-masked]>
To: Tobias Gondrom <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked],
	[email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked]
Subject: Re: [secdir]  SecDir review of draft-ietf-sipping-v6-transition-05

Tobias Gondrom wrote:
> Hello,
> 
> Sam Weiler informed me that this draft will be on telechat this week.
> 
> I did not receive any answer from the authors to my review of this 
> document as part of the security directorate review process, three 
> weeks ago.
> 
> Please consider my comments as formal COMMENTS in the IESG 
> evaluation.
> 
> And at the discretion of the AD: #2 and #4 could/should be seen as a
>  DISCUSS.

Tobias: Thanks for your time in reviewing the draft, and
apologies for not getting back to you earlier.  We did get your
original review dated June 28th, but with business travel and other
summer plans, it was a bit of a logistical problem to have the
authors sync up on addressing your review until recently.  As it
happens, I was about to send a reply to your review today.

Your first comment was related to a spelling error; that will
be fixed.

Your second comment was as follows:
> 2. section 4.3: I can not understand why this is a MAY and not at 
> least a SHOULD (or MUST): Once the answerer has generated an answer 
> following the ICE procedures, both user agents MAY perform the 
> connectivity checks specified by ICE.
> 
> Would recommend to use at least SHOULD instead of MAY in this 
> statement. Maybe good would even be a MUST???

We've decided to reword that sentence as shown below.  Because
we are mandating/recommending the use of ICE, we simply say do
what ICE wants you to do.

OLD:
    both user agents MAY perform the connectivity checks
    specified by ICE.

NEW:
    both user agents perform the connectivity checks as
    specified by ICE.

The third comments was:
> 3. section 7 security consideration:
> 
> This section refers to sec considerations in other documents, stating
>  that those cover threats and countermeasures adequately, namely 
> references [6], [7] and [2]
> 
> [2] is ok, but [6] and [7] are still work in progress, so it must be 
> especially taken care of by the WG chairs that both documents really 
> fulfil this promise. With [7] this looks like near to fulfilment, but
>  [6] still is not complete in its Security considerations section and
>  must be improved in before LC to also keep up with the promise made 
> in this document.

[6] is the reference for STUN relay usage; yes, the v6-transition
draft will have to wait until the STUN relay usage draft has its
security consideration section flushed out in more detail.

And the last comment was:
> 4. section 7:
> 
> The section correctly informs about the risk that this draft
> 
> “they may make hosts more amenable to existing threats.  ”
> 
> And it provides an example afterwards. This is good.
> 
> But I would expect or at least suggest to also provide information
> about how this risen risk should be countered.

Fair enough; how about adding text along these lines:

OLD:
    Malicious user agents that may intercept the request
    can mount a denial of service attack targeted to the different
    network interfaces of the UAC.

NEW:
    Malicious user agents that may intercept the request
    can mount a denial of service attack targeted to the different
    network interfaces of the UAC.  In such a case, the UAC
    should use mechanisms that protects confidentiality and
    integrity, such as TLS [add reference] or S/MIME [add reference].
    If HTTP Digest is used as an authentication mechanism in
    SIP, then the UAC should ensure that the quality of protection
    also includes the SDP payload.

Please let us know if we were remiss in addressing any other
concern.  And once again, apologies for the late reply.

Best regards,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 16 Jul 2007 17:18:01 +0200

>  must be improved in before LC to also keep up with the promise made=20
> in this document.

And the last comment was:
>=20
>=20
> =93they may make hosts more amenable to existing threats.  =94
>=20
>=20

OLD:

NEW:

Best regards,

- vijay
--=20

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 16 Jul 2007 17:18:01 +0200

OLD:

NEW:

Best regards,

- vijay
--=20

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 16 Jul 2007 17:18:01 +0200

OLD:

NEW:

Best regards,

- vijay
--=20

---

From: "Tobias Gondrom" <[email-masked]>
Date: Mon, 16 Jul 2007 17:18:01 +0200

Hello, 

I did not receive any answer from the authors to my review of this document as part of the security directorate review process, three weeks ago. 

Please consider my comments as formal COMMENTS in the IESG evaluation. 

And at the discretion of the AD: #2 and #4 could/should be seen as a DISCUSS.

Best regards, Tobias

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Gondrom
Sent: Thursday, June 28, 2007 3:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [secdir] SecDir review of draft-ietf-sipping-v6-transition-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

My review has the following comments to the draft: 

1. One spelling error:

s/domain instead of of using the/ domain instead of using the

2. section 4.3: I can not understand why this is a MAY and not at least a SHOULD (or MUST): 

Once the answerer has generated an answer following the ICE 

procedures, both user agents MAY perform the connectivity checks

specified by ICE.

Would recommend to use at least SHOULD instead of MAY in this statement. 

Maybe good would even be a MUST???

This section refers to sec considerations in other documents, stating that those cover threats and countermeasures adequately, namely references [6], [7] and [2]

[2] is ok, but [6] and [7] are still work in progress, so it must be especially taken care of by the WG chairs that both documents really fulfil this promise. With [7] this looks like near to fulfilment, but [6] still is not complete in its Security considerations section and must be improved in before LC to also keep up with the promise made in this document. 

4. section 7: 

"they may make hosts more amenable to existing threats.  "

But I would expect or at least suggest to also provide information about how this risen risk should be countered. 

Best regards, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton

Hello, 

I did not receive any answer from the authors to my review of this document as part of the security directorate review process, three weeks ago. 

Please consider my comments as formal COMMENTS in the IESG evaluation. 

And at the discretion of the AD: #2 and #4 could/should be seen as a DISCUSS.

Best regards, Tobias

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Gondrom
Sent: Thursday, June 28, 2007 3:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [secdir] SecDir review of draft-ietf-sipping-v6-transition-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

My review has the following comments to the draft: 

1. One spelling error:

s/domain instead of of using the/ domain instead of using the

2. section 4.3: I can not understand why this is a MAY and not at least a SHOULD (or MUST): 

Once the answerer has generated an answer following the ICE 

procedures, both user agents MAY perform the connectivity checks

specified by ICE.

Would recommend to use at least SHOULD instead of MAY in this statement. 

Maybe good would even be a MUST???

This section refers to sec considerations in other documents, stating that those cover threats and countermeasures adequately, namely references [6], [7] and [2]

[2] is ok, but [6] and [7] are still work in progress, so it must be especially taken care of by the WG chairs that both documents really fulfil this promise. With [7] this looks like near to fulfilment, but [6] still is not complete in its Security considerations section and must be improved in before LC to also keep up with the promise made in this document. 

4. section 7: 

"they may make hosts more amenable to existing threats.  "

But I would expect or at least suggest to also provide information about how this risen risk should be countered. 

Best regards, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton

Hello, 

I did not receive any answer from the authors to my review of this document as part of the security directorate review process, three weeks ago. 

Please consider my comments as formal COMMENTS in the IESG evaluation. 

And at the discretion of the AD: #2 and #4 could/should be seen as a DISCUSS.

Best regards, Tobias

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Gondrom
Sent: Thursday, June 28, 2007 3:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [secdir] SecDir review of draft-ietf-sipping-v6-transition-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

My review has the following comments to the draft: 

1. One spelling error:

s/domain instead of of using the/ domain instead of using the

2. section 4.3: I can not understand why this is a MAY and not at least a SHOULD (or MUST): 

Once the answerer has generated an answer following the ICE 

procedures, both user agents MAY perform the connectivity checks

specified by ICE.

Would recommend to use at least SHOULD instead of MAY in this statement. 

Maybe good would even be a MUST???

This section refers to sec considerations in other documents, stating that those cover threats and countermeasures adequately, namely references [6], [7] and [2]

[2] is ok, but [6] and [7] are still work in progress, so it must be especially taken care of by the WG chairs that both documents really fulfil this promise. With [7] this looks like near to fulfilment, but [6] still is not complete in its Security considerations section and must be improved in before LC to also keep up with the promise made in this document. 

4. section 7: 

"they may make hosts more amenable to existing threats.  "

But I would expect or at least suggest to also provide information about how this risen risk should be countered. 

Best regards, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton

Hello, 

I did not receive any answer from the authors to my review of this document as part of the security directorate review process, three weeks ago. 

Please consider my comments as formal COMMENTS in the IESG evaluation. 

And at the discretion of the AD: #2 and #4 could/should be seen as a DISCUSS.

Best regards, Tobias

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Gondrom
Sent: Thursday, June 28, 2007 3:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [secdir] SecDir review of draft-ietf-sipping-v6-transition-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

My review has the following comments to the draft: 

1. One spelling error:

s/domain instead of of using the/ domain instead of using the

2. section 4.3: I can not understand why this is a MAY and not at least a SHOULD (or MUST): 

Once the answerer has generated an answer following the ICE 

procedures, both user agents MAY perform the connectivity checks

specified by ICE.

Would recommend to use at least SHOULD instead of MAY in this statement. 

Maybe good would even be a MUST???

This section refers to sec considerations in other documents, stating that those cover threats and countermeasures adequately, namely references [6], [7] and [2]

[2] is ok, but [6] and [7] are still work in progress, so it must be especially taken care of by the WG chairs that both documents really fulfil this promise. With [7] this looks like near to fulfilment, but [6] still is not complete in its Security considerations section and must be improved in before LC to also keep up with the promise made in this document. 

4. section 7: 

"they may make hosts more amenable to existing threats.  "

But I would expect or at least suggest to also provide information about how this risen risk should be countered. 

Best regards, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton

--===============1278767342= lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>And it provides an example afterwards. This is =
good.</span></font><span
lang=3DEN-GB> </span><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>But I would</span></font><span lang=3DEN-GB> </span><font =
size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>expect
or at least</span></font><span lang=3DEN-GB> </span><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>suggest to =
also provide
information about</span></font><span lang=3DEN-GB> </span><font size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>how this
risen risk</span></font><span lang=3DEN-GB> </span><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>should</span></font><span
lang=3DEN-GB> </span><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>be</span></font><span lang=3DEN-GB> =
</span><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>countered.
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>Best regards, Tobias</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><a name=3D""><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>_____________________________________=
_____</span></font></b></a><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Head of Open Text Security Team<br>
Director, Product Security<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Open Text =
Corporation</span></font></b><br>
<font color=3Dblack><span style=3D'color:black'>Technopark 2<br>
Werner-von-Siemens-Ring 20<br>
D-85630 Grasbrunn</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>Phone: +49 (0) 89 4629-1816<br>
Mobile: +49 (0) 173 5942987<br>
Telefax: +49 (0) 89 4629-33-1816<br>
eMail:</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</a><br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:</span></font></span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.opentext.com/">http://www.opentext.com/</a>&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D1 face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial'>Place
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift =
65,
63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 =
89 04
11 | Register Court / Registergericht: Offenbach, Germany | Trade =
Register
Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 169 819 | =
Managing
Director / Gesch=E4ftsf=FChrer: John =
Shackleton</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C7C7BC.81205259--

--===============1278767342= lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>And it provides an example afterwards. This is =
good.</span></font><span
lang=3DEN-GB> </span><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>But I would</span></font><span lang=3DEN-GB> </span><font =
size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>expect
or at least</span></font><span lang=3DEN-GB> </span><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>suggest to =
also provide
information about</span></font><span lang=3DEN-GB> </span><font size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>how this
risen risk</span></font><span lang=3DEN-GB> </span><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>should</span></font><span
lang=3DEN-GB> </span><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>be</span></font><span lang=3DEN-GB> =
</span><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>countered.
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>Best regards, Tobias</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><a name=3D""><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>_____________________________________=
_____</span></font></b></a><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Head of Open Text Security Team<br>
Director, Product Security<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Open Text =
Corporation</span></font></b><br>
<font color=3Dblack><span style=3D'color:black'>Technopark 2<br>
Werner-von-Siemens-Ring 20<br>
D-85630 Grasbrunn</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>Phone: +49 (0) 89 4629-1816<br>
Mobile: +49 (0) 173 5942987<br>
Telefax: +49 (0) 89 4629-33-1816<br>
eMail:</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</a><br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:</span></font></span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.opentext.com/">http://www.opentext.com/</a>&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D1 face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial'>Place
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift =
65,
63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 =
89 04
11 | Register Court / Registergericht: Offenbach, Germany | Trade =
Register
Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 169 819 | =
Managing
Director / Gesch=E4ftsf=FChrer: John =
Shackleton</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C7C7BC.81205259--

--===============1278767342= lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>And it provides an example afterwards. This is =
good.</span></font><span
lang=3DEN-GB> </span><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>But I would</span></font><span lang=3DEN-GB> </span><font =
size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>expect
or at least</span></font><span lang=3DEN-GB> </span><font size=3D2 =
face=3DArial><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>suggest to =
also provide
information about</span></font><span lang=3DEN-GB> </span><font size=3D2
face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>how this
risen risk</span></font><span lang=3DEN-GB> </span><font size=3D2 =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>should</span></font><span
lang=3DEN-GB> </span><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>be</span></font><span lang=3DEN-GB> =
</span><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>countered.
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
Arial'>Best regards, Tobias</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><a name=3D""><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>_____________________________________=
_____</span></font></b></a><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Head of Open Text Security Team<br>
Director, Product Security<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Open Text =
Corporation</span></font></b><br>
<font color=3Dblack><span style=3D'color:black'>Technopark 2<br>
Werner-von-Siemens-Ring 20<br>
D-85630 Grasbrunn</span></font><o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>Phone: +49 (0) 89 4629-1816<br>
Mobile: +49 (0) 173 5942987<br>
Telefax: +49 (0) 89 4629-33-1816<br>
eMail:</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</a><br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:</span></font></span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><a
href=3D"http://www.opentext.com/">http://www.opentext.com/</a>&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D1 face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial'>Place
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift =
65,
63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 =
89 04
11 | Register Court / Registergericht: Offenbach, Germany | Trade =
Register
Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 169 819 | =
Managing
Director / Gesch=E4ftsf=FChrer: John =
Shackleton</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C7C7BC.81205259--

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Jul 2007 08:11:35 -0500

Tobias Gondrom wrote:
> Hello Vijay,
> 
> thank you for your answer. 
> Your proposed changes resolve my comments. 

Tobias: Great.  Thanks for your review and follow-up.

> Please note that with the revised text for #4 you have introduced a new
> spelling error: 
> s/mechanisms that protects confidentiality/mechanisms that protect
> confidentiality

I will take care of this.

Regards,

- vijay

---

From: "Tobias Gondrom" <[email-masked]>
Date: Tue, 17 Jul 2007 11:47:03 +0200

Hello Vijay,

Best regards, 

Tobias

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Monday, July 16, 2007 6:15 PM
> To: Tobias Gondrom
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; vkg@alcatel-
> lucent.com

contents are
sufficient to identify IPFIX message boundaries, how/why
does SCTP's preservation of them matter to IPFIX
implementations?

Section 4.2:

   Although it is not explicitly mentioned in the protocol draft the
   order of Information Elements within the Template MAY be changed by
   Exporting or Collecting Processes for example for alignment purposes.

It looks like this allows a single Collecting implementation
(multiple Collecting Processes) to receive information from
multiple Exporting Processes using the same template but with
different ordering of information sent by each Exporting Process.
If that is correct, it would be good to advise implementers of
this possibility and suggest that a single normalized order of
stored information for each template be used in a Collecting
implementation to avoid confusion if/when this happens -
somewhere in Section 5 would be an appropriate location
for this advice.

Section 6.1:

   There is an additional service provided by SCTP and useful in
   conjunction with PR-SCTP: unordered delivery.  This also works on a
   per-message basis by declaring that a given message should be
   delivered at the receiver as soon as it is received rather than kept
   in sequence; however, it should be noted that unless explicitly
   requested by the sender even messages sent partially reliably will
   still be delivered in order.

[1] Isn't this likely to cause problems when messages are
processed out of order?  If three messages are sent containing
absolute counts of 45, 87, and 138, out of order processing
combined with a delay to the first message could result in the
count being 45 at the recipient after the three messages are
processed, which seems rather wrong.  Whose responsibility
is it to prevent this?  In contrast, partial reliability skips
updates that would be generated by processing the dropped
messages, and hence seems ok.

   o  Increase the bandwidth of the links through which the Data Records
      are exported.

Both instances of this should be rephrased to:

   o  Increase the bandwidth available for communicating the exported
      Data Records.

There are a number of scenarios in which link bandwidth
increases do not benefit all flows on a link.

Section 6.2: UDP

[2] I don't see any discussion of congestion control in here.
Something needs to be done to avoid a high rate IPFIX protocol
session over UDP worsening a congestion situation because not
only is the IPFIX flow non-responsive to congestion, but
congested conditions may increase the volume of IPFIX data
to be reported.  At the very least, this draft should repeat
and reinforce the discussion in Section 10.3.1 of
draft-ietf-ipfix-protocol-24.txt, which says that UDP should
not be used over congestion sensitive network paths - I'm not
thrilled about that approach, but the ipfix-protocol draft
is already in the RFC Editor Queue.  A general recommendation
against UDP when TCP or SCTP is possible may be appropriate,
and the first item in Section 10.1 is related to this concern,
as it requires availability of a congestion-controlled protocol.

The possibility of Exporter vs. Collector misconfiguration
on template resend interval vs. template expiry time is
unfortunate and (as described) can cause interoperability
issues.  Can IPFIX define a template for an Exporter to
report its resend interval?  That would enable a Collector
to determine an appropriate expiry time for each Exporter,
and might obviate the need for the packet-count-based
resend mechanism discussion.

   Before using a Template for the first time, the Exporter may send it
   in several different IPFIX messages in quick succession to increase
   the likelihood that the Collector has received the Template.

That's exactly the wrong thing to do if there's a congested
tail-drop queue in the path, as it increases the likelihood of
all of the messages being dropped.  It's better to space these
out over some period of time to avoid a transient congestion
spike causing all the copies of the template to be lost.

Section 7.1:

The text describing each of Figures 1-4 should provide an
example of a middlebox or two that has the function shown
in the Figure.

Section 7.3:

   Only in the case of composed middleboxes with well defined and well
   separated internal middlebox functions, for example a combined NAT
   and firewall, MAY an Observation Point be inside a middlebox, but in
   any case it SHOULD be located in between the middlebox functions.

That's a poor use of "MAY".  Here's a suggestion for
replacement text:

   If an Observation Point is located inside a middlebox, the middlebox
   MUST have well defined and well separated internal functions,
   for example a combined NAT and firewall, and the Observation Point
   SHOULD be located on a boundary between middlebox functions rather
   than within one of the functions.

Section 7.4:

   Still, if possible, IPFIX implementations co-located with uncovered
   middleboxes (i.e. of type 7 or 11 - 20) MAY follow the
   recommendations given in this section if they can be applied in a way
   that reflects the intention of these recommendations.

I would change "MAY" to "should" (lower-case), as I think
the intent is to make a recommendation, but one that
does not rise to the strength of an RFC 2119 "SHOULD".

Section 8.2:

[3] This appears to only reference X.509 for certificates.  That's
not interoperable, and there's no X.509 reference in the list
of references.  An appropriate reference to RFC 3280 will
correct these issues.

--- Nits ---

Section 3.4:
PSAMP acronym needs expansion or definition before it is used.

Section 4.4:

   At first, reporting the running total may seem to be the obvious
   choice, but requires that the system accurately maintains the flow
   over a long time without any loss or error,

"maintains the flow" -> "maintains information about the flow"

   Delta counters offer some advantages: flows don't have to be
   permanently maintained,

"flows" --> "information about flows"

   Note that delta counters have an origin of zero, and that a
   Collecting Process receiving delta counters for a new flow must
   assume the deltas are from zero.

"new flow" --> "flow that is new to the Collecting Process"

Section 4.5.2 and 4.5.3

Both sections talk about a "limited" need for alignment without
providing justification.  They would be clearer if they only asserted
that the 32-bit alignment that always occurs is sufficient.

Section 7.1/7.2: 

Figure 4 should be after the Section 7.2 heading, if possible.

idnits 2.04.12 found a couple of minor reference nits:

  == Unused Reference: 'RFC2434' is defined on line 1516, but no
explicit
     reference was found in the text

  == Outdated reference: A later version (-12) exists of
     draft-ietf-ipfix-as-11

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Tobias Gondrom" <[email-masked]>
Date: Tue, 17 Jul 2007 11:47:03 +0200

Hello Vijay,

Best regards, 

Tobias