Subject: [edu-team] Fw: Gen-ART Review of draft-ietf-sip-rfc3312-update-03.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Oct 2004 06:38:04 -0500

I know Avri (and others) have seen this, but re: editor training - as 
a Gen-ART reviewer, I'm trying to push back on "this document updates 
these other documents in mysterious ways, so if we were you, we'd read 
all of them carefully" because It Does Not Scale, but it's really not 
fair for editors to hear this during IESG review of their documents 
for the first time.

Is this something Avri is comfortable with mentioning in Editor 
Training?

My attached e-mail chain illustrates the usual chain of events 
(Spencer asks, editor or WG chair says "you may be right, but we were 
hoping we were through", AD says "not worth another cycle").

If someone gave editors a hint about this, we might not end up with (I 
believe the final count was) 50 or so RFCs that addressed some aspect 
of TCP but were not included in "the TCP standard" - see TCPM for 
details...

Spencer

----- Original Message ----- 
From: "Allison Mankin" <[email-masked]>
To: "Gonzalo Camarillo" <[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; 
<[email-masked]>; "Paul Kyzivat" <[email-masked]>
Sent: Thursday, October 28, 2004 11:42 AM
Subject: Re: Gen-ART Review of draft-ietf-sip-rfc3312-update-03.txt

> Gonzalo, Spencer,
>
> I also thank Spencer for the comments...however, when the IESG
> saw both the review and the document, they thought that it was
> reasonable to leave the document in its current state of 
> readability.
>
> We agreed to put some words in the abstract and info (via
> an RFC Editor Note) making it clearer that the doc updates 3312 -
> to call it out righty up front.  We can take Spencer's suggestion 
> and
> add a sentence or two with a thumbnail on what is added by this
> document, which I can insert in the intro, using an RFC Editor Note.
> Gonzalo, will you write and send this asap?
>
> I can make a few of the editorial fixes from Spencer's comments
> in the RFC Editor Notes too.
>
> I'll send authors and Spencer the proposed RFC Editor Notes.
>
> Once I have the RFC Editor Notes in place, the document is approved.
>
> Thanks again,
>
> Allison
>
>>
>> Spencer,
>>
>> thanks for your comments. I would like to ask Allison for advice on
>> this. We have two possibilities:
>>
>> 1) This document specifies an update to RFC 3312, as it currently 
>> does,
>> and I introduce all the clarifications requested by Spencer.
>>
>> 2) I go thru the copy/paste exercise of creating a new RFC that
>> substitutes completely RFC 3312 and has a new section explaining 
>> the
>> diffs with RFC 3312.
>>
>> I am leaning towards 1), because there are a lot of existing
>> implementations of RFC 3312 (every single 3GPP and 3GPP2 IMS call 
>> flow
>> is based on this RFC) and I believe an update would be easier to
>> implement by them.
>>
>> In any case, I admit that new implementers would find 2) easier...
>>
>> Allison?
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>>
>> Spencer Dawkins wrote:
>>
>> > I'm reviewing this document as a Working Group submission for 
>> > Proposed
>> > Standard.
>> >
>> > Please take this as a compliment - I think most of the problems 
>> > with
>> > this document stem from having very knowledgeable authors who 
>> > forget how
>> > little some of us know about SIP! I'd say "headed the right 
>> > direction,
>> > but considerable work is needed before publishing".
>> >
>> > Overall - I'm wondering why we're doing this document as an 
>> > update to
>> > RFC 3312, instead of as a replacement for RFC 3312. We really 
>> > aren't
>> > very good at saying what a standard is, and if a standard can 
>> > reasonably
>> > be published as a single document, instead of as a set of 
>> > documents
>> > published over time, I'd prefer to see that. We ended up with an 
>> > entire
>> > working group chartered to figure out what TCP really is, and I'm 
>> > sure
>> > we'll see more SIP documents in the next 23 years than we've seen
>> > published on TCP in the last 23 years (since RFC 793).
>> >
>> > If there's a good reason for publishing an update (and not 
>> > something
>> > silly like "we want to republish as a draft standard and don't 
>> > want to
>> > reset our clock"), there should at least be a summary section 
>> > that says
>> > "these are the things we changed". It is possible to figure this 
>> > out by
>> > reading the entire document, but that means people may be reading 
>> > a
>> > document that doesn't affect them, and they can't figure out that 
>> > they
>> > don't need to read it until they finish it :-(
>> >
>> > Section 3.4 - "In general, the called user is not alterted until 
>> > the
>> > preconditions are met" - "alterted" is typoed, but that's a nit. 
>> > I'd
>> > really like to understand why this isn't "is never alerted 
>> > until" - is
>> > this always true, but that's not what the draft says? Is there a
>> > well-known case where called users ARE alerted before the 
>> > preconditions
>> > are met? (If there is, should we change the spec for 
>> > consistency?)
>> >
>> > second paragraph in 3.4 - "Still" isn't needed and is confusing.
>> >
>> > third paragraph in 3.4, and following - this section is way too
>> > confusing - at the minimum, the indented text should be NEW text,
>> > reflecting the updated concept, because indentation draws the 
>> > reader's
>> > eyes to the old text that is no longer completely true!
>> >
>> > Section 4 - s/oft/of/, but that's a nit. Paragraphs three and 
>> > four seem
>> > to say "the specification has been misleading up to this point, 
>> > so now
>> > we'll tell you what we should have said in the first place".
>> >
>> > Section 5 - the end of the fourth paragraph explains that moving 
>> > a media
>> > stream is like setting it up in the first place, from a 
>> > precondition
>> > point of view. This statement should appear a LOT higher in 
>> > section 4,
>> > because it is key to understanding what's going on.
>> >
>> > sixth paragraph in 4.1 - I THINK s/answer/answerer/, but might be
>> > confused. The following table doesn't seem to be required (some 
>> > ideas
>> > really justify prose).
>> >
>> > Section 6 - "no IANA considerations", but preconditions ARE 
>> > registered
>> > by IANA (as pointed out in 3.1). I think this is saying "3312 had 
>> > IANA
>> > considerations, but the parts that we're changing don't" - I'd 
>> > still
>> > like to see this draft contain all of 3312...
>> >
>> > Extremely minor nit throughout - reference identifiers are 
>> > attached to a
>> > lot of occurrences, not just the first one. RFC 3312 is tagged as 
>> > [3]
>> > about twelve times.
>>
>> 

_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 29 Oct 2004 08:59:53 -0700

Hi again. We decided on the last EDU telechat that I'm going to do 
the Editor's Training this time around. I revised many of Avri's 
slides, including the one you're referring to. The slide now reads:

Relationship to other RFCs
- The IETF has a spotty record with RFCs that "update", "revise", or 
"obsolete" other RFCs
- That is all the more reason to be clear in every RFC what other 
RFCs are related, and how they are related
- Check with your ADs early on this: other WGs might be updating the same RFC

--Paul Hoffman, Director
--VPN Consortium