Subject: Last Call & Consensus

From: Bob Mahoney <[email-masked]>
Date: Fri, 22 Feb 2002 17:50:00 -0500

All-

Pat and I have been observing the list traffic, and following the 
various threads.  It is our conclusion that the WG has not yet 
reached consensus on some key points, and so the draft is not yet 
ready for last call.  Considering the significant movement and change 
in the last few months, our hope for a last-call by Minneapolis was 
probably too optimistic.

Our goal now is to gather what consensus changes we have together for 
an -07 version of the draft, so that we can get it submitted by the 
deadline next Friday (3/1/02), and available for discussion in 
Minneapolis.

To refresh for those who may not be familiar, the end point of this 
process looks like:

1) The WG enters a (somewhat informal) last-call period, which serves 
as a second-to-last review before this document will be considered by 
the IESG.  If the chairs can detect sufficient consensus on the 
issues, and the document is as mature and correct as we can make it, 
it is forwarded to the Area Directors with our request that it 
advance.

2) The ADs/IESG announce the formal last-call period on the 
ietf-announce list, and the document gets a "final review by the 
general Internet community".  Be aware that significant 
feedback/objections are not unknown.

3) Only after the IESG feels that any objections raised in last-call 
have been satisfied, can the document be considered for review as a 
Proposed Standard.

(For details of the whole process, see: http://www.ietf.org/rfc/rfc2026.txt )

The point to take away from this reminder is that our work will have 
serious review by the entire community.   We need to be confident we 
have done a complete and correct design before we expose our work to 
judgement.  We are close, and have come far, but we're not yet 
finished.

We hope that the recent energetic review on the list will continue, 
and that the document will continue to mature rapidly.

-Bob & Pat

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Feb 2002 16:46:56 -0700

I think we have reached consensus on (not that the proposed
text is bug free or needs tweaking) - but I think we agree on:

    o VCAR	- latest proposal

    o VQUERY	- latest proposal

    o shorter commands	- latest proposal w/tweaks from WG.

    o Using SEQUENCE, LOCAL, and ENABLE to tag local only VALARMS.
      See thread: (#1) synchronization part 2, and identifying a
                       components VALARM

    o CALID url - latest proposal.

    o Review process. - latest proposal

    o Overlap booking - no change - latest proposal.

    o How to identify who sent the COUNTER - use Franks proposal.

    o CALMASTER - change "MUST BE" to "SHOULD BE" a mailto url.

    o TRANSP - no change.
   
    o Synchronization - omit this from CAP - to complex for now.

    o RELCALID - globally unique - no.

    o RELATED-TO to replace CHILD/PARENT

And I think that covers the major issues.

Open:

    Do we use text/calendar or application/???-xml

And the draft needs cleaned up as Bruce has pointed out
with the examples and the various proposals were sent
by N people and there will need to be an editing session
to clean it up.