Narrative Minutes for the January 5, 2006 IESG
Teleconference
Scribe: Spencer Dawkins <spencer@mcsr-labs.org>
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
No bashing took place.
1.3 Approval of the Minutes
No discussion of 12-1-2005 minutes. Allison reported a narrative
minutes glitch for the 12-1 meeting.
We will do narrative minutes approval electronically and use a
last-call mechanism for approval.
1.4 Review of Action Items
1.5 Review of Projects
http://www.unreason.com/jfp/iesg-projects
No update to projects list over the holidays (website was down due to
weather/power issues over the holidays). Jon will provide a prod soon.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-pkix-acpolicies-extn-07.txt
Attribute Certificate Policies extension (Proposed
Standard) - 1 of 4
Token: Russ Housley
No discussion (revised ID needed)
o draft-ietf-mmusic-comedia-tls-05.txt
Connection-Oriented Media Transport over the
Transport Layer Security (TLS)
Protocol in the Session Description Protocol (SDP)
(Proposed Standard) - 2
of 4
Note: PROTO shepherd Colin Perkins
csp@csperkins.org
Token: Allison Mankin
This document had three DISCUSSes (from Sam, Ted, and Russ). Sam and
Ted's DISCUSSes need to be worked with author, but Allison thought they
could be resolved quickly. Russ's DISCUSS could be fixed with an
RFC-Editor Note.
Russ asked if IANA was OK with adding an update to RFC 3279 as part of
the policy. Michelle answered, "yes".
o draft-ietf-imss-fc-nsm-mib-05.txt
Fibre-Channel Name Server MIB (Proposed Standard) -
3 of 4
Token: Bert Wijnen
Allison raised a question about the reviewer for this document being
one of the document authors. Bert pointed out that the reviewer didn't
do all the writing, and Allison suggested that "the protocol was
reviewed by only one of a large group of authors" would sound better.
Bert agreed.
o draft-ietf-imss-fc-fam-mib-03.txt
Fibre Channel Fabric Address Manager MIB (Proposed
Standard) - 4 of 4
Token: Bert Wijnen
Approved without discussion.
2.1.2 Returning Item
o draft-ietf-mpls-lsp-ping-12.txt
Detecting MPLS Data Plane Failures (Proposed
Standard) - 1 of 1
Note: ITU requires an RFC number by December 12th.
Token: Alex Zinin
Alex had added this document to the agenda to ask people with DISCUSSes
for status. Margaret had updated her DISCUSS because one issue (of two)
had been resolved. Alex and Margaret will locate George's proposal
(amid the holiday break mail) and follow up.
Sam believes that this specification can now be implemented, and that
the rest of the references are informative.
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
NONE
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o draft-ietf-tsvwg-mlpp-that-works-02.txt
Implementing an Emergency Telecommunications Service
for Real Time Services
in the Internet Protocol Suite (Informational) - 1
of 2
Token: Allison Mankin
Allison reported that the working group was OK with removing the
non-normative paragraph on QoS mentioned in David's DISCUSS.
Ted commented (but not as a DISCUSS) that these people have
talked about how to do management without talking about placement for
it to be effective. Shipboard example - management may be for an
application with proxies at various places in the network, and proxy
placement matters (if you've already traversed the choke-point link
before you get to the proxy). Is there a reason why this isn't
explained, or is it obvious?
Allison said that the WG thinks of this as obvious and assumes networks
are tightly engineered - that's probably why it's not explained. IEPREP
documents do talk about this (and one is in some distress because it
didn't have enough detail).
Russ raised a concern about the reference to HAIPE (High Assurance
Internet Protocol Encryptor), because there's no specification the
document can use as a reference.
Alex raised a concern with the amount of NATO/USG/DOD discussion in the
main body of the document = too much material to be "an example", and
not appropriate as a general standard. Could this be reworded as
technology-centric and move some material to appendix?
Allison said that MLPP is particularly for NATO and DOD (although
perhaps changing the title would set expectations more appropriately),
and Brian said that most of IEPREP is the same way
Alex - but that's not a good thing. If this was Informational, that
would be fine, but we're talking about a general standard. Needs to be
more government-agnostic.
Allison said that the WG is basing its work on standards from
NATO/USG/DOD, and that the issue needed to be worked with the WG. Alex
and Allison agreed that Allison would do the right thing...
o draft-ietf-sipping-consent-reqs-03.txt
Requirements for Consent-Based Communications in the
Session Initiation
Protocol (SIP) (Informational) - 2 of 2
Note: PROTO shepherd Rohan Mahy
rohan@ekabal.com
Token: Allison Mankin
Sam has problems with Section 2 and scope of requirements. Section 2
describes problems that could be resolved in UA, but this isn't
explained. Sam will write up his DISCUSS promptly, to avoid a DEFER.
3.1.2 Returning Item
NONE
3.2 Individual Submissions Via AD
3.2.1 New Item
o draft-savola-mtufrag-network-tunneling-05.txt
MTU and Fragmentation Issues with In-the-Network
Tunneling (Informational)
- 1 of 3
Token: Mark Townsley
Allison asked Mark to follow up with Pekka on her comment about PMTU-D
applicability (or lack thereof)
o draft-songlee-aes-cmac-03.txt
The AES-CMAC Algorithm (Informational) - 2 of 3
Token: Russ Housley
Allison noted that this is an Informational publication of an
algorithm, and Russ noted that it's already in use in IEEE 802.16, and
was reviewed in IRTF CFRG (Crypto Forum Research Group).
Allison pointed out that the RFC-Editor Note needed to be explicit
about what was being superceeded, and the note was added during the
telechat.
RFC Editor note was added during telechat.
o draft-jennings-sip-voicemail-uri-05.txt
Session Initiation Protocol (SIP) URIs for
Applications such as Voicemail
and Interactive Voice Response (IVR) (Informational)
- 3 of 3
Token: Allison Mankin
Allison said that the authors will have a revised ID, and are not quite
finished with comments yet.
3.2.2 Returning Item
o draft-jones-avt-audio-t38-05.txt
Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type
Registration
(Historic) - 1 of 1
Note: Last Called to Historic for the same reason
audio/t140c was - allow
registration of a "legacy" because of the way SDP
uses these
registrations,Ã, but make sure this is
not a precedent in any way.
Token: Allison Mankin
Allison noted that she is holding DISCUSS for registration issue on
this document.
3.3 Individual Submissions Via RFC Editor
3.3.1 New Item
o draft-bberry-pppoe-credit-04.txt
PPP Over Ethernet (PPPoE) Extensions for Credit Flow
and Link Metrics
(Informational) - 1 of 1
Note: Requested TSVWG review of flow-control
procedures, will sync up with
draft-arberg-pppoe-iana-00.txt
Token: Mark Townsley
Brian said he was satisfied with flow control issue based on feedback
from Sally Floyd and asked how to handle IANA issue.
Mark explained that the author was happy to include text on message
types. This document defines registries for PPPoE, for the first time,
and Mark is worried about everything cross-referencing everything else.
His suggestion was to limit the IANA document references to policy and
PPPoE, as a BCP.
Sam asked how the document could be a BCP when the base specification
for PPPoE is Informational, and Mark explained that the "BCP" would
cover only IANA practices. This could be handled with a downref.
Mark said there was a need for guidance on IANA documents in general -
he has seen several different statuses used for different IANA
documents.
Allison pointed out that in order for other standards-track documents
to reference a specification, it's useful to have a BCP (and that we
need a downref registry).
Sam pointed out that RFC 3932 doesn't give the IESG authority to do
what we're talking about - "give one of a finite number of responses
quickly". Can't say the document conflicts with IETF work because we're
not working on PPPoE.
Brian suggested that IESG would respond that this specification is
related to PPPEXT, but this does not prevent publishing, and then add
text about IANA issue.
Mark said the tracker already contains warning text from the PPPEXT WG,
and asked if the note should also reference
draft-arberg-pppoe-iana-00.txt . Sam said, "not in the RFC Editor note,
only in the IESG Note."
Mark also asked about the Gen-ART review which raised concerns. Brian
pointed out that the Gen-ART reviewer can discuss this with RFC Editor
directly, and Allison pointed out that these tags are allocated
first-come, first served anyway.
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Domain Keys Identified Mail (dkim) - 1 of 4
Token: Russ Housley
No discussion minuted.
o EAP Method Update (emu) - 2 of 4
Token: Sam Hartman
Sam reported that Pekka wishes the working group was doing more, but
the charter can be approved as it stands.
Sam asked "is mailing list creation automatic?" It isn't, the WG chairs
put in a request and the AD approves it. The announcement can't be sent
until the mailing list has been created (since it points to the mailing
list).
o Diameter Maintanence and Extentions (dime) - 3 of 4
Token: Bert Wijnen
Brian and Allison tagged a couple of spelling errors.
There was some discussion about whether chairs needed to be identified
before IESG approved the creation, since chair selection is an AD
matter. David said new ADs should be asking for advice, but ADs
shouldn't have to clear chairs with the other ADs, in general.
o Network-based Localized Mobility Management (netlmm) - 4 of 4
Token: Margaret Wasserman
Approved with no discussion.
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Transport Layer Security (tls) - 1 of 3
Token: Russ Housley
Russ asked if this recharter should go for external review - this is
for TLS 1.2, moving away from SHA-1 and MD-5, and it's a major change.
It was discussed in Vancouver, and no contentious objections have been
raised.
Bert said the charter should go to the New-Work mailing list also
(since we complain when other SDOs don't send information like this to
New-Work)
o ADSL MIB (adslmib) - 2 of 3
Token: Bert Wijnen
Bert wants this charter to go for external review because this is
management for protocols done in other organizations
o Security Issues in Network Event Logging (syslog) - 3 of 3
Token: Sam Hartman
Sam said that the proposed charter needs to be either turned down or
sent for review. Syslog was chartered to do signing and reliability,
but syslog is so poorly specified they couldn't do what they were
charter to do, then developed a new protocol that no one implemented,
and now they are trying to get the protocol into the charter as well as
reliability and signing. There are real questions whether anyone will
use this work - so we should either close the working group or send
this for external review.
Brian said it is probably legal, but not right, to close the working
group without discussing it with the IETF, and Bert suggested that Sam
include his concerns in the request for feedback.
Allison asked how many people are active in syslog. Sam said it's hard
to say - the meeting attendees aren't the mailing list participants.
There were 30 people at the meeting but it's not clear who will stay
involved on the mailing list.
Sam raised one other issue - Syslog isn't planning on having a
mandatory-to-implement security requirement, and asked if Russ was OK
with this.
Bert raised a concern about the signal this sends to other working
groups. This is an atypical situation - syslog has been around for 30
years, so it's not like "other working groups"
Russ said that the security area needs to hold ourselves to the same
standard as everyone else - Bert is right - and asked if the working
group could agree on a mandatory-to-implement requirement?
Allison asked why Syslog is a working group in SEC, since they are
doing protocols, they are doing transport mappings ... if they are
talking about reliability, fragmentation ... this sounds like APPS.
Sam agreed that APPS would also be a reasonable choice, and said that
he understands the applications issues well enough to manage the
working group but would be willing to give it away. Russ pointed out
that this might be a loadbalancing opportunity when we have new ADs and
a new area.
Sam agreed to tell the working group that they need a
mandatory-to-implement requirement, and that the IESG will see the
revised charter.
4.2.2 Proposed for Approval
o Pseudo Wire Emulation Edge to Edge (pwe3) - 1 of 1
Token: Mark Townsley
Mark pointed out that the current version of the charter doesn't
include MPLS PWs, which was the source of negative external comments.
Allison asked about wildcard FEC, and Mark said this is part of
signaling in L2VPN. Allison is concerned about Fiber Channel being a
pseudowire, and Mark mentioned that David Black is following the work
closely.
5. IAB News We can use - Dave Meyer
- IAB is moving to Round Two of multihoming at APRICOT. PC is somewhat
disorganized, but it looks like the date is March 1. We are considering
locations for a workshop on "unwanted traffic". Has this been
socialized with IESG? <only a little> - there's a blurb on the
IAB webpage, but timing information may not be correct (it's tough to
schedule so close to NANOG and IETF). If you know key players who need
to be involved, please IAB know.
- The Liaison document has been through a couple of revs.
- IAB Work on the Jefsey appeal is spinning up now (whether to uphold
Harald's action).
David also asked how best to keep IESG in the loop on the "unwanted
traffic" workshop, and Leslie pointed out that the invitee list would
be open to IAB and IESG members who are interested. Brian requested a
summary to the IESG.
6. Management Issue
6.1 Timeout on AUTH48 (Brian Carpenter)
Current wording is "The IESG has decided that as of now, any
IESG-approved drafts that enter the AUTH48 state, where the RFC Editor
waits for final text approval from all listed authors, may be released
on the responsible AD's authority if any authors have not responded
after a reasonable time, typically two weeks." Brian pointed out that
this allows the RFC Editor to expand to four weeks, but doesn't require
four weeks as the minimum period.
Brian said IESG can also ask Joyce to request that RFC Editor changes
the state name to something more realistic ("AUTH-CHECK"), but this is
separate.
Allison raised a concern that ADs should use this with discretion,
since authors check things that ADs don't, and the IESG doesn't want to
cut off someone who really needs to be checking.
6.2 IKEv1 is obsoleted by IKEv2 (Russ Housley)
Russ asked if anything needs to be done, since IKEv1 is obsoleted, but
also PS-not Historic. Other work depends in IKEv1, and there's no
security reason or other reason to force a change. We will probably
talk more about this when someone who depends on IKEv1 and wants to go
to DS.
Brian said there is still work to do on versioning in general, but ISDs
would make this MORE confusing...
Allison - nobody said this is straightforward...
<Short discussion of the entertainment goals [or lack thereof] that
narrative minutes should be striving for, followed here>
6.3 Approval of text for PR-Action decision (Brian Carpenter)
<discussion here was not minuted>
6.4 Changing document status from Proposed to Experimental (David
Kessens)
David has revceived this recommendation on NAT-PT from v6ops, and it
looks good, but approving it would also move NAT-PT from PS to
Experimental. David thought this was fine, but 2026 doesn't seem to
support this and we've never done it before, so wanted to ask.
Margaret said that if IESG does the normal thing and Last Call this
action, that should be OK.
Brian asked why v6ops is choosing Experimental and not Historic? Sam -
or Informational? Margraret explained that this decision happened a
long time ago, and we've changed the meaning of Experimental, etc.
since then.
Brian pointed out the actual RFC text says "this is a standards-track
RFC" - it would be wrong to have this move to Experimental or
Informational. Margaret noted that Historic is on the standards track.
Sam pointed out that we can have an applicability statement that says
"limited use" in any of these cases. 2026 says you're supposed to move
to Historic if you're writing a "limited use" applicability statement.
6.5 IESG to Say OK to 3 IAB Documents in RFC-Editor Queue (Bert
Wijnen)
Leslie objected to this agenda item, and the result of a quick
discussion is that IESG will let RFC Editor know that IAB documents
don't wait for IESG feedback before publication - Brian will reply to
mail on this.
January Retreat - Brian
Alex will provide logistics offers tomorrow - he has two or three
offers. Will start at mid-day on January 30. The agenda will be
discussed via e-mail (possibly on call next week as well). Allison will
be the agenda mistress.
7. Agenda Working Group News
Sam is hosting an ISMS interim meeting at MIT, February 13-14th.
Mark will be the advisor for 6LOWPAN, DNA, and HIP. 6LOWPAN has
scheduled their interim as well.
Jon - ECRIT will be meeting on Feburary 1-2 in DC.
Ted asked "how will we schedule the new RAI area at IETF 65? Will this
be a separate track?" Jon pointed out that this work forms a single
consolidated track, even in the past. Allison agreed with Ted, we
should schedule RAI using the tools (but we don't know if the tools
will support this, so we need to find out), as RAI, and asked that a
message be sent to agenda@ietf.org saying that we want RAI to appear,
and let them check out the tool support for this. Ted said there should
also be an RAI Area meeting, and that he and Allison would take the
action to draft the message text.