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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to