[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft IESG Telechat Agenda and Package for April 3, 2003
* DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the April 3, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- March 6, 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 Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return to next telechat with discussion points.
o Thomas and Bill to follow up on
draft-ietf-ipngwg-rfc2292bis-09.txt, and notify Secretariat when
it is ready to be announced.
o Alex, Leslie and Harald to discuss announcement text for
draft-zinin-ietf-jtc1-aggr-01.txt. Harald to send note to IAB
and Alex to send announcement text to Secretariat, who will then
announce.
DONE o Secretariat to install paragraph into charter and fix milestone
dates in Network File System Version 4 charter.
IP o Secretariat to send RMT WG Review Message (removing any personal
notes) to IAB and Working Group Chairs. Secretariat to make sure
that any private notes are not publicly visible.
DONE o Randy will suggest slight word change to Problem Statement
milestones. Secretariat to wait for go-ahead from Harald before
announcing.
o Allison and Thomas will email Secretariat note to send to RFC
Editor about 3GPP RFC Editor documents.
DONE o Harald to draft an announcement about Alex becoming Sub-IP AD.
o Secretariat to modify auto-response for Internet-Drafts to point
to I-D Nits.
o Secretariat to email Working Group Chairs after each conference
with pointer to I-D Nits.
2. Protocol Actions
o Multicast Router Discovery (Proposed Standard)
<draft-ietf-idmr-igmp-mrdisc-10.txt>
Token: Fenner, Bill
o Mobility Support in IPv6 (Proposed Standard)
<draft-ietf-mobileip-ipv6-21.txt>
Token: Narten, Thomas
o Traffic Engineering Extensions to OSPF Version 2 (Proposed
Standard)
<draft-katz-yeung-ospf-traffic-09.txt>
Token: Fenner, Bill
o Enhanced Compressed RTP (CRTP) for links with high delay,packet
loss and reordering (Proposed Standard)
<draft-ietf-avt-crtp-enhance-07.txt>
Token: Mankin, Allison
Note: 07 was Last Called - it had clarification fixes.
o On the Use of SCTP with IPsec (Proposed Standard)
<draft-ietf-ipsec-sctp-04.txt>
Token: Housley, Russ
Note: Responsible: Housley
o Definitions of Managed Objects for the SONET/SDH Interface Type
(Draft Standard)
<draft-ietf-atommib-rfc2558bis-01.txt>
Token: Nordmark, Erik
Note: The implementation report can be viewed at
http://www.ietf.org/IESG/Implementations/RFC2558-Implementation.txt
o Textual Conventions for MIB Modules Using Performance History
Based on 15 Minute Intervals (Draft Standard)
<draft-ietf-atommib-rfc2493bis-01.txt>
Token: Nordmark, Erik
Note: The implementation report can be viewed at
http://www.ietf.org/IESG/Implementations/RFC2493-Implementation.txt
o Definitions of Managed Objects for the Optical Interface Type
(Proposed)
<draft-ietf-atommib-opticalmib-08.txt>
Token: Nordmark, Erik
o Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol
(L2TP) (Proposed Standard)
<draft-ietf-l2tpext-v92-moh-04.txt>
Token: Narten, Thomas
Note: 2003-03-25: looks fine, except RFC 2434 reference should be
normative; will put back on next agenda and have authors resubmit
in parallel.
o IP Header Compression over PPP (Proposed Standard)
<draft-koren-pppext-rfc2509bis-03.txt>
Token: Mankin, Allison
Note: IPHC over PPP is quite useful for tunnels for the GSM folks
- this bis adds support for ECRTP (see draft-ietf-avt-ecrtp) and
some fixes that were waiting for a rev for quite a while. Also
reviewed by Thomas Narten.
3. Under Discussion
o Internet Printing Protocol (IPP): Event Notifications and
Subscriptions (Proposed Standard)
<draft-ietf-ipp-not-spec-11.txt>
Token: Freed, Ned
Note: Template submitted; on IESG agenda
o Internet Printing Protocol: Requirements for IPP
Notifications (Informational)
<draft-ietf-ipp-not-06.txt>
o Internet Printing Protocol (IPP): The 'ippget' Delivery
Method for Event Notifications (Proposed Standard)
<draft-ietf-ipp-notify-get-09.txt>
4. Working Group Submissions
o Security Requirements for Keys used with the TCP MD5 Signature
Option (Informational)
<draft-ietf-idr-md5-keys-00.txt>
Token: Fenner, Bill
o Requirements for IP Flow Information Export (Informational)
<draft-ietf-ipfix-reqs-09.txt>
Token: Bush, Randy
5. Individual Submissions
o Multihoming issues in the Stream Control Transmission Protocol
<draft-coene-sctp-multihome-03.txt>
Token: Mankin, Allison
Note: Architecture review requested - this document assumes hosts
should know routing paths.
o A URN Namespace for MACE (Informational)
<draft-hazelton-mace-urn-namespace-02.txt>
Token: Hardie, Ted
o Base Encodings of Data (Request)
<draft-josefsson-base-encoding-04.txt>
Token: Freed, Ned
o The application/smil and application/smil+xml Media Types
(Informational)
<draft-hoschka-smil-media-type-11.txt>
Token: Freed, Ned
Note: To be added to IESG agenda
o Counter with CBC-MAC (CCM) (Informational)
<draft-housley-ccm-mode-02.txt>
Token: Bellovin, Ste
o Security Mechanisms for the Internet (Informational)
<draft-iab-secmech-02.txt>
Token: Nordmark, Erik
Note: The IAB is requesting comments on this before they send it
to the rfc-editor for publication. (Note that the rfc-editor
doesn't route IAB documents through the IESG 2 week timeout any
more).
6. Proposed Working Groups
o Lemonade
7. Working Group News we can use
8. IAB News we can use
9. Management Issues
o Disposition of former IESGers' DISCUSS ballots
o BGP and RFC2385
o automated key management
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
March 6, 2003
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bradner, Scott / Harvard
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Coya, Steve / IETF
Daigle, Leslie / Verisign (IAB)
Faltstrom, Patrik / Cisco
Fenner, Bill / AT&T
Freed, Ned / Innosoft
Hardie, Ted / Qualcomm, Inc.
Hargest, Jacqueline / IETF
Housley, Russ / Vigil Security, LLC
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Peterson, Jon / NeuStar, Inc.
Reynolds, Joyce K. / ISI (RFC Editor)
Schiller, Jeff / MIT
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Nordmark, Erik / Sun
Minutes
-------
1. The minutes of the February 20, 2003 teleconference were approved,
pending change in wording about DHC "recharter". Secretariat to then
place in public archives.
2. The following action items were reported as DONE:
DONE o Patrik to take action on elevating RFC2279 to Standard.
DONE o Allison to send Secretariat message that
draft-malis-sonet-ces-mpls is resolved once she receives a
reply.
DONE o Steve Bellovin to use channel to firewall vendors wrt
draft-ietf-tsvwg-tcp-nonce-04.txt
DONE o Bert will follow up to make sure we have agreement from JORGE
wrt IANA MIB Copyright.
DONE o Thomas will ask the WG whether they want to publish
draft-ietf-ipngwg-addr-arch-v3-11.txt as a Proposed Standard.
DONE o Scott will draft "how to inform the community about ID Nits".
3. Protocol Actions APPROVED:
The IESG has approved the Internet-Draft 'IP Version 6 Addressing
Architecture' <draft-ietf-ipngwg-addr-arch-v3-11.txt> as a Proposed
Standard. Secretariat to announce.
4. Document Actions APPROVED:
The IESG has approved the Internet-Draft 'A Flexible Method for
Managing the Assignment of Bits of an IPv6 Address Block'
<draft-ietf-ipv6-ipaddressassign-06.txt> as an Informational RFC.
Secretariat to send announcement.
The IESG has approved the Internet-Draft 'Draft of agreement between
ISOC/IETF and SO/IEC JTC1/SC6 on IS-IS protocol development'
<draft-zinin-ietf-jtc1-aggr-01.txt> as an Informational RFC.
Note: Alex, Leslie and Harald to discuss announcement text. Harald to
send note to IAB. Alex to send announcement text to Secretariat, who
will then announce.
The IESG has approved the Internet-Draft 'Terminology Used in
Internationalization in the IETF' <draft-hoffman-i18n-terms-11.txt>
as an Informational RFC. Secretariat to send announcement.
5. Document Actions TENTATIVELY APPROVED:
o Advanced Sockets API for IPv6 (Informational)
<draft-ietf-ipngwg-rfc2292bis-08.txt>
Note: Thomas and Bill to follow up on this document, and notify
the Secretariat when it is ready to be announced.
o Ad Hoc On Demand Distance Vector (AODV) Routing (Experimental)
<draft-ietf-manet-aodv-13.txt>
Note: After addressing Steve's comments, Alex will notify
the Secretariat that this can be announced.
6. The following documents are still under DISCUSSION:
o Mobility Support in IPv6 (Proposed Standard)
<draft-ietf-mobileip-ipv6-21.txt>
o Generalized Multiprotocol Label Switching Extensions for SONET
and SDH Control (Proposed Standard)
<draft-ietf-ccamp-gmpls-sonet-sdh-08.txt>
o Advice for Internet Subnetwork Designers (BCP)
<draft-ietf-pilc-link-design-13.txt>
o Requirements for support of Diff-Serv-aware MPLS Traffic
Engineering (Informational)
<draft-ietf-tewg-diff-te-reqts-07.txt>
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
7. Working Group Actions:
o Network File System Version 4
Note: Secretariat to install paragraph into charter and fix
milestone dates.
o IPv6
Note: Revised charter tentatively approved; waiting for final
go-ahead from Thomas.
o Reliable Multicast Transport
Note: Secretariat to send WG Review Message (removing any personal
notes) to IAB and Working Group Chairs. Secretariat to make sure
that any private notes are not publicly visible.
o Problem Statement
Note: Scott will suggest slight word change to milestones.
Secretariat to wait for go-ahead from Harald before announcing.
o AAA
Note: Secretariat to update revised charter.
o BMWG
Note: Secretariat to update revised charter.
8. NEW Action Items:
o Thomas and Bill to follow up on
draft-ietf-ipngwg-rfc2292bis-09.txt, and notify Secretariat when
it is ready to be announced.
o Alex, Leslie and Harald to discuss announcement text for
draft-zinin-ietf-jtc1-aggr-01.txt. Harald to send note to IAB
and Alex to send announcement text to Secretariat, who will then
announce.
o Secretariat to install paragraph into charter and fix milestone
dates in Network File System Version 4 charter.
o Secretariat to send RMT WG Review Message (removing any personal
notes) to IAB and Working Group Chairs. Secretariat to make sure
that any private notes are not publicly visible.
o Scott will suggest slight word change to Problem Statement
milestones. Secretariat to wait for go-ahead from Harald before
announcing.
o Allison and Thomas will email Secretariat note to send to RFC
Editor about 3GPP RFC Editor documents.
o Harald to draft an announcement about Alex becoming Sub-IP AD.
o Secretariat to modify auto-response for Internet-Drafts to point
to I-D Nits.
o Secretariat to email Working Group Chairs after each conference
with pointer to I-D Nits.
9. 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 Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return to next telechat with discussion points.
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-idmr-igmp-mrdisc - Multicast Router
Discovery to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
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>, idmr@cs.ucl.ac.uk
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Multicast Router Discovery to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Multicast Router Discovery'
<draft-ietf-idmr-igmp-mrdisc-10.txt> as a Proposed Standard. This
document is the product of the Inter-Domain Multicast Routing Working
Group. The IESG contact persons are Bill Fenner and Alex Zinin.
Technical Summary
This document describes Multicast Router Discovery for both IPv4 and
IPv6. For IPv4, Multicast Router Discovery is a direct translation
of ICMP Router Discovery (RFC 1256); for IPv6 it is an extension to
the Router Advertisement messages of the ICMP Neighbor Discovery
protocol.
Multicast Router Discovery performs two tasks. It allows devices
such as IGMP-snooping switches to discover multicast routers in a
protocol-independent way; without Multicast Router Discovery such
devices have to snoop each type of routing protocol Hello to guess
which ports point to multicast routers. In addition, it allows
multicast routers to convey configuration parameters, such as the
SSM group range, to all hosts on the subnet.
Working Group Summary
There was working group consensus on this document.
Protocol Quality
Bill Fenner reviewed the spec 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-mobileip-ipv6 - Mobility Support in
IPv6 to Proposed Standard
--------
Last Call to expire on: 2003-2-6
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 [ ] [ D ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ X ] [ DD]
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:
For a spec of this length, complexity, and security sensitivity, I'm
remarkably happy with it. I have some issues, but I suspect that most
can be resolved pretty easily. It was a delight to be able to delete
some of my notes as I progressed through the document. Furthermore,
given the length and complexity of the spec, I could easily be wrong
about many of these points. I'd be delighted if that were the case.
5.1 In my opinion, IKE support should be a SHOULD, not a MAY. I
have problems with the replay protection (see below).
5.2.5 The figure shows the Home Test Init message going from the
mobile->home agent->correspondent. The text says that
it goes from the mobile->correspondent. Which is it?
There are a number of HMAC'd fields floating around. Some, at
least, seem to have a distinguishing type value, such as 0 in
the home keygen token. The Binding Update takes a parameter
with a BU in the last byte. Is that intended to serve the same
purpose? I don't see a value for BU defined anywhere -- is that
the '5' in Section 14? If so, the 0 and 1 shouldn't overlap
that type space, and there should be an explicit statement about
the reserved values in Section 14, so that no future IANA
assignments conflict with them. I'd also like the authors to
verify that all HMAC'd fields have such such type code that is
never used elsewhere.
6.1.7 The text here (and in 6.1.8 and 6.1.9) should note that the
authorization option is mandatory. It says so later, but not
that clearly.
6.2.6 Should Mobility Data include the home address? The option
doesn't seem to protect other data, including things like
lifetime, sequence #, etc.
7.5 Those advertisement frequencies scare me -- they're quite high.
Worse yet, the most likely place they're needed -- microcells --
have limited bandwidth.
7.6 Which link is this link-local local to? The home network?
9.5.1 If there's no IPsec-level replay protection, this sequence number
just won't do the trick. A wireless mobile node could very
easily generate enough binding updates per day that an enemy
could replay old ones that appeared to be in the window.
10.3.1 Has the IPsec wg verified that K=1 really works? I'm not
convinced of it, since some cookies are address-dependent.
Beyond that, the SPD and the SADB will need to change as the
source and destination IP addresses change.
10.4.5 In the absence of ESP -- and why would it be omitted? --
how can the home agent reliably verify that the source address
in the tunnel IP header is legitimate? I'd say that reverse-
tunneled packets MUST be discard unless ESP-protected. (I'm
astonished that it isn't even a SHOULD.)
11.3.5 Should some sort of timeout be associated with the fact that
a certain destination address can't accept Mobility Headers?
11.7.2 Same comment about sequence number processing
Erik:
I'd like to finish reading it thus I have both a discuss and a
defer :-)
Comments on draft-ietf-mobileip-ipv6-21.txt
I've so far only read about half the spec, but overall, especially
given its size, it looks very well written. (I was expecting to see
lots of inconsistencies but find very few.)
Substantial:
Section 2:
o The movement detection mechanism in Mobile IPv6 provides
bidirectional confirmation of a mobile node's ability to
communicate with its default router in its current location.
But this is not sufficient when there are more than one router
on the visited link. In many cases each of those routers will
be used to forward inbound packets towards the MNs COA.
Thus the fact that the MN knows that it has bidirectional
connectivity with one router on the link is no guarantee for it to be
able to communicate when there are more than one router on the link.
So unless the purpose of this detection in section 11.5.1
is to provide an indication to the MN to do a handover to a different
link I don't see the benefit of this.
The mechanism adds complexity to the notion of reachability beyond
what is done in RFC 2461.
I haven't seen any discussion of the duplicate address detection
changes in section 7.6 in the IPv6 WG.
While these changes seem harmless I'm concerned about them being
included in such a huge specification which makes them less likely
to receive careful review. Can't this be handled separately by a
small specification?
Minor:
The abstract and introduction have text of the flavour:
This document specifies the operation of the IPv6 Internet with
mobile computers.
I think the scope of the specification is quite narrower for instance
it doesn't specify any operational procedures for the Internet.
I think it is more accurate to say e.g.
This document specifies a protocol which allows IPv6 nodes
to move around in the Internet while remaining reachable at
a fixed IPv6 address.
It makes sense to make it more clear that the specification doesn't
prevent a MN from having multiple home addresses.
I suggest clarifying this in the definitions section by:
home address
A unicast routable address assigned to a mobile node, used as
the permanent address of the mobile node. This address is within
the mobile node's home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home address to its
home link.
ADD When there are multiple home prefixes on the home link the mobile
node will have multiple home addresses.
care-of address
A unicast routable address associated with a mobile node while
visiting a foreign link; the subnet prefix of this IP address is
a foreign subnet prefix. Among the multiple care-of addresses
that a mobile node may have at any given time (e.g., with
different subnet prefixes), the one registered with the mobile
node's home agent is called its "primary" care-of address.
Change "home agent" to "home agent for a given home address".
Section 5.2.5 says:
For improved security, the data passed between the home agent
and the mobile node can be made immune to inspection and passive
attacks. Such protection can be gained by encrypting the home
keygen token as it is tunneled from the home agent to the mobile
node as specified in Section 10.4.6.
which reads like an optional thing
but in 10.4.6 the support for this is mandatory.
Suggest rewording the above by s/can be/is/ in two places in the text.
Section 7.2 and 7.5 are inconsistent.
The former says that routers MAY and the latter says they SHOULD
include at least one R-bit prefix.
Nits:
The document uses the term "byte" about 5 times, and otherwise uses
"octet". Why not use "octet" throughout?
The definition of "registration" vs. "binding procedure" seem
confusing. Are they intended to mean exactly the same thing or
something slightly different? Perhaps the term "registration" isn't
needed or the relationship between the terms can be clarified somehow.
Section 4.1 says:
Mobile IPv6 also provides support for multiple home agents, and
the reconfiguration of the home network.
Given that the security aspects of renumbering the home link are not
worked out it makes sense to tone down the language somehow.
Section 4.2 says:
These four messages are used to initiate the return
routability procedure from the mobile node to a correspondent
node.
I thought "perform" would be more accurate than "initiate"
since the 4 messages is the entirety of the RR procedure, right?
Section 4.2:
Binding Refresh Request
A Binding Refresh Request is used to request a mobile node to
re-establish its binding with the correspondent node.
Hard for a new reader to understand that only CN send BRs (and not e.g.
a HA). Change "used" to "used by a correspondent node".
Section 4.6:
Mobile nodes may not be aware of which site they are currently on, it
s/on/in/
Section 6.7 doesn't state whether or not ICMP Mobile Prefix
Solicitation Messages can carry options. I think RFC 2461 router
solicitations can which is why I think it makes sense to be explicit
on this point.
It would be useful to state in section 6.7 and 6.8 respectively
that these are just slightly modified router solicitation and
router advertisement messages to make it more obvious
that they use the RFC 2461 option format etc.
Erik:
> 6.1.7 The text here (and in 6.1.8 and 6.1.9) should note that the
> authorization option is mandatory. It says so later, but not
> that clearly.
I think it is only mandatory for BUs to a correspondent - BUs to
a home agent are protected with IPsec.
Erik
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mobile-ip@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Mobility Support in IPv6 to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Mobility Support in IPv6'
<draft-ietf-mobileip-ipv6-21.txt> as a Proposed Standard. This
document is the product of the IP Routing for Wireless/Mobile Hosts
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
This document specifies the Mobile IP protocol for IPv6. Mobile IP
allows a node to move around the internet, yet keep the same
address while continue to communicate transparently with other
nodes as it moves. Each mobile node is identified by its home
address, regardless of its current point of attachment to the
Internet. While situated away from its home, a mobile node is also
associated with a care-of address, which provides information about
the mobile node's current location. IPv6 packets addressed to a
mobile node's home address are transparently routed to its care-of
address. The protocol enables IPv6 nodes to cache the binding of a
mobile node's home address with its care-of address, and to then
send any packets destined for the mobile node directly to it at
this care-of address.
Mobile IP for IPv6 includes a route optimization mechanism that
allows communicating nodes to forward packets directly to each
other without having to relay all traffic via a Home Agent at the
mobile node's home address. Route optimization can be invoked
between arbitrary nodes without the need for some pre-existing
shared security relationship. Route optimization uses a
return-routablity procedure to verify the safety of performing
route optimization.
Working Group Summary
This document has been under very long development within the WG. It
was brought to the IESG over a year ago, but was sent back to the WG
in order to make changes to the security properties of route
optimization. That led to the development of the return-routability
mechanism.
There is strong support for moving this document forward, and there
continues to be frustration at the length of time this document has
been under development.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
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 [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
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>, 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 Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-avt-crtp-enhance - Enhanced Compressed
RTP (CRTP) for links with high delay, packet loss and
reordering to Proposed Standard
--------
Last Call to expire on: 2003-3-19
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
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.
* Indicate reason if 'Discuss'.
^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: Enhanced Compressed RTP (CRTP) for links
with high delay, packet loss and reordering to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Enhanced Compressed RTP
(CRTP) for Links with High Delay, Packet Loss and Reordering'
<draft-ietf-avt-crtp-enhance-07.txt> as a Proposed Standard. This
document is the product of the Audio Video Transport Working Group.
The IESG contact persons are Allison Mankin and Jon Peterson.
Technical Summary
This document describes a header compression scheme for point to point
links with packet loss and long delays. It is based on Compressed
Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression
described in RFC 2508. Original CRTP does not perform well on such
links: packet loss results in context corruption and due to the long
delay, excessive packets are discarded before the context is
repaired. To correct the behavior of CRTP over such links, a few
extensions to the protocol are specified here. The extensions aim to
reduce context corruption by changing the way the compressor updates
the context at the decompressor: updates are repeated and include
updates to full and differential context parameters. With these
extensions, ECRTP performs well over links with packet loss, packet
reordering and long delays.
The distinction is made that ECRTP is robust for links with
reordering such as tunnels and multihop, and it is also robust for
cellular links with high loss but that ROHC (RFC 3095) is expected
"to be the preferred compression mechanism over links where
compression efficiency is important" and packet misordering is
infrequent.
Working Group Summary
The working group supported advancement of this document. There were
no Last Call concerns with the document, but Area Director comments
resulted in clarifications on IPv6, Security considerations, and
applicability.
Protocol Quality/Review
This document was reviewed for the IESG by Allison Mankin.
The Transport Area seeks information about implementations of ECRTP
and their performance.
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-ipsec-sctp - On the Use of SCTP with
IPsec to Proposed Standard
--------
Last Call to expire on: June 18, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ R ]
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 [ X ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
=======
Scott: MUST used but not defined
the abstract does not meet RFC Editor guidelines
IANA consideration
No actions by IANA are required (yet).
"yet" huh?
the references needs to be split into normative & non-normative
Erik:
Comments:
The introduction says:
This document presents some considerations on the use of SCTP
in conjunction with IPsec.
I thought this document was going to standardize how to use SCTP
with IPsec, not merely provide some considerations??? Some
more accurate language would be good.
4. Security Considerations
This documents discusses the use of a security protocol
(IPsec) in the context of a new transport protocol (SCTP).
It would be nice to have this section talk about threats,
mitigations, and any residual threats. If there is nothing SCTP
specific for those 3 parts, having the document explicitly say so
would be useful.
Thomas:
1) The document talks about how to handle multiple IP addresses (since
an SCTP endpoint may have multiple equivalent IP addresses available
for use). But the discussion about allowing an SA created for one
particular IPsrc/IPdst pair to automatically extend to other
IPsrc/IPdst pairs associated with that SCTP session seem to have
authorization issues that are not discussed and may lead to problems.
Consider a host with the address A. It can set up a phase I IKE SA,
and then during phase II, indicate that it not only has address A, but
(say) address B, where B could be any address (e.g., MIT's). But the
host may not be authorized create an SA for address B. Yet the current
document says it should in fact do that (i.e., create "alias" SAs for
all possible address combinations of addresses that the SCTP session
may be using). Seems like there are some security/DOS issues that at
the very least need to be discussed.
2) Overall, this document seems a bit unclear about what is actual
required to be implemented. I think this is a matter of writing style
(more use of active voice, less use of passive voice would help, for
example). Also, the document talks more about what an implementation
might/could do instead of saying "implementions should/must do X, Y, &
Z". Unfortunately, the ormer doesn't generally lead to clear guidance
ot the implementor and thus may result in interoperability problems.
Examples:
This document presents some considerations on the use of SCTP in
conjunction with IPsec. In particular, we discuss some additional
support in the form of a new ID type in IKE [RFC2409] and some
implementation choices in the IPsec processing to accomodate for
the multiplicity of source and destination addresses associated
with a single SCTP association.
It talks about "considerations" and "implementation choices", rather
than just clearly saying here is what you need to do.
IPsec implementations should already be able to use the SCTP
transport protocol number as assigned by IANA as a selector in their
Security Policy Database (SPD). It should be possible to use the
SCTP source and destination port numbers as selectors in the SPD.
Since the concept of a port, and its location in the transport
header is protocol-specific, the IPsec code responsible for
identifying the transport protocol ports has to be suitable modified.
If the above is really true, why is this spec needed? I suspect that
what is the case is that adding support for SCTP will be easy in most
implementaitons because of the similarity with UDP and TCP ports. But
what I'd expect this document to still say is that implementations
must support SPD rules that use SCTP port numbers, etc.
In order to accomodate the same simple scenario in the context of
multiple source/destination addresses in an SCTP association, it
must be possible to:
The above states what is needed in order for this to work. But the use
of passive voice makes it unclear whether the following is required of
implementations.
Note that the inefficient method described in 3a) seems to work
without using the proposed extensions. Are implementations that only
do that compliant with this spec? I would assume not, but this is not
clear from the wording. I.e., where does it say the recipients must
handle the new offers/ID types?
Note: I haven't cited all text, jut given some examples. It would be
good to make a pass through the document with the above issues in mind.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ipsec@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: On the Use of SCTP with IPsec to Proposed
Standard
-------------
The IESG has approved the Internet-Draft On the Use of SCTP with IPsec
<draft-ietf-ipsec-sctp-04.txt> as a Proposed Standard. This document
is the product of the IP Security Protocol Working Group. The IESG
contact persons are Jeffrey Schiller and Steve Bellovin.
Technical Summary
SCTP introduces the notion that a protocol end-point might have
multiple IP addresses associated with it at one time (as a multi-homed
host is). By specifying a set of addresses associated with each
end-point, it can provide increased reliability in the event that one
of its addresses become unreachable.
IPSEC on the other-hand was designed with the notion that one host is
one address. Important data structures such as SPD entries tend to be
tied to an address.
This document recommends implementation strategies (i.e., changes that
do not require a "wire protocol" change) that can make for more
efficient uses of IPSEC in multi-homed SCTP environments. It also
recommends a new IKE payload to facilitate negotiating a list of
addresses in place of a single address (the ID_LIST ID payload).
Working Group Summary
The working group had consensus on this document.
Protocol Quality
This document has been reviewed for the IESG by Jeff Schiller.
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-atommib-rfc2558bis - Definitions of
Managed Objects for the SONET/SDH Interface Type to Draft
Standard
--------
Last Call to expire on: 2003-2-18
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
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>, atommib@research.telcordia.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definitions of Managed Objects for the
SONET/SDH Interface Type to Draft Standard
-------------
The IESG has approved the Internet-Draft 'Definitions of Managed
Objects for the SONET/SDH Interface Type'
<draft-ietf-atommib-rfc2558bis-01.txt> as a Draft Standard. This
document is the product of the AToM MIB Working Group. The IESG
contact persons are Erik Nordmark and Thomas Narten.
The implementation report can be viewed at
http://www.ietf.org/IESG/Implementations/RFC2558-Implementation.txt
Technical Summary
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP-
based internets. In particular, it defines objects for
managing Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) interfaces. This document is a
companion to the documents that define Managed Objects for the
DS1/E1/DS2/E2 and DS3/E3 Interface Types.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The document has been 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-atommib-rfc2493bis - Textual
Conventions for MIB Modules Using Performance History Based
on 15 Minute Intervals to Draft Standard
--------
Last Call to expire on: 2003-2-18
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
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>, atommib@research.telcordia.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Textual Conventions for MIB Modules Using
Performance History Based on 15 Minute Intervals to Draft
Standard
-------------
The IESG has approved the Internet-Draft 'Textual Conventions for MIB
Modules Using Performance History Based on 15 Minute Intervals'
<draft-ietf-atommib-rfc2493bis-01.txt> as a Draft Standard. This
document is the product of the AToM MIB Working Group. The IESG contact
persons are Thomas Narten and Erik Nordmark.
The implementation report may be viewed at
http://www.ietf.org/IESG/Implementations/RFC2493-Implementation.txt
Technical Summary
This document defines a set of Textual Conventions for MIB
modules which make use of performance history data based on 15
minute intervals.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The document has been 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-atommib-opticalmib - Definitions of
Managed Objects for the Optical Interface Type to Proposed
Standard
--------
Last Call to expire on: 2003-2-19
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
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>, atommib@research.telcordia.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definitions of Managed Objects for the
Optical Interface Type to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Definitions of Managed
Objects for the Optical Interface Type'
<draft-ietf-atommib-opticalmib-08.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.
Technical Summary
This memo defines a portion of the Management Information Base (MIB)
for use with SNMP in TCP/IP-based internets. In particular, it
defines objects for managing Optical Interfaces associated with
WavelengthDivision Multiplexing systems or characterized by the
Optical Transport Network (OTN) in accordance with the OTN
architecture defined in ITU-T Recommendation G.872.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The document has been reviewed for the IESG by Erik Nordmark, Bert
Wijnen and Mike Heard.
Note
When the references in draft-ietf-atommib-opticalmib-08.txt
were reorganized to and conform to the new MIB boilerplate one of
the references that went away was RFC 2571. It was not replaced
because the MIB boilerplate no longer requires it; in this case,
however, RFC 3411 should have appeared in its place because the
OPT-IF-MIB imports SnmpAdminString from SNMP-FRAMEWORK-MIB. Sorry
that I did not catch this earlier. Perhaps if nothing else comes
up in IESG review this can be handled by a note to the RFC Editor
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-l2tpext-v92-moh - Signalling of
Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) to
Proposed Standard
--------
Last Call to expire on: 2002-12-6
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 [ ] [ ] [ ] [ ]
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:
========
Scott:
notes (non-blocking):
references need to be split
full of ^Ms
note (blocking)
do not understand
0000 0 Reserved for the ITU
...
1110 14 Reserved for the ITU
1111 15 Reserved for the ITU
and
The Modem On-Hold Status AVP includes an enumerated value,
called "Timeout", whose value is defined by ITU in [V92].
I think these need to be explained in this document
COMMENTS:
=========
Steve:
Nit: the abstract is several paragraphs; will that fly?
Allison:
Nit: Even if V.92 is a major modem that uses modem on hold, I think
it should not be mentioned in the abstract - this should be generalized -
but I don't care enough about this even to require an RFC Editor note -
only make the fix if someone else insists on opening the document. I think
it is a careful document (I'm sure due to some careful work before getting
to us).
Thomas:
Scott Bradner <sob@harvard.edu> writes:
> notes (non-blocking):
> references need to be split
Oops..
> full of ^Ms
Hmm.. my version doesn't have this problem.
> note (blocking)
> do not understand
> 0000 0 Reserved for the ITU
> ...
> 1110 14 Reserved for the ITU
> 1111 15 Reserved for the ITU
I believe this is copied from the ITU spec. I.e.,
> The Timeout field is a 4 bits quantity that indicates the negotiated
> maximum amount of time that the call can remain on-hold. It is only
> valid if the H bit is 1 and it MUST be ignored if the H bit is 0. The
> value of this field is defined in [V92] and it is reproduced here for
> easy reference:
Note the last part of the paragraph.
> and
> The Modem On-Hold Status AVP includes an enumerated value, called
> "Timeout", whose value is defined by ITU in [V92].
> I think these need to be explained in this document
Should they? Note that the document (in the introduction) says the
following:
> This document provides additional L2TP AVPs and control messages that
> may be used to communicate some modem information from the LAC to the
> LNS. However, it does not define what, if anything, the LNS should
> do with this information. A sample of the possible actions that an
> LNS may consider are listed in section 5.
I.e., this AVP provides info, and the document gives examples of how
the info can be used, but doesn't make any hard recommendations.
That said, I'm willing to go ask the author/WG if it makes sense to
add more explicit text here.
Scott:
> I believe this is copied from the ITU spec. I.e.,
it could say that & say what process (or who) is used in the ITU is
used to unreserve them
> Should they? Note that the document (in the introduction) says the
> following:
I think so - I see little reason to try to hide the information
Thomas:
> Nit: the abstract is several paragraphs; will that fly?
I would assume so. We've always had multi-paragraph abstracts. In this
case it is 4, but the total number of words is not that large.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, l2tpext@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Signalling of Modem-On-Hold status in Layer 2
Tunneling Protocol (L2TP) to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Signalling of Modem-On-Hold
status in Layer 2 Tunneling Protocol (L2TP)'
<draft-ietf-l2tpext-v92-moh-05.txt> as a Proposed Standard. This
document is the product of the Layer Two Tunneling Protocol Extensions
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for
tunneling Point-to-Point Protocol (PPP) sessions. It is common for
these PPP sessions to be established using modems connected over the
public switched telephone network.
One of the standards governing modem operation is the ITU-T
Recommendation V.92, which defines procedures that enable a client
modem to put the call on hold and later, re-establish the modem link
with minimal delay and without having to redial. While the modem
call is on hold, the client phone line can be used to place or
receive other calls.
The L2TP base protocol does not provide any means to signal these
events from the L2TP Access Controller (LAC), where the modem is
physically connected, to the L2TP Network Server (LNS), where the PPP
session is handled.
This document describes a method to let the LNS know when a client
modem connected to a LAC has placed the call on hold.
Working Group Summary
There was support for this extension in the WG and no issues were
raised during the Last Call.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
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-koren-pppext-rfc2509bis - IP Header
Compression over PPP to Proposed Standard
--------
Last Call to expire on: 2003-4-5
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
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.
* 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: IP Header Compression over PPP to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'IP Headr Compression Over
PPP" <draft-koren-pppext-rfc2509bis-03.txt> as a Proposed Standard.
This document is not the product of a working group. It was given a
four week Last Call. The IESG contact persons are Allison Mankin, Jon
Peterson, and Thomas Narten.
Technical Summary
The IP Header Compression (IPHC) defined in RFC2507 may be used for
compression of both IPv4 and IPv6 datagrams or packets encapsulated
with multiple IP headers. IPHC is also capable of compressing both
TCP and UDP transport protocol headers. The IP/UDP/RTP header
compression defined in RFC2508 and Enhanced Compressed RTbP (ECRTP)
fits within the framework defined by IPHC so that it may also be
applied to both IPv4 and IPv6 packets.
In order to establish compression of IP datagrams sent over a PPP
link each end of the link must agree on a set of configuration
parameters for the compression. The process of negotiating link
parameters for network layer protocols is handled in PPP by a family
of network control protocols (NCPs). Since there are separate NCPs
for IPv4 and IPv6, this document defines configuration options to be
used in both NCPs to negotiate parameters for the compression scheme.
This document obsoletes RFC 2509, adding two new suboptions to the IP
header compression configuration option. One suboption negotiates
usage of ECRTP and other suboption negotiates header compression
for only TCP or only non-TCP packets.
IPHC relies on the link layer's ability to indicate the types of
datagrams carried in the link layer frames. In this document, nine new
types for the PPP Data Link Layer Protocol Field are defined along
with their meaning.
Working Group Summary
The PPPEXT working group gave a nominal review to this bis document
and did not find errors.
Protocol Quality/Review
This document was reviewed for the IESG by Allison Mankin and Thomas
Narten.
Enhancements to Internet email to support diverse service
environments (lemonade)
----------------------------------------------------------------
Chairs:
Eric Burger <eburger@snowshore.com>
Glenn Parsons <gparsons@nortelnetworks.com>
Mailing lists:
General Discussion: um@snowshore.com
To Subscribe: majordomo@snowshore.com, In Body: subscribe um
Archive: http://flyingfox.snowshore.com/um_archive/maillist.html
Description of Working Group:
Lemonade is tasked to provide a set of enhancements and profiles of
Internet email submission, transport, and retrieval protocols to
facilitate operation on platforms with constrained resources, or
communications links with high latency or limited bandwidth. A primary
goal of this work is to ensure that those profiles and enhancements
continue to interoperate with the existing Internet email protocols in
use on the Internet, so that these environments and more traditional
Internet users have access to a seamless service.
Lemonade's work is at the crossroads of a body of work related to
Internet messaging, in particular work done by the VPIM, FAX, and
IMAPEXT IETF working groups. Given the potentially broad scope of
activities this group could engage in, the group will focus
specifically on the following work items:
0. An informational RFC or RFCs will be produced on LEMONADE
architecture and the issues it seeks to address.
1. Enhance the existing IMAP4 message retrieval and message submission
(RFC 2476) protocols to satisfy the requirements for handling
streaming multimedia content. The existing standards-track
CONNEG framework will be used if content negotiation
capabilities are needed. The group will employ existing
protocols (such as for streaming) with IMAP4 instead of
duplicating such functionality within IMAP4.
2. Enhance the existing IMAP4 message retrieval and/or message
submission (RFC 2476) protocols to satisfy the requirements for
forwarding a message and/or its attachments without downloading
the message to the client and subsequently uploading the
message to a server.
3. Refine the existing IMAP4 message retrieval protocol to facilitate
its use with devices that have limited capabilities such as
mobile endpoints. At most one backwards compatible profile of
IMAP4 will be produced by this effort.
4. Define a format for message notifications for servers reporting
message status information to other servers. Specify the method
for delivery of those notifications.
5. Create a specification describing the use of Internet message
services in environments where message delivery may take place
using either Internet protocols or through an MMS server using
WAP to communicate with the receiving user agent.
Any protocols defined by this working group will include appopriate
security mechanisms, including authentication, privacy, and access
control. Mandatory-to-implement security mechanisms will be specified
as needed in order to guarantee secure protocol interoperability.
The transport area will be consulted to deal with any transport-related
issues that arise, especially in regards to items 1-4 above.
The IAB is currently working on the specification of general guidelines
and requirements for notification services. Once complete this work
will be used as input to item 4 above.
The working group is aware of several related activities in other
groups:
- 3GPP TSG T WG2 SWG3 Messaging <http://www.3gpp.org/TB/T/T2/T2.htm>
- W3C Mulitmodal interaction Activity <http://www.w3.org/2002/mmi/>
- Open Mobile Alliance <http://www.openmobilealliance.org/>
- 3GPP2 TSG-X <http://3gpp2.org/Public_html/X/index.cfm>"
The goal is to coordinate efforts with at least these groups as
required.
While there is obvious synergy, given the end-of-life of the VPIM and
FAX work groups and the similar membership, the working group does not
expect to coordinate with these other groups.
Goals and Milestones:
Jun 2003 - Submit LEMONADE requirements and architecture specification
to the IESG
Jul 2003 - Submit server to server notification protocol to the IESG
Sep 2003 - Submit IMAP4 and message submission extensions for streaming
multimedia to the IESG
Nov 2003 - Submit IMAP4 profile for mobile devices to the IESG
Management Issues:
Automated Key Management
These are a set of guidelines, not rules, for evaluating when automated
key management should or shouldn't be used. Informed judgment is
necessary when applying them.
In this context, "key management" is automatic derivation of
session key(s), as opposite to long-term keys used to
authenticate the derived key(s). How this long-term
key gets to the talking entities and what kind of
a key it is (pre-shared secret, RSA public key, DSA, you-name-it)
is beyond the scope of this document. Examples of key management
systems include IKE and Kerberos; S/MIME and TLS include key
management functions.
A session key is used to protect application data.
In general, automated key management SHOULD be used. This is a
very strong "SHOULD".
Key management MUST be used if:
A central party will have to manage n^2 static keys.
A stream cipher (i.e., RC4) is used.
Long-lived session keys are used by more than two parties.
(Except for multicast, this is a dubious situation in the first
place, and should generally be discouraged no matter what.)
The likely operational environment is one where personnel
(or device) turnover is reasonably frequent, thus creating
a requirement for frequent rekeying.
Even manually-keyed systems need some provision for key changes;
there must be some way to indicate which key is in use, to avoid
problems during transition. Designs should sketch plausible
mechanisms for deploying new keys and/or revoking compromised keys.
If done well, such mechanisms can later be used by an add-on key
management scheme.
Lack of automated key management can lead to vulnerabilities,
including (but not limited to) cryptographic weaknesses or loss of
some functionality, such as replay protection.
Key management software is not always large or bloated; even IKEv1
can be done in <200K, and TLS in half that much space. (TLS includes
other functionality as well.)
Lack of clarity about who the principals are is not a valid reason
for avoiding key management. Rather, it tends to indicate a deeper
problem with the underlying security model.
Key management schemes should not be designed by amateurs; it is
almost certainly inappropriate for WGs to design their own. To
put it in concrete terms, the very first key management protocol
in the open literature was published in 1978. A flaw was published
in 1983. The fix proposed in 1983 was cracked in 1994. In 1996,
a new flaw was found in the original 1978 version, in an area not
affected by the 1983/1994 issue. All of these flaws were blindingly
obvious once described -- but no one spotted them earlier. Note
that the original protocol (translated to know about certificates,
which hadn't been invented at the time) was only 3 messages.
Situations where a desire to avoid key mangement may be reasonable
include:
Very limited available bandwidth or very high round-trip
times. There are interactions here -- public key systems
tend to require long messages and lots of computation;
symmetric key alternatives, such as Kerberos, often require
several round trips and interaction with third parties.
Low value of the information
Very limited scale of each deployment
Note that assertions about such things should often be viewed with
the skepticism afforded to claims that "this will only be used on
a LAN or two". In other words, the burden of demonstrating that
manual key management is appropriate should be on the proponents
--- and it's a fairly high barrier that they need to overcome.