Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt

[Fernando Gont <[e-mail]>]

Hello, Wes,

Thanks so much for your feedback. COmments in-line....


> Editorial:
> 
> - section 1, paragraph 3:
>   "IT accommodates" -> "it accommodates" ?

Fixed.



> - section 1, paragraph 3:
>   "using urgent the urgent" -> "using the urgent"

Thanks :-)




> - section 1, paragraph 4:
>   "how current TCP implementations" ->
>   "how some current TCP implementations"

"how some popular TCP implementations"? (i.e., yes, they are not
"all"... but we assessed Linux, BSD's, Cisco, MS...)



> - section 3.2, paragraph 1:
>   "never reflected into" -> "never was reflected in"

Fixed.



> Semi-Technical:
> 
> - section 2.3 - on the allowed length of urgent data, should this
>   mention that obviously there is a limitation due to the length
>   of a sequence number field?  You can't send a terabyte of urgent
>   data.

Well, you cannot send a terabyte of normal data, either. :-)

I see your point, though... Here we just mentioned what was there in RFC
1122...

I think the spirit of the text in RFC 1122 is that the mechanism (flag +
pointer) should not limit the amount of urgent data that you can send...
(although, as dicussed on the list some time ago, the concept of "urgent
data" is flawed. It's more of a "mark of an interesting point in the
data stream")



> - section 6:
>   I think it's not worded correctly when we say that applications
>   using the sockets API MUST set SO_OOBINLINE.  What we really
>   want to say is more like:
> 
>   "Even though applications SHOULD NOT employ the urgent mechanism,
>    applications that require the use of urgent data MUST set
>    SO_OOBINLINE."
> 
>   Right?  Apps that don't use urgent data shouldn't have to be
>   bothered by the fact that it's broken.

I fully agree. Thanks for catching this one!

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1