Subject: [sipcore] RFC3265bis: reason code registration policy

From: Adam Roach <[email-masked]>
Date: Thu, 12 Apr 2012 12:19:40 -0500

[as document author]

As you probably know, RFC3265bis has been handed off to the IESG for 
pre-publication evaluation.

Section 7.2 of the RFC3265bis document discusses the new IANA registry 
for the "reason" code. The gen-art review of this document turned up the 
following discrepancy:

  * 'Following the policies outlined in "Guidelines for Writing an IANA
    Considerations Section in RFCs" [RFC5226], new reason codes require
    a Standards Action.'

  * ' Insertion of such values takes place as part of the RFC
    publication process or as the result of inter-SDO liaison activity.'

The problem is that the "Standards Action" requirement is defined: 
"Values are assigned only for Standards Track RFCs approved by the 
IESG," which implies that inter-SDO liaising isn't sufficient for adding 
values.

I can't find any relic of this issue being discussed on the mailing 
list, and have no specific recollection how we arrived at the current 
text. Keep in mind that the need to expand these reason codes should be 
very slight (we've only had one in nine years since 3265 was published), 
and will almost certainly be paired with protocol changes that RFC 5727 
would require an RFC for anyway.

Based on those two factors (and especially the second one), I think what 
we probably want to do is remove the phrase "of as the result of 
inter-SDO liaison activity," and leave the policy "Standards Action" as 
currently stated.

Please raise any objections to this proposed course of action on the 
SIPCORE mailing list. I will make sure the results of any on-list 
discussion are brought to the attention of the IESG.

/a

---

From: Adam Roach - SIPCORE Chair <[email-masked]>
Date: Mon, 30 Apr 2012 14:28:43 -0500

[as chair]

Lacking any feedback on this topic, the document has been revised 
according to IESG feedback. The new text appears in section 7.2 of 
draft-ietf-sipcore-rfc3265bis-09:

    Registrations with the IANA include the reason code being registered
    and a reference to a published document which describes the event
    package.  Insertion of such values takes place as part of the RFC
    publication process or as the result of inter-SDO liaison activity,
    the result of which will be publication of an associated RFC.  New
    reason codes must conform to the syntax of the ABNF "token" element
    defined in [RFC3261].

At this point, any objections to the text should be brought to the 
attention of the SIPCORE chairs and our RAI AD (presently Robert Sparks).

Thank you.

/a

On 4/12/12 12:19 PM, Adam Roach wrote:
> for the "reason" code. The gen-art review of this document turned up 
> the following discrepancy:
>
> IESG," which implies that inter-SDO liaising isn't sufficient for 
> adding values.
>
> text. Keep in mind that the need to expand these reason codes should 
> be very slight (we've only had one in nine years since 3265 was 
> published), and will almost certainly be paired with protocol changes 
> that RFC 5727 would require an RFC for anyway.
>
> Based on those two factors (and especially the second one), I think 
> what we probably want to do is remove the phrase "of as the result of 
> inter-SDO liaison activity," and leave the policy "Standards Action" 
> as currently stated.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore