I'm just watching out for the poor Gen-ART reviewer who gets
the last
document in this string...
- Is it the intention that the ICMP document UPDATEs the UDP
document, in
the RFC Editor sense of the word?
- Is it the intention that the TCP document updates the ICMP
document?
Given that the UDP draft is in the RFC Editor Queue, and the
ICMP and TCP
documents are not even assigned to a shepherding AD in the
tracker yet, your
best path forward really may be to issue UDP, UPDATE it with
ICMP, and refer
to ICMP for the ICMP requirements supporting TCP... assuming
that the TCP
draft doesn't pass the ICMP draft in the chute.
This does tend to make our archival document series denser
and less
implementer-friendly, but sometimes "good enough"
is the best we can do.
If I got this hand grenade over the review transom, I'd
definitely be asking
this at IETF Last Call time, and probably at IESG Telechat
time as well, so
thinking about this now is probably better than thinking
about it some other
times...
Thanks,
Spencer
>I full agree with Fernando. I do believe, all normative
requirements
>related to
> ICMP should be in the ICMP document and not spread
across multiple
> documents.
> Repeating in multiple drafts in different words is
prone to language
> interpretation problems. I also believe, a NAT MUST
rewrite the payload.
>
> As for the requirement in UDP draft (soon to be an RFC)
- During the WG
> last
> call when this issue was brought up, folks wanted to
leave the requirement
> in
> there so the publication is not delayed (I dont recall
discussig the
> SHOULD vs
> MUST for the requirement, however.).
>
> This exception for the UDP draft is understandable.
However, the
> requirement
> shoudlnt have to be repeated in the TCP draft. TCP
draft could simply
> refer the
> requirement in the ICMP draft rather than list as a
distinct TCP
> requirement.
>
> My 2c.
>
> regards,
> suresh
>
> --- Fernando Gont <fernando gont.com.ar> wrote:
>
>> At 19:45 24/10/2006, Saikat Guha wrote:
>>
>> >TCP currently aligns itself with ICMP/MUST
because receiving the ICMP
>> >messages and being able to link them to the
actual connection is
>> >essential for path MTU discovery.
>> >
>> > From my reading of the documents, the
requirements in ICMP/TCP and UDP
>> >are in conflict.
>> >
>> >Is there any particular UDP has a SHOULD and
not a MUST? If so, should
>> >the recommendation be narrowed only to UDP
payloads inside ICMP packets?
>>
>> As a meta comment, I'd suggest that all the
ICMP-related stuff be
>> included only in the ICMP document, rather than
spread it over three
>> documents (ICMP, TCP, and UDP).
>>
>> As for whether to rewrite the ICMP payload is a
MUST or SHOULD, I'd
>> vote for the "MUST".
>>
>> Whether one likes it or not, ICMP is a signalling
protocol that is
>> part of the TCP/IP suite. You cannot just NAT the
transport protocol,
>> but kill the protocol that aids in signalling error
conditions.
>>
>> If anybody wants to get rid of ICMP, the one should
get rid of it for
>> "non-NATed" traffic, and only then the
NAT-related specs should follow.
>>
>> Just my two cents,
_______________________________________________
Ietf-behave mailing list
Ietf-behave list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
|