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

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Aug 2009 10:16:59 -0700

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?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 10 Aug 2009 10:39:24 -0500

Hi, Bernard,

I had some comments on your comments (below):
  ----- Original Message ----- 
  From: Bernard Aboba 
  To: [email-masked] 
  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>

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Aug 2009 18:00:37 -0500

Bernard Aboba wrote:
> Do all [SIP] option tags really need to be standards track? 
>   

I would argue that they do. Option tags define normative extensions to 
the core SIP protocol. The prospect of defining a SIP protocol extension 
in, say, an informational or historical document seems rather 
ill-advised. Even an experimental document is probably the wrong place 
to put extensions to core SIP protocol handling.

I would feel even more uneasy about allowing non-IETF documents to 
define option tags: the types of extensions that would necessitate an 
options tag usually add enough semantics to the protocol that it would 
be foolish to condone their creation without IESG review.

/a