IESG Narrative Minutes

Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the December 20, 2007 IESG Teleconference

Narrative Scribe: Spencer Dawkins <spencer@mcsr-labs.org>

With corrections from: Russ Housley, Mark Townsley

1. Administrivia

1.1 Roll Call

1.2 Bash the Agenda

Sam - added management issue on IANA instruction for GSS-API registry

Russ - move Cullen's management item to the end? It could occupy whole telechat time.

Sam - what about executive session?

Cullen - could limit it to 5 minutes

Put after the current executive session management item, to allow use of all remaining time. Consequently, it will also be handled in executive session.

1.3 Approval of the Minutes

2007 11 29 Minutes - approved with no discussion

2007 11 29 Narrative Minutes - Spencer sent out corrected narrative minutes this morning, will approve on next telechat.

1.4 Review of Action Items

o Lisa Dusseault to find an author to update RFC 3406.

Lisa - Still in progress

o Jari Arkko to write an explaination of IESG policy of when ADs can request documents be considered by the IESG before the Last Call has ended.

Jari - no progress since last time

o Chris Newman to draft a policy on Autoresponse Messages sent to any IETF mailing list.

Chris - posted on Nov 1, no comments - believe this action item is done. CCed Narten's IANA draft, they can pick up this text if they want

This action item is completed.

o Cullen Jennings to get a response from the AVT WG to help solve an IANA Registration issue for wave-avi-codec-registry [IANA # 97962]

Cullen - about to give up and call this done...

o Sam - supposed to be writing up a draft explanation of informational balloting

- in progress

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o Three-document ballot: - 1 of 8
- draft-ietf-pkix-2797-bis-06.txt
Certificate Management Messages over CMS (Proposed Standard)
Note: PROTO Shepherd: Stefan Santesson <stefans@microsoft.com>

- draft-ietf-pkix-cmc-compl-05.txt
Certificate Managmement Messages over CMS (CMC): Complience Requirements (Proposed Standard)
Note: PROTO Shepherd: Stefan Santesson <stefans@microsoft.com>
- draft-ietf-pkix-cmc-trans-07.txt

Certificate Management over CMS (CMC): Transport Protocols (Proposed Standard)
Note: PROTO Shepherd: Stefan Santesson <stefans@microsoft.com>
Token: Tim Polk

Tim - DISCUSS briefly. Down to text for part of Lars DISCUSS, Lars not on the call. How do I handle the ports for TCP-based transport? Lars thinks should be private ports range, Sam doesn't quite agree, not my area of expertise. What should the author do?

Russ - this is a bis - what did we do last time? in appendix in the previous doc? or did we just screw up?

Sam - I was talking about HTTP transport

Russ - MIME types take care of that

Sam - but HTTP/substrate says should be using separate port

Lisa - I should be updating that BCP, because MIME types are used a lot in this way

Tim - this is revised ID needed

Sam - you have text to clear my DISCUSS

Tim - want to clear both with revision

Chris - please look at my comments - I was thinking about ABSTAIN, but thought that would be tacky

Tim - part of why I want revised ID needed

Chris - community is split - couldn't get doc through IESG on port 80, then you could, now community is split - won't DISCUSS based on that

o draft-ietf-shim6-hba-04.txt
Hash Based Addresses (HBA) (Proposed Standard) - 2 of 8
Note: Please also read draft-ietf-shim6-applicability. Mark Townsley to
handle any IPR questions in AD review/IETF LC/IESG, if any. Document
Shepherd is Geoff Huston <gih@apnic.net>.
Token: Jari Arkko

Jari - status of DISCUSSes - should some of this be DEFERed? Lars and Chris needed more time. Thought HBA was clearer. Should I DEFER?

Dan - feedback from authors?

Jari - not during last couple of days - have to wait for the authors.

Jari - Agree with Tim, text in the tracker as RFC Editor note addresses concerns, but I'll require revised ID to pull everything together.

Tim - text looks good, will clear.

Jari - agreed with everything Dan said, haven't had time to respond/propose changes, will deal with this over e-mail. Remaining is DWards - is this on the right document? If so, I don't understand.

DWard - agree, will move comment to other document.

Jari - revised ID needed, waiting for authors to post new version and deal with Dan's comments

Sam - still considering Experimental?

Jari - standards-track still appropriate for HBA

Sam - if we're not going Experimental, no problem, but IPR gets strange if you DO go experimental

Will be revised ID needed

o draft-ietf-shim6-failure-detection-09.txt
Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming (Proposed Standard) - 3 of 8
Note: Please also read draft-ietf-shim6-applicability. Mark is handling
this for Jari as he is an author
Token: Mark Townsley

Jari - understand DWard's DISCUSS, not sure I agree but don't have arguments in place, will converse on e-mail

DWard - question is "why not BFD state machine"

Jari - do we want to DEFER?

Cullen - primary question about proto is EXP or PS, this is affected by that decision.

Mark - agree, but there are four DISCUSSes - won't be approved today anyway

Magnus - probing?

Mark - push the DEFER button!

And we DEFERed...

o draft-ietf-shim6-proto-09.txt
Shim6: Level 3 Multihoming Shim Protocol for IPv6 (Proposed Standard) - 4 of 8
Note: Please also read draft-ietf-shim6-applicability. Document Shepherd is
Geoff Huston <gih@apnic.net>
Token: Jari Arkko

Jari - Sam makes excellent points, not sure what to do ("does not play well with IPsec")

DWard - HIP was experimental, but this is PS, should be addressed

Jari - should be easier than HIP, no new name space, need to look at details.

DEFERed until next telechat

o draft-ietf-dnsext-2929bis-06.txt
Domain Name System (DNS) IANA Considerations (BCP) - 5 of 8
Token: Mark Townsley

Mark - don't need to DISCUSS today, will bug guys to respond to Sam

Russ - they responded this morning after they say my DISCUSS, but we need to give Sam a chance to read response.

AD Followup...

Michelle - just sent some suggested text, please have Donald and Olafur respond. Olafur is very responsive on this document

o draft-ietf-sieve-notify-11.txt
SIEVE Email Filtering: Extension for Notifications (Proposed Standard) - 6 of 8
Token: Lisa Dusseault

Lisa - can debate with Cullen offline, don't understand the security issues about extracting receiver list from incoming e-mail.

Cullen - I may be wrong that you can even do this - will discuss offline with Lisa and Chris, didn't have enough time on these documents to be sure.

Lisa - not sure why changing examples from sms to tel URLs?

Cullen - examples will be implemented just this way, we have a URL that would work. If you remove the examples, that would work, too. Great feature in Sieve

Lisa - if sms URI is standardized it wll be much more widely used than tel

Cullen - need to clarify this

Sam - how does system know what to do with sms (e-mail or sms)?

Lisa - could be in action

Cullen - we're dragging argument about sms URL draft into this discussion, need to resolve that one.

Lisa - don't want to hang on that document - remove example

Cullen - not my first choice, but acceptable.

Lisa - mark as revised ID needed

Chris - digging into text for Cullen's DISCUSS. Last para in Sec Cons deals with this - if you don't have sieve variable extension, this isn't a concern, but if you do, there is an attack vector if you're extracting addresses. Don't think this is what most people will do.

Lisa - agree, can you send your comments in writing so we don't lose them?

Chris - yes, will suggest sentence or two

o draft-ietf-sieve-notify-xmpp-07.txt
Sieve Notification Mechanism: xmpp (Proposed Standard) - 7 of 8
Token: Lisa Dusseault

Lisa - Cullen's DISCUSS about interacting with online state, authors think this is covered in Section 2.2.

Cullen - will check quickly

Chris - agree this is covered

Cullen - sorry, totally missed, will clear

Lisa - Chris, response on loops?

Chris - basic direction is to just say address should never autoreply - that should be sufficient (plus text about XMPP's lack of forwarding). Agreed on FROM tag syntax. Resolved, possibly today.

Lisa - Mark as AD Followup, can change to Revised ID Needed if we go that way

o draft-ietf-sip-consent-framework-03.txt
A Framework for Consent-based Communications in the Session Initiation Protocol (SIP) (Proposed Standard) - 8 of 8
Note: Keith Drage is the document shepherd
Token: Cullen Jennings

Was DEFERed

2.1.2 Returning Item
NONE

2.2 Individual Submissions
2.2.1 New Item
o draft-cheshire-ipv4-acd-05.txt
IPv4 Address Conflict Detection (Proposed Standard) - 1 of 1
Note: -05 includes changes based on int-area review.
Token: Mark Townsley

Ross - had questions about where document came from, why it's on the agenda, etc. Need to understand to state a position

Mark - document originated with zeroconf which folded a long time ago. Basically selecting IP address and seeing if it's being used, Implemented in MacOS (then) and Windows (now). Decided a couple of years ago to document what's implemented and shipping on multiple OSes as AD submission. This is PS because it's a fundamental part of the OS and implemented by multiple vendors.

Sam - people raised concerns about Randy's DISCUSS, older DISCUSSes. If people want to bring issues forward, fine, but DISCUSS criteria have changed, many DISCUSS comments weren't valid/actionable (things AD just didn't like). Need to make change in order to bring DISCUSSes forward.

Dan - thought I had inherited Randy's comments, but shows up with DISCUSSes that were never answered. If they have been answered because document was changed OR criteria changed, would like confirmation about this from shepherd.

Mark - Last Call in INT-AREA, not a lot of comments, Bernard asked for changes and the changes happened (over a long period of time). Looked at DISCUSS text entered by former ADs, some concerns have been addressed coincidentally. Can go through whole list providing responses, but would add significant delay - is it worth it? There was one Last Call comment from CM Heard, about a SHOULD being a MUST or a MAY, sent off e-mail and haven't gotten response. Will be AD Followup anyway. Are you going to force me to go through all the former-AD comments and provide explanations?

Dan - just asking for a sanity check, suspect everything is fine (except ID Nits), but want to make sure we did not leave door open for document approval shortcuts where we forget old DISCUSS comments when we bring a document back from the dead.

Mark - won't break process if we ignore old DISCUSS text from former ADs, unless that text is picked up as a DISCUSS by a current AD, and our attention has been called to the text in the old DISCUSSes anyway. I'll treat the text as comments, and point Stuart to them. Do need to confirm one point with Eric, based on a DISCUSS he entered as AD, about a possible conflict with SunOS implementation.

Ross - NO-OBJ

Dan - clearing DISCUSS to NO-OBJ

Will go into AD followup.

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
o draft-ietf-sipping-toip-08.txt
Framework for real-time text over IP using the Session Initiation Protocol (SIP) (Informational) - 1 of 8
Token: Jon Peterson

Jon - going back to authors anyway.

Sam - don't have DISCUSS, but SECDIR review pointed to SIP document on third parties not being transparent. Authors ignoring that.

Jon - talked with authors about transcoding stuff. Open to different wording. Authors have strong preference that nothing will be an obstacle, but this is a difficult line to walk (without creating a playground for MITM attacks). Wording here is not idea.

Sam - please get specifics in line with general requirements, be consistent.

Jon - I also said this in my review. Document is a one-off, small community, not a lot of review outside that community.

Jari - reading refered documents, RFC 4103 already has some text, just point to it.

Jon - paging versus transfer is also a fundamental issue

Jari - was surprised about TCP, etc. but now understand the design they have

Jon - will take a look at RFC 4103

o draft-ietf-16ng-ps-goals-03.txt
IP over 802.16 Problem Statement and Goals (Informational) - 2 of 8
Note: Document shepherd is Daniel Park <soohong.park@samsung.com>
Token: Jari Arkko

Jari - don't need to DISCUSS today, can address Dan's issue, may need revised ID because of editorial stuff from OPSDIR review

o draft-ietf-l2vpn-vpls-mcast-reqts-05.txt
Requirements for Multicast Support in Virtual Private LAN Services (Informational) - 3 of 8
Token: Mark Townsley

Mark - Ron, seen my e-mail on MAC Learning? VPLS has MAC learning. Is there a special multicast mode you're thinking of?

Ron - no, just generic learning.

Mark - need to go away and study, security issues, not enough time to get through on this call.

o draft-ietf-mipshop-mis-ps-05.txt
Mobility Services Transport: Problem Statement (Informational) - 4 of 8
Note: Document Shepherd is Stefano Faccin
Token: Jari Arkko

Document was approved with no discussion on this call

o draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt
Framework for MPLS-TE to GMPLS migration (Informational) - 5 of 8
Token: Ross Callon

Ross - Tim's DISCUSS - already a little warning in document, inclined to add one or two more sentences. OK?

Tim - sure, but does this happen all the time? Do operators undersrand how to do this? Mix-and-match standards something you shouldn't try at home...

Ross - used only in small amounts if you know what you're doing ("leave to professionals")

Tim - can clear and trust you to put words in, don't want to hold this document up for my comments. Would be a train wreck if you mix-and-match in security.

Dan - also operational aspects, need positive documentation that authors have thought about migration plans and operational concerns. Not DISCUSSing, just echoing Tim's concerns.

Ross - if you don't clear, I have bigger stick for the authors. WIll poke you when text is ready, OK? Revised ID needed, can change if we use RFC Editor's note

o draft-ietf-ccamp-mpls-gmpls-interwork-reqts-03.txt
Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks (Informational) - 6 of 8
Token: Ross Callon

Ross - same question about additional sentence - going revised ID needed, because we'll have more than one sentence

Ron - reasonable

DWard - neither draft has MPLS/GMPLS interworking text - is that a problem? PCE does both. If this is a framework for how to do all the scenarios, seems like it should be here. Not religious, but at least saying PCEs are new would be worth doing.

Ross - outside of the scope of this document

Loa - don't agree

DWard - think they should be mentioned in the framework

Loa - Requirements or Framework?

DWard - that's the way they wrote the document set

Loa - it's a possibility, should meet requirements

Ross - a lot of text, or a little?

Loa - two sentences

DWard - or a section that says "do your funtional role" in requirements, same in framework. Would love text, send e-mail to remind me.

Revised ID needed

o draft-ietf-l2vpn-vpls-bridge-interop-02.txt
VPLS Interoperability with CE Bridges (Informational) - 7 of 8
Token: Mark Townsley

Mark - too many DISCUSSes for this call. Revised ID needed, major readability issues

Sam - have strong readability DISCUSS, others please evaluate

Mark - others do, too, readability has been an issue

Russ - Gen-ART said this in last call

Revised ID needed

o draft-ietf-l2vpn-oam-req-frmk-09.txt
L2VPN OAM Requirements and Framework (Informational) - 8 of 8
Token: Mark Townsley

Mark - also revised ID needed as well

DWard - I have Comment, not DISCUSS. Recommendations are so unclear I don't know what's being recommended in Section 9. Need to clear this up - COMMENT or DISCUSS?

Mark - DISCUSS is bigger stick

Dan - use point in my DISCUSS to make that happen. Layered division of work between protocols defined by different organizations. Talk about relations between OAM protocols, use normative languages.

DWard - will let Dan hold the DISCUSS.

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-creed-ogc-urn-03.txt
A Uniform Resource Name (URN) namespace for the Open Geospatial Consortium (OGC) (Informational) - 1 of 3
Token: Lisa Dusseault

Lisa - URL pointing to policies but it was behind members-only login, they will make right page visible.

o draft-korhonen-mip6-service-05.txt
Service Selection for Mobile IPv6 (Informational) - 2 of 3
Note: No document shepherd
Token: Jari Arkko

Document was approved on this call with no discussion.

o draft-sjdcox-cgi-urn-00.txt
A URN namespace for the Commission for the Management and Application of Geoscience Information (CGI) (Informational) - 3 of 3
Token: Lisa Dusseault

Document was approved on this call with no discussion.

3.2.2 Returning Item
o draft-goodwin-iso-urn-03.txt
A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) (Informational) - 1 of 1
Token: Lisa Dusseault

Document was approved on this call with no discussion.

3.3 Independent Submissions Via RFC Editor

3.3.1 New Item
NONE
3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Timing over IP Connection and Transfer of Clock (tictoc) - 1 of 1
Token: Mark

Dan - sent comments, would like to address them

Mark - addressed Dave Oran and Dave Ward, sorry if I missed Dan's comments (or Sam's)

Sam - replied to internal review note

Russ - should also have editorial comments from me

Mark - will forward them to the chair, For Sam's comments - pretty fundamental, were you at the BOF? This stuff would have been covered there.

Sam - may have been, but needs to make it into the charter. Don't know from this charter what expertise is required to do this work.

Mark - more about whether text answers your questions

Sam - right, could listen to audio stream (for me) but still need text for people who weren't at the BOF

Mark - did assume some level of background here. Authors wrote a bunch of documents before second BOF. Could have charter refer to them (even if they are drafts). Can list them as starting points. Can answer questions but can't find all the answers in the text.

Sam - PWE3 had very different outcome than I expected when I read its first charter. Are we setting ourselves up for the same thing here? "No idea what documents coming out of this working group might look like".

Mark - will need to discuss this with Sam offline, may have conference call with other stuff.

DWard - found Mark's response unsatisfying but it answered the question.

Mark - wish we had one protocol, but we have two with interplay (as Dave Oran pointed out)

DWard - think people will having a hard time knowing what to do. Also had concerns about PS/EXP. Need more than Dave Oran's questions answered.

Sam - Is NTPv4 information model documented anywhere? talking about model between NTPv4 and consumers, how NTPv4 talks to the rest of the world - have we ever thought about that?

Mark - if not, TICTOC is right place ("NTPv5" is the goal).

Sam - Dan's DISCUSS is talking about management information model, Dave Oran's is not.

Dan - models go to different things, but would be good to reuse structures.

Sam - don't think I've ever seen that done. But - are they discovering the information model (to be consistent with it), or being consistent with an existing information model.

Mark - could modify information model if we need to

Sam - that's what Dave Oran is saying what we should NOT do. If IEEE1588 and NTPv4 aren't compatible, he's saying that interfaces need to be consistent with NTPv4.

Mark - working group has latitude to create NTPv5

Sam - everyone agrees with that, but Dave Oran is arguing working group should not have latitude to change information model.

Cullen - people have said this, but "there are two protocols, not clear what the relationship is"

Mark - charter says timing in existing protocols aren't accurate enough.

Cullen - didn't get that from the charter

Sam - me, either

Mark - may have gotten edited out

Chris - NTPv4 assumes that you can do any accuracy if the upstream can provide it.

Sam - NTPv4 does include leap seconds

Chris - by ignoring them?

Sam - not clear enough

Mark - Don't automatically put this on the agenda for next time. Holidays may cause the revisions to take longer.

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

5. IAB News We can use

Loa -

1. the discussion on the IAB plenary
- we have a framework and guidelines for what we want the
IAB plenary to be
- we are not really up to speed in implmenting it

2. we are preparing to get the IESG slate in, in January, haven't seen any big problems yet and don't think there will be.

3. we have a message to the research community on starting research groups on unwanted traffic. Made progress during IETF week but has been stalled because a couple of key people are overloaded. Will restart after Christmas/New Year

4. T-MPLS :), we've poked the ant hill enough now to cause quite a bit of activity - all kinds of discussions. Had SG13 chair on PWE3 list very active, discussing OAM stuff, Ericsson people asking what's really going on. Looks like people people we're communicating with aren't communicating enough into ITU-T - people were surprised we have a 60-item issue list with no resolutions.

Ross - planning to attend in Seoul, but not until Thursday - will I be there at the right time?

Loa - should be fine, Stewart will be arriving Monday, other people are still arriving the second week. Key discussions schedule for second week. Monday morning should be fine (but talk to Tom about that).

Loa - did everyone see my mail? Not optimistic we'll get through, especially since we won't have enough people on other side who are discussing with us. Don't think we will meet January 2 deadline.

Mark - be very clear that's not us back-pedaling, the deadline is way beyond what we should have ever signed up for (always a stretch goal) - please make that clear. Getting feedback that we aren't being clear enough about this. Can try to provide text, but if it doesn't happen tomorrow it won't happen before January.

Loa - concerned that amount of effort is starting to break people

Mark - exactly, we've worked as hard as we possibly can, if we don't meet the stretch goal, it's not because we lack good faith.

Loa - thought SG13 was aware of this, but don't think Huub is aware.

6. Management Issue

6.1 Executive Session for Appeal (Russ Housley)

6.2 Scribe Recruiting from Vancouver meeting (Russ Housley)

Some people forgot to ask, others asked but got no volunteers (APPS-AREA enjoyed seeing ADs frame volunteer request as transparency issue, though).

Russ - will make call and ask for new names.

Loa - could provide names of good candidates - will respond to Russ's call

6.3 Approval of the IESG Policy on Autoresponse Messages Sent to IETF Mailing Lists (Chris Newman)

Chris - will get to this over the holidays

This will appear on the next agenda.

6.4 Do we need any response to discussion on the 30-60 minute IPv6 experiment (Cullen Jennings)

6.5 Lifting of DNPs - Mark

Mark - would like to list DNPs for specific documents.

Russ - how?

Mark - no DNP has actually been sent to RFC Editor, so we just send OK to publish.

Russ - how do we get correct IESG note into the tracker?

Mark - can put "this work may be related to Softwires but no objection" for independent submission, other document comes from working group

Jari - think they should be published

Russ - can we approve documents in a management item?

Cullen - have been on agendas before

Sam - Mark cleared DISCUSS on huston draft, both have enough votes to publish

Mark - can slap these back on the agenda for next time?

(Mark entered the IESG note in real time, and IESG approved the "okay to publish" to the RFC Editor.

6.6 Instructions to IANA for GSS-API Service Name registry - Sam

Registry doesn't specify character sets for this registry - want to send mail to IANA not to approve registrations that will turn out to be invalid after the KITTEN working group develops a character set recommendation.

Chris - understand and support this.

Any objection to telling IANA this? No, Sam will send Amy a note with his proposed text, and IESG approved the restricted character set being specified to IANA (alpha-numeric, plus the following characters: '+', '-' and '.') while KITTEN works on a document that actually says this.

7. Agenda Working Group News

Jon - appears Dave Meyer would like to step down from SPEERMINT, exploring replacements.

Mark - circulated new DNSEXT charter, have small edits, will go out tomorrow