Subject: [Int-area] Conclusion: Joe vs draft-savola-mtufrag-network-tunneling-04.txt

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Oct 2005 13:17:06 +0300 (EEST)

On Fri, 23 Sep 2005, Joe Touch wrote:
>> which changes you'd like to see so I'll just have to ask "send text" and
>> I'll check it out.
>
> IMO, the major doc focus issues are more important and need to be
> resolved before it would be useful to contribute text, since the latter
> assumes that such pointwise patches would be productive, and I don't yet
> see that.

Ok, I think your main argument against the current structure is:

   Documenting existing practice and pointing out the violation as a
   side-issue isn't acceptable to me because it ends up
   meaning that this doc is a snapshot of current practice, which I
   don't think is appropriate for an RFC. IMO, the RFC should make a
   statement that this is either OK and the spec should be changed or
   that it's not OK and the implementations should be fixed.

I do not think this is an appropriate as a blocking reason for a 
document, but everyone is entitles to an opinion. If that didn't 
capture your objection well enough, I'd encourage you to write a short 
summary, so that other folks can judge by themselves.

As for the document, I'm shipping off -05 with the small mods I've 
made based on your (and others') input and we'll see how it turns out.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Oct 2005 11:15:52 -0700

Pekka Savola wrote:
> document

I-D aren't on a default path to RFC that is 'blocked'.

They're on a default path to disappear in 6 months; there needs to be a
*reason* to move to RFC.

There have been cases where there are significant reasons to snapshot
existing practice, so I'm not saying that "no RFCs are just ephemeral
snapshots". But the bar ought to be high, and I think that most of the
key points in this doc, except the fact that people break specs in ways
that we're not intending to endorse, have been made in other docs.
That's why I think the other reasons ought to apply (change the spec or
denounce the practice).

So, yes, this is my position. And yes, it's one person's opinion.

I hope others will consider whether and why this doc should move
forward, not whether it should not, however.

Joe