[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Agenda and Package for July 10, 2003 Telechat (First Draft)




        INTERNET ENGINEERING STEERING GROUP (IESG)
      Agenda for the July 10, 2003 IESG Teleconference
                                                                                
1. Administrivia
                                                                                
  o Roll Call

Dear IESG Members:

The next IESG teleconference will take place on Thursday, June 26, 2003 
from 11:30-14:00 US-ET.  If you are *unable* to participate in the 
teleconference, or if you wish to change your usual procedures for 
connecting to the call (as indicated in the list below), then please reply 
to this message as follows:

o If you are unable to participate, then please write "Regrets" after your 
name.
o If you normally call in, but will require operator assistance for this 
teleconference, then please provide the telephone number where you can be 
reached.
o If you are normally connected to the teleconference by an operator, but 
will call in for this teleconference, then please write "Will call in" next 
to your name in place of the telephone number.

Harald Alvestrand---Will call in
Rob Austein---Will call in
Marcia Beaulieu---Will call in
Steve Bellovin---Will call in
Randy Bush---Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Dinara Suleymanova---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in
Ted Hardie---Will call in
Jacqueline Hargest---Regrets
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten---Will call in
Erik Nordmark---Call at +33 4 76 99 84 29
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Bert Wijnen---Regrets
Alex Zinin---Will call in

To join the teleconference, please call the appropriate dial-in number (see 
below) at 11:30 AM ET.  If you have requested operator assistance, then an 
operator will call you and connect you to the call.

Participants inside the U.S. should use the toll-free number 888-315-1685.

Participants outside the U.S. should use either one of the toll-free 
numbers listed at the end of this message, or the direct-dial number 
703-788-0617.  Participants using the direct-dial number will pay their own 
long distance charges through their own carriers.  Participants dialing the 
toll-free number will not pay any charges for the conference as all 
charges, including long distance, will be included on the invoice sent to 
the company hosting the call.  In some cases, participants from certain 
international countries may only use a direct-dial number.

All participant should enter the passcode 235467 when prompted to do so.

The first person on the call will not hear anything until joined by other 
participants.  A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS

ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726

PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE THE DIRECT DIAL NUMBER AND 
THUS INCUR CHARGES FROM THEIR OWN CARRIER.



  o Bash the Agenda











  o Approval of the Minutes
    - June 26, 2003
  o Review of Action Items
OUTSTANDING TASKS
	Last updated: June 20, 2003
	
IP  	o Allison to review draft-agrawal-sip-h323-interworking-reqs
      	  and send decision to IESG.
IP  	o Erik to document process of how the IESG goes about asking architectural
      	  questions of the IAB
IP  	o Thomas to write (or cause to be written) a draft on "how to get to Draft".
IP  	o Thomas to contact Cablelabs to discuss formal relationship with IAB
IP  	o Allison and Thomas will email Secretariat note to send to RFC Editor
      	  about 3GPP RFC Editor documents.
IP  	o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP  	o Steve to write RFC re: TCP MD5 option
IP  	o Randy and Ned to finish ID on Clarifying when Standards Track Documents may
      	  Refer Normatively to Documents at a Lower Level
IP  	o Alex to send proposal and justification for interim document review.
IP  	o Steve to generate a summary of IESG views of the "problem"
IP  	o Steve to propose a different document classification than the current
      	  info/proposed/etc.
IP      o Next Steps in Signaling (nsis)
          Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
          to send a WG Review Announcement with copy to new-work@ietf.org.
IP	o Harald Alvestrand to talk to RFC Editor about independent submissions.
IP	o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB 
	  on PPVPN issue. Alex to summarize the results as a proposed IESG consensus 
	  regarding the PPVPN issue to be given to the PPVPN working group. 
IP	o Secretariat to include teleconference bridge/call-in details in telechat 
	  packages going forward.

                                                                                
2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-dnsext-gss-tsig-06.txt
    GSS Algorithm for TSIG (GSS-TSIG) (Proposed Standard) 
    Token: Nordmark, Erik
    Note: Need to get re-approved by the IESG. 05 was removed from the 
    rfc-editor's queue after IESG approval due to a conflict with TSIG 
    which has been resolved in 06.. 
  o draft-katz-yeung-ospf-traffic-10.txt
    Traffic Engineering Extensions to OSPF Version 2 (Proposed Standard) 
    Token: Fenner, Bill
    Note: Last Call sent per Alex Zinin's request 
  o draft-ietf-atommib-atm2-19.txt
    Definitions of Supplemental Managed Objects for ATM Interface (Proposed 
    Standard) 
    Token: Nordmark, Erik
    Note: Please put on the IESG agenda. 
  o draft-ietf-policy-qos-device-info-model-10.txt
    Information Model for Describing Network Device QoS Datapath Mechanisms 
    (Proposed Standard) 
    Token: Wijnen, Bert
    Note: On IESG agenda for July 10th. Responsible: Bert 
  o draft-ietf-policy-qos-info-model-05.txt
    Policy QoS Information Model (Proposed Standard) 
    Token: Wijnen, Bert
    Note: On IESG Agenda for July 10th. Responsible: Bert Wijnen 
  o draft-ietf-sip-sctp-03.txt
    The Stream Control Transmission Protocol as a Transport for for the 
    Session Initiation Protocol (Proposed Standard) 
    Token: Mankin, Allison
  o draft-ietf-ips-fcip-slp-07.txt
    Finding FCIP Entities Using SLPv2 (Proposed Standard) 
    Token: Mankin, Allison
    Note: SLP details were expert-reviewed (mediated by Thomas Narten) 
  - draft-ietf-ips-iscsi-slp-06.txt 
Finding iSCSI Targets and Name Servers Using SLP (Proposed Standard) 
  o draft-ietf-sipping-3pcc-04.txt
    Best Current Practices for Third Party Call Control in the Session 
    Initiation Protocol (BCP) 
    Token: Mankin, Allison
  o draft-ietf-dnsext-rfc1886bis-03.txt
    DNS Extensions to support IP version 6 (Draft Standard) 
    Token: Nordmark, Erik
    Note: Please put on agenda. 
  o draft-ietf-ospf-hitless-restart-07.txt
    Graceful OSPF Restart (Proposed Standard) 
    Token: Zinin, Alex
  o draft-ietf-webdav-ordering-protocol-09.txt
    WebDAV Ordered Collections Protocol (Proposed Standard) 
    Token: Hardie, Ted
  o draft-ietf-avt-rtcp-report-extns-06.txt
    RTP Control Protocol Extended Reports (RTCP XR) (Proposed Standard) 
    Token: Mankin, Allison

2.1.2 Returning Item
  o draft-ietf-dnsext-ad-is-secure-06.txt
    Redefinition of DNS AD bit (Proposed Standard) 
    Token: Nordmark, Erik
    Note: Version 06 seems to satisfy discusses. Check if this. is the 
    case. 
  o draft-ietf-enum-rfc2916bis-06.txt
    The E.164 to URI DDDS Application (ENUM) (Proposed Standard) 
    Token: Mankin, Allison
    Note: Liaison statement was sent to SG-2 about Last Call. 
  o draft-ietf-sip-scvrtdisco-04.txt
    Session Initiation Protocol Extension Header Field for Service Route 
    Discovery During Registration (Proposed Standard) 
    Token: Mankin, Allison
    Note: Returning document on agenda to have SMB review security Discuss 
    and Ted review Discuss by Patrik - minor issue of unclear schematics.  
    Revision cycles were slow. 
  o draft-ietf-magma-mld-source-07.txt
    Source Address Selection for Multicast Listener Discovery Protocol (RFC 
    2710) (Proposed Standard) 
    Token: Nordmark, Erik
    Note: Document has been updated to address concerns from Thomas and 
    Russ. 
  o draft-ietf-dnsext-unknown-rrs-06.txt
    Handling of Unknown DNS Resource Record Types (Proposed Standard) 
    Token: Nordmark, Erik
    Note: 06 has replaced IANA considerations with. "no 
    considerations". 


2.2 Individual Submissions
2.2.1 New Item
 NONE
2.2.2 Returning Item
  o draft-legg-ldapext-component-matching-11.txt
    LDAP & X.500 Component Matching Rules (Proposed Standard) 
    Token: Hardie, Ted
    Note: Depending on Subentry Specification for LDAP. 



3. Document Actions

3.1 WG Submissions
3.1.1 New Item
  o draft-ietf-gsmp-reqs-06.txt
    Requirements For Adding Optical Support To GSMPv3 (Informational) 
    Token: Wijnen, Bert
    Note: Responsible: Bert Wijnen 
  o draft-ietf-sipping-3gpp-r5-requirements-00.txt
    3rd-Generation Partnership Project (3GPP) Release 5 requirements on the 
    Session Initiation Protocol (SIP) (Informational) 
    Token: Mankin, Allison
    Note: On agenda with a proposed IESG Note clarifying that this 
    requirements discussion with 3GPP was a give-and-take, and that not 
    every requirement in this document is met. 
  o draft-ietf-manet-tbrpf-09.txt
    Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) 
    (Experimental) 
    Token: Zinin, Alex

3.1.2 Returning Item
  o draft-ietf-ippm-owdp-reqs-06.txt
    A One-way Active Measurement Protocol Requirements (Informational) 
    Token: Mankin, Allison
    Note: Returning document.  Important as guides main protocol of WG.  
    Now has strong mandatory to implement security and supports timestamp 
    encryption - on agenda  for SMB to check against his pseudo-discuss.. 
  o draft-ietf-manet-olsr-11.txt
    Optimized Link State Routing Protocol (Experimental) 
    Token: Zinin, Alex


3.2 Indiviual Submissions Via AD
3.2.1 New Item
  o draft-siemborski-mupdate-04.txt
    The MUPDATE Distributed Mailbox Database Protocol (Experimental) 
    Token: Freed, Ned
    Note: On IESG agenda 

3.2.2 Returning Item
 NONE

3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
  o draft-sun-handle-system-11.txt
    Handle System Overview (Informational) 
    Token: Hardie, Ted
    Note: It is suggested that these go forward with the following. IESG 
    Note attached (originally drafted by Patrik): IESG NOTE: The IETF and 
    IRTF have discussed the Handle system in the realm of URI-related 
    work. The IESG wishes to point out that there is no IETF 
    consensus on the current Handle system nor on where it fits in the 
    IETF architecture. The IESG is of the view that the Handle 
    system would be able to, with very small changes, fit into the IETF 
    architecture as a URN namespace. These documents, however, 
    contain information on the Handle system without these changes. 
  o draft-sun-handle-system-protocol-05.txt
    Handle System Protocol (ver 2.1) Specification (Informational) 
    Token: Hardie, Ted
    Note: It is suggested that these go forward with the following. IESG 
    Note attached (originally drafted by Patrik): IESG NOTE: The IETF and 
    IRTF have discussed the Handle system in the realm of URI-related 
    work. The IESG wishes to point out that there is no IETF 
    consensus on the current Handle system nor on where it fits in the 
    IETF architecture. The IESG is of the view that the Handle 
    system would be able to, with very small changes, fit into the IETF 
    architecture as a URN namespace. These documents, however, 
    contain information on the Handle system without these changes. 
  o draft-sun-handle-system-def-08.txt
    Handle System Namespace and Service Definition (Informational) 
    Token: Hardie, Ted
    Note: It is suggested that these go forward with the following. IESG 
    Note attached (originally drafted by Patrik): IESG NOTE: The IETF and 
    IRTF have discussed the Handle system in the realm of URI-related 
    work.  The IESG wishes to point out that there is no IETF 
    consensus on the current Handle system nor on where it fits in the 
    IETF architecture.  The IESG is of the view that the Handle 
    system would be able to, with very small changes, fit into the IETF 
    architecture as a URN namespace. These documents, however, 
    contain information on the Handle system without these changes. 

3.3.2 Returning Item
  o draft-bradner-pbk-frame-06.txt
    A Framework for Purpose-Built Keys (PBK) (Informational) 
    Token: Bellovin, Steve
  o draft-leech-chinese-lottery-04.txt
    Chinese Lottery Cryptanalysis Revisited: The Internet as Codebreaking 
    Tool (Informational) 
    Token: Bellovin, Steve




4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
    NONE
4.1.2 Proposed for Approval
    NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
    NONE
4.2.2 Proposed for Approval
    NONE

5. Working Group News We Can Use

                                                                                
6. IAB News We Can Use
                                                                                
7. Management Issues

DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Minutes of the June 26, 2003 IESG Teleconference

Reported by: Dinara Suleymanova, IETF Secretariat
                                                                                
ATTENDEES
------------------

Harald Alvestrand / Cisco
Rob Austein / IAB Liaison 
Marcia Beaulieu / IETF Secretariat
Randy Bush / IIJ
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Erik Nordmark / Sun
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Dinara Suleymanova / IETF Secretariat
Alex Zinin / Alcatel

REGRETS
------------
Michelle Cotton / ICANN
Jacqueline Hargest / IETF Secretariat
Bert Wijnen / Lucent

MINUTES
---------------

1. The minutes of the June 12, 2003 Teleconference were approved pending the removal of 
   Microsoft characters. The Secretariat will place the minutes in the public archives.

2. Review of Action Items


DONE:
o	Allison and Thomas will email Secretariat note to send to RFC Editor about 3GPP 
	RFC Editor documents.
o	Ned to write an IESG note for draft-tegen-smqp (Informational)
o	Allison Mankin to submit a Revised Charter for the Next Steps in Signaling WG 
	(nsis) to the Secretariat. Secretariat to send a WG Review Announcement with copy
	to new-work@ietf.org.
o	Secretariat to include teleconference bridge/call-in details in teleconference
	packages going forward.

DELETED:
o    Steve to generate a summary of IESG views of the "problem"

OUTSTANDING:
IP	o Allison to review draft-agrawal-sip-h323-interworking-reqs and send
	decision to IESG.
IP	o Erik to document process of how the IESG goes about asking architectural
	questions of the IAB
IP  	o Thomas to write (or cause to be written) a draft on "how to get to Draft".
IP  	o Thomas to contact Cablelabs to discuss formal relationship with IAB
IP  	o Steve to write RFC re: TCP MD5 option
IP  	o Randy and Ned to finish ID on Clarifying when Standards Track Documents
	may Refer Normatively to Documents at a Lower Level
IP	o Alex to send proposal and justification for interim document review.
IP  	o Steve to propose a different document classification than the current
	info/proposed/etc.
IP	o Harald Alvestrand to talk to RFC Editor about independent submissions.
IP	o Alex Zinin to phrase a question to RTG and OPS Area Directorates and IAB
	on PPVPN issue. Alex to summarize the results as a proposed IESG
	consensus regarding the PPVPN issue to be given to the PPVPN working
	group. 
                                                                                
NEW :
o	Thomas Narten to coordinate and send comments on minutes to the Secretariat. IESG
	to review the format of the minutes and propose changes to improve readability and 
   	communication to the outside world. 
o	Steve Bellovin to make proposal to discuss "problem" at the Sunday IESG meeting 
   	in Vienna.
o	Thomas Narten to writeup issue with references in draft-dasilva-l2tp-relaysvc-06.txt
	and start discussion in IESG list. 

2. Protocol Actions 
	2.1 WG Submissions 
		2.1.1 New Item  - 1 of 3 

		o draft-ietf-enum-rfc2916bis-06.txt
 	  	The E.164 to URI DDDS Application (ENUM) (Proposed Standard) 
   		Token: Mankin, Allison
	
		The document was deferred to the next teleconference by 
   		Harald Alvestrand. The document remains under discussion by the IESG
		in order to resolve points raised by Ted Hardie.


 		o draft-ietf-mmusic-sdp-new-13.txt - 2 of 3
    		SDP: Session Description Protocol (Proposed Standard) 
    		Token: Peterson, Jon

		The document remains under discussion by the IESG in order to resolve points
		raised by Steve Bellovin, Bill Fenner, Ned Freed, Ted Hardie and Russ Housley.

 		o draft-ietf-avt-mpeg4-simple-07.txt - 3 of 3
    		RTP Payload Format for Transport of MPEG-4 Elementary Streams (Proposed 
    		Standard) 
    		Token: Mankin, Allison

		The document remains under discussion by the IESG in order to resolve points 
		raised by Steve Bellovin. 

2. Protocol Actions 
	2.1 WG Submissions 
		2.1.2 Returning Item  - 1 of 3 
  		o draft-ietf-avt-srtp-08.txt
    		The Secure Real-time Transport Protocol (Proposed Standard) 
    		Token: Mankin, Allison

		The document remains under discussion by the IESG in order to resolve points
		raised by Russ Housley.

  		o draft-ietf-sipping-overlap-04.txt - 2 of 3
    		Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to
		the Session Initiation Protocol (Proposed Standard) 
    		Token: Mankin, Allison

		The document was approved by the IESG. 
		The Secretariat will send a Protocol Action Announcement.

		o draft-ietf-ccamp-lmp.txt - 3 of 3
		Link Management Protocol (LMP).
		Token: Zinin, Alex

		The document was added to the agenda by Alex Zinin and remains under
		discussion by the IESG in order to resolve points raised by Steve Bellovin, 
		Ted Hardie, Thomas Narten and Russ Housley.

2. Protocol Actions 
	2.2 Individual Submissions 
		2.2.1 New Item  - 1 of 1 
  		o draft-legg-ldapext-component-matching-10.txt
   		 LDAP & X.500 Component Matching Rules (Proposed Standard) 
    		Token: Hardie, Ted

		The document was deferred to the next teleconference by Harald Alvestrand 
		and Bill Fenner.
 
		2.2.2 Returning Item  - NONE
  		    	
3. Document Actions 
	3.1 WG Submissions 
		3.1.1 New Item  
  		o draft-ietf-speechsc-reqts-04.txt - 1 of 7
    		Requirements for Distributed Control of ASR, SI/SV and TTS Resources 
   		(Informational) 
    		Token: Peterson, Jon

		The document remains under discussion by the IESG. A revised I-D is needed. 

 		o draft-ietf-nsis-req-08.txt - 2 of 7
    		Requirements for Signaling Protocols (Informational) 
    		Token: Mankin, Allison
    		Note: Extensive review with WG and editor.  Document was revised to meet
		deadline of 6/26 agenda. 
 
		The document remains under discussion by the IESG. A revised I-D is needed

 		o draft-ietf-mpls-ldp-restart-applic-01.txt - 3 of 7
   		Applicability Statement for Restart Mechanisms for the Label 
    		Distribution Protocol (Informational) 
    		Token: Zinin, Alex
    		Note: Responsible: WG chairs 
 
		The document was approved by the IESG. 
		The Secretariat will send a Document Action Announcement.
 
  		o draft-ietf-manet-olsr-10.txt - 4 of 7
    		Optimized Link State Routing Protocol (Experimental) 
    		Token: Zinin, Alex

		The document remains under discussion by the IESG. 

  		o draft-ietf-rmt-bb-fec-supp-compact-01.txt - 5 of 7
    		Compact Forward Error Correction (FEC) Schemes (Experimental) 
   		Token: Mankin, Allison

 		The document was approved by the IESG pending an RFC Editor Note regarding
		IANA considerations to be prepared by Thomas Narten and Allison Mankin.  
		The Secretariat will send a Document Action Announcement that includes the 
		RFC Editor Note. 

  		o draft-ietf-crisp-requirements-05.txt - 6 of 7
    		Cross Registry Internet Service Protocol (CRISP) Requirements (Informational) 
    		Token: Freed, Ned
    		Note: Asked to be added to IESG agenda 
 
		The document remains under discussion by the IESG. 

3. Document Actions 
	3.1 WG Submissions 
		3.1.1 New Item  - 
  		o draft-ietf-v6ops-unman-scenarios-02.txt - 7of 7
    		Unmanaged Networks IPv6 Transition Scenarios (Informational) 
    		Token: Bush, Randy

		Ted Hardie and Allison Mankin will send comments to the IESG on this 
		document. 

3. Document Actions 
	3.1 WG Submissions 
		3.1.2 Returning Item  
  		o draft-ietf-multi6-multihoming-requirements-07.txt - 1 of 3
    		Goals for IPv6 Site-Multihoming Architectures (Informational) 
    		Token: Bush, Randy

		The document was approved by the IESG. 
		The Secretariat will send a Document Action Announcement.
 
  		o draft-ietf-nsis-qos-requirements-01.txt - 2 of 3
    		Requirements of a QoS Solution for Mobile IP (Informational) 
   		Token: Mankin, Allison
    		Note: This document is a renaming of  
		draft-ietf-mobileip-qos-requirements-03.txt (expired). That document was
		reviewed by IESG already and was given a go, except for lacking a Security
		Consideration section, which it now has (2003-06-19). 

		The document was approved by the IESG. 
		The Secretariat will send a Document Action Announcement.
  
 		o draft-ietf-ccamp-tracereq-05.txt - 3 of 3
    		Tracing Requirements for Generic Tunnels (Informational) 
    		Token: Wijnen, Bert
    		Note: Approved by IESG

		The document was approved by the IESG pending confirmation from Alex Zinin 
		that Randy Bush approves. Upon notification from Alex Zinin, the Secretariat will 
		send a Document Action Announcement. 

3. Document Actions 
	3.2 Indiviual Submissions Via AD 
		3.2.1 New Item  
  		o draft-lear-tftp-uri-06.txt - 1 of 1
   		URI Scheme for the TFTP Protocol (Informational) 
    		Token: Hardie, Ted

		The document was approved by the IESG pending an RFC Editor Note to be 
		prepared by Ted  Hardie. 
		The Secretariat will send a Document Action Announcement that includes 
		the RFC Editor Note.

3.2.2 Returning Item
 		NONE

3. Document Actions 
	3.3 Indiviual Submissions Via RFC Editor 
		3.3.1 New Item  
 		 o draft-paskin-doi-uri-03.txt - 1 of 4
   		The 'doi' URI Scheme for Digital Object Identifier (DOI) (Informational) 
   		Token: Hardie, Ted

		The IESG recommends that the RFC Editor does not publish this document. 
		The Secretariat will send a Do Not Publish note to the RFC Editor. 

  		o draft-foster-mgcp-bulkaudits-09.txt - 2 of 4
    		The Media Gateway Control Protocol (MGCP) Bulk Audit Package
		(Informational) 
    		Token: Peterson, Jon

		The IESG has no problem with the RFC Editor publishing this document. 
		Jon Peterson will prepare a "no problem" message, and forward it to 
		the Secretariat to send to the RFC Editor.
 
  		o draft-eastlake-xxx-06.txt - 3 of 4
   		.sex Considered Dangerous (Informational) 
   		Token: Alvestrand, Harald

		The IESG has no problem with the RFC Editor publishing this document. 
		The Secretariat will send a standard "no problem" message to the RFC Editor.

		o draft-baker-slem-architecture-01.txt - 4 of 4
    		Cisco Support for Lawful Intercept In IP Networks (Informational) 
    		Token: Alvestrand, Harald
 
		The document was assigned to Steve Bellovin. 
		The Secretariat will update the ID-Tracker.


3.3.2 Returning Item
 		NONE

4. Working Group Actions
	4.1 WG Creation
		4.1.1 Proposed for IETF Review
    		NONE

		
		4.1.2 Proposed for Approval 
 		o Layer 2 Virtual Private Networks - 1 of 3
    		Token: Thomas

		Thomas Narten and Alex Zinin will send a message to the IETF mailing list
		regarding the formation of the two working groups: Layer 2 Virtual Private
		Networks and  Layer 3 Virtual Private Networks.  
		Both working groups were approved by the IESG. However, the Secretariat will
		not send the WG Action Announcements until it receives the go-ahead 
		from Alex Zinin.

  		o Layer 3 Virtual Private Networks - 2 of 3
   		Token: Thomas

		See decision under Layer 2 Virtual Private Networks


	4.1.2 Proposed for Approval - 3 of 3
  		o Path Maximum Transmission Unit Discovery
		Token: Allison

		Allison Mankin will provide a revised charter to the IESG for review. 
		The Secretariat will send a WG Action Announcement when Allison Mankin 
		confirms that the IESG has approved the new charter.

4. Working Group Actions
	4.2 WG Rechartering
		4.2.1 Under evaluation for IETF Review
    		NONE

		4.2.2 Proposed for Approval
    		NONE

5. Working Group News We Can Use
                                                                             
6. IAB News We Can Use
                                                                             
7. Management Issues

o  Issues on L2TP Active Discovery Relay for PPPoE - added by Thomas Narten
   (discussed)

o Issues on "problem" group - added by Harald Alvestrand
    (discussed)








To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-katz-yeung-ospf-traffic - Traffic
	 Engineering Extensions to OSPF Version 2 to Proposed Standard
--------

Last Call to expire on: 2002-12-26

	Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain  


Harald Alvestrand   [   ]     [   ]       [   ]      [   ] 
Steve Bellovin      [   ]     [ X ]       [   ]      [   ] 
Randy Bush          [   ]     [ X ]       [   ]      [   ] 
Bill Fenner         [ X ]     [   ]       [   ]      [   ] 
Ned Freed           [   ]     [ X ]       [   ]      [   ] 
Ted Hardie          [   ]     [ X ]       [   ]      [   ] 
Russ Housley        [   ]     [ X ]       [   ]      [   ] 
Allison Mankin      [   ]     [ X ]       [   ]      [   ] 
Thomas Narten       [   ]     [   ]       [ X ]      [   ] 
Erik Nordmark       [   ]     [ X ]       [   ]      [   ]
Jon Peterson        [   ]     [ X ]       [   ]      [   ] 
Bert Wijnen         [   ]     [ X ]       [   ]      [   ]
Alex Zinin          [ X ]     [   ]       [   ]      [   ] 


 2/3 (9) Yes or No-Objection opinions needed to pass. 
 
 * Indicate reason if 'Discuss'.

COMMENTS:
=========
Randy:
still no-ob, and apologies for posting a no-ob to the list, but an 
ops-dir reviewer says

one question that strikes me is whether *Intra-area* TE is actually 
usable and applicable to TE scenarios... and whether it's inter-area 
which you really need, and having possibly different solutions for 
each -- if this could not be extended to support inter-area -- could 
be undesirable.
 
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, ospf@discuss.microsoft.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Traffic Engineering Extensions to OSPF
	 Version 2 to Proposed Standard
-------------

The IESG has approved the Internet-Draft 'Traffic Engineering 
Extensions to OSPF Version 2' <draft-katz-yeung-ospf-traffic-09.txt> 
as a Proposed Standard. This document is the product of the Open 
Shortest Path First IGP Working Group.

The IESG contact persons are Bill Fenner and Alex Zinin.


Technical Summary
   
The Traffic Engineering Extensions to OSPF Version 2 define a method
for describing the traffic engineering topology (including bandwidth
and administrative constraints) and distributing this information
within a given OSPF area. The traffic engineering topology need not
be congruent with the regular routed topology.
   
Working Group Summary
   
There was strong support in the working group for this extension.
The working group made several clarifications to the document
during Working Group Last Call. Other minor changes, especially
to clarify that this extension is only suitable for intra-area
Traffic Engineering, were agreed to during IETF Last Call.
   
Protocol Quality
   
Bill Fenner and Alex Zinin reviewed the spec for the IESG. These
extensions are widely implemented and deployed.

To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-atommib-atm2 -
        Definitions of Supplemental Managed Objects for ATM Interface
--------

Last Call to expire on: 2003-06-19

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [   ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Erik Nordmark        [ X ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
To: IETF-Announce:; 
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, atommib@research.telcordia.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definitions of Supplemental Managed Objects for ATM 
     Interface to Proposed Standard 
-------------

The IESG has approved the Internet-Draft 'Definitions of Supplemental 
Managed Objects for ATM Interface' <draft-ietf-atommib-atm2-19.txt> as a 
Proposed Standard. This document is the product of the AToM MIB Working 
Group. The IESG contact persons are Thomas Narten and Erik Nordmark 

The IESG has approved the Internet-Draft 'Definitions of Supplemental 
Managed Objects for ATM Interface' <draft-ietf-atommib-atm2-19.txt> as 
a Proposed Standard.
This document is the product of the AToM MIB Working Group.
The IESG contact persons are 
	Thomas Narten
	Erik Nordmark
 
 
Technical Summary
 
   This memo defines objects used for managing ATM-based interfaces, devices,
   and services in addition to those defined in the ATM-MIB [24], to
   provide additional support for the management of:

        - ATM Switched Virtual Connections (SVCs)
        - ATM Permanent Virtual Connections (PVCs)
 
Working Group Summary
 
   There was consensus in the WG to advance this document.
 
Protocol Quality
 
   This document has reviewed for the IESG by Erik Nordmark and Bert Wijnen.








To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dnsext-ad-is-secure - Redefinition of 
DNS AD bit to Proposed Standard
--------

Last Call to expire on: May 21, 2002

	Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain  


Harald Alvestrand   [   ]     [ X ]       [   ]      [   ] 
Steve Bellovin      [   ]     [ X ]       [   ]      [   ] 
Scott Bradner       [   ]     [   ]       [ X ]      [   ] 
Randy Bush          [   ]     [   ]       [ X ]      [   ] 
Patrik Faltstrom    [   ]     [ X ]       [   ]      [   ] 
Bill Fenner         [   ]     [ X ]       [   ]      [   ] 
Ned Freed           [   ]     [ X ]       [   ]      [   ] 
Allison Mankin      [   ]     [   ]       [ X ]      [   ] 
Thomas Narten       [   ]     [ X ]       [   ]      [   ] 
Erik Nordmark       [ X ]     [   ]       [   ]      [   ] 
Jeff Schiller       [   ]     [XX ]       [ X ]      [   ] 
Bert Wijnen         [   ]     [ X ]       [   ]      [   ]
Alex Zinin          [   ]     [ X ]       [   ]      [   ] 

 2/3 (9) Yes or No-Objection opinions needed to pass. 
 
 * Indicate reason if 'Discuss'.

COMMENT:
========
Randy: this 'discuss' is meant literally. i just think that there are 
some issues here worth discussing. 

the major issue here is that having a remote, often untrusted, server 
assert (often over an untrusted channel) that the data met its local 
policies is not overly useful and is possibly misleading. the counter 
is that the stub client may have a trust relationship, via tsig or 
whatever, with the server, which also provides a trustable channel. 

on the other hand, this is no worse, and arguably better than the 
current definition of the AD bit. this then devolves into the 
question of whether it is better to improve a weak assertion or to 
recover the bit and reserve it for future use. 

who is going to use this assertion? is it thought that application 
layers will learn the trust state of the dns data which they use? 

and then, there is the exciting question of what this means in the 
presense of the dreaded opt-in. the client can not tell if the server 
which set the AD bit is locally configured to like opted-out data.

Scott:
never says what "AD" means - should expand in title and abstract 
sec 2 - I can not tell what is old & what is new behavior 
	it would be good if the wording were clear 
usage model would help 
references not split

Allison: The final paragraph of the Security Considerations is written
in a way that obscures meaning, in contrast to the related
final paragraph of Section 3.

> Resolvers (full or stub) that blindly trust the AD bit without
>    knowing the security policy of the server generating the answer can
>    not be considered security aware.


A better version would be "that blindly trust the AD bit MUST
be used only in an environment in which configurations ensure
that the security policy of the server is  appropriate to
the AD bit's information being valid for a decision on whether
to use the information it applies to"

Perhaps rather than obscuring meaning, it is actually wrong.
But the above hasty attempt tried to express something less
wrong.



^L
To: IETF-Announce:;
Dcc: all-ietf
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, namedroppers@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Redefinition of DNS AD bit to Proposed 
         Standard
-------------

The IESG has approved the Internet-Draft 'Redefinition of DNS AD bit' 
<draft-ietf-dnsext-ad-is-secure-06.txt> as a Proposed Standard.
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are Erik Nordmark and Thomas Narten.
   
   
Technical Summary
   
Based on implementation experience, the current definition of the AD
bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where
signatures have been cryptographically verified or the server is
authoritative for the data and is allowed to set the bit by policy.
   
Working Group Summary
   
There was some dissent expressed by one person whether the AD bit 
carries any semantics which can not be inferred from the replies 
which the stub resolver receives.
   
Protocol Quality
   
The specification has been reviewed for the IESG by Erik Nordmark.




To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-sip-sctp -
        The Stream Control Transmission Protocol as a Transport for  for the Session Initiation Protocol
--------

Last Call to expire on: 2003-07-03

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [ X ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Erik Nordmark        [   ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
To: IETF-Announce:; 
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The Stream Control Transmission Protocol as a 
     Transport for for the Session Initiation Protocol to Proposed Standard 
-------------

The IESG has approved the Internet-Draft 'The Stream Control
Transmission Protocol as a Transport for for the Session Initiation
Protocol' <draft-ietf-sip-sctp-03.txt> as a Proposed Standard. This
document is the product of the Session Initiation Protocol Working
Group. The IESG contact persons are A. Mankin and J. Peterson.

Technical Summary

      The Stream Control Transmission Protocol (SCTP)] has been designed
      as a new transport protocol for the Internet at the
      same layer as TCP and UDP. SCTP has been designed with the transport
      of legacy SS7 signaling messages in mind. A number of
      of the features designed to support transport of such signaling are
      also useful for the transport of SIP (the Session Initiation
      Protocol) [2], which is used to initiate and manage interactive
      sessions on the Internet.

      SIP itself is transport-independent, and can run over any reliable or
      unreliable message or stream transport. However, procedures are only
      defined for transport over UDP and TCP. In order to encourage
      experimentation and evaluation of the appropriateness of SCTP for SIP
      transport, this document defines transport of SIP over SCTP.

      Note that this is not a proposal that SCTP be adopted as the primary
      or preferred transport for SIP; substantial evaluation of SCTP,
      deployment, and experimentation can take place before that happens.
      This specification is targeted at encouraging such experimentation by
      enabling it in SIP.

Working Group Summary

The working group had consensus to advance the draft to Proposed
Standard.

Protocol Quality

An implementation of a SIP client over SCTP in Linux has recently been
announced.

Review of this specification for the IESG was by Allison Mankin.


RFC Editor Note

In the following sentence:
                                                                      This extra layer
      sometimes requires ordered delivery of messages from the transport
      layer (e.g., TLS [6]).

Add a normative reference to RFC 3436 (SCTP over TLS).


Replace Section 6 Security Considerations

    The security issues raised in [2] are not worsened by SCTP, provided the
    advice in Section 4 is followed and SCTP over TLS [cite RFC 2436] is
    used where TLS would be required in [2].


To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ips-fcip-slp -
        Finding FCIP Entities Using SLPv2
--------

Last Call to expire on: 2003-07-03

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [ X ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Erik Nordmark        [   ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
To: IETF-Announce:; 
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, ips@ece.cmu.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Finding FCIP Entities Using SLPv2 to Proposed 
     Standard 
-------------

The IESG has approved the Internet-Drafts

* 'Finding FCIP Entities Using SLPv2'
      <draft-ietf-ips-fcip-slp-07.txt>
* 'Finding iSCSI Targets and Name Servers Using SLP'
      <draft-ietf-ips-iscsi-slp-06.txt>

as Proposed Standards. These documents are products of the IP Storage
Working Group. The IESG contact persons are A. Mankin and J. Peterson

Technical Summary

      draft-ietf-ips-fcip-slp-07.txt describes the use of the Service
      Location Protocol Version 2 (SLPv2) to perform dynamic discovery of
      participating FCIP Entities. Implementation guidelines, service
      type templates, and security considerations are specified. FCIP is
      a pure FC encapsulation protocol that transports FC frames. As
      defined by the IPS WG, it interconnects Fibre Channel switches over
      TCP/IP networks.


      draft-ietf-ips-iscsi-slp-06.txt defines the use of SLPv2 by iSCSI
      hosts, devices, and management services, along with the SLP service
      type templates that describe the services they provide and security
      considerations. The iSCSI protocol provides a way for hosts to
      access SCSI devices over TCP/IP.


Working Group Summary

    The Working Group had consensus to advance both documents to Proposed
    Standard. The SLPv2 and discovery aspects were given review and
    discussion on the mailing list by Erik Guttman and James Kempf, and this
    was an active discussion.

Protocol Quality

    The documents were reviewed for the IESG by Erik Guttman, James Kempf,
    Thomas Narten and Allison Mankin.





To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-sipping-3pcc -
        Best Current Practices for Third Party Call Control in the Session Initiation Protocol
--------

Last Call to expire on: 2002-06-03

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [ X ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Erik Nordmark        [   ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
To: IETF-Announce:; 
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, sipping@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Best Current Practices for Third Party Call Control 
     in the Session Initiation Protocol to BCP 
-------------

The IESG has approved the Internet-Draft 'Best Current Practices for
Third Party Call Control in the Session Initiation Protocol'
<draft-ietf-sipping-3pcc-04.txt> as a BCP. This document is the
product of the Session Initiation Proposal Investigation Working
Group. The IESG contact persons are A. Mankin and J. Peterson.

Technical Summary

      Third party call control refers to the ability of one entity to
      create a call in which communications is actually between other
      parties. Third party call control is possible using the mechanisms
      specified within the Session Initiation Protocol (SIP). However,
      there are several possible approaches, each with different benefits
      and drawbacks. This document discusses best current practices for the
      usage of SIP for third party call control.

      Security and identity are important issues in third party call control.
      The document provides recommendations for the controller to use a
      credentialled identity. It also provides recommendations to ensure that
      the two endpoints in the third party controlled call can set up end-to-end
      secured media.

Working Group Summary

        There was strong working group consensus to advance this document and
        it has a significant pull from the community, including 3GPP. There were
        no issues raised during IETF Last Call.

Protocol Quality

        The document was reviewed for the IESG by Eric Rescorla and Allison Mankin



To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dnsext-rfc1886bis -
        DNS Extensions to support IP version 6
--------

Last Call to expire on: 2003-06-17

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [   ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Erik Nordmark        [ X ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
To: IETF-Announce:; 
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, namedroppers@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: DNS Extensions to support IP version 6 to Draft 
     Standard 
-------------

The IESG has approved the Internet-Draft 'DNS Extensions to support IP 
version 6' <draft-ietf-dnsext-rfc1886bis-03.txt> as a Draft Standard. This 
document is the product of the DNS Extensions Working Group. The IESG 
contact persons are Thomas Narten and Erik Nordmark 

The IESG has approved the Internet-Draft 'DNS Extensions to support 
IP version 6' <draft-ietf-dnsext-rfc1886bis-03.txt> as a Draft Standard.
This document is the product of the DNS Extensions Working Group.
The IESG contact persons are 
	Thomas Narten
	Erik Nordmark
 
 
Technical Summary
 
   This document defines the changes that need to be made to the Domain
   Name System to support hosts running IP version 6 (IPv6).  The
   changes include a resource record type to store an IPv6 address,
   a domain to support lookups based on an IPv6 address, and updated
   definitions of existing query types that return Internet addresses as
   part of additional section processing.  The extensions are designed
   to be compatible with existing applications and, in particular, DNS
   implementations themselves.

   This Document combines RFC1886 and changes to RFC 1886 made by
   RFC 3152, obsoleting both. Changes mainly consist in replacing 
   the IP6.INT domain by IP6.ARPA as defined in RFC 3152. 
 
 
Working Group Summary
 
  There was WG consensus to advance this document.
 
Protocol Quality
 
   The specification has been reviewed for the IESG by Erik Nordmark.








To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Scretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-avt-rtcp-report-extns -
        RTP Control Protocol Extended Reports (RTCP XR)
--------

Last Call to expire on: 2003-07-03

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Harald Alvestrand    [   ]     [   ]     [   ]     [   ]
Steve Bellovin       [   ]     [   ]     [   ]     [   ]
Randy Bush           [   ]     [   ]     [   ]     [   ]
Bill Fenner          [   ]     [   ]     [   ]     [   ]
Ned Freed            [   ]     [   ]     [   ]     [   ]
Ted Hardie           [   ]     [   ]     [   ]     [   ]
Russ Housley         [   ]     [   ]     [   ]     [   ]
Allison Mankin       [ X ]     [   ]     [   ]     [   ]
Thomas Narten        [   ]     [   ]     [   ]     [   ]
Erik Nordmark        [   ]     [   ]     [   ]     [   ]
Jon Peterson         [   ]     [   ]     [   ]     [   ]
Bert Wijnen          [   ]     [   ]     [   ]     [   ]
Alex Zinin           [   ]     [   ]     [   ]     [   ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L 
To: IETF-Announce:; 
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTP Control Protocol Extended Reports (RTCP XR) to 
     Proposed Standard 
-------------

The IESG has approved the Internet-Draft 'RTP Control Protocol
Extended Reports (RTCP XR)' <draft-ietf-avt-rtcp-report-extns-06.txt>
as a Proposed Standard. This document is the product of the
Audio/Video Transport Working Group. The IESG contact persons are
A. Mankin and J. Peterson

Technical Summary

      This document defines the Extended Report (XR) packet type for the
      RTP Control Protocol (RTCP), and defines how the use of XR packets
      can be signaled by an application if it employs the Session
      Description Protocol (SDP). XR packets are composed of report
      blocks, and seven block types are defined here. The purpose of the
      extended reporting format is to convey information that supplements
      the six statistics that are contained in the report blocks used by
      RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some
      applications, such as multicast inference of network characteristics
      (MINC) or voice over IP (VoIP) monitoring, require other and more
      detailed statistics. In addition to the block types defined here,
      additional block types may be defined in the future by adhering to
      the framework that this document provides. Security considerations
      including the use of Secure RTCP to overcome the heightened amount of
      information provided by the XR packet type are described.

Working Group Summary

      The working group divided for a time on whether to include more complex
      types of monitoring in the initial seven block types, but the resolution
      on the framework achieved a very good consensus.

Protocol Quality

      Prototype implementations exist of the XR packet type and have been
      discussed in reviewing the specification.

      The review of the specification was very active due to strong interest
      by a variety of communities.

      The review for the IESG was done by Allison Mankin.



To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-enum-rfc2916bis - The E.164 to URI DDDS 
         Application (ENUM) to Proposed Standard
--------

Last Call to expire on: 2003-6-23

	Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain


Harald Alvestrand   [   ]     [   ]       [   ]      [ D ]
Steve Bellovin      [   ]     [ X ]       [   ]      [   ]
Randy Bush          [   ]     [   ]       [   ]      [   ]
Bill Fenner         [   ]     [ X ]       [   ]      [   ]
Ned Freed           [   ]     [ X ]       [   ]      [   ]
Ted Hardie          [   ]     [   ]       [ X ]      [   ]
Russ Housley        [   ]     [ X ]       [   ]      [   ]
Allison Mankin      [ X ]     [   ]       [   ]      [   ]
Thomas Narten       [   ]     [ X ]       [   ]      [   ]
Erik Nordmark       [   ]     [ X ]       [   ]      [   ]
Jon Peterson        [ X ]     [   ]       [   ]      [   ]
Bert Wijnen         [   ]     [   ]       [   ]      [   ]
Alex Zinin          [   ]     [ X ]       [   ]      [   ]


 2/3 (9) Yes or No-Objection opinions needed to pass.

 * Indicate reason if 'Discuss'.
DISCUSS:
=======
Ted:
I went back forth as to whether these were serious nits
or a mild discuss. The tired lady mentioned in the nit
related to section 2.1 was the deciding factor. In other
words, I think these should be fixed, but pushback is
welcome.


In the introduction:

        "like delegation through NS records and NAPTR records, one can look up
        what services are available for a specific domain name"

Would it not make more sense to say, "what services are associated with a
specific E.164 number"? This is not general to all domain names.


For Section 1.2, the language seems less than clear. How about:

          This document describes the operation of these mechanisms in the context
          of numbers allocated according to the ITU-T recommendation E.164. The
          same mechanisms might be used for private dialing plans. If the
          mechanisms are re-used, the suffix used for the private dialing plan
          MUST NOT be e164.arpa, to avoid conflict with this specification.
          Parties to the private dialing plan will need to know the the suffix
          used by their private dialing plan for correct operation of these
          mechanisms. Further, the application unique string used SHOULD be
          the full number as specified, but without the leading '+'

In Section 2.1, the draft says:


        For example, the E.164 number could start out as "+1-770-923-9595".
        To ensure that no syntactic sugar is allowed into the AUS, all
        non-digits except for "+" are removed, yielding "+17709239595".

I'm not sure "syntactic sugar" is clear. Is the AUS a gas tank? :)
Frankly, I'd suggest deleting the second paragraph, as I don't think it adds
anything, but if it's kept, I'd suggest updating it to "the E.164 number could
be represented to a user as". I'd also suggest using a known-to-be invalid
number. A tired lady answer this number when I called it,
and she didn't know anything about this draft.

In section 2.4.2.1, the draft says:

        The mapping, if any, have
        to be made explicit in the specification for the Enumservice itself.
        A registration of a specific Type also have to specify the Subtypes
        allowed.

I think the grammar is off there. how about: "the mapping, if any,
must be made
explicit"?


I'm concerned that section 2.5 might cause as much confusion as it
prevents. How about replacing the whole thing with "The ENUM algorithm
always returns a single rule. Specific applications may have
application-specific knowledge or facilities that allow them to
present multiple results or speed selection, but these should
never change the operation of the algorithm."

For the IANA consideration, the work requested by the first two paragraphs
is done. I think that it would be betterto change it to note that
the obsoleted RFC
requested these, and to give a pointer to the current IAB/ITU-T agreement.


COMMENTS:
========
Thomas:
One other nit on this document:

      the document series specified in RFC 3401. It is very important to
      note that it is impossible to read and understand this document
      without reading the documents discussed in RFC 3401.

yet, 3401 is not a normative reference? That doesn't seem right.

Thomas

COMMENT:
=======
Allison:
Thomas,

I agree, I think it's an oversight that 3401 is not a normative reference.

Allison

^L
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, enum@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: The E.164 to URI DDDS Application (ENUM) to 
         Proposed Standard
-------------


The IESG has approved the Internet-Draft 'The E.164 to URI DDDS Application
(ENUM)' <draft-ietf-enum-rfc2916bis-06.txt> as a Proposed Standard.
This document is the product of the Telephone Number Mapping Working Group.
The IESG contact persons are Allison Mankin and Jon Peterson.
 
Technical Summary

This document specifies how DNS can be used for identifying available
services connected to one E.164 number. It specifically obsoletes RFC
2916 to bring it in line with the Dynamic Delegation Discovery System
(DDDS) Application specification found in RFC 3401 and its companion
RFCs.
 
Working Group Summary
 
  The working group strongly supported advancement of the draft, after
  careful technical review.
 
Protocol Quality
 
  There are currently in prototype use several implementations of this
  draft, and registries of services following the format here are under
  active development. The document was reviewed for the IESG by Allison
  Mankin

RFC Editor Note -

Change the first sentence of Section 3.1.4 Publication Requirements:

Old:
      Proposals for Enumservices registered must be published as RFCs on
      the Standards Track or as a BCP.
New:
      Proposals for Enumservices registered must be published as RFCs.



To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-sip-scvrtdisco - Session Initiation
	 Protocol Extension Header Field for Service Route Discovery
	 During Registration to Proposed Standard
--------

Last Call to expire on: 2002-11-15

	Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain  


Harald Alvestrand   [   ]     [   ]       [   ]      [   ]
Steve Bellovin      [   ]     [   ]       [ X ]      [   ]
Scott Bradner       [ X ]     [   ]       [   ]      [   ]
Randy Bush          [   ]     [ X ]       [   ]      [   ]
Patrik Faltstrom    [   ]     [   ]       [ X ]      [   ]
Bill Fenner         [   ]     [ X ]       [   ]      [   ]
Ned Freed           [   ]     [ X ]       [   ]      [   ]
Allison Mankin      [   ]     [   ]       [ X ]      [   ]
Thomas Narten       [   ]     [ X ]       [   ]      [   ]
Erik Nordmark       [   ]     [   ]       [   ]      [   ]
Jeff Schiller       [   ]     [ X ]       [   ]      [   ]
Bert Wijnen         [   ]     [XX ]       [ X ]      [   ]
Alex Zinin          [   ]     [   ]       [   ]      [   ]



 2/3 (9) Yes or No-Objection opinions needed to pass. 
 
 * Indicate reason if 'Discuss'.

DISCUSS
=======
Steve: The Security Considerations section is confusing, and (I think) wrong.

The first paragraph speaks of proxies modifying things. This is indeed
a threat. But the end of that paragraph and the next speak of using
transport security between proxies. That does nothing against this
threat -- the problem occurs from misbehavior by the authorized proxy.
Transport security protects against MITM attacks, not nasty endpoints.

The note at the end of the second paragrap, suggesting S/MIME, is the
correct answer against this threat. Transport-level security might be
useful against other threats.

I suspect that fixing the first sentence of Section 7 to speak of MITMs
instead of proxies will clear up the confusion; the issue of
misbehaving proxies can be described briefly in the second paragraph.

I'm also concerned that there's no mandatory-to-implement specified (or
is S/MIME support required of Registrars elsewhere?). If not, there
should be some text somewhere mandating implementation of it, though
(of course) not necessarily use; the current "SHOULD" language is
sufficient.

Patrik:
Discuss/nit:

 The scenario in section 6.4 is confusing.

             UA1----P1-----| |--R-------|
                                         | | |
                                         P2---| DBMS
                                         | | |
             UA2-----------| |--HS------|

 HS is not used anywhere, but HSP. I guess this is a mistake.

 Secondly, if we have nodes connected to a network which is IP enabled 
 (this is SIP, remember), and UA1 is to contact R initially, why is P1 
 and P2 there?

 The correct scenario should be that UA1 contacts R, and get a 
 notification that his "home" at the moment is at HS(P) for the domain 
 HOMEDOMAIN.

 The ascii art need to be more clear. What does the lines represent? 
 Lines between clouds which have firewalls between them? If so, where do 
 the RTP go?

Bert:
I think it should not be me to take these DISCUSSes, 
but they are using (pages 9 and further):

       EXAMPLEHOME.COM
       EXAMPLEVISITED.COM

Probably they should use

       home.example.com
       visited.example.com

Possibly this can be fixed with an RFC-Editor note


 
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Session Initiation Protocol Extension Header
	 Field for Service Route Discovery During Registration to
	 Proposed Standard
-------------


The IESG has approved the Internet-Draft 'Session Initiation Protocol
Extension Header Field for Service Route Discovery During Registration'
<draft-ietf-sip-scvrtdisco-02.txt> as a Proposed Standard.  This
document is the product of the Session Initiation Protocol Working
Group.  The IESG contact persons are Scott Bradner and Allison Mankin.


Technical Summary
 
      This document defines a SIP extension header field used in
      conjunction with responses to REGISTER requests to provide a
      mechanism by which a registrar may inform a registering User 
	Agent (UA), that is, an end-user, of a service route that the UA 
	may use to request outbound services from the registrar's domain.
     
      SIP has a Route Header which is used to loosely source route
      messages, and this Service Route extension allows providers to
      offer plans in which a user can ensure that they visit a provider's
      proxy at which they registered. IETF protocols should neither favor
      nor preclude* such capabilities. Security for the user and the
      provider are provided by the use of the SIP sips: address of record
      mandating that the hops be carried over TLS, and use of S/MIME for
      the bodies in the messages.

 
Working Group Summary
 
      There was active review. This document was split out from
      the other direction, called the PATH header and worked on until
      it had adequate clarity and security. Its current version has
      good consensus.


Protocol Quality
 
    This document has been reviewed for the IESG by Rohan Mahy and
    and Allison Mankin. Some implementations were tested in recent
    interoperability events.



To: Internet Engineering Steering Group <iesg@ietf.org>
Fcc: OUTBOX
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-magma-mld-source - Source Address 
	   Selection for Multicast Listener Discovery Protocol (RFC 2710) 
	   to Proposed Standard
--------

Last Call to expire on: 2002-10-25

	Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain  


Harald Alvestrand   [   ]     [ X ]       [   ]      [   ]
Steve Bellovin      [   ]     [ X ]       [   ]      [   ]
Scott Bradner       [   ]     [ X ]       [   ]      [   ]
Randy Bush          [   ]     [ X ]       [   ]      [   ]
Patrik Faltstrom    [   ]     [ X ]       [   ]      [   ]
Bill Fenner         [   ]     [   ]       [   ]      [ R ]
Ned Freed           [   ]     [ X ]       [   ]      [   ]
Russ Housley        [   ]     [   ]       [ X ]      [   ]
Allison Mankin      [   ]     [ X ]       [   ]      [   ]
Thomas Narten       [   ]     [ XX]       [ X ]      [   ]
Erik Nordmark       [ X ]     [   ]       [   ]      [   ]
Jeff Schiller       [   ]     [ X ]       [   ]      [   ]
Bert Wijnen         [   ]     [ X ]       [   ]      [   ]
Alex Zinin          [   ]     [ X ]       [   ]      [   ]


 2/3 (9) Yes or No-Objection opinions needed to pass. 
 
 * Indicate reason if 'Discuss'.

DISCUSS:
========
Thomas:
> MLD Report and Done messages MUST be sent with a valid link-local
 > address as the IPv6 source address. If a valid link-local address is
 > not available, the message MUST be sent with the unspecified address
 > (::) as the IPv6 source address.

 A bit of a nit, but the MUSTs are almost contradictory. It's a bit odd
 to say: Do X. Well except if you can't, in which case you do Y. Better
 to rewrite something like:

         MLD Report and Done messages are sent with a link-local address as
         the IPv6 source address, if the one has been assigned to the
         interface. If a none exists (e.g., one hasn't been assigned to
         the interface yet), the message is sent with the unspecified
         address (::) as the IPv6 source address.

 nit: RFC 2119 reference should be normative rather than informative.

 Finally, the document really could include a bit more context about
 why the document exists and what problem is being solved.

 Based on some discussions with the author, the exact problem being
 solved seems to be:

 The rules and desired behavior with regards to receiving multicast
 traffic prior to having an IP address need clarification. Before
 assigning an LL address to an interface, a node needs to run DAD. But
 DAD involves recieving multicast traffic sent to the solicited node
 multicast address. But joining a multicast group involves running
 MLD. The MLD spec says that MLD messages MUST be sourced from a LL
 source address. This is needed even for LL multicast addresses due to
 l2 bridge snooping. Thus, clarifications/guidelines regarding the
 handling of joining multicast groups when one has no LL address are
 needed.

 It would be good to get words into the document that explain this
 better.

 Also, I think it would be good to add some explicit wording to the
 document making it clear which rules in 2710 are being changed. I
 particular, it would be good to indicate that receivers should not
 drop packets with a source address of unspecified.

 In general, you might want to say something about what problems have
 been encountered in practice from the current wording, and whether
 this change will result in different/better/worse behavior.

 For example, should an implementation (once it has a valid ll address)
 also run MLD again with its new address, to be sure that it
 interoperates well with routers that drop packets with a source
 address of unspecified?

Russ:
The security considerations say:

The ability to send MLD messages with the unspecified address can
lead to on-link abuse that is harder to trace.

Harder than what? Please clarify.

 
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>, magma@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Source Address Selection for Multicast 
	   Listener Discovery Protocol (RFC 2710) to Proposed Standard
-------------

The IESG has approved the Internet-Draft 'Source Address Selection for 
Multicast Listener Discovery Protocol (RFC 2710)' 
<draft-ietf-magma-mld-source-02.txt> as a Proposed Standard. This 
document is the product of the Multicast & Anycast Group Membership 
Working Group. The IESG contact persons are Thomas Narten and Erik 
Nordmark.
   
   
Technical Summary
   
The neighbor discovery specification allows using the unspecified
address as source for certain MLD messages but this is not captured 
in the MLD specification. This document updates the MLD specification
with source address rules that are consistent with neighbor discovery.
   
Working Group Summary
   
There was WG consensus to advance this document.
   
Protocol Quality
   
The document has been reviewed for the IESG by Erik Nordmark.


To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-dnsext-unknown-rrs - Handling of 
	   Unknown DNS Resource Record Types to Proposed Standard
--------

Last Call to expire on: 2003-4-16

	Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain  


Harald Alvestrand   [ X ]     [   ]       [   ]      [   ]
Steve Bellovin      [   ]     [ X ]       [   ]      [   ]  
Randy Bush          [   ]     [ X ]       [   ]      [   ] 
Bill Fenner         [   ]     [ X ]       [   ]      [   ] 
Ned Freed           [   ]     [ X ]       [   ]      [   ] 
Ted Hardie          [ X ]     [   ]       [   ]      [   ] 
Russ Housley        [   ]     [ X ]       [   ]      [   ] 
Allison Mankin      [   ]     [ X ]       [   ]      [   ] 
Thomas Narten       [   ]     [   ]       [ X ]      [   ] 
Erik Nordmark       [ X ]     [   ]       [   ]      [   ]
Jon Peterson        [   ]     [XX ]       [ X ]      [   ] 
Bert Wijnen         [   ]     [ X ]       [   ]      [   ]
Alex Zinin          [   ]     [ X ]       [   ]      [   ] 


 2/3 (9) Yes or No-Objection opinions needed to pass. 
 
 * Indicate reason if 'Discuss'.

COMMENTS:
=========
Steve:
It's clearly necessary to have something like that, but frankly, 
the document scares me; it retroactively changes the behavior 
required for older RFCs. I sure with Mockapetris had thought of 
saying this.

Am I offbase? Is this much better -- or much worse -- than I fear?

Russ:
Please change "RFC TBD" to "this specification." I believe that it 
will be easier for the reader.

Jon:
> Jon Peterson [ ] [ ] [ x ] [ ] 

 Does this document place too great a burden on the IANA? The IANA
 Considerations require IANA to enforce the policy described in the
 second-to-last paragraph of Section 4, I gather, which entails pretty deep
 knowledge of the mechanics of a new RR - significantly more than just
 verifying whether or not the RR name has been taken, or what have you. The
 policy for name compression in RDATA definitely makes sense, but I suspect
 IANA isn't the right body to analyze new RR proposals and enforce that
 policy. Perhaps it would be better if the IESG, or an Expert Reviewer, or
 something along those lines were identified as the enforcer of the name
 compression policy.

 
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, namedroppers@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Handling of Unknown DNS Resource Record 
	   Types to Proposed Standard
-------------


The IESG has approved the Internet-Draft 'Handling of Unknown DNS 
Resource Record Types' <draft-ietf-dnsext-unknown-rrs-05.txt> as a 
Proposed Standard. This document is the product of the DNS Extensions 
Working Group. The IESG contact persons are Thomas Narten and Erik 
Nordmark. 
   
Technical Summary
   
Extending the Domain Name System with new Resource Record (RR) types
currently requires changes to name server software. This document
specifies the changes necessary to allow future DNS implementations
to handle new RR types transparently.
   
Working Group Summary
   
There was WG consensus to advance the document.
   
Protocol Quality
   
The specification has been reviewed for the IESG by Erik Nordmark.

>From: hardie@qualcomm.com
>To: Steve Bellovin <smb@research.att.com>, iesg-secretary@ietf.org
>Subject: Re: evaluation: draft-ietf-crisp-requirements

Steve,
                This is meant to be covered by this text:

3.1.4.1 Protocol Requirement

        The protocol MUST NOT prohibit an operator from granularly assigning
        multiple types of access to data according to the policies of the
        operator. The protocol MUST provide an authentication mechanism and
        MUST NOT prohibit an operator from granting types of access based on
        authentication.

        The protocol MUST provide an anonymous access mechanism that may be
        turned on or off based on the policy of an operator.

                Since these protocol requirements apply only to distributing
information, there is no place in it for the client to express
privacy preferences about the data (indeed, that's likely to be covered
by EPP).
                                                                regards,
                                                                                Ted

>From: hardie@qualcomm.com
>To: mankin@psg.com, iesg@ietf.org
>Subject: Re: Comment: draft-ietf-crisp-requirements-05.txt

At 5:43 AM -0700 6/26/03, Allison Mankin wrote:
>Overall this is a very well-written spec. One transport issue and two
>questions about scope - perfectly reasonable answers are out of scope,
>or already discussed and dismissed.
>
>1.
>
>The protocol MUST
> define one or more transport mechanisms for mandatory implementation.
> ^congestion-aware or overload-aware
>
>I realize that the transport choice could be UDP, but in that case,
>congestion-aware would mean UDP without aggressive retransmission.
>And in the case that that "transport" may be used here to mean a
>higher layer protocol such as mail or http, then the term
>overload-aware applies.


Speaking as one of the chairs, this change should be uncontroversial,
so an RFC editor note could cover it.

>2.
>
>Is it out of scope for there to be a requirement in the protocol for
>the registry to be able to authenticate itself to the client, because
>in some cases there could be falsified registries?

3.1.9 covers the protocol and service descriptions here; the wg
did discuss the various use case scenarios. The result was:
must be able to authenticate itself, but does not require that
for operation of a CRISP server.

If you have further issues, I'd be happy to discuss it with you,
or set up a call with the author.

>3.
>
>Is it out of scope for there to be a requirement on the protocol for
>some support for authentication of the contact information?


This would have to be covered by the requirements on the protocol
that populates the data. A distribution protocol is pretty much too late
in the game to put in requirements for authenticating the contact
information that _has_been_populated.

>To: hardie@qualcomm.com
>Subject: Re: evaluation: draft-ietf-crisp-requirements
>From: "Steven M. Bellovin" <smb@research.att.com>

In message <p06001201bb20c6217d42@[129.46.227.161]>, hardie@qualcomm.com writes
:
>Steve,
> This is meant to be covered by this text:
>
>3.1.4.1 Protocol Requirement
>
> The protocol MUST NOT prohibit an operator from granularly assigning
> multiple types of access to data according to the policies of the
> operator. The protocol MUST provide an authentication mechanism and
> MUST NOT prohibit an operator from granting types of access based on
> authentication.
>
> The protocol MUST provide an anonymous access mechanism that may be
> turned on or off based on the policy of an operator.
>
> Since these protocol requirements apply only to distributing
>information, there is no place in it for the client to express
>privacy preferences about the data (indeed, that's likely to be covered
>by EPP).

Not very explicit, and authentication isn't the same as authorization.

But what attracted my attention was 3.1.3, which talks about tagging
data. What I'm asking about is language about privacy-related tags, or
use of tags for privacy purposes. That was the big hangup with the EPP
document, as I recall.

At 9:25 AM -0400 6/26/03, Steve Bellovin wrote:
>I think there should be some requirement that data be taggable to meet
>privacy requirements. We just went through this a few months ago.
>
> --Steve Bellovin, http://www.research.att.com/~smb (me)
> http://www.wilyhacker.com (2nd edition of "Firewalls" book)

>From: Leslie Daigle <leslie@thinkingcat.com>
>To: hardie@qualcomm.com
>Subject: Re: Comment: draft-ietf-crisp-requirements-05.txt

Speaking as a WG participant:

hardie@qualcomm.com wrote:
> At 5:43 AM -0700 6/26/03, Allison Mankin wrote:
>
>> Overall this is a very well-written spec. One transport issue and two
>> questions about scope - perfectly reasonable answers are out of scope,
>> or already discussed and dismissed.
>>
>> 1.
>>
>> The protocol MUST
>> define one or more transport mechanisms for mandatory implementation.
>> ^congestion-aware or overload-aware
>>
>> I realize that the transport choice could be UDP, but in that case,
>> congestion-aware would mean UDP without aggressive retransmission.
>> And in the case that that "transport" may be used here to mean a
>> higher layer protocol such as mail or http, then the term
>> overload-aware applies.
>
>
>
> Speaking as one of the chairs, this change should be uncontroversial,
> so an RFC editor note could cover it.

I believe the intention of the requirement is to be an
*application* transport. I.e., beep, http, etc.

Leslie.



Layer 3 Virtual Private Networks (l3vpn)
-----------------------------------------

 Charter
 Last Modified: 2003-06-12

 Current Status: Proposed Working Group

 Chair(s): 
       <under discussion>

 Area Director(s):
       Thomas Narten <narten@us.ibm.com>
       Erik Nordmark <nordmark@sun.com>

 Area Advisor:
       Thomas Narten <narten@us.ibm.com>

 Technical Advisor:
       Alex Zinin <zinin@psg.com>

 Mailing Lists:

 General Discussion: l3vpn@ietf.org
 To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn
 Archive: https://www1.ietf.org/mail-archive/working-groups/l3vpn/current/maillist.html
       
 Description of Working Group:

 Alex is the routing advisor.

 This working group is responsible for defining and specifying a
 limited number of solutions for supporting provider-provisioned 
 Layer-3 (routed) Virtual Private Networks (L3VPNs).

 The WG is responsible for standardization of the following solutions:

       1. BGP/MPLS IP VPNs (based on RFC 2547)
       2. IP VPNs using Virtual Routers
       3. CE-based VPNs using IPSEC

 The following VPN deployment scenarios will be considered by the WG:

       1. Internet-wide: VPN sites attached to arbitratry points in
             the Internet

       2. Single SP/single AS: VPN sites attached to the network of a
             single provider within the scope of a single AS

       3. Single SP/multiple AS'es: VPN sites attached to the network
             of a single provider consisting of multiple AS'es

       4. Cooperating SPs: VPN sites attached to networks of different
             providers that cooperate with each other to provide VPN service

 As part of this effort the WG will work on the following tasks
 (additional work items will require rechartering):

       1. Requirements and framework for Layer 3 VPNs
       2. Solution documents for each approach listed above (including
             applicability statements)
       3. MIB definitions for each approach
       4. Security mechanisms for each approach

 As a general rule, the WG will not create new protocols, but will provide 
 functional requirements for extensions of the existing protocols that will 
 be discussed in the protocol-specific WGs. L3VPN WG will review proposed 
 protocol extensions for L3VPNs before they are recommended to appropriate 
 protocol-specific WGs.

 Multicast and QoS support are excluded from the charter at this time. 
 They may be considered for inclusion in an updated charter 
 at a later time. Future work items may also include OAM support.

 WG Milestones (optimistic):

 Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info
                     (completed)
 Dec 2002 Submit Generic Requirements Document to IESG for publication as Info
                     (completed)
 Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info
                     (completed)

 Dec 2003 Submit VPN Security Analysis to IESG for publication as Info
                     (draft-fang-ppvpn-security-framework-00)
 Dec 2003 Submit BGP/MPLS VPNs specification and AS to IESG for 
                     publication as PS
                   (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)
 Dec 2003 Submit CE-based specification and AS to IESG for publication as PS
                   (draft-ietf-ppvpn-ce-based-03)
                   (draft-declercq-ppvpn-ce-based-sol-00)
                   (draft-declercq-ppvpn-ce-based-as-01)

 Jan 2004 Submit VPN MIB Textual Conventions to IESG for publication as PS
                   (draft-ietf-ppvpn-tc-mib-02)
 Jan 2004 Submit MPLS/BGP VPN MIB to IESG for publication as PS
                   (draft-ietf-ppvpn-mpls-vpn-mib-05)
 Jan 2004 Submit VR MIB to IESG for publication as PS
                   (draft-ietf-ppvpn-vr-mib-04)
 Jan 2004 Submit BGP as an Auto-Discovery Mechanism for publication as PS.
                   (draft-ietf-ppvpn-bgpvpn-auto-05.txt)

 March 2004 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG
                   for publication as PS
                   (draft-ietf-ppvpn-ipsec-2547-03)
 March 2004 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG
                   for publication as PS
                   (draft-ietf-ppvpn-gre-ip-2547-02)
 March 2004 Submit specification of BGP-MPLS VPN extension for IPv6 VPN to IESG for publication as PS
                           (draft-ietf-ppvpn-bgp-ipv6-vpn-03)


Path Maximum Transmission Unit Discovery (pmtud)
------------------------------------------------

 Charter
 Last Modified: 2003-06-06

 Current Status: Proposed Working Group

 Chair(s):

 Matt Mathis <mathis@psc.edu>
 TBD

 Transport Area Directors(s):

 Allison Mankin <mankin@psg.com>
 Jon Peterson <jon.peterson@neustar.biz>

 Transport Area Advisor:

 Allison Mankin <mankin@psg.com>

 Mailing List (temporary):

 General Discussion: mtu@psc.edu
 Subscribe: majordomo@psc.edu with "subscribe mtu" in the body
 Archive: http://www.psc.edu/~mathis/MTU/mbox.txt

 (This is to be moved to the IETF as soon as chartered).

 Description of Working Group: 

 The goal of the PMTUD working group is to specify a robust method for
 determining the IP Maximum Transmission Unit supported over an
 end-to-end path. This new method is expected to update most uses of
 RFC1191 and RFC1981, the current standards track protocols for this
 purpose. Various weakness in the current methods are documented in
 RFC2923, and have proven to be a chronic impediment to the deployment
 of new technologies that alter the path MTU, such as tunnels and new
 types of link layers.

 The proposed new method does not rely on ICMP or other messages from
 the network. It finds the proper MTU by starting a connection using
 relatively small packets (e.g. TCP segments) and searching upwards by
 probing with progressively larger test packets (containing application
 data). If a probe packet is successfully delivered, then the path MTU
 is raised. The isolated loss of a probe packet (with or without an
 ICMP can't fragment message) is treated as an indication of a MTU
 limit, and not a congestion indicator.

 The working group will specify the method for use in TCP, SCTP, and
 will outline what is necessary to support the method in transports
 such as DCCP. It will particularly describe the precise conditions
 under which lost packets are not treated as congestion indications.
 The work will pay particular attention to details that affect
 robustness and security.

 Path MTU discovery has the potential to interact with many other parts
 of the Internet, including all link, transport, encapsulation and
 tunnel protocols. Thereforethis working group will particularly
 encourage input from a wide cross section of the IETF to help to
 maximize the robustness of path MTU discovery in the presence of
 pathological behaviors from other components.

 Input draft: 

                 Packetization Layer Path MTU Discovery
                 draft-mathis-plpmtud-00.txt

 Goals and Milestones:

 Jul 03 Reorganized Internet-Draft. Solicit implementation and field experience.

 Dec 03 Update Internet-Draft incorporating implementers experience,
               actively solicit input from stakeholders - all communities that might
               be affected by changing PMTUD.

 Feb 04 Submit completed Internet-draft and a PMTUD MIB draft for 
               Proposed Standard.




Layer 2 Virtual Private Networks (l2vpn)
-----------------------------------------

 Charter
 Last Modified: 2003-06-17

 Current Status: Proposed Working Group

 Chairs: <under discussion>

 Area Director(s):
       Thomas Narten <narten@us.ibm.com>
       Erik Nordmark <nordmark@sun.com>

 Area Advisor:
       Thomas Narten <narten@us.ibm.com>

 Technical Advisor:
       Alex Zinin <zinin@psg.com>
       Russ Housley <housley@vigilsec.com>

 Mailing Lists:

       General Discussion: l2vpn@ietf.org
       To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn
       Archive: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/maillist.html

 Description of Working Group:

 Alex is the routing advisor.
 Russ is the security advisor.

 This working group is responsible for defining and specifying a
 limited number of solutions for supporting provider-provisioned
 layer-2 virtual private networks (L2VPNs).

 The WG is responsible for standardization of the following solutions:

 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
       across an IP and an MPLS-enabled IP network, allowing standard
       Ethernet devices communicate with each other as if they were
       connected to a common LAN segment.
   
 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
       point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
       point-to-point Ethernet) across an IP and an MPLS-enabled IP network.

 3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
       IP network, allowing standard IP devices to communicate with each
       other as if they were connected to a common LAN segment or a point-
       to-point circuit.

 The WG will address intra-AS scenarios only at this point (other
 scenarios will be considered for inclusion in the updated charter when 
 the current one is completed.)
       
 As a general rule, the WG will not create new protocols, but will 
 provide functional requirements for extensions of the existing 
 protocols that will be discussed in the protocol-specific WGs.
 As a specific example, this WG will not define new encapsulation
 mechanism, but will use those defined in the PWE3 WG.
 L2VPN WG will review proposed protocol extensions for L2VPNs before 
 they are recommended to appropriate protocol-specific WGs.

 The WG will work on the following items. Adding new work items 
 will require rechartering.

 1. Discovery of PEs participating in L2 service, and
       topology of required connectivity

 2. Signaling of l2vpn related information for the purpose of 
       setup and maintenance of l2vpn circuits. As much as possible
       PWE3 signaling procedures should be used

 3. Solution documents (providing the framework for a specific
       solution, should include info on how discovery, signaling,
       and encaps work together, include security, AS as a separate
       document)

 4. MIBs
       
 5. L2VPN-specific OAM extensions--extensions to existing OAM
       solutions for VPLS, VPWS, and IP-only L2VPNs.

 Where necessary, the WG will coordinate its activities with IEEE 802.1
       
 Milestones (optimistic):

 JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC
 JUL 2003 Submit L2 framework to IESG for publication as Informational RFC
 JUL 2003 Identify VPLS and VPWS solutions for the WG
 AUG 2003 Submit an I-D describing MIB for VPLS
 AUG 2003 Submit an I-D describing MIB for VPWS
 AUG 2003 Submit an I-D on OAM for VPLS
 AUG 2003 Submit an I-D on OAM for VPWS
 DEC 2003 Submit VPLS solution documents to IESG
 DEC 2003 Submit VPWS solution documents to IESG
 JAN 2004 Submit IP-only L2VPN solution documents to IESG
 FEB 2004 Submit MIB for VPLS to IESG
 MAR 2004 Submit OAM for VPWS to IESG
 APR 2004 Submit OAM for IP L2VPN to IESG