Re: [RAI] comments on draft-peterson-rai-rfc3427bis-01.txt

[Jon Peterson <jon.peterson at neustar.biz>]

Now that the Last Call on rfc3427bis has concluded, I'm going through all LC
comments to prepare a revision. I know these notes were sent before our
discussions in SF, so some of this way have been clarified along the way. A
few notes inline below...

> A couple of comments on this.
> 
> Firstly, I still think its not very clear about what kind of work can be
> chartered in non-SIPCORE groups. The draft is clear about event
> packages, but nothing else. I think the draft is trying to classify SIP
> work into four buckets:
> 
> 1. updates/obsoletes of 3261-5
> 2. informational only headers
> 3. normal SIP extensions
> 4. event packages
> 
> So we know that:
> 
> 1-> SIPCORE
> 2-> designated expert review
> 3-> ???
> 4-> anywhere
> 
> I think its:
> 
> 3-> any ietf working group

That is the intention, yes, although it may be we need a more rigorous
definition of "normal SIP extensions". RFC3427bis is not the authoritative
location for all of the rules that define ways SIP can be extended (header
and URI parameters, for example).

> but that is not clear. For example, location-conveyance. Or sip-saml. I
> am presuming that, this kind of thing is in bucket 3.

Very much so.

> If my breakdown above is correct, I think it would be valuable to
> clearly define these four different types of work and make it clear
> about this third category.

I think we can add text to precisely that effect, certainly.
 
> I also found this part confusing:
> 
>> The DISPATCH working group chairs, in conjunction with the RAI Area
>>    Directors, will determine if the particular problems raised in the
>>    requirements Internet-Draft is indeed outside the charter of existing
>>    efforts, and if so, if it warrants a DISPATCH milestone for the
>>    definition of a new effort.
> 
> this seems to imply that we'll be defining dispatch milestones for
> delivery of requirements documents - I thought we are trying to avoid that.

This uses the words "definition of a new effort" pretty broadly. As we
discussed in the SF sessions, this could be anything from a problem
statement to a charter, but definitely excludes protocol development work.
Intuitively, I probably wouldn't want to say that requirements are
absolutely excluded from the problem definition.

> Later on the document says:
> 
>> With respect to standardization, this process means that SIP
>>    extensions come only from the IETF, the body that created SIP.  The
>>    IETF will not publish a SIP extension RFC outside of the processes
>>    described here.
> 
> this is confusing too. I think many people (myself included) view these
> 'informational headers' as 'extensions'. This text would then seem to
> contradict the rules later which allow designated expert registration of
> new headers.

That is a bit of legacy text there left over from RFC3427 that takes a
stronger position than now hold. That text should be qualified or removed
wholesale. Good catch.

> I think this is all cleaned up by having a clear definition of the whole
> suite of SIP 'extensions/enhancements'.

Right.

Thanks!

Jon Peterson
NeuStar, Inc.

> Thanks,
> Jonathan R.