IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2008-07-03. These are not an official record of the meeting.

Narrative scribe: John Leslie (The scribe was often uncertain who was speaking.)

Corrections from: Dan

1 Administrivia

  1. Roll Call 1135 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2 Protocol Actions

2.1 WG submission

2.1.1 - New Items

  1. Multicast Negative-Acknowledgment (NACK) Building Blocks (Proposed Standard)
    draft-ietf-rmt-bb-norm-revised-05.txt
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Ron Bonica: Discuss [2008-07-02]: in Security Considerations, SSM won't solve the problem
      Also, not clear how you react when N parties fall behind
    2. Ross Callon: Comment [2008-07-03]: minor comments that the authors can address or not at their discretion. Having once long ago looked at a few reliable multicast protocols I
      Does this document obsolete RFC3941? If so it should say so.
      say a bit more about what to do when one receiver, or a few receivers, are suffering from either much slower or much less reliable service than other receivers.
      In section 1, the following sentence is at best awkward: "...since the use of packet-based Forward Error Correction (FEC) erasure coding for recovery of missing packets as compared to classical re-transmission schemes"
      suggest brief forward reference on page 5 to section 3.5 on page 25
    3. Lars Eggert: Discuss [2008-06-30]: This draft obsoletes RFC3941. Need to state this in the first-page header and the abstract.
      Comment [2008-06-30]: Suggest to remove the reference to the RMT WG for the published RFC.
    4. Pasi Eronen: Discuss [2008-07-03]: Concerns from SecDir review: if member identification is done inside the actual content, and cryptographic authentication is provided by IPsec, there's room for participants to send different information in these two layers.
      "Encryption" is not a security service, it's a technique for providing certain security services... be specific about the security services these protocols need
      Comment [2008-07-03]: typo in acknowledgements section
    5. Tim Polk: Discuss [2008-07-03]: need a MUST in first paragraph of the security considerations

    Telechat:

  2. SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 (Proposed Standard)
    draft-ietf-pwe3-cep-mib-12.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Dan Romascanu: Discuss [2008-07-02]:
      1. DESCRIPTION clause of pwCepConfigError insufficient.
      2. hard to understand functionality of pwCepConformanceCfgTable
      2a. What does 'CEP PW statistics objects are supported (conformed to) or not' mean?
      2b. What type of information is entered by an agent in the 'description' object?
      Comment [2008-07-01]:
      1. I cannot understand why PwCepCfgIndexTC is a Textual Convention.
      2. Introduction - mentioning the PWE3 WG for comments does not seem appropriate
      3. phrase in section 5 is confusing
      4. DESCRIPTION clause of PwCepFracAsyncMap - phrase is confusing
      5. Why are pwCepTableIndex and pwCepFracIndex defined as 'primary'
      6. counter objects in this MIB module can benefit from optional UNITS clauses

    Telechat:

  3. Managed Objects for TDM over Packet Switched Network (PSN) (Proposed Standard)
    draft-ietf-pwe3-tdm-mib-10.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-07-02]: support Dan's discuss
    2. Pasi Eronen: Comment [2008-07-01]: Editorial suggestions from SecDir review
    3. Tim Polk: Comment [2008-07-01]: As noted in secdir review and Dan's preliminary discuss, replacement of parentheses with double quotes is somewhat confusing. I support Dan's position.
    4. Dan Romascanu: Discuss [2008-07-02]:
      1. The Security Considerations section replaces brackets by double quotes, non-conformant with RFC4181 and making the texts confusing
      2. TDM PW table: DESCRIPTION contradicts the fact that this table has a StorageType object.
      Comment [2008-07-02]:
      1. introduction shouldn't refer to WG
      2. Section 3, fix [SATOP] reference
      3. question use of RFC2119 keywords in Section 3
      4. in Section 7, what actions are taken if there are errors reported in this object?
      5. UNITS clause is defined for some objects, not for others.
      6. pwTDMValidDayIntervals defines the minimal value as 1. Syntax allows for 0, is there any special significance?

    Telechat:

  4. Managed Objects for ATM over Packet Switched Network (PSN) (Proposed Standard)
    draft-ietf-pwe3-pw-atm-mib-05.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-07-02]: support Dan's discuss
    2. Pasi Eronen: Discuss [2008-07-02]: from SecDir review: are entries created in pwAtmCfgTable only for PW's carrying ATM?
      Comment [2008-07-02]: SecDir review suggestions for clarifications and editorial improvements should be considered
    3. Tim Polk: Discuss [2008-07-01]: security considerations section refers to pwTDMTable... wonder if the correct reference is pwATMCfgTable?
      Comment [2008-07-01]: support Dan's discuss regarding the formatting in security considerations
    4. Dan Romascanu: Discuss [2008-07-02]: Security Considerations section replaces brackets by double quotes, non-conformant with RFC4181 and making the texts confusing
      Comment [2008-07-02]: introduction shouldn't refer to WG

    Telechat:

  5. MIB for Fibre-Channel Security Protocols (FC-SP) (Proposed Standard)
    draft-ietf-imss-fc-fcsp-mib-02.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-07-03]:
      Section 3.4.2: the "ESP_Header" mechanism is *not* the same as IPsec ESP so citing RFC4303 is confusing or even misleading.
      REFERENCE clauses for t11FcSpSaIfReplayPrevention and t11FcSpSaIfReplayWindowSize should probably reference FC-FS-2 instead of RFC4303
      Section 4.6: Making an assumption that involves the IPSP documents probably isn't realistic
      Reference [FC-SP], and numerous REFERENCE clauses in the MIB, should probably point to ANSI/INCITS 426-2007
      SecDir review identified places that would benefit from clarification; changes suggested by David Black look fine to me. Need to make sure these aren't forgotten during AUTH48.
      Comment [2008-07-03]: I'm currently not able to review this 246-page document (plus the 300+ page FC Security Protocols document) in depth that would be likely to find real problems (if any exist).
    2. Dan Romascanu: Discuss [2008-07-03]: PROTO shepherd and the document editor asked to allow for a revised ID to be submitted in order to address issues raised in the SECDIR and GenART reviews.

    Telechat:

  6. Restart Signaling for Intermediate System to Intermediate System (IS-IS) (Proposed Standard)
    draft-ietf-isis-rfc3847bis-00.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-07-02]: Draft should obsolete RFC3847, rather than updating it.
      References to RFC3373 and RFC3567 need to be changed to cite the respective -bis documents, otherwise they're DOWNREFs.

    Telechat:

  7. Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies (Proposed Standard)
    draft-ietf-isis-rfc3373bis-01.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-07-02]: The references to RFC3373 and RFC3567 should be changed to cite the respective -bis documents that are about to obsolete the original RFCs.

    Telechat:

  8. Domain-wide Prefix Distribution with Two-Level IS-IS (Proposed Standard)
    draft-ietf-isis-rfc2966bis-03.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-07-02]: The reference to RFC3784 should be changed to cite the respective -bis document that is about to obsolete the original RFC.
    2. Tim Polk: Discuss [2008-07-03]: need to provide readers with a reference that describes generic is-is security considerations. [3567bis] would seem to be the best choice.

    Telechat:

  9. IS-IS extensions for Traffic Engineering (Proposed Standard)
    draft-ietf-isis-te-bis-00.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-06-30]: I support the publication of this spec as PS. I did have a few questions and observations though:
      1. I didn't understand the difference in use for Interface IP address and Neighbor IP address options.
      2. For my education, what is the state of IPv6 support in IS-IS?
      3. In the document header, there is confusing linewrap on "Working Group".
      4. The first author's contact information needs an update.
    2. Lars Eggert: Discuss [2008-07-02]: Reference to RFC2966 needs to be changed to cite the respective -bis document, otherwise it's a DOWNREF.
    3. Tim Polk: Discuss [2008-07-03]: need to provide readers with a reference that describes the generic is-is security considerations. [3567bis] would seem to be the best choice.
    4. Dan Romascanu: Comment [2008-07-03]: Where are "Mechanisms and procedures to migrate to the new TLVs" discussed? What is the operational impact of the migration on existing networks? Also, what changes from a manageability point of view. Does the IS-IS MIB published as RFC4444 need an update? Or maybe some other new management interfaces need to be introduced?
    5. David Ward: Comment [2008-07-02]: ISIS has an IPv6 draft for the base proto and a V6-TE draft. V6 in ISIS is widely developed and deployed on the internet

    Telechat:

  10. Dynamic Hostname Exchange Mechanism for IS-IS (Proposed Standard)
    draft-ietf-isis-rfc2763bis-00.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-07-02]: If this document updates RFC 2763, the header should say that.
    2. Lars Eggert: Discuss [2008-07-02]: I believe this obsoletes RFC2763 (instead of updating it). This also needs to be added to the first-page header.
      Comment [2008-07-02]: Section 6., paragraph 2: Add names or remove paragraph.
    3. Pasi Eronen: Discuss [2008-07-03]: The document should say what a router should do if it receives a (name, systemID) mapping for a name or systemID it already has a (different) mapping for. Documenting what existing implementations do would be sufficient.
      The security considerations text should say where the existing security considerations are discussed (e.g. in rfc3567bis).
      There's also one new security consideration: a misconfigured or compromised router can inject false mapping information.
    4. Chris Newman: Discuss [2008-07-02]: This document needs to describe its relationship to IDN (RFC 3490).

    Telechat:

  11. Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication (Proposed Standard)
    draft-ietf-isis-rfc3567bis-01.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-07-02]: This is a no-objection with point raised. What happens when a NOC guy who knew the shared secret leaves the company? Do you have to bounce all of the ISIS adjacencies so that you can change the secret. It would be great if you could change the shared secret without bouncing the adjacency.
    2. Pasi Eronen: Discuss [2008-07-03]: Since this is basically the main document discussing ISIS security considerations, it should also say what is not addressed.
      From SecDir review: character-string to octet-string conversion algorithm matters; text similar to RFC 2385 Section 4.5 should be added.
      The table in IANA considerations section should reference this document, not RFC3567 (which is obsoleted by this document).
    3. Chris Newman: Discuss [2008-07-02]: The document should not make questionable claims. In particular: "believed secure against passive attacks"
      I would like to understand the procedure for hash-function (authentication mechanism) transition.

    Telechat:

  12. Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (Proposed Standard)
    draft-ietf-isis-rfc4205bis-00.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-07-02]: References to RFC 3373, RFC 3847, RFC 3784, and RFC 3567 need to be changed to cite the respective -bis documents, otherwise they're DOWNREFs.
      Comment [2008-07-02]: It's a bit unusual for one draft to update another draft, since they update could as well have been rolled into 3784bis. Do the two drafts really still have this "updates" relationship?

    Telechat:

2.1.2 Returning Items

  1. Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services (Proposed Standard)
    draft-ietf-sipping-uri-services-07.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-06-30]:
      Section 3.1., paragraph 2: "The invocation mechanism SHOULD NOT require more than one RTT"
      Discuss-discuss: I'm not sure if I fully understand this requirement. Is this trying to express that an invocation operation on a URI-list should execute in less than some time duration? If so, this seems to be extremely dependent on a lot of external conditions. Also, since the time duration is defined as a round-trip time, the round-trip time between which two nodes in the network is meant here?
      Section 8.1., paragraph 4: [I-D.ietf-sipping-consent-framework]
      Discuss: This is a DOWNREF, but easily fixed by citing the standards-track draft-ietf-sip-consent-framework instead of the older SIPPING draft.
    2. Chris Newman: Comment [2008-06-30]:
      "clients SHOULD integrity protect URI lists using mechanisms such as S/MIME"
      Given I've never seen S/MIME deploy outside limited enclaves, I question if this mitigation will actually deploy on Internet scale. Can you suggest an alternative mitigation option that might actually be deployable (e.g., hop-to-hop TLS/DTLS, leap-of-faith keying similar to SSH, etc)? I find it both misleading and distasteful to use "SHOULD" when it's something that's likely to remain unimplemented or rarely deployed. I do not view this issue as a barrier to proposed status, but it would be a barrier to future advancement so it might be better to be realistic now.
      "recipient-list the body contains a list of URIs"
      This is unclear and misleading for a "disposition". A disposition should describe how the content is used, while the media type should describe what's in the content.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters (BCP)
    draft-eastlake-ethernet-iana-considerations-07.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-06-19]: support Mark's DISCUSS
    2. Lars Eggert: Discuss [2008-06-18]: Section 2.1.2, paragraph 9:
      DISCUSS: Since Internet Drafts are ephemeral and hence aren't a permanent form of documentation, we should require an RFC here.Comment [2008-06-18]:
      Comment on the same piece of text: Also, since the first bullet talks about standards, do you mean an IETF Standards Track RFC, or do you mean any standard (e.g., by another body) published as an RFC (e.g., on the independent stream)?
      Section 2.1.2, paragraph 14: Who is the expert? Do we need a management item to assign one?
    3. Cullen Jennings: Discuss [2008-07-02]: This deprecates an portion of 2153 so it needs to at least be called out that it updates 2153.
      I doubt that having IANA archive IDs has IETF consensus... why not just drop the requirement for a draft? Of if what folks wanted was to have something that explained what the code point was for, why not ask for specification required?
    4. Mark Townsley: Discuss [2008-06-19]: Disagree with Lars about the use of an Internet Draft - one of the whole purposes behind "Expert Review" is that the numbers can be assigned before an RFC is approved when necessary. I am unsure, however, about the policy asking IANA to archive an ID.
      I do have a concern here: "If the allocation is based on IESG Ratification the procedure starts with the first two steps above for Expert Review..."
      For a very large allocation, perhaps we should give the expert the ability to "pass the buck" of responsibility to the IESG rather than forcing him or her to either be strictly for or against.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. ENUM-based Softswitch Requirement (Informational)
    draft-ietf-enum-softswitch-req-03.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-07-02]: text about processing DNS answers in Section 4.1 seems to assume that all NAPTR records contain terminal rules; this should be said explictly (so that an implementer reading this text realizes that more is needed for full RFC 3761 functionality).
      SecDir review identified some areas that require clarification; the authors have proposed text (which looks OK) which should be added
    2. Dan Romascanu: Discuss [2008-07-03]: The title of the document and of section 4 are mis-leading. It looks to me that the document rather deals with 'Operational Requirements for Enum-based Softswitches' than 'ENUM-based Softswitch Requirement'. I suggest to consider changing the title in order to avoid confusions.
      In any case the name of the document in the header of each page is different, this needs to be aligned with whatever the name will eventually be.

    Telechat:

  2. Two-Document ballot (Experimental)
    draft-ietf-eai-smtpext-12.txt
    draft-ietf-eai-utf8headers-11.txt
    Token: Chris Newman Note: Harald Alvestrand is document shepherd.
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-06-30]:
      draft-ietf-eai-utf8headers, Section 1.2., paragraph 1: DISCUSS: Add "updates" to the first-page header and abstract.
      draft-ietf-eai-utf8headers, Section 1.2., paragraph 3: DISCUSS: Ditto. And please provide an RFC number for "MIME".
      Comment [2008-06-30]:
      draft-ietf-eai-utf8headers, Section 4.3., paragraph 21: Remove note for publication as an RFC.
      draft-ietf-eai-smtpext, INTRODUCTION, paragraph 10: Should briefly describe what it updates in RFCs 4952, 2821 and 2822.
      draft-ietf-eai-smtpext, Section 3.7.3., paragraph 7: Doesn't look like a note to the RFC Editor - remove?
    2. Pasi Eronen: Discuss [2008-07-03]: The security considerations text in utf8headers needs to include a (normative) reference to RFC 4952. In addition, the text should explictly point out that many current email security mechanisms are specified for RFC 2822 compliant messages, and may not correctly work with messages that have UTF-8 headers.
    3. Magnus Westerlund: Comment [2008-07-03]: I think the ABNF could be improved and be made easier to verify.
      1. putting in rulenames for the rules that didn't have name in RFC 2821, like for VRFY and MAILTO. Otherwise you are not really having correct ABNF.
      2. Put in the equivalent of import clause for different rules. What I mean is that for a rule defined in another document, like "atext = <See section 3.2.4 of RFC 2822>"

    Telechat:

  3. Internationalized Delivery Status and Disposition Notifications (Experimental)
    draft-ietf-eai-dsn-06.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-07-03]: ABNF compiles. But only after changing indents in Section 4 to be the same as those in Section 3 (two vs. three spaces). No time to check whether this is a real problem or something that Bill's parser just does...
    2. Magnus Westerlund: Comment [2008-07-03]: I think the ABNF could be improved and be made easier to verify.
      2. Put in the equivalent of import clause for different rules. What I mean is that for a rule defined in another document, like "xtext = <xtext is defined in [RFC3461]>"

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) (Informational)
    draft-hautakorpi-sipping-uri-list-handling-refused-03.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-07-02]: The draft uses non-RFC2606 domain names in examples; some of these (e.g. "example3.com") actually exist and are owned by someone.
    2. Chris Newman: Comment [2008-06-30]: from section 9: "Therefore it is RECOMMENDED that either hop-by-hop or end-to-end encryption is used" would be better if it provided references to the specific technologies that can be used to provide such encryption.
      The "Personnel" section of the ballot write-up is incomplete. Is that intentional?

    Telechat:

3.2.2 Returning Items

  1. (none)

3.2.3 For Action

  1. Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment (Informational)
    draft-sanjib-private-vlan-09.txt
    Token: Mark Townsley Note: This is an independent submission, going on telechat for RFC3932 check.
    (No Balloting Link):

    Telechat:

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. IP Security Maintenance and Extensions (ipsecme)
    Token: Pasi

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Host Identity Protocol (hip)
    Token: Mark

    Telechat:

  2. Network-based Localized Mobility Management (netlmm)
    Token: Jari

    Telechat:

  3. IPv6 over Low power WPAN (6lowpan)
    Token: Mark

    Telechat:

4.2.2 Proposed for Approval

  1. Pseudowire Emulation Edge to Edge (pwe3)
    Token: Mark

    Telechat:

    1228 EDT break

    1234 EDT back

5. IAB News We can use

  1. Loa: planning Dublin; Wed morning free; discuss 3 items started in retreat, ICANN (stronger position), tech plenary IPv6 (panel to include vendor, operator, academia)
  2. Loa: also with liaison mtg in Dublin, liaison managers reporting needs work

6. Management Issues

  1. Executive Session: Discussion of Appeal (Russ Housley/Tim Polk)

    Telechat:

  2. NAT-PT

    Telechat:

7. Agenda Working Group News

1327 EDT went into executive session