Subject: [Sipping] voipeer agenda/charter uploaded

From: David Meyer <[email-masked]>
Date: Tue, 11 Oct 2005 11:06:44 -0700

Please see

	http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt

	Note that the bulk of our session will be devoted to
	hammering out our charter (charter bashing).

	Thanks,

	Dave
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Oct 2005 18:17:06 +0200

Thanks,
 
>(ii).   Regarding RFC 3263, several folks asked for a
>                document that outlines the *deployment issues*
>                (and perhaps BCPs) with 3263.
>
>        Does (ii). clarify the situation?

Yes and no. I personally considered 3263 sufficent, but on the other
hand, if I consider the discussions going on since one year within GSMA
to leave out the NAPTR and SRV records (the so-called 4-step approach)
because they fear that two additional DNS queries may prolong their mobile
call setup time of 15 seconds by 100 milliseconds ...

... a BCP may be helpful clarifying the issue ;-)
 
Richard

________________________________

Von: David Meyer [mailto:[email-masked]]
Gesendet: Mi 12.10.2005 17:50
An: Stastny Richard
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Enum] voipeer agenda/charter uploaded

On Wed, Oct 12, 2005 at 01:23:40AM +0200, Stastny Richard wrote:
> Congatulations, the charter seems quite well done on first reading

        Hey, thanks!

> first questions and remarks:
> 
> 1. The goals and milestones seem to be a bit out-of-order and confusing
> 
> 2. -Jan 07          Submit I-D on the use of DNS SRV and NAPTR
>     -Jan 07          Submit document to IESG on the use of DNS SRV and NAPTR
>                  records as specified by RFC 3263 (BCP)
>
> What is the reason for this I-D and what in addition to RFC 3263
> should be stated?

        (i).    The dates are clearly botched, thanks for
                pointing that out. I'll just mention that I'm
                expecting that we'll hammer out some realistic
                dates for the work-plan I've described. I put up
                what I believe is a pretty agressive (and
                possibly unrealistic), and I'm planning for us to
                have that discussion in Vancouver.

        (ii).   Regarding RFC 3263, several folks asked for a
                document that outlines the *deployment issues*
                (and perhaps BCPs) with 3263.

        I'll fix (i). above. Does (ii). clarify the situation?

        Thanks for the comments.

        Dave