Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational

[Fred Baker <fred@cisco.com>]

No, I'm not trying to say "we're not going to do anything with the  
feedback". I *am*, however, saying that feedback needs to be timely,  
and given all the delays built into the system (one of which is me)  
and the number of times that the working group (which you are a part  
of) has been asked for comment, sending small comments in immediately  
after I *finally* send the document off to the IESG is *really*late*,  
and expecting the authors and the working group to spin on a dime to  
fix them isn't very realistic. If you want to discuss delays in  
process in detail, I would suggest you take Jim Bound or Yannick  
Pouffary aside and ask them what they really think about that silly  
chair of the v6ops WG delaying things every time just to get the  
document right...

We'll pick these comments up if the IESG asks for a revision.

As to my comment on the Hop Limit, I did read the document. It  
states, in several places, that the recommendation is that the Hop  
Limit be set to 255 and tested for still being 255 on receipt. What I  
stated was that I would go at it a different way. If the packet is  
sent with Hop Limit = 1, it cannot pass a compliant router or  
firewall, so there is no need to test for whether it did or didn't.  
My way is, I think, more robust - it depends only on the sender, not  
the sender and the receiver. But you note that I didn't require a  
change to suit my fancy either.

On Jun 13, 2006, at 4:12 PM, Iljitsch van Beijnum wrote:

> On 14-jun-2006, at 0:48, Fred Baker wrote:
>
> > Let's see. How long have you had to review this, and when did the  
> > WGLC close? Remind me?
>
> I didn't read the document until a week ago or so when Pekka linked  
> to it on the IETF list and asked for comments.
>
> > There will not be an IETF Last Call, as this is an informational  
> > document. If there were, I would encourage you to make the comment  
> > in response to the IETF last call. If the ADs send the document  
> > back for a new I-D for some reason, I will expect the authors to  
> > respond to this. I'm not going to hold it up for this, though. The  
> > document makes rather a point that there is significant value to  
> > ICMP filtering, so I can't imagine the comment really being  
> > interpreted as a reason to not filter.
>
> No, why would we point out to people that our protocols are clever  
> enough to not require any filtering? Or use the same name for the  
> same field in different documents? That's way too much trouble with  
> all those RFCs we have to write that no one in operations reads  
> anyway because they're too long and too hard to read, and which are  
> too hard to find out that they exist in the first place.
>
> The fact that you talked about TTL=1 while claiming to have  
> reviewed the document proves several of these points. Refusal to  
> make changes proves a few more.
>
> I know running a standards organization based 90% on volunteer  
> effort is hard, but producing sub-par documents is not part of the  
> solution.
>
> The IETF seems fundamentally incapable of doing things fast, so  
> getting things right is all the more important.
>
> Last but not least: is "don't bother reviewing documents as we're  
> going to ignore feedback" really the message you want to send? As  
> soon as someone pays me to do IETF work I promise I'll get in my  
> comments before last calls expire. Until that time, other work will  
> have to take precedence.