IESG Telechat 2006-08-31 (Narrative Summary)

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the August 31, 2006 IESG Teleconference

Scribe: Spencer Dawkins <spencerdawkins@gmail.com>

With corrections from: Ted Hardlie, Leslie Daigle, Brian Carpenter, Dan Romascanu, David Kessens

--------------------------------------------------------------------------------

1. Administrivia

1.1 Roll Call

1.2 Bash the Agenda

No new items, no changes noted.

1.3 Approval of the Minutes of the past telechat

Ted is providing text in ticket number 88347 for 8-17 minutes. Minutes were approved with this addition.

Spencer will provide 9-17 narrative minutes for posting.

1.4 List of Remaining Action Items from Last Telechat

Sam creating mailing list experiment procedure - done, now ready for review.

David/Brian/Dave Meyers writing job description for IANA multicast address assignment expert - done.

1.5 Review of Projects

Jon - No updates, no specific hassling, but general hassling is needed to move forward, and is duly noted.

2. Protocol Actions

Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
           2.1 WG Submissions
           2.1.1 New Item        Area Date
RAI Two-Document ballot: - 1 of 7
   The Message Session Relay Protocol (Proposed Standard) - 1 of 7
   draft-ietf-simple-message-sessions-15.txt
   Relay Extensions for the Message Sessions Relay Protocol (MSRP) (Proposed Standard)
   draft-ietf-simple-msrp-relays-08.txt
Token: Jon Peterson

Jon - lots of substance to the DISCUSSes for this document, too much to resolve at this call - will go revised ID needed.

Brian - can DISCUSS at next week's informal call if necessary.

Jon - people are still reacting to positions, don't panic yet.

RTG GMPLS - Communication of Alarm Information (Proposed Standard) - 2 of 7
   draft-ietf-ccamp-gmpls-alarm-spec-04.txt
Token: Ross Callon

Russ - will work the DISCUSSes with the authors and CC WG chairs.

Bill - timestamp thing - I've seen other things say "this is beginning/middle/end of NTP timestamp"

Sam - Russ has excellent on timestamps

Russ - which is in the DISCUSS - not sure what the authors entended at the end.

Ross - Magnus DISCUSS is separate, will work separately.

Document will go into AD followup.

RTG Three-Document ballot: - 3 of 7
   Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base (Proposed Standard) - 3 of 7
   draft-ietf-ccamp-gmpls-lsr-mib-14.txt
   Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management (Proposed Standard)
   draft-ietf-ccamp-gmpls-tc-mib-10.txt
   Note: Awaiting update from final MIB review.
   Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base (Proposed Standard)
   draft-ietf-ccamp-gmpls-te-mib-15.txt
   Note: Awaiting update from final MIB review.
Token: Bill Fenner

Brian - is Russ's note about word "protection" just terminology question?

Bill - thought Adrian had replied - in this case, this is one parallel link protecting the other, not about integrity/confidentiality.

Dan's issues are OID issues plus some comments, have been resolved.

Russ - will clear based on Adrian's response.

Bill - AD followup, will decide if OID issue is RFC Editor Note.

RTG IANA Considerations for OSPF (BCP) - 4 of 7
   draft-ietf-ospf-iana-01.txt
Token: Bill Fenner

Bill - doesn't update protocol, only IANA considerations

Russ - understand and will clear DISCUSS

Mark - comment is close to DISCUSS - looks like "NT" is assigned but you don't mention this, similar to the way you did in section 5.1. Change to DISCUSS?

Bill - yes, please.

Brian - agree with Jari's discuss - that's why I'm just a COMMENT.

Bill - I more or less agree. We'ved removed a DISCUSS and added a DISCUSS, will go into AD followup.

TSV Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (BCP) - 5 of 7
   draft-ietf-tsvwg-ecn-alternates-01.txt
   Note: PROTO Shepherd: James Polk (jmpolk@cisco.com)
Token: Lars Eggert

Three active DISCUSSes...

Lars - sent e-mail to Mark (who just responded - don't think semantic difference between example and recommendation justifies removing DISCUSS, especially if you have only one example. Having routers decrement something is a big deal, not casual. Use another example?)

Mark's DISCUSS backed Sam's DISCUSS which isn't there any more. Cullen's is also on the same point, but it's a COMMENT., and Cullen agrees with Sam's additional text.

Lars - not worth additional discussion on this call.

Brian - Sally has agreed to the Gen-ART review comment.

Ross - sorry for late DISCUSS (this morning)

Lars - will be AD followup.

RTG Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) (Proposed Standard) - 6 of 7
   draft-ooms-v6ops-bgp-tunnel-06.txt
   Note: Despite its filename, this is an *IDR* working group draft.
Token: Bill Fenner

Was deferred to next telechat.

RAI Two-Document ballot: - 7 of 7
   Media Type Registration of RTP Payload Formats (Proposed Standard) - 7 of 7
   draft-ietf-avt-rfc3555bis-04.txt
   Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences (Proposed Standard)
   draft-ietf-avt-rfc3555bis-part2-01.txt
Token: Cullen Jennings

Cullen - don't need to DISCUSS now, thanks to Russ for a very actionable DISCUSS, will work with the authors.

2.1.2 Returning Item
      NONE

2.2 Individual Submissions
           2.2.1 New Item
      NONE

2.2.2 Returning Item        Area Date
APP Calendaring Extensions to WebDAV (CalDAV) (Proposed Standard) - 1 of 1
   draft-dusseault-caldav-14.txt
Token: Ted Hardie

Ted - want to DISCUSS Sam's DISCUSS - inherits a lot of stuff from WebDAV, which inherits from HTTP - what do we need to add to meet Sam's DISCUSS?

Sam - lot of internationalization issues associated with searching internaltionalized strings. When we looked at this in LDAP and IDN, we came up with a more complicated solution, don't understand why this is easier for CalDAV than LDAP.

Lisa - we limited to avoid international characters for simplicity.

Sam - you can limit to ASCII, but you're already comparing UTF-8 strings, including user-provided strings.

Ted - Two cases here. The first case is a known item search, where the user knows the token. The second is one in which there is an unbounded set of possible strings, in utf-8. This document has limited its search capabilities to "pattern of octets", rather than taking on the harder problem of matching things like combining characters and their pre-composed equivalents. If you look at 8.4 there's text to say "find other users" - you're asking "does this pattern of octets occur?" - we can say this more clearly, would this address your issue?

Sam - think IETF consensus is that we don't do that, but am happy to have discussion IETF-wide, because it would be simpler for a lot of items if we've changed discussion.

Ted - we don't have a working group, so there's a limit to what we can ask. Pull the search section to another document?

Sam - that would be unfortunate.

Lisa - familiar with DASL? We didn't want to do anything that would conflict with DASL, even though DASL hasn't completed.

Ted - in reality, most of these searches are within a context where we know the language

Sam - but not the same input method or even operating system - this was a problem when we did Kerberos.

Ted - we also have addtional work that handles these cases - punt to that?

Sam - not the way I would do this, but I wouldn't have a reason to hold a DISCUSS if you did. Bring this up as a Last Call issue and ask for consensus? If people don't care, I'd remove the DISCUSS.

Ted - have suggested that normative reference is to RFC 2518, but since 2518bis is not changing the protocol, would also include it as informative, for clarifications.

Ted will go to the author group with two options: push search discussion to external work and declare out of scope for this document or have larger discussion with IETF on whether this limited search capability is okay if called out as limited.

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        Area Date
INT Goals for Network-based Localized Mobility Management (NETLMM) (Informational) - 1 of 1
   draft-ietf-netlmm-nohost-req-04.txt
Token: Jari Arkko
3.1.2 Returning Item
      NONE

Jari - have gotten comments and DISCUSSes, (Gen-ART of privacy aspects, Sam's DISCUSS, Last Call).

Have gotten discussion about general readability. Not sure it's useful to send document back to working group, this isn't their main output, but agree with Sam's concern that he doesn't get the whole picture without the threats documents (third in the series) - Jari OK to wait until third document is forwarded.

Brian - sending documents back for restructuring is a way to become unpopular.

Jari - Privacy - GeoPriv wants to reveal locations, but we don't want to do that here.

Ted - I think this is not clear enough on which threats relate to the network topology and which to the geography. When geographic location is of concern, it is because the attacker knowing where the node is physically poses a threat. Only a small portion of this section relates to that threat. They need to tease topology from location more carefully, both in the threat model and the description.

Brian - this was "topology hiding" in V6OPS draft-ietf-v6ops-nap draft - is that valuable here? It's not privacy in the geopriv sense.

Jari - agree that this needs to be rewritten.

Ted - metaquestion - this is a chartered working group where the goals are in the charter - how important is this document, now that the working group has been chartered? Not sure this document will even be read.

Jari - fair question, don't know how much interest there is in fixing this document. Would rather delete problematic text than fix it. There are silly requirements ("reuse where possible") based on long WG discussions that finally compromised, not useful for outsiders and maybe not even useful in the group itself.

Brian - had same problem in multi6, but this gave us a way to go forward. If WG wants this, they should just work on it, not put it on the critical path.

Cullen - this goes beyond what's in the charter and clips off part of the solution space - that's probably a good thing ("don't reopen old discussions").

Brian - does add to what's in the charter.

Jari - Sam has problem with "multicast is out of scope".

Sam - inappropriate to break global multicast here, if router has same address and doesn't rejoin groups, would expect traffic to continue to arrive. This is part of IP service model, LMM can't break this.

Jari - shouldn't break anything, that's what I think. Expect problem is that WG hasn't thought about this at all. If there's something beyond the IP service model we would have to worry, but don't know what that "something" might be.

Sam - WG thinks securing this requires more credentials - why?

Jari - don't think WG expects this.

Sam - positive statement of a goal ("secure without additional credentials").

Jari - OK, revised ID needed.

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        Area Date
SEC EAP Password Authenticated Exchange (Informational) - 1 of 3
   draft-clancy-eap-pax-09.txt
Token: Russ Housley

No DISCUSSes, document is approved, Russ wants to include Gen-ART comments before announcement.

RTG RFC 1264 is Obsolete (Informational) - 2 of 3
   draft-fenner-obsolete-1264-02.txt
Token: Ross Callon

Ross - DISCUSS looks like Dan and Bill should be able to update the document in the short term - Dan agrees -

Brian - think paragraph can simply be removed, now that newtrk has been close.

Dan - document says "someone else is working on process issues, but now they aren't" - how?

Mark - "newtrk tried and failed?"

Brian - not helpful in RFC that lasts 50 years.

Ross - where did idea of security considerations and management considerations come from?

Brian - Security considerations goes back very far, Jeff Schiller is the one who insisted on more than "Secuity considerations are not discussed in this memo".

Sam - there is a BCP on security considerations

Will go revised ID needed.

APP A Uniform Resource Name (URN) Namespace for The Near Field Communication Forum (NFC Forum) (Informational) - 3 of 3
   draft-abel-nfc-urn-00.txt
Token: Ted Hardie

Ted - reference to 3406 can be fixed in AUTH48..

Russ - completely fine with that (so I made this a COMMENT).

Approved and will be sent as document action.

3.2.2 Returning Item        Area Date
GEN Apr 11 A Process Experiment in Normative Reference Handling (Experimental) - 1 of 1
   draft-klensin-norm-ref-01.txt
   Note: RFC 3933 process experiment
Token: Brian Carpenter

Brian - We have proposed message to send to the community - any final thoughts before Brian sends it? Author isn't happy with message but thinks we need to send it. Will post to IETF Announce and IETF Discussion list.

Sam - does anyone think we're doing the wrong thing?

Cullen - we've had several proposed actions, and I'm fine with all of them, including this one.

Brian - not lots of community support, just a lack of community opposition.

Will stay in AD followup, but isn't under IESG discussion any more.

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
      NONE
3.3.2 Returning Item
      NONE

3.3.3 For Action        Area Date
GEN A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization (Informational) - 1 of 1
   draft-irtf-mobopts-ro-enhancements-08.txt
Token: Brian Carpenter

Discussion is who we assign as AD.

Brian - has already been approved by IRSG. We're entitled to look at it, but life would be tricky if we say "do not publish", even under the current procedures. Unless something is violently objectionable, it would be published.

Mark - Jari's a co-author

Brian - that narrows the choices - Mark is the obvious shepherd.

Mark - what process do we follow? Last Call this?

Brian - there is a draft about IRTF documents. Look at proposed procedures.

Sam - need to make sure we don't subject document to MORE review than RFC 3932 requires.

4. Working Group Actions
           4.1 WG Creation
           4.1.1 Proposed for IETF Review
                    NONE
           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
           Area Date
APP Aug 8 Language Tag Registry Update (ltru) - 1 of 1
Token: Ted

Discussion on this topic was not minuted.

5. IAB News We Can Use

From Dave Meyer

Talking about followup from Montreal plenary about net neutrality, protocol correctness.

Leslie - think we're making progress here.

IAB Routing and Addressing Workshop is shaping up, with great ISOC and RIPE support.

OIF liaison and ITU/MPLS/GMPLS are under discussion.

Leslie - as there have been many discussions surrounding MPLS issues and ITU work, there's a specific proposal on the table to have an IETF liaison to ITU-T for the MPLS topic (much as we have one for NGN). Please tell us if you have input on the proposal.

Ross - will workshop be two full days? Because so many of us are traveling to Europe.

6. Management Issues

6.1 Stuckees to analyze two appeals (Brian Carpenter)

Discussion was not minuted.

6.2 Sending RFC Editor communication to ietf-announce (Bill Fenner)

Bill thinks this was decided last time - is this still open?

Amy - Expedited handling request was the only thing we discussed.

Bill - that's correct, so it's not still open.

6.3 Get rid of mailserv@ietf.org mention in I-D announcements? (Bill Fenner)

Bill - noticed this a couple of years ago - this hasn't worked for a few years and no one has complained, so let's kill it silently.

Brian - don't need to announce a service that isn't being provided now.

Bill - probably need to look for other mentions on the website

Lars - need to announce, just for transparency.

Bill - We're deleting the MIME e-mail part - add the URL?

Brian - it's directly in the message now, anyway. Tao announcement doesn't have any mention of mail retrieval.

6.4 Approval of RFC 4633 procedure for six month suspensions (Sam Hartman)

Sam - not sure we're ready to approve because not sure who's read it yet. Goal of draft is that ADs who have gone through one-month suspension can suspend up to 6 months and delegate (perhaps WG chair for WG mailing lists). Would send this out to the community, becomes effective 14 days after sending. Also need to update the web page.

Ross - is wg secretary as administrator OK?

Brian - draft is neutral, and covers non-WG mailing lists as well

Sam - is this necessary if Brian's draft is approved? It includes delegation and it is experimental.

Brian - need to make sure that people can't suspend IESG members from the IESG mailing list...

Sam - probably need to state "non-WG mailing lists" more clearly. Do people think we're in a position to approve this today? Want another cycle? Don't want to approve?

Cullen - read and don't object.

Brian - anyone need another two weeks? none noted. Would love to have ad hoc ballot.

Sam - how do I deal with administrivia?

Brian - good question. Announcement should probably come from Brian, not from a specific AD.

Cullen - happy to hack the web page.

Brian - we've never had flesh on an experiment before.

Brian volunteered to draft a procedure for the Wiki on how experiments are handled (where they are announced, etc.).

Sam - we approved the procedure, right? Seems right.

7. Working Group News

Jari Arkko - MIPSHOP has new co-chair. 16ng added technical advisor. Have two BOF requests - mobile platform group (connection-oriented) and PSMI, going beyond NetLMM - could just add this work when NetLMM recharters.

Ross Callon - no

Brian Carpenter - no

Lisa Dusseault - no

Lars Eggert - no

Bill Fenner - IDR working group has two documents that are aimed at the same problem, and they need to come at the problem from a different angle, and there's no strong selector between proposals. Working group participants have asked chairs and ADs, chairs have asked ADs, we don't ever have a good answer for this. We have a strong stance that we don't publish competing protocols, but we could, or we could publish both at experimental, or ...

- Mark - any guidance from implementations/deployments?

- Bill - good thought, don't know the facts.

- Mark - if you can get that information, it's a time you could ask for additional inputs. Is there a sense in the working group that one choice must be chosen?

- Bill - no, not really.

- Mark - had this problem with PWE3, are we really going to do twice the work? Need to establish that we need to choose before we can make a choice.

- Cullen - would publishing both at PS impact deployment of either?

- Russ - PKIX didn't decide this, there's fragmentation with no interoperation, this is bad.

- Ted - if participants don't want to make a choice, having the IETF pick a winner doesn't do anything. Picking one doesn't make people change their plans.

- Mark - you can strongly encourage, right?

- Ted - we can involve more people to get a different consensus, but we can't overrule the consensus.

- Ross - getting service providers involved helps, if you are able to get them to speak up.

- Sam - if both documents are PS-quality, publishing two documents as experimental is the wrong way - publish both at PS.

- Ross - get design team of service providers involved?

- Bill - good way to try to move forward.

- Brian - think they'd converge?

- David Meyer - depends on who you involve.

- Mark <???> - are there implementations on both sides, or just authors?

- Bill - don't know if there are any fielded implementations.

- Mark - first question is whether there is running code, not knowing what the actual issue is, of course.

- Bill - thanks for the brainstorming

Ted Hardie - Looking for a volunteer to replace charset reviewer expert

Sam Hartman - WG ??? another case where we get the requirements document with the protocol document

- OpenPGP working group will be closing down if Sam ever finishes their documents

- Russ - has OpenPGP looked at using certificates in TLS?

- Sam - there's not much of a working group left here...

- Sam - have also convinced people that SASL can't update previous versions of the specs it uses.

Russ Housley - no

Cullen Jennings - no

David Kessens - another last call on anycast document, expect activity regarding this last call

Jon Peterson - no

Dan Romascanu - asked IP storage working group to consider if it would not be more efficient to do future MIB work in T11, with the IETF MIB Doctors performing reviews, similar to the transition process defined for Bridge MIB WG. The rather detailed answer received from the WG chair is that such a change will not lead to a more efficient process. We let them know that when rechartering we shall be applying the same criteria for all WG rechartering (enough energy, editors, enough reviewers, etc.)

Mark Townsley - no

Magnus Westerlund - no