[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft IESG Telechat Agenda and Package for May 15, 2003
* DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the May 15, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- April 30, 2003
o Review of Action Items
OUTSTANDING TASKS
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
o Alex to send proposal and justification for interim document review.
DONE o Secretariat to send drafted auto-response text for I-D submissions
to IESG for review.
DONE o Secretariat to send drafted Working Group Chairs reminder text w/
pointer to I-D Nits to IESG for review.
o Allison will send RFC Editor Note to address Patrik's issues for Ted
for draft-ietf-sipping-basic-call-flows
DONE o Allison to ask Steve Casner, AVT Chair, to review draft-smith-urn-mpeg
o Ted to write straw working group procedures for handling consensus-
blocked decisions
o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
o Ted will notify Secretariat when ready to announce
draft-ietf-cdi-scenarios-01.txt
o Ted will send note as well as notify Secretariat when
draft-gustin-goyens-urn-id-02.txt is officially approved and ready
to announce.
IP o Secretariat to send change in mmusic charter (WG Re-charter) to IAB,
IESG and WG Chairs. After one week, if ok, Jon will tell the
Secretariat to send this charter to ietf-announce and new-work.
IP o Secretariat to send ldup WG Action/Re-charter announcement to IAB,
IESG, WG Chairs. If nothing happens, in one week Ted will ask
Secretariat to announce.
IP o Secretariat to send grow WG Action announcement to ietf-announce,
install charter.
o After netconf WG Chairs are approved, Bert will ask Secretariat to
send WG Action to ietf-announce, cc: WG Chairs.
IP o Alex to send DNP message for draft-srisuresh-ospf-te-05.txt to
Secretariat to send on behalf of IESG.
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.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Handling of Unknown DNS Resource Record Types (Proposed Standard)
<draft-ietf-dnsext-unknown-rrs-05.txt>
Token: Nordmark, Erik
2.1.2 Returning Item
o Extensible Provisioning Protocol (Proposed Standard)
<draft-ietf-provreg-epp-09.txt>
Token: Hardie, Ted
o Extensible Provisioning Protocol Domain Name Mapping (Proposed
Standard)
<draft-ietf-provreg-epp-domain-07.txt>
o Extensible Provisioning Protocol Host Mapping (Proposed Standard)
<draft-ietf-provreg-epp-host-07.txt>
o Extensible Provisioning Protocol Contact Mapping (Proposed Standard)
<draft-ietf-provreg-epp-contact-07.txt>
o Extensible Provisioning Protocol Transport Over TCP (Proposed
Standard)
<draft-ietf-provreg-epp-tcp-06.txt>
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt>
Token: Wijnen, Bert
Note: New revision needed
Responsible: Authors and WG
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
AreaDate
SUB
Service requirements for Layer 3 Provider Provisioned Virtual Private Networks: (Informational)
draft-ietf-ppvpn-requirements-06.txt
Token:
Zinin, Alex
SUB
A Framework for Layer 3 Provider Provisioned Virtual Private Networks (Informational)
draft-ietf-ppvpn-framework-08.txt
Token:
Zinin, Alex
3.1.2 Returning Item
AreaDate
TSV
FEB 21
SDPng Transition (Informational)
draft-ietf-mmusic-sdpng-trans-03.txt
Token:
Peterson, Jon
Note:
Roadmap document explaining relation of various extensions of SDP such as offer-answer and fid to the
SDPng work.
3.2 Individual Submissions Via AD
3.2.1 New Item
AreaDate
INT
IP Version 6 over MAPOS (Informational)
draft-ogura-ipv6-mapos-02.txt
Token:
Narten, Thomas
Note:
IESG: This is a returning document. security considerations revised per smb's request, document is ready
to go. Needs the following IESG note added: This memo documents a way of carrying IPv6
packets over MAPOS networks. This document is
NOT the product of an IETF working group
nor is it a standards track document. It has
not necessarily benefited from the widespread and
in-depth community review that standards track
documents receive.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
NONE
3.3.2 Returning Item
NONE
4. Working Group Actions
Area
Date
TSV
MAR 31
IP Telephony
Token:
Jon Peterson
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
*DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
April 30, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bush, Randy / IIJ
Daigle, Leslie / Verisign (IAB)
Falk, Aaron / ISI
Fenner, Bill / AT&T
Freed, Ned / Innosoft
Fuller, Barbara / IETF
Hardie, Ted / Qualcomm, Inc.
Hargest, Jacqueline / IETF
Housley, Russ / Vigil Security, LLC
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Peterson, Jon / NeuStar, Inc.
Reynolds, Joyce K. / ISI (RFC Editor)
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Cotton, Michelle / ICANN
Minutes
-------
1. The minutes of the April 17, 2003 teleconference were approved.
Secretariat to place in public archives and update minutes web page.
2. The following action items were reported as DONE:
o Secretariat to modify auto-response for Internet-Drafts
submissions so that when someone submits an I-D, a note is
automatically generated which recommends that they consider
the issues listed in ID-Nits before submitting the I-D to the
IESG. Auto-response to include the URL pointing to the
I-D Nits page. IESG will review the auto-response text.
o Secretariat to email Working Group Chairs a reminder after each
conference with pointer to I-D Nits. Secretariat to draft
reminder text and pass by IESG first.
3. Protocol Actions Deferred:
o Link Management Protocol (LMP) (Proposed Standard)
<draft-ietf-ccamp-lmp-08.txt
4. Document Actions Tentatively Approved:
o IP over Optical Networks: A Framework (Informational)
<draft-ietf-ipo-framework-04.txt>
Note: Tentatively approved, subject to addressing Allison's
concerns. Alex will notify Secretariat once ok to announce.
o Content Internetworking (CDI) Scenarios (Informational)
<draft-ietf-cdi-scenarios-01.txt>
Note: Tentatively approved pending references correction. Ted
will notify Secretariat when ready to announce.
o A Description of the Camellia Encryption Algorithm
(Informational)
<draft-nakajima-camellia-02.txt>
Note: Tentatively approved pending new revision to address
Thomas's boilerplate issue.
o A URN Namespace for SWIFT's Financial Messaging (Informational)
<draft-gustin-goyens-urn-id-02.txt>
Note: Tentatively approved pending note from Ted.
o A URN Namespace for MPEG (Informational)
<draft-smith-urn-mpeg-01.txt>
Note: Tentatively approved, subject to review by AVT Chair.
o A URN Namespace for FIPA (Informational)
<draft-bellifemine-urn-fipa-00.txt>
Note: Tentatively approved pending update to security
considerations and expansion of acronym in title.
5. Document Action Deferred:
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-03.txt>
6. Working Group Actions Approved:
o Multiparty Multimedia Session Control (mmusic)
Note: Secretariat to send change in charter (WG Re-charter) to IAB,
IESG and WG Chairs. After one week, if ok, Jon can tell the
Secretariat to send this charter to ietf-announce and new-work.
o LDAP Duplication/Replication/Update Protocols
Note: Secretariat to send WG Action/Re-charter announcement to IAB,
IESG, WG Chairs. If nothing happens, in one week Ted will ask
Secretariat to announce.
o Global Routing Operations (grow)
Note: IESG gave final approval. Secretariat to send WG Action
announcement to ietf-announce, install charter.
7. Working Group Action Tentatively Approved:
o Network Configuration (netconf)
Note: Once WG Chairs are approved, Bert will ask Secretariat to
send WG Action to ietf-announce, cc: WG Chairs.
8. Documents Remaining Under Discussion:
o LDAPv3: A Collection of User Schema (Proposed Standard)
<draft-zeilenga-ldap-user-schema-06.txt>
o Message Disposition Notification (Draft Standard)
<draft-vaudreuil-mdnbis-03.txt>
o The IETF XML Registry (BCP)
<draft-mealling-iana-xmlns-registry-04.txt>
o Generalized Multi-Protocol Label Switching Architecture
(Proposed Standard)
<draft-ietf-ccamp-gmpls-architecture-05.txt>
o Session Initiation Protocol Basic Call Flow Examples (BCP)
<draft-ietf-sipping-basic-call-flows-02.txt>
o UTF-8, a transformation format of ISO 10646 (Standard)
<draft-yergeau-rfc2279bis-04.txt>
o Internet X.509 Public Key Infrastructure Certificate Management
Protocols (Proposed Standard)
<draft-ietf-pkix-rfc2510bis-08.txt>
o Internet X.509 Public Key Infrastructure Certificate Request
Message Format (CRMF)(Proposed Standard)
<draft-ietf-pkix-rfc2511bis-06.txt>
o Exclusive XML Canonicalization, Version 1.0 (Informational)
<draft-ietf-xmldsig-xc14n-00.txt>
o Policy Requirements for Time-Stamping Authorities (Informational)
<draft-ietf-pkix-pr-tsa-04.txt>
o Extreme Networks' Ethernet Automatic Protection Switching
(EAPS), Version 1 (Informational)
<draft-shah-extreme-eaps-02.txt>
o A Framework for Purpose Built Keys (PBK) (Informational)
<draft-bradner-pbk-frame-04.txt>
9. DNP (Do Not Publish):
o OSPF-xTE: An experimental extension to OSPF for Traffic
Engineering (Experimental)
<draft-srisuresh-ospf-te-05.txt>
Note: Alex to send DNP message to Secretariat to send on behalf
of IESG.
10. The IESG agreed that, since the IPR WG is currently discussing
boilerplate issues regarding informational and experimental
documents, until the working group reaches a conclusion it is
inappropriate for the IESG to make a permanent change to policy.
Where IPR might be relevant, standard boilerplate should be used.
In addition, if there are IPR, then IPR claims should be filed.
11. New Action Items:
o Alex to send proposal and justification for interim document
review.
o Secretariat to send drafted auto-response text for I-D
submissions to IESG for review.
o Secretariat to send drafted Working Group Chairs reminder text
w/ pointer to I-D Nits to IESG for review.
o Allison will send RFC Editor Note to address Patrik's issues
for Ted for draft-ietf-sipping-basic-call-flows
o Allison to ask Steve Casner, AVT Chair, to review
draft-smith-urn-mpeg
o Ted to write straw working group procedures for handling
consensus-blocked decisions
o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
o Ted will notify Secretariat when ready to announce
draft-ietf-cdi-scenarios-01.txt
o Ted will send note as well as notify Secretariat when
draft-gustin-goyens-urn-id-02.txt is officially approved and
ready to announce.
o Secretariat to send change in mmusic charter (WG Re-charter) to
IAB, IESG and WG Chairs. After one week, if ok, Jon will tell
the Secretariat to send this charter to ietf-announce and
new-work.
o Secretariat to send ldup WG Action/Re-charter announcement to
IAB, IESG, WG Chairs. If nothing happens, in one week Ted will
ask Secretariat to announce.
o Secretariat to send grow WG Action announcement to
ietf-announce, install charter.
o After netconf WG Chairs are approved, Bert will ask Secretariat
to send WG Action to ietf-announce, cc: WG Chairs.
o Alex to send DNP message for draft-srisuresh-ospf-te-05.txt to
Secretariat to send on behalf of IESG.
o Steve to generate a summary of IESG views of the "problem"
o Steve to propose a different document classification than the
current info/proposed/etc.
12. Outstanding Action Items:
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
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 [ ] [ ] [ ] [ ]
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.
* Indicate reason if 'Discuss'.
^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.
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-provreg-epp - Extensible Provisioning
Protocol to Proposed Standard
--------
Last Call to expire on: March 29, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ D ] [ ] [ ]
Steve Bellovin [ ] [ ] [XX ] [ D ]
Scott Bradner [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ XX] [ X ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ 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
-------
Steve:
> <draft-ietf-provreg-epp-07.txt>
Do we put mailing list names and URLs in RFCs?
I'd like a stronger Security Considerations section, though I think
it can be added by an RFC Editor note. In particular, I want it to
say that EPP "MUST NOT be used over a transport mechanism that does
not provide confidentiality", or "All transport mappings for EPP
MUST provide confidentiality and integrity". (I think that that's what
they intend, but it's not clear enough.)
> <draft-ietf-provreg-epp-domain-05.txt>
What is an "authorization token"? It's not defined, but it's mandated
by the security considerations. (I suspect it's what is discussed in
2.6, but it doesn't use the same words.)
> <draft-ietf-provreg-epp-contact-05.txt>
What is an "authorization token"? It's not defined, but it's mandated
by the security considerations. (I suspect it's what is discussed in
2.8, but it doesn't use the same words.)
> <draft-ietf-provreg-epp-tcp-05.txt>
The Security Considerations section seems to require TLS client
authentication, which in turn requires client certificates. Is this
intended? If so, great! But in that case, what is the fate, if any,
of the EPP login/password command? Is it still needed? Is it still
legal? What does it mean? Must the identities agree? (The requirement
for server authentication is excellent, but some more text mentioning
the need to validate the certificate chain is probably a good idea.)
Scott:
note:
draft-ietf-provreg-epp-07.txt sec 2.1
I think it would be good to be a bit more strict about
the use of congestion control protocols specifically require
the use of an IETF standards track congestion control
protocol such as TCP or SCTP
i.e. change the following line:
- The transport mapping MUST manage congestion.
to:
- The transport mapping MUST only be to an IETF standards
track congestion control protocol such as TCP or SCTP.
Bert: document: draft-ietf-provreg-epp-07.txt
page 12, example greeting has:
S: <svID>Example EPP server epp.example.tld</svID>
in an example greeting. Did we not decide at some point
that examples should be of the form: epp.example.org ??
Patrik answers:
> We should follow RFC 2606 which states that:
>
> 3. Reserved Example Second Level Domain Names
>
> The Internet Assigned Numbers Authority (IANA) also
> currently has the
> following second level domain names reserved which can be used as
> examples.
>
> example.com
> example.net
> example.org
>
>
> I.e. using "tld" as an example top level domain is wrong.
>
> Can you please have a discuss on this?
>
Sure... it seemed more like a small nit to me, in any event, such a
discuss I think can be cleared with a RFC-Editor note.
Allison:
ISSUES with draft-ietf-provreg-epp-07.txt
1.
The transport mapping MUST manage congestion.
This wording would be better replaced by the following (and
my comment takes into account both Scott's request and
the fact that the transport mapping may be over SMTP or
something other than a "transport" such as TCP or SCTP.
The transport mapping MUST be onto a transport such
as TCP or SCTP that provides congestion avoidance that
follows RFC 2914, or if it maps onto a protocol such
as SMTP or BEEP, then the performance issues need to
take into account issues of overload, server availability
and so forth.
2.
Within the optional dcp (data collection policy) element:
there is a non-technical spin in at least the
following label definition, what kind of marketing is meant?
<contact/>: Contact for marketing purposes.
Please add more to this definition so that is more neutral in
in its terminology.
About the recipient and data retention
elements - how would they provide a means to allow provisioning
a strick privacy policy in some use of EPP (they are not used
in one of the companion documents? The author is asked to
give a few sentences to encourage a view that they have teeth
(more so than their parent P3P) in EPP.
3.
This is a general question, but I would like the author, as
an expert on the topic, to send an written answer to the IESG,
not to make a change to this document set:
How does IESG and the community check the extensive XML in a
specification like this (analogous to the ABNF and MIB
checking described that is done regularly...)? How did you
check what's here? Why might it not matter?
******
ISSUES with draft-ietf-provreg-epp-tcp-05.txt
1.
An EPP client streams EPP commands to an EPP server on an established
TCP connection. A client MAY establish multiple TCP connections to
create multiple command exchange channels. A server MAY limit a
client to a maximum number of TCP connections based on server
capabilities and operational load.
It is not a good thing for the net for services to choose
this approach. A MAY like this is problematic for congestion
control reasons. I would like to change this language from
"MAY establish" to "MAY but SHOULD NOT" and from "A server MAY
limit" to "A server SHOULD limit"
2.
For references to TCP, besides RFC 793, you need:
RFC 2581, 2914.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ietf-provreg@cafax.se
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Extensible Provisioning Protocol to Proposed
Standard
-------------
The IESG has approved the following Internet-Drafts as Proposed
Standards:
o Extensible Provisioning Protocol
<draft-ietf-provreg-epp-07.txt>
o Extensible Provisioning Protocol Domain Name Mapping
<draft-ietf-provreg-epp-domain-05.txt>
o Extensible Provisioning Protocol Host Mapping
<draft-ietf-provreg-epp-host-05.txt>
o Extensible Provisioning Protocol Contact Mapping
<draft-ietf-provreg-epp-contact-05.txt>
o Extensible Provisioning Protocol Transport Over TCP
<draft-ietf-provreg-epp-tcp-05.txt>
These documents are the product of the Provisioning Registry Protocol
Working Group. The IESG contact persons are Ned Freed and Patrik
Faltstrom.
Technical Summary
These documents describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository. Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects. Further, object definitions of a few
objects needed for domain name registration and a binding to TCP as
transport protocl is provided.
Working Group Summary
There has been discussions in the wg whether the binding to TCP should
be the only binding, whether other bindings like SMTP and Beep is
"better" or "required" and during last call whether the protcol
itself should be asynchronous or not.
Result of these discussions ended up with TCP as one extension
mechanism of many possible ones (SMTP and Beep bindings in separate
documents), and that the protocol itself should be synchronous. This
last point make the protocol simpler, but will possibly make some
bindings more complicated.
The changes had concensus in the working group, and resulted in the
version of the documents which are now approved.
Protocol Quality
The specification has been reviewed by Patrik Faltstrom for the IESG.
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-ccamp-lmp - Link Management Protocol
(LMP) to Proposed Standard
--------
Last Call to expire on: 2003-4-24
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 [ ] [ ] [ ] [ D ]
Thomas Narten [ ] [ ] [ ] [ D ]
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'.
DISCUSS:
========
Russ:
Section 16.1 says:
o Security mechanism should provide for well defined key
management schemes. The key management schemes should be well
analyzed to be cryptographically secure. The key management
schemes should be scalable.
I think that automated key management SHOULD be provided.
Section 16.2 recommends the use of AH in tunnel mode. I would greatly
prefer ESP in tunnel mode, even if confidentiality is not turned on. In my
opinion, ESP with integrity-only security associations is better.
In section 16.2, the term "crypto channel" is not clear. Usually, it
means "IPsec security association." Yet, sometimes it refers to both the
IKE SA as well as the IPsec SA. I think that IKE SA and IPsec SA can be used.
In section 16.2, please change "man-in-the middle attacks" to
"man-in-the-middle attacks."
Section 16.2 says:
Digital signature based authentication is not prone to such
problems. It is recommended using digital signature based
authentication mechanism where possible. If pre-shared key based
authentication is required, then aggressive mode SHOULD be used.
IKE pre-shared authentication key values SHOULD be protected in a
manner similar to the user's account password.
Please change "recommended" to upper case.
Steve:
I'm not sure how much the ccamp and forces people talk, but isn't this
sentence:
the control channel MUST terminate on the same two nodes
that the TE link spans.
incorrect with remote control elements?
16.2:
The IPsec selectors are all SHOULDs -- what are the MUSTs?
Setting the port number to 0 means that all UDP traffic between
those nodes is protected -- is that right? I though the
document spoke of an LMP port.
The channel identifer is part of the payload, not the IP or UDP
headers, and thus can't be a selector.
IKE is listed as a SHOULD, not a MUST, but the requirements
mandate replay detection. You can't do that with manual keying.
(The requirements also mandate support for manual keying.)
If replay protection is needed, either IKE must be required,
or an application-specific replay protection mechanism must
be defined.
Ted:
In section 3.2.1, there is a recommendation for setting
the default values for the HelloInterval to 150ms and
the HelloDeadInterval to 500ms. The text seems to
indicate that the same default is used when you pass
the traffic over an IP network as when you are
directly connected. This seems low in the presence
of a multi-hop IP network, as you seem likely to end
up in Degraded state unnecessarily. Language indicating
how to judge a deviation from this default would
be very useful.
The draft does not seem to be clear on what happens
if a TestStatusSuccess or TestStatusFailure message
is lost in flight; the current language could be read
to indicate that the same TestStatusAck message
would be sent in both cases (5.0, just above 5.1)
In section 8, Graceful Restart, it is not clear whether
Multicast discovery is re-done on interfaces which
have had Interface_Ids discovered through
that method, or whether these are also assumed
to remain stable.
In section 12.1, how are bits which
are currently reserved later assigned?
Notes:
In the introduction, paragraph 2 the use of "neighboring" is
non-trivially different from the usual, so defining it would
be a good idea.
The first SHOULD occurs before the Terminology definition.
In LMP overview the statement "All LMP packest are run over
UDP with an LMP port number [except in some cases]" would
be better if "Except in for test messages, which may be limited
by the transport mechanism to in-band messaging, all LMP..."
In section 3. there is a requirement for a unique 32-bit
non-zero integer, but no specification for how to ensure uniqueness.
In Section 3.0, is a unicast source address used for the multicast
packet?
In section 3.1, the nodes MAY continue to retransmit Config messages
both when Node_Ids are equal and when a ConfigNack with unacceptable
alternate values is received. Some justification for *why*it would
seems
useful.
In Section 3.2.1, it notes that "if other methods are used to indicate
bi-directional control channel connectivity", but there are no pointers
to other methods; if none are currently specified, it might be
useful to change the language to indicate that.
Is the Verify_Id monotonically increasing, or random?
In 6.0, "procedure can be used to rapidly isolate link failures" seems
to mean data link failures, and it might be better to be more precise.
In Section 7, the statement "Note that the 32-bit Message_Id value MAY
wrap"
does not need an RFC 2119 MAY, since it is a statement of fact, not
an interoperability point.
In 11.3.1, there is a ligatured ae in the text for Down:
COMMENTS:
=========
Bert:
ID-NITS biting me too
Bad chars at 1870
-: 1 lines containing non-US-ASCII characters
RFC-Editor note:
Pls change on page 33, line 1870:
OLD:
(i.e., the link is not \xE6in service')
NEW:
(i.e., the link is not 'in service')
Erik:
I didn't see anything about autorization/access control in
the document. Presumably there is something an implementation needs
to do to associate authority for certain TE links with a particular
IPsec SA.
Nit:
In two places it explicitly talks about 224.0.0.1 even though the
document supports IPv6 for example:
the control channel. This is done by sending the Config message to
the Multicast address (224.0.0.1). The ConfigAck and ConfigNack
How about at least saying "224.0.0.1 or ff02::1" instead.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ccamp@ops.ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Link Management Protocol (LMP) to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Link Management Protocol
(LMP)' <draft-ietf-ccamp-lmp-08.txt> as a Proposed Standard. This
document is the product of the Common Control and Measurement Plane
Working Group. The IESG contact persons are Bert Wijnen and Alex
Zinin.
Technical Summary
For scalability purposes, multiple data links can be combined to
form a single traffic engineering (TE) link. Furthermore, the
management of TE links is not restricted to in-band messaging, but
instead can be done using out-of-band techniques. This document
specifies a link management protocol (LMP) that runs between
neighboring nodes and is used to manage TE links. Specifically, LMP
will be used to maintain control channel connectivity, verify the
physical connectivity of the data links, correlate the link property
information, suppress downstream alarms, and localize link failures
for protection/restoration purposes in multiple kinds of networks.
Working Group Summary
The WG has consensus on this document. In the beginning there was too
much SONET/SDH specific material in this document, but that has now
been moved out into a separate document.
Protocol Quality
This memo has been reviewed for the IESG by 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-murchison-sieve-subaddress - Sieve --
Subaddress Extension to Proposed Standard
--------
Last Call to expire on: 2003-4-25
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Sieve -- Subaddress Extension to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Sieve -- Subaddress
Extension' <draft-murchison-sieve-subaddress-06.txt> as a Proposed
Standard. This has been reviewed in the IETF but is not the product of
an IETF Working Group. The IESG contact persons are Ned Freed and Ted
Hardie.
Technical Summary
On email systems that allow for "subaddressing" or "detailed
addressing" (eg, "ken+sieve@example.org"), it is sometimes desirable
to make comparisons against these sub-parts of addresses. This draft
defines an extension to the Sieve mail filtering language that
allows users to compare against the user and detail parts of an
address.
Working Group Summary
This document is an extension to the sieve mail filtering language
defined in RFC 3028. There are already several implementations of
this extension.
Protocol Quality
Ned Freed reviewed the specification for the IESG.
RFC Editor note
Please change the title of this document to "Sieve Email
Filtering -- Subaddress Extension" to avoid confusion with other
uses of the term "subaddressing"
IP Telephony (iptel)
-----------------------------
The focus of the IP Telephony (iptel) group is on the problems related
to propagation of routing information for VoIP protocols. Specifically,
both SIP and H.323 have the notion of signaling intermediaries (proxies
in SIP and gatekeepers in H.323). When these devices receive call
establishment messages, they must make a routing decision on where to
forward the call setup messages.
The iptel group has already defined a protocol, Telephony Routing over
IP (TRIP), which solves one aspect of this problem. Specifically, it
handles the case where calls need to be routed between domains. It
allows for the exchange of routing information between these
providers, so that policies can be applied to the resulting data to
create a forwarding information base.
However, this protocol does not address all the scenarios of route
information exchange between servers. One important scenario is the
propagation of routing information between gateways and the signaling
servers in front of them. This is also known as "gateway registration".
It allows the signaling server to make a routing decision about which
gateway to use based on dynamic information about the gateway
resources. Vendors have deployed proprietary solutions for this
communications interface. A standard is needed. The group will
generate a standards track document that defines a protocol (possibly
based on TRIP) for this interface.
The group will also generate a MIB document for TRIP.
Note that the group is not working on elevating TRIP to Draft
Standard at this time.
Deliverables:
1. A proposed standard RFC for gateway to server route exchange.
2. A proposed standard TRIP MIB specification, based heavily on the
existing BGP-4 MIB documents.