----- Original Message -----
Sent: Saturday, August 08, 2009 12:16
PM
Subject: Comments on
draft-peterson-rai-rfc3427bis-02.txt
Section 2.1
"All SIP extensions considered in SIPCORE must be standards track."
Is this statement will really necessary in this document, or would it
be better suited for inclusion in the SIPCORE WG charter?
<Spencer> I agree that this seems to tie hands more tightly than is necessary. WG charter revisions are certainly reviewed as much as anything else we publish. </Spencer>
"Typical IETF working groups do not live forever; SIPCORE's charter is
however open-ended in order to allow it to remain the place where
core SIP development will continue. In the event that the SIPCORE
working group has closed and no suitable replacement or follow-on
working group is active (and this specification also has not been
superseded), then when modifications to the core SIP protocol are
proposed the RAI Area Directors will the use the non-working group
standards track document process (described in Section 6.1.2 of RFC
2026 [RFC2026]) using the SIPCORE mailing list and designated experts
from the SIP community for review. The IETF will remain the home of
extensions of SIP and the rest of this document. The rate of growth
of extensions of any protocol in the IETF is hoped to be low."
It would be helpful for this paragraph to explicitly state that the ADs
have the ability to specify a successor to SIPCORE with respect to the
above responsibilities. That would allow a new WG to take on these
responsibilities without requiring a revision to RFC3427bis.
<Spencer> It seems somewhat insane for the RAI ADs to shut down SIPCORE with no successor, but I don't see any reason NOT to provide the flexibility that Bernard suggests here. </Spencer>
While it does not have the traditional deliverables of
a working group, DISPATCH may at the discretion of its chairs adopt
milestones such as the production of charter text for a BoF or
working group,
Is this really at the discretion of the chairs of DISPATCH?
Typically, production of charter text for a BoF or WG is handled
by the chairs of that BoF or WG, not some other WG.
<Spencer> OK, I was reading this text from RFC 2418 to say that DISPATCH milestone adoption should be at the discretion of the DISPATCH chairs and the responsible AD, right?
2.2. Charter
The formation of a working group requires a charter which is
primarily negotiated between a prospective working group Chair and
the relevant Area Director(s), although final approval is made by the
IESG with advice from the Internet Architecture Board (IAB). A
charter is a contract between a working group and the IETF to perform
a set of tasks.
So, I was reading the rfc3427bis text to say that DISPATCH might add a milestone to its OWN charter to develop charter text for a BOF or another working group, which would then go through normal charter revision review. Jon/Robert/Cullen, could you confirm that?
</Spencer>
Instead, the registration of SIP headers in Informational IETF
specifications, or in documents outside the IETF, is now permitted
under the Designated Expert (per RFC5226) criteria.
Good idea.
Note that the deprecation of the "P-" header process does not alter
processes for the registration of SIP methods, URI parameters,
response codes, or option tags.
Do all option tags really need to be standards track?
<Spencer> Please tell me whether I'm getting this right or not, but my understanding is that we need option tags to indicate support for an extension that, if that support isn't present, should cause an operation to fail, right?
If I've gotten that right, I think the answer should be "no" - and I know Bernard's question was also asked by Alan Johnston in http://www.ietf.org/mail-archive/web/ietf/current/msg56223.html, raising concerns about the lack of a discovery mechanism for extensions that aren't standards-track.
</Spencer>