Comments on draft-peterson-rai-rfc3427bis-02.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

"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.

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.

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?




_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]