Re: Requirements for INFO work

Keith,

I can see why you would send this out, but IMO the status is not as far 
in the weeds as you seem to think.

AFAIK the only real scope creep that has come up is around multiple info 
packages per INFO. And I think we have all largely agreed to exclude that.

There has been a lot of discussion of how the negotiation of packages 
works, but that is intrinsic to what we are doing. And once you agree 
that you must negotiate this (which I think we did) then renegotiation 
must be addressed.

The rest of the discussion has been on clarifying ambiguities, and so is 
a good thing.

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
> (As WG chair)
> 
> I believe that the original starting point for INFO was to regularise
> the existing position with INFO usage, and that the decision we made to
> charter this work was based on developing a more valid basis for meeting
> the existing INFO requirements. I believe previous discussion related
> around overriding such constraints as:
> 
> 1)	identification of INFO usages to the remote entity so that both
> could agree that INFO was in use for the same purpose
> 
> 2)	registration of usages so that there could be some
> interoperability between two INFO usages from different vendors.
> 
> (I am not trying to create a complete list here and now)
> 
> Much of the discussion seems to be now on "We have this new capability
> so it must now be capable of doing these things as well". I do not
> believe many of these things were possible with legacy INFO usage.
> 
> If we are not careful, I would think that the SIP chairs are going to
> have to insist on a requirements phase to make sure we have a robust and
> complete set of requirements before proceeding further. Too many
> previous SIP deliverables have been derailed because we get to the end
> of the work, and then find we don't understand why we were doing the
> work in the first place.
> 
> I would direct that the editors start compiling a list of what they
> consider this work is meant to do, in terms independent of the actual
> implementation, as this discussion proceeds, and we will embed that in
> the document at some time. Treat this as the requirements list we are
> trying to work to. Moreover, if we have the need to add or amend that
> list, we will do a consensus call on that change. 
> 
> If in the review of the document by the working group - we find
> something that is not in the requirements, and the document would be
> simpler by not doing it, then we will take it out. That should be
> stimulation enough for making sure we keep this list up to date.
> 
> Regards
> 
> Keith
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip