Narrative Minutes

Narrative Minutes for the September 20, 2007 IESG Teleconference

Narrative Scribe: Spencer Dawkins <>

With corrections by Russ Housley, Jari Arkko, Magnus Westerlund

1. Administrivia

1.1 Roll Call

Yoshiko will not be joining the calls in the future...

1.2 Bash the Agenda

Appeal discussion will be the last item on the agenda (because it's an executive session)

1.3 Approval of the Minutes

1.4 Review of Action Items

IANA Expert for RFC 4422 - Sam has expert identified (Simon Josefsson)

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-geopriv-policy-12.txt
Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information (Proposed Standard) - 1 of 9
Note: Robert Sparks is PROTO Shepherd
Token: Cullen Jennings

Cullen - don't need to DISCUSS most of the DISCUSSes, most serious is Sam's concern about privacy. What is the right thing to do?

Sam - bring back to the working group and clearly document what we've identified, but would be a good idea to ask a couple of people to review for additional information leaks. If WG looks at this, I'd be happy to clear.

Cullen - don't think this was discussed in the working group (kind of concerned about this).

Revised ID needed.

Lisa - lots of the DISCUSSes aren't easy to deal with without hacking away functionality, and working groups are often reluctant to do that.

Cullen - I was thinking about polygons and such - will take this back to the WG and have them work on it.

Jon - need to describe how an application figures out if a polygon is inside a polygon. A lot of detail is in the OpenGIS specs, required to implement. Don't think it's right to add a lot of details.

Russ - need to say more than "need to understand polygon-in-polygon"

Jon - don't want to describe application behavior, only protocol behavior, and this is a Pandora's Box.

Cullen - need to be clear about the polygon on the wire, not about the polygon analysis work.

Lisa - need to think about how UIs will work, or there will be interop problems based on what users do.

Jon - heavily depending on OpenGIS, don't want to change their recommendations.

Lisa - of course not, but does the application have to display a map to the user?

Jon - would be a better UI, but this is about implementation, not about protocols.

Lisa - depends on whether users can tell that their privacy is being protected - same as access control system, if it's too complicated, applications can't present the details and people don't have the access controls they think they do.

Cullen - security DISCUSS will need WG discussion, that alone sends the document back.

Sam - Lisa, please be prepared to make sure all the parts of your DISCUSS fits in the DISCUSS Criteria document, if someone asks.

o draft-ietf-enum-validation-epp-06.txt
ENUM Validation Information Mapping for the Extensible Provisioning Protocol (Proposed Standard) - 2 of 9
Token: Jon Peterson

Approved with no discussion

o draft-ietf-mboned-ip-mcast-mib-07.txt
IP Multicast MIB (Proposed Standard) - 3 of 9
Token: Dan Romascanu

Approved with no discussion.

o draft-ietf-ccamp-te-node-cap-05.txt
IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities (Proposed Standard) - 4 of 9
Token: Ross Callon

Ross - Magnus correct about my misuse of IESG note, will delete that, will add a clarification as an RFC Editor's Note, will go into AD Followup.

o draft-ietf-smime-cms-auth-enveloped-05.txt
Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type (Proposed Standard) - 5 of 9
Token: Tim Polk

Tim - Chris has DISCUSS I'd like him to elaborate on.

Chris - basic concern is that if you get end-to-end security deployed, how will spam use that technology? Most of our current strategies would be defeated by encryption. Probably belongs in CMS base spec - no, S/MIME base spec.

Russ - can also use CMS in non-messaging environments

Chris - great, but the security concern needs to go SOMEwhere. When you accept encrypted messages from unknown sources you are opening yourself up to spam and breaking many existing mitigation mechanisms.

Sam - kind of support that documenting security considerations somewhere, until base spec is revised, is the right thng to do.

Chris - don't want to give impression I'm asking for full discussion of Spam mitigation - that's research

Tim - have a better understanding of what you're looking for - "not unique to this spec, but not documented anywhere else"

Cullen - what does this actually mean? Don't accept e-mail from people that aren't in your address book?

Sam - no, the point is that you're not outsourcing your spam mitigation to a middle box, you have to do it yourself

Chris - concerned that we're not giving specific advice

Russ - can work with Chris to write a paragraph we can live with. Also, should be universal, not explicit - errata in base spec I need to deal with.

Russ - Sam, do you want references added?

Sam - adding references would make me 100 percent happy, in both documents.

Russ - references are about counter mode. Because of the relationship to counter mode, I think it is better to put the references in draft-ietf-smime-cms-aes-ccm-and-gcm

Sam - OK with removing paragraph from this document, do whatever you want

Revised ID needed.

o draft-ietf-smime-cms-aes-ccm-and-gcm-02.txt
Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) (Proposed Standard) - 6 of 9
Token: Tim Polk

Approved, point raised. Russ will provide text to Tim.

o draft-ietf-mip6-ha-switch-03.txt
Mobility Header Home Agent Switch Message (Proposed Standard) - 7 of 9
Note: Document Shepherd is Basavaraj Patil <>
Token: Jari Arkko

Jari - need to DISCUSS today - thought I had three easy documents, boy was I wrong. Agree with all the DISCUSSes but there is some overlap.

Sam - agree with proposed resolution, waiting for text.

Jari - need much better description of how this mechanism is actually used. Can we merge other DISCUSSes from Lars and David into Dan's so we only have one DISCUSS to resolve? Sam's DISCUSS needs the most work.

Dan - can do this

Dave - please CC us on discussions with authors

Jari - need to clarify moving on the same subnet versus other operations in the text. Revised ID needed, we'll look at merged DISCUSSes

o draft-ietf-mip6-experimental-messages-01.txt
Mobile IPv6 Experimental Messages (Proposed Standard) - 8 of 9
Note: Document Shepherd is Basavaraj Patil <>
Token: Jari Arkko

Jari - Mark and I agree, but author doesn't agree yet. This isn't the document to describe the experimental message (Dave's DISCUSS), only the allocation of the codepoint.

Dave - you've created a packet format where you can't pass multiple options.

Jari - whoever uses this mechanism would provide contents, Can be multiple options, either experimental or not, this is the way all messages have been designed today. Most experiments would use the same options.

Mark - drive home the point that you need to explain the contents in each draft that describes an experiment using this codepoint

Dave - we don't usually use the length as a discriminant between options, we have suboptions.

Sam - experiments don't interoperate, right?

Dave - this isn't the way we do experiments in our protocols. I guess saying "you have to understand the experiment" is OK, but ...

Mark - idea is to tell people not to rely on experiments, or they'll screw themselves

Dave - agree, that's fine, but you have one code point, everybody has to be running the same experiment, so this is a limitation. If you're OK with that, fine.

Mark - if you're going to force people out of experiments, you have to treat this as a blob

Dave - you can have multiple sub-TLVs so you don't break implementations that don't understand the experiment. In this protocol, there is no notion of sub-TLVs, if you want to do it this way, just say so explicitly

Jari - you can have mobility options but that's not for selection between experiments - don't want to support lots of experiments because then people stay experimental.

Lars - 4727 has same type of mechanism (using option space that's nearly full), and has text that talks about need to be aware of experimental collisions

o draft-ietf-mip6-vsm-01.txt
Mobile IPv6 Vendor Specific Option (Proposed Standard) - 9 of 9
Note: Document Shepherd is Basavaraj Patil <>
Token: Jari Arkko

Jari - one easy thing, David's discuss, related to previous document. Point is that you can have options inside a message but length and contents are defined by vendor in question. David's question is defined in the base spec, pass multiple options, one or more can be vendor-specific options

Mark - one option, followed by vendor ID, if you have multiple sub-options, vendor needs to say that

Sam - advise vendors to use subtype code as first field, would improve document

Jari - can actually mandate this in the document

Dave - will clear when I see proposed text

Jari - other concern is that we shouldn't be having vendor-specific codes, document originally had vendor-specific messages, not options. Two extremes, too far in controlling things or too relaxed, and either extreme can cause problems - ignoring options you don't ignore can lead to protocol violations.

Lars - agree that vendor-specific options are less harmful than vendor-specific messages, but we've had problems in this area before

Lars - why is this needed? Do people really want to pass a lot of data using Binding Updates?

Jari- don't really have a use case for this.

Lars - concerned that we're opening a hole where we have no control over a key protocol

Jari - ignoring or prohibiting something we don't agree with may be problematic - NAT and DIAMETER experience

Jari - people can play and then come back to IETF for real codepoint. Three options - we're OK with it, or go back to working group and say "bad idea", or find another way to do this with more restrictions.

Jari - let's discuss via e-mail for a few days

Lars - check whether other people think we have an issue, or I can ABSTAIN, that's the other way to deal with this.

Jari - think we need balance, I've been burned by this one before

Sam - speaking as someone who ships products, if I have to choose between shipping and jumping through an IETF hoop, I'll stomp on a codepoint. Can't have IETF on the critical path for product delivery dates.

Jari - Lars DISCUSS being handled - goes revised ID needed

2.1.2 Returning Item
o Two-document ballot: - 1 of 1
- draft-ietf-pana-pana-18.txt
Protocol for Carrying Authentication for Network Access (PANA) (Proposed Standard)
Note: Returning for ballot by new ADs

- draft-ietf-pana-framework-10.txt
Protocol for Carrying Authentication for Network Access (PANA) Framework (Informational)
Note: Returning for ballot by new ADs
Token: Mark Townsley

Sam - there is an issue - mail flying back and forth, short version is that removing specification of SNMP as a protocol for PAA to EP communication when the PAA and EP are not co-located was removed, and this is a big enough change to require another IETF last call

Mark - that would be a third Last Call. We removed this protocol because it was never going to be implemented, and it was object of a DISCUSS. WG decided to document what we thought was really going to be used. In many environments, protocol you need already exists, and PANA can use that.

Sam - Framework document does not reference these existing protocols, right? Could live with change, but it's big enough that it changes the entire intoperability model for the protocol.

Mark - maybe this came up in first WGLC, but clearly didn't come up during the second. Understood at WG level, now at IESG level. Think the bar is higher for PANA than for other protocols.

Sam - will try to be more consistent in the future, but when we change the interoperability model, need to tell the community.

Dan - I was holding DISCUSS that triggered this, my understanding ait this point in time. Understood that SNMP-based interaction would not have worked.

Sam - horrid use of SNMP, give you that, didn't agree with WG at all. Is there a way forward that doesn't have four-week delay? One-week timeout on a note to the community? Please mention this issue so people know what to look for.

Mark - what can we do with this document? Last Call Requested

Lars - IANA had questions, need to make sure they are answered.

Mark - DISCUSS blocking for IANA issue? yes... special one-week IETF Last Call

2.2 Individual Submissions
2.2.1 New Item
2.2.2 Returning Item

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
3.1.2 Returning Item

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-shacham-sipping-session-mobility-04.txt
Session Initiation Protocol (SIP) Session Mobility (Informational) - 1 of 1
Token: Jon Peterson

Lots of DISCUSS positions on this document

Jon - sent a note about number of editorial comments on individual submissions, hard to see why document that says "this is a possible way" gets this kind of scrutiny.

Sam - just say "this is one way, we think it might work"? Document quality is high enough that I thought it would have more support. Move me to "yes"

Magnus - I found a number of issues in this document, however I didn't list them in my DISCUSS. But this clearly is a sketch and I would like to have clearer warning of this.

Jon: The abstract for example indicates that this is sketch

Magnus: I do not agree it being clear, the second part of that sentence indicates that it is a "specification".

Jon - sent note yesterday, there is no chartered work in this area. My discomfort is that there is no working group and this is Informational - don't think level of review should be the same

Sam - happy to have that discussion, don't entirely agree, but let's not talk about it now.

Jari: - my DISCUSS has easy parts, a number of things that can be handled by a text change. But I also have more open ended questions about the security.

Revised ID needed.

3.2.2 Returning Item
3.3 Independent Submissions Via RFC Editor

3.3.1 New Item
o draft-saleem-msml-05.txt
Media Server Markup Language (MSML) (Informational) - 1 of 1
Note: IESG Note: 3. The IESG thinks that publication is harmful to the IETF work done in the MEDIACTRL WG and recommends not publishing the
document at this time.
Token: Jon Peterson

Considered for "Do Not Publish".

One DISCUSS - Ross - we all agree on the note, but do we say "recommend that you don't publish, but if you do, here's a note"?

Sam - think RFC Editor will figure this out even if we don't switch the RFC Editor note and the IESG note.

Sandy - the RFC Editor understands the situation

Ross - clearing now.

3.3.2 Returning Item

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
o IPv6 Maintenance (6man) - 1 of 1
Token: Jari Arkko

Sam - don't object, but have a quesiton - does charter say revisions don't have to come back to IESG?

Jari - not exactly, draft charter says "do maintenance" and then lists currently known work items. When we discover a bug (say, similar to the RH0 issue that we had), after an agreement with the chairs and AD, the WG can add a milestone to work on a fix for that bug. New features, big things would come to the IESG. But it does not make sense to recharter for every bug.

Jari - one question requiring text changes from Margaret Wasserman, but we can deal with that with a milestone change.

Sam - using existing mailing list?

Jari - yes

Jari to send ticket closing IPv6, 6man is approved...

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval

5. IAB News We can use

Policy changed for independent submissions, BCP 78 requires that authors give up rights within the IETF context, now extended to work in IRTF and elsewhere outside IETF - not just IRTF submissions.

Discussing Thaler/Aboba document and adoption as IAB document.

Also discussed enterprise routing workshop, don't have enough momentum to set up workshop

DNSSEC issue (Olaf) - draft-weiler-dnssec-dlv-iana in last call, IAB responded on topics where IAB has responsibility (new zone under .arpa), inluding clarity of instructions and concerns about MoU violation. We can resolve MoU with clarity and with IETF concensus.

Loa - try to keep these reports short, read Mark's report to IAB and it's longer and more wordy. Is IESG happy with current reports, or does IESG need more elaborate reports?

Jari - Mark's report is useful, why not the rest of the community?

Mark - Mark's report does go into a public report from IAB

Russ - IAB minutes are a dumb place to look for a report of IESG activities

Loa - should also have one way to find liaison reports, especially if a report comes regularly - not just inserting in the minutes

Russ - happy with both liaisons, but I listen to both teleconferences - what do people who don't listen to both teleconferences think?

Cullen - current level of detail includes pointer, and that's what I need.

Ross - seems to me like Mark had more to day than usual because we were all at ITU meeting last week.

Mark - ironically, didn't mention this at all in my report, assume Stewart would handle this in his report and didn't want to step on toes.

6. Management Issue

6.1 Narrative minutes catchup

Spencer will submit 7/19 narrative minutes (approved but not submitted as final).

Marc and Marshall each have one set of narrative minutes on their plate for submission.

6.2 Draft deadline for 00 WG drafts (Cullen Jennings)

Renaming a WG draft at 00 moves the cutoff a week

Barbara - this would be handled manually (not supported in the current version of the tool).

Sam - proposal is just to remove one of the motivations for leaving drafts as apparently-individual by allowing renaming? No objection to this proposal but want to revisit broader question.

Ross - aware of documents that weren't renamed for two IETF cycles because author did all the work so close to the cutoff.

Loa - want to support having documents adopted all the way up to the deadline.

Barbara - we can do this manually, but cover note needs to point out the exception. Next version of the tool does handle replacements. Could post and then send a note saying "replaces draft name".

Lisa - mild disagreement, idea is to give people more time to read new documents, when it's adopted, it's new to the working group

Loa - not my experience, document was discussed on workng group mailing list

Ross - working group should have agreed to adopt

Sam - we have wide variability on what current practice is

Cullen - posted WGchairs agreeing with Lisa, but someone responded "change the dates, don't get more time as a side effect". Thought this was compellng.

Loa - hundreds of 00 individual drafts, but very small number of 00 working group drafts.

Sam - chairs have flexibility to make a draft a WG document at any time, we're just making them easier to find. We're talking in circles, Lisa has a mile disagreement, other peiople have spoke in favor, other opinions?

None noted...

Lisa - go ahead

Russ - action to write up an IESG statement (Cullen will take this action)

Sam - include "proposed BIS to secretariat text pointing out the change" in e-mail

6.3 Executive Session for Appeal (Russ Housley)

All observers (liaisons, scribes, etc) were excused.

7. Agenda Working Group News

Ross Callon - Right time to talk about ITU meeting last week? Very brief summary, they said "yes" to our solution #1, but we weren't talking to final deciders, and we don't know about how this will be followed through in a consistent, solid way.

- Loa - will have report ready by next week

Chris Newman - CalConnect held vCard workshop, strong industry feeling vCard needs work, especially around synchronization, have reviewers, chairs, and authors (pending the outcome of the BOF)

Dan Romascanu - actually on behalf of Ron, OPSEC chair(s?) stepped down, doing an open call for new chairs.

Magnus Westerlund - looking for WG chairs for ROHC, if you have candidates, please send them my way.