On 10/18/2011 10:36 AM, Gorry Fairhurst wrote:
In most cases you replied OK - so I'm assuming the draft will be updated
to reflect this and my comments will have been addressed.
Thanks Gorry. I've submitted 09 now which I think should address all the
issues you raised. If you like, see the diff at
You raised a few specific questions:
On 11/10/2011 18:36, Stig Venaas wrote:
>> a few retransmissions would be OK, "several" seems better.
> OK, but isn't it usually 3 or so?
> a few retransmissions would be OK, "several" seems better.
"OK, but isn't it usually 3 or so?"
GF - No it's not. The TCP RTO backs off each TO, and stops when this
exceeds 64 secs. It can be a while...
"The issue is what IP addresses to use in the pseudo header. We could
say they should be the same as the addresses for the PORT connection
(but that is problematic since they may be of a different address
familty), or the addresses you would have used for the native PIM
message (this is better, but doesn't make much sense really). However,
what do you think of saying that they should be 0 when calculating the
Since the message is sent inside a TCP connection (which has its own
checksum), it is almost redundant. At least I don't think including
the addresses in the checksum are all that useful, since there is no
danger of a single PIM message ending up at the wrong host (due to
the TCP checks).
I'll ask the WG about this too, but wondering if you have any
concerns with just setting them to 0."
GF - I think this would be fine, IMHO zeroed addresses with checksum is
much better than no checksum.
"It is defined that critical option means that the entire message must be
ignored if unknown. For non-critical, only the option is ignored. When
defining future options the doc/RFC must specify what type it is. They
would know what is the right thing to do."
GF - This sounds fine, if it actually say this in the IANA section, I'd
have ignored this.
GF - If the IPv6-IPv4 comments have been considered and don't seem to be
an issue by you after thinking this through, then I'd assume this is not
Hope this helps,
Ietf mailing list