RE: WG last call: draft-ietf-behave-nat-udp-01.txt
Senthil Sivakumar (ssenthil <ssenthil <at> cisco.com>
2005-05-09 18:13:36 GMT
A lot of text in this
document is generic to both TCP and UDP but the applicability
states
"This document only
covers the UDP Unicast aspects of NAT traversal and does not cover TCP,
IPSEC, or other protocols. Since the document is for UDP only, packet
inspection below the UDP layer (including RTP) is also out-of-scope."
We felt this while writing the TCP behavior
draft where we had to refer to the UDP draft for generic issues. The
common requirements should be addressed in a seperate document, that will make
both the TCP and UDP requirements concise and should not be interleaved in this
UDP requirements draft.
Senthil
Hi Paul,
Thank you for your careful reading of the document.
I agree with all your comments and will make the changes
accordingly
unless there is opposition on the
list.
Cheers.
> -----Original Message-----
>
From: ietf-behave-bounces <at> list.sipfoundry.org
> [mailto:ietf-behave-bounces <at> list.sipfoundry.org]
On Behalf Of
> Paul Hoffman
> Sent: Monday, May 09, 2005 10:11
> To:
Jiri Kuthan; Ietf-behave <at> list.sipfoundry.org
>
Subject: Re: [Ietf-behave] WG last call:
>
draft-ietf-behave-nat-udp-01.txt
>
>
> At 2:10 AM +0200 4/26/05, Jiri Kuthan
wrote:
> >This is a BEHAVE Working Group Last Call
for comments
> >on draft-ietf-behave-nat-udp-01.
This last call closes
> >Tuesday May 12, 2005.
Please post any final comments you
> >have on this
draft to this list by that date.
>
> **Unnecessary specification of UDP**
>
> In a few sentences in the document, UDP is
mentioned as if it is the
> specific protocol being
discussed, but TCP could be equivalently
>
substituted in its place. These sentences should be made
> protocol-agnostic if they really are protocol-agnostic, which I
think
> the following are. (Of course, there are
still many UDP-specific
> sections in the
document!)
>
> 4.1, first
sentence, delete "UDP" because the same would be true for
> "TCP" and possibly other protocols.
>
> 4.3, first sentence, remove "UDP" because the
timers are very
> unlikely to be different than TCP
timers.
>
> 5.1, first
sentence, remove "UDP" because the same would be true for
> "TCP" and possibly other protocols.
>
> 7, first sentence, remove "UDP" because the same
would be true for
> "TCP" and possibly other
protocols.
>
> 9, first
sentence, remove "UDP" because the same would be true for
> "TCP" and possibly other protocols.
>
> 11, first two sentences, remove "UDP" because the
same would be true
> for "TCP" and possibly other
protocols.
>
>
> **Editorial**
>
> 1, fourth paragraph, remove "the" and change "off"
to "of":
> "...control off middle boxes..."
>
> 1, last paragraph, RTP and
other UDP-based protocols are said to run
> on top of
UDP, so change "below" to "above".
>
> 4.2.3, first paragraph, "glare" should be "glaring".
>
> 5.1, second bullet, replace
"...packets to Y..." with "packets to
> Y:any ..." to
make it parallel with the other usage in the section.
>
> 7, last paragraph, after "methods" add
"or protocols that try to be
> NAT-aware" to make it
more general.
>
> 9,
section title should be "ICMP Destination Unreachable Behavior"
> because that is the only type of ICMP behavior being discussed in
the
> section.
>
> 10, section title should be "Fragmentation of
Outgoing Packets" to
> emphasize that the entire
section is about packets flowing in one
>
direction.
>
> 10.1, end
of first paragraph, add ", or other reasons" because there
> are many reasons why the MTU is set higher on the NAT.
>
> 10.1, third and fourth
paragraph, "should" needs to be capitalized.
>
> 10.2, end of first paragraph, add "as specified in"
before "RFC 1812".
>
> 11,
first sentence, change "first or last" to "in any fragment"
> because there may be more than two fragments for the packet.
>
> 13, last paragraph, add "if
done incorrectly" after "...a DoS
> opportunity"
because many stacks correctly buffer fragments in a
>
manner that doesn't make them susceptible.
>
>
> --Paul Hoffman,
Director
> --Cybersecurity Association
>
_______________________________________________
>
Ietf-behave mailing list
>
Ietf-behave <at> list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>
>
<div>
<div dir="ltr" align="left"><span class="942490718-09052005">A lot of text in this
document is generic to both TCP and UDP but the applicability
states</span></div>
<div dir="ltr" align="left">
<span class="942490718-09052005"></span> </div>
<div dir="ltr" align="left"><span class="942490718-09052005">"This document only
covers the UDP Unicast aspects of NAT traversal and does not cover TCP,
IPSEC, or other protocols. Since the document is for UDP only, packet
inspection below the UDP layer (including RTP) is also out-of-scope."</span></div>
<div> </div>
<div><span class="942490718-09052005">We felt this while writing the TCP behavior
draft where we had to refer to the UDP draft for generic issues. The
common requirements should be addressed in a seperate document, that will make
both the TCP and UDP requirements concise and should not be interleaved in this
UDP requirements draft.</span></div>
<div>
<span class="942490718-09052005"></span> </div>
<div><span class="942490718-09052005">Senthil</span></div>
<div><br></div>
<div class="OutlookMessageHeader" lang="en-us" dir="ltr" align="left">
From: ietf-behave-bounces <at> list.sipfoundry.org
[mailto:ietf-behave-bounces <at> list.sipfoundry.org] On Behalf Of Francois
Audet<br>Sent: Monday, May 09, 2005 11:02 AM<br>To: 'Paul
Hoffman'; 'Jiri Kuthan'; 'Ietf-behave <at> list.sipfoundry.org'<br>Subject:
RE: [Ietf-behave] WG last call:
draft-ietf-behave-nat-udp-01.txt<br><br>
</div>
<div></div>
<p>Hi Paul, </p>
<p>Thank you for your careful reading of the document. </p>
<p>I agree with all your comments and will make the changes
accordingly <br>unless there is opposition on the
list. </p>
<p>Cheers. </p>
<p>> -----Original Message----- <br>>
From: ietf-behave-bounces <at> list.sipfoundry.org <br>> [<a href="mailto:ietf-behave-bounces <at> list.sipfoundry.org">mailto:ietf-behave-bounces <at> list.sipfoundry.org</a>]
On Behalf Of <br>> Paul Hoffman <br>> Sent: Monday, May 09, 2005 10:11 <br>> To:
Jiri Kuthan; Ietf-behave <at> list.sipfoundry.org <br>>
Subject: Re: [Ietf-behave] WG last call: <br>>
draft-ietf-behave-nat-udp-01.txt <br>> <br>> <br>> At 2:10 AM +0200 4/26/05, Jiri Kuthan
wrote: <br>> >This is a BEHAVE Working Group Last Call
for comments <br>> >on draft-ietf-behave-nat-udp-01.
This last call closes <br>> >Tuesday May 12, 2005.
Please post any final comments you <br>> >have on this
draft to this list by that date. <br>> <br>> **Unnecessary specification of UDP** <br>>
<br>> In a few sentences in the document, UDP is
mentioned as if it is the <br>> specific protocol being
discussed, but TCP could be equivalently <br>>
substituted in its place. These sentences should be made <br>> protocol-agnostic if they really are protocol-agnostic, which I
think <br>> the following are. (Of course, there are
still many UDP-specific <br>> sections in the
document!) <br>> <br>> 4.1, first
sentence, delete "UDP" because the same would be true for <br>> "TCP" and possibly other protocols. <br>>
<br>> 4.3, first sentence, remove "UDP" because the
timers are very <br>> unlikely to be different than TCP
timers. <br>> <br>> 5.1, first
sentence, remove "UDP" because the same would be true for <br>> "TCP" and possibly other protocols. <br>>
<br>> 7, first sentence, remove "UDP" because the same
would be true for <br>> "TCP" and possibly other
protocols. <br>> <br>> 9, first
sentence, remove "UDP" because the same would be true for <br>> "TCP" and possibly other protocols. <br>>
<br>> 11, first two sentences, remove "UDP" because the
same would be true <br>> for "TCP" and possibly other
protocols. <br>> <br>>
<br>> **Editorial** <br>>
<br>> 1, fourth paragraph, remove "the" and change "off"
to "of": <br>> "...control off middle boxes..."
<br>> <br>> 1, last paragraph, RTP and
other UDP-based protocols are said to run <br>> on top of
UDP, so change "below" to "above". <br>> <br>> 4.2.3, first paragraph, "glare" should be "glaring".
<br>> <br>> 5.1, second bullet, replace
"...packets to Y..." with "packets to <br>> Y:any ..." to
make it parallel with the other usage in the section. <br>> <br>> 7, last paragraph, after "methods" add
"or protocols that try to be <br>> NAT-aware" to make it
more general. <br>> <br>> 9,
section title should be "ICMP Destination Unreachable Behavior" <br>> because that is the only type of ICMP behavior being discussed in
the <br>> section. <br>>
<br>> 10, section title should be "Fragmentation of
Outgoing Packets" to <br>> emphasize that the entire
section is about packets flowing in one <br>>
direction. <br>> <br>> 10.1, end
of first paragraph, add ", or other reasons" because there <br>> are many reasons why the MTU is set higher on the NAT.
<br>> <br>> 10.1, third and fourth
paragraph, "should" needs to be capitalized. <br>>
<br>> 10.2, end of first paragraph, add "as specified in"
before "RFC 1812". <br>> <br>> 11,
first sentence, change "first or last" to "in any fragment" <br>> because there may be more than two fragments for the packet.
<br>> <br>> 13, last paragraph, add "if
done incorrectly" after "...a DoS <br>> opportunity"
because many stacks correctly buffer fragments in a <br>>
manner that doesn't make them susceptible. <br>>
<br>> <br>> --Paul Hoffman,
Director <br>> --Cybersecurity Association
<br>>
_______________________________________________ <br>>
Ietf-behave mailing list <br>>
Ietf-behave <at> list.sipfoundry.org <br>> <a href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" target="_blank">https://list.sipfoundry.org/mailman/listinfo/ietf-behave</a>
<br>> <br>> </p>
</div>
RSS Feed