Hi, Bernard,
I had some comments on your comments (below):
----- Original Message -----
From: Bernard Aboba
To: ietf(_at_)ietf(_dot_)org
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 itbe 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 ADshave the ability to specify
a successor to SIPCORE with respect to theabove responsibilities. That would
allow a new WG to take on theseresponsibilities 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 handledby
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>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf