Extensions to GMPLS RSVP
Graceful Restart (Proposed Standard) - 2 of 7
Token: Ross Callon
DISCUSSes can be worked offline - no discussion here.
o draft-ietf-pim-mib-v2-09.txt
Protocol Independent Multicast MIB (Proposed Standard) - 3
of 7
Note: IETF Last Call ends January 25.
Token: Bill Fenner
Bill just sent e-mail (nanoseconds earlier) - Lars' issue is a downref
for PIM Dense Mode (it's experimental), but decision was to keep the
objects together (not worth the overhead to split them out). Now need
to decide about the references
Brian - PIM-RM is optional, but we've treated option references as
normative.
Bill - you don't need to know anything about PIM-DM to implement PIM.
Cullen - would I need to know IP to implement IP packet counts on
Ethernet?
Sam - that's not a normal case, because we all know what an IP packet
is. Think SIP - I'd argue that this would be normative. Need to find
the most expeditious way to not care.
Bill - this isn't what the downref procedure was intended for. Don't
want to split the document, but do want to figure out how to treat
"conditionally normative" references involving options. Any objections
to using the downref procedure for this?
<No one objected - we'll use the downref process>
Lars - Bill has a downref script, and Henrik is adding support for
downrefs in id-nits..
o draft-ietf-crisp-iris-common
-transport-04.txt
A Common Schema for Internet Registry Information Service
Transfer
Protocols (Proposed Standard) - 4 of 7
Token: Ted Hardie
Cullen and Mark didn't state positions on the call.
Ted asked to chat about DISCUSSes. Thanks for everyone's reviews - I've
been involved with these specs for so long as WG chair that missing
context just flew by me. We really are missing critical contextualizing
information. I'll be talking to DISCUSSants individually. CRISP has had
a milestone for UDP transport, but we've assumed that most people will
be able to move from UDP to TCP transport and keep a common view of the
schema.
Lars - Application isn't well-suited for UDP with 4000-byte messages.
We try to stay under minimum-MTU sizes. There are other concerns
Magnus has raised, and by the time you fix them, this isn't lightweight
any more.
Brian - that's the problem you have building on UDP.
Ted - by the time the protocol acts like it's TCP, it's not worth doing.
Brian - we should be having this discussion with the working group.
Ted - squeezing into 512-byte packets isn't practical.
Lars - if you want to send larger packets, you have to do PMTU
discovery, and then it's not lightweight.
Brian - the working group has to know this, and then figure out what to
do.
Jari - what about DNS reflection attacks - isn't that a danger here?
Ted - we can make sure security considerations cover that
Jari - it's mentioned, but it doesn't say how good the tools are for
dealing with these attacks.
This will go Revised ID Needed.
Sam - my DISCUSS is simple to deal with - if it's not, come back and
let me know.
o draft-ietf-crisp-iris-lwz-07.txt
A Lightweight UDP Transfer Protocol for the the Internet
Registry
Information Service (Proposed Standard) - 5 of 7
Token: Ted Hardie
Also in Revised ID Needed.
o draft-ietf-crisp-iris-xpc-05.txt
XML Pipelining with Chunks for the Information Registry
Information Service
(Proposed Standard) - 6 of 7
Token: Ted Hardie
Also in Revised ID Needed.
o draft-ietf-lemonade-compress-07.txt
The IMAP COMPRESS Extension (Proposed Standard) - 7 of 7
Note: Eric Burger is the Shepherd for this document.
Token: Ted Hardie
One DISCUSS is a downref issue to DEFLATE, which we've done before. Ted
needs to check for precedents.
Ted has sent Cullen mail about dealing with DEFLATE, and Cullen is
reading the writeup. Cullen wants to know if we can already deprecate
DEFLATE in favor of TLS - most phones Cullen knows about are using
stacks that can support this as a compile time option.
Ted said the pushback was from Nokia, but Cullen said he's done some
background investigation here - maybe we're making work, maybe adding
into the stack is easier than adding to the application.
Sam - even if you're right, is your DISCUSS a DISCUSS?
Cullen - I think "fundamental premise is wrong" is a DISCUSS. If this
caused no harm, I wouldn't care, but it's hard to argue that this won't
cause confusion - two mechanisms to do the same thing at the same time.
Double compressing is even worse. If this has been carefully
considered, I can remove the DISCUSS.
Ted - WG has done the investigation, but maybe not with the same data
and maybe with old data. We should ask the working group about this,
and about a cornder case where you would use this without TLS.
Sam - if you're not using TLS for security, yes.
Ted - so the question is whether not using TLS in these targeted
devices is ever reasonable.
Cullen - I can look at WG archive for previous discussion.
Brian - have to do downref last call again anyway, right?
Ted - need to check on how we've handled this in the past.
Russ - we don't usually move algorithms up the stack.
Ted - please put this in AD followup.
Bill - remember that hope is that downref Wiki is updated by ADs at
Last Call time, right?
2.1.2 Returning Item
o draft-ietf-tsvwg-tcp-mib-extension-14.txt
TCP Extended Statistics MIB (Proposed Standard) - 1 of 2
Note: PROTO Document Shepherd: James Polk. MIB Doctors:
Dan Romascanu, Bert Wijnen
Token: Lars Eggert
Document was approved with no discussion.
Lars - has Bill heard from authors on question you put in COMMENT?
Bill - have not heard.
Lars - Point Raised, please let me check with authors.
o rfc3989.txt
MIDCOM Protocol Semantics (BCP) - 2 of 2
Token: Magnus Westerlund
Magnus will try to sort DISCUSSes out - AD Followup for now.
2.2 Individual Submissions
2.2.1 New Item
o draft-bonica-internet-icmp-14.txt
Modifying ICMP to Support Multi-part Messages (Proposed
Standard) - 1 of 4
Token: Jari Arkko
Sam - stated NO-OBJ, David did not state a position.
Jari - holding DISCUSS for IANA until they complete review. Downref
doesn't have to be normative. More concerned about Cullen's DISCUSS -
have you seen Ron's e-mail?
Cullen is still working through... preliminary impression is positive,
though.
Revised ID needed.
o draft-manral-ipsec-rfc4305-bis-errata-03.txt
Cryptographic Algorithm Implementation Requirements for
Encapsulating
Security Payload (ESP) and Authentication Header (AH)
(Proposed Standard) - 2 of 4
Token: Russ Housley
Mark did not state a position on the call.
Document was approved with no discussion on the call.
o draft-solinas-ui-suites-01.txt
Suite B Cryptographic Suites for IPsec (Proposed Standard)
- 3 of 4
Token: Russ Housley
Mark did not state a position on the document.
Russ - two ways I can handle the DISCUSS - go Informational, or Last
Call again - is there a third choice?
Brian - if reference is normative, there is no third solution, right?
IANA only requires a document, not a standard? Several ADs think so. If
the only thing that matters is getting the registration done, we'll go
the quick was and go Informational.
Document is approved as Informational (when DISCUSS is cleared).
o draft-daigle-unaptr-01.txt
Domain-based Application Service Location Using URIs and
the Dynamic
Delegation Discovery Service (DDDS) (Proposed Standard) -
4 of 4
Token: Ted Hardie
Ted can work DISCUSSes offline - Revised ID Needed, and thanks for
actionable DISCUSSes.
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
Reviews should focus on these questions: "Is
this document a reasonable
contribution to the area of Internet
engineering which it covers? If
not, what changes would make it so?"
3.1.1 New Item
o draft-ietf-widex-requirements-04.txt
Widget Description Exchange Service (WIDEX) Requirements
(Informational) - 1 of 1
Token: Lisa Dusseault
Lisa - has Russ seen answers to security directorate review? Russ has
not. Lisa would like to stop working on security considerations
(Informational document, requirements, working group being shut down...)
Russ - can go ABSTAIN, or could have IESG Note that says issues aren't
being addressed.
Brian - would need to have Lisa craft an IESG Note.
Lisa will do this via e-mail.
Will Dan do the same thing? Lisa will propose text, and then we'll ask
Dan what he thinks, too.
Will be approved, AD Followup.
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
Reviews should focus on these questions: "Is
this document a reasonable
contribution to the area of Internet
engineering which it covers? If
not, what changes would make it so?"
3.2.1 New Item
o draft-cam-winget-eap-fast-06.txt
The Flexible Authentication via Secure Tunneling
Extensible Authentication
Protocol Method (EAP-FAST) (Informational) - 1 of 2
Token: Russ Housley
Document was approved with no discussion on the call.
Brian - still an open discussion around Dan's comment...
Russ - we can handle anything there in AUTH48.
o draft-conboy-mime-opf-00.txt
Media Type Registrations for OEBPS Package File (OPF)
(Informational) - 2 of 2
Note: Sent to ietf-types in October of 2006
Token: Ted Hardie
Document was approved with no discussion on the call. Gen-ART review
didn't generate a DISCUSS, only COMMENTs.
3.2.2 Returning Item
NONE
3.3 Individual Submissions Via RFC Editor
The IESG will use RFC 3932 responses: 1) The
IESG has not
found any conflict between this document and
IETF work; 2) The
IESG thinks that this work is related to
IETF work done in WG
<X>, but this does not prevent
publishing; 3) The IESG thinks
that publication is harmful to work in WG
<X> and recommends
not publishing at this time; 4) The IESG
thinks that this
document violates the IETF procedures for
<X> and should
therefore not be published without IETF
review and IESG
approval; 5) The IESG thinks that this
document extends an
IETF protocol in a way that requires IETF
review and should
therefore not be published without IETF
review and IESG approval.
Other matters may be recorded in comments to
be passed on
to the RFC Editor as community review of the
document.
3.3.1 New Item
o draft-zorn-radius-keywrap-12.txt
RADIUS Attributes for the Delivery of Keying Material
(Informational) - 1 of 3
Token: Russ Housley
Russ - there is DNP text in the writeup now - just send this off to RFC
Editor.
Brian - might consider Russ doing followup note to RFC Editor - clear
from Tracker text, but may need special handling.
Any objections to "Please Do Not Publish" as an exceedingly strong
polite request? None noted.
o draft-burke-vxml-02.txt
SIP Interface to VoiceXML Media Services (Informational) -
2 of 3
Note: This is an individual submission to the RFC Editor
being shepherded
through the IESG review process by Cullen Jennings.
Token: Cullen Jennings
Cullen - this is dead-on-center for not-yet-chartered Mediactrl WG -
others suggested asking authors to pull their own document. Will defer
this until next telechat while Cullen has conversations with authors.
Cullen will move to DISCUSS to hold it for two weeks.
o draft-irtf-dtnrg-arch-08.txt
Delay-Tolerant Networking Architecture (Informational) - 3
of 3
Note: Advancing according to: draft-irtf-rfcs-00.txt.
Document Shepherd:
Stephen Farrell (stephen.farrell@cs.tcd.ie)
Token: Lars Eggert
There were no objections to RFC Editor publishing this document.
David - we should make sure we don't have the problem I mentioned in my
DISCUSS again.
Brian - IRTF doesn't have an "Amy" to fix that problem...
3.3.2 Returning Item
o draft-deoliveira-diff-te-preemption-06.txt
LSP Preemption Policies for MPLS Traffic Engineering
(Informational) - 1 of 1
Token: Ross Callon
Document was approved with no discussion.
Brian - just change "I believe" to "We believe" in the approval text,
since we now all agree...
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Provisioning of Symmetric Keys (keyprov) - 1 of 1
Token: Russ Housley
No discussion about technical part of the announcement. Discussion of
proposed chairs was not minuted.
WG creation was approved.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Network Mobility (nemo) - 1 of 1
Token: Jari Arkko
Significant charter change - lots of proposed work, but hacked the list
down to route optimizations for air industry/space industry. Jari is
calling for detailed requirements for each application area. There is
business riding on some of these problems, but the problems are really
hard. Jari thinks we should let people try to solve them.
David - more ready for a BOF. WG completed, close it. This is new work,
not an extension. I think this area is research and not engineering at
this point, unless you're a lot more specific about the problem you're
solving and how you're going to solve it within constraints.
Jari - there are ideas about how to solve the ideas.
David - not convinced that proposals for solutions are workable.
Jari - question of making tradeoffs. Boeing's design is completely
based on routing protocol updates, other people are competely based on
tunneling. If you could combine the proposals, the end result might be
better.
David - need to be clear about direction in the charter, not general
research. Should be a BOF.
Brian - either WG or BOF needs to be tightly chartered, is that what
you're saying?
Jari - this is a continuation of route optimization work done
previously, and we have safeguards in the charter - if people fail to
deliver, the work disappears.
David - what do other ADs think?
Mark - didn't we decide NOT to hold a BOF on these items, at IESG/IAB
level? Requested airplane mobility BOF at last IETF. People had problem
statement, everything for a BOF, but we told organizers they could do
work within working groups.
Jari - we sent them to Nemo for the specific issues, that's right.
David - the problem domains are pretty disjoint - space applications
are the research end of the problem domain.
Brian - other opinions?
Cullen - general comment that semi-chartering ("if stuff doesn't happen
on time we'll remove it") gives us enormous pain, every single time. If
we don't know a solution, this is research, and we shouldn't charter it.
Jari - don't think this is research. There are research topics in the
area, but this isn't about research.
Mark - we have one AD in entire IESG who is willing to voice this
concern.
Mark - don't want to cycle on "oh, now we think we need to do a BOF" as
a 180-degree turn. Either tweak it or kill it.
Russ - send this out for IETF review and see if community has similar
concerns.
Brian - let Jari tighten up charter on what's in scope/out of scope
before we send this out for review.
David - start with a charter that just defines requirements - we did
this with Multi6/SHIM6.
Cullen - if the work is so questionable you have to do that, do it, but
there will be pain.
Jari - problem domains have similar technology issues.
??? - believe difference is relative speeds, etc.
Jari - technology matters, too - you have problems with satellites no
matter what you do.
Mark - this is all part of engineering the solution. The point was that
people recognized commonalities and want to look for common mechanisms.
If a specific application falls outside the boundary, that's fine.
Brian - Jari needs to tighten charter before review.
Jari - bring it back to the IESG?
Brian - need another look, maybe by e-mail after the propsoed charter
is updated.
4.2.2 Proposed for Approval
NONE
5. IAB News We can use - Leslie
IAB has completed IAOC selection.
Have made some changes to multiple-encapsuations draft (in RFC Editor
queue), multilink document going for last call.
ISOC BoT position search is underway.
ECRIT - tech chat will be in late February (these are usually
informal).
- Cullen - heard rumors - people bringing you architectures to approve,
etc.
- Leslie - generally intended to make sure the IAB is clued in to
what's going on in this space, in case liaison or other decisions are
needed
- Ted - please have ECRIT put together a reading list for topics like
PhoneBCP, expecially.
- David - Any idea for the timeframe when the IAB confirms or does not
confirm the IESG slate?
- Leslie - best I know we don't have a slate under consideration, but
I'm not involved in this for other reasons.
6. Management Issue
6.1 Expert for draft-ietf-hubmib-rfc3636bis-05.txt [IANA
#33594] (Michelle Cotton)
Michelle - we need an expert, who can get is one?
Brian - Bert suggested experts would be Dan and HUBMIB WG chair
No one objected to giving this job to Dan (who was not on the call) and
the HUBMIB WG chair, currently Bert Wijnen.
6.2 Wordsmithing of Approval (Ted Hardie)
Ted - wasn't able to reply to Sam's suggestion, but Sam's suggestion
was to add to the writeup for draft-hollenbeck-epp-rfc3733bis, which
Ted has done. Sam is fine with this (because the reason is given as
modularity) and will remove his DISCUSS.
Addition was "The IESG believes that IANA may allocate an additional
port in the 'user port' range to protocols whose current port
allocation requires access to a privileged port. This allocation
should not be automatic, but may occur upon application by an
interested party whose application would otherwise fit IANA's policies."
This addition seemed to make sense to everyone on the call...
6.3 Confirmation of IAOC Candidate (Cullen Jennings)
Candidate was confirmed in executive session with no discussion, will
be announced with the rest of NomCom's candidates.
6.4 Ed Lewis as Designated Expert for RFC2929bis experiment (Mark
Townsley)
No objections to this appointment on the call.
6.5 New revision of the AD sponsoring guidelines (Jari Arkko)
People have had a chance to comment, and guidelines were revised based
on comments.
Question - what to do about documents that have been through IETF
process but didn't come to us in the normal way? WG rejected approach,
etc. Klensin draft proposed that we are stuck with anything that has
ever been in the IETF, Jari's proposal isn't quite so strong.
Brian - set a deadline for comments?
Jari - I did - it was today...
Cullen - only wanted to say "thank you" as my comment.
Jari - have also reviewed independent submission document, others
should as well.
Brian - also need to decide whether this is an RFC or an ION.
Leslie - put forward pros and cons, worth having the discussion.
Brian - clearly can't do an ION that changes the rules.
Leslie - document does a good job of focusing on interpreting, not on
making new rules.
Brian - we'll come back to this on the next formal chat.
Jari - don't care, either way, toss a coin.
Brian - if no reason this can't be an ION, make it an ION - easier to
ION->RFC than to go the other way.
David - is there a reason not to publish an RFC? I didn't see one.
Brian - we can figure this out at Last Call time.
Leslie - would be more comfortable as RFC, we don't have air under our
wings with IONs yet.
(There was general agreement to pursue this direction, at this point in
the telechat)
7. Agenda Working Group News
Brian Carpenter - please pay attention to IPR issues about patent
policy, from open source community
Lisa Dusseault - non-WG news - SMTP to draft standard? John Klensin
volunteered to do a draft, but there's no WG group for SMTP. Hoping
this can all happen as an open cabal with a mailing list. Any
objections?
- Brian - no objections because the work is visible to the community.
Two steps ahead of you, because SMTP is a full standard now.
- Cullen - if you meet, you might be able to get new people
participating.
- Lisa - new e-mail people show up every two meetings....
Ted Hardie - John Klensin is working on a proposal to describe UNICODE
in Internet Drafts, on apps mailing list. Will see a reasonable
proposal in the near future. Webdav is the interesting one, with lots
of feedback at IETF Last Call time. Draft will be revised, but we may
get an appeal that we are publishing a document with known technical
issues. This will be a tough one. WG has very low energy and IETF Last
Call opened old disagreements. Lisa and Cullen are both recused, but
incoming AD will have to deal with this.
Russ Housley - thank you for your efforts on the DKIM telecomm, but the
document doesn't reflect all my recollections of the telecomm. May need
another telecomm to get the "rest of the way" before Prague.
Cullen Jennings - proposal to merge DTLS and ZRTP proposals. Authors
think this will go somewhere, I'm less convinced.
David Kessens - currently participating in CAPWAP interim, good
progress.
Jon Peterson - IEPREP people are coming back with a BOF request. Have
people seen it? Think that contentious parts are unchanged from WG
charter proposal, so we're probably not through here.