IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2008-12-04. 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 1134 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. NFS Version 4 Minor Version 1 (Proposed Standard)
    draft-ietf-nfsv4-minorversion1-27.txt
    Token: Lars Eggert Note: Brian Pawslowski (beepy@netapp.com) is the document shepherd.
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2008-12-02]:
      1. Doc says: "The base assumption with respect to minor versioning is that any future accepted minor version must follow the IETF process and be documented in a standards track RFC."
        Do the authors mean to imply IETF WG process? Or IETF Consensus process over a document? Might save grief if this is clearer.
      2. The acronym SSV is not explained or even expanded until page 69. The difference between the state protection option and the GSS mechanism (or the relationship between them) is unclear. It's also not clear until several re-readings, that this was invented for NFS and doesn't reference some standard GSS mechanism in another RFC.
      3. It would be good to have some examples of how NFS ACLs can work when clients are accessing data stores directly. Section 12.9 is a little short on security considerations for pNFS.
      4. I was looking for some more security considerations of the grace period. Can a bad client take advantage of the grace period to commit changes that weren't the client's in the first place, or to take over locks that it didn't have?
      5. The stringprep and nameprep building blocks are no longer used by the community that developed them (IDNA).
      6. Some behaviors are specified by reference to POSIX or left unspecified. Even where there is a reference to POSIX it doesn't actually point to a normative reference document as far as I can tell.
    2. Pasi Eronen: Comment [2008-12-04]: NFSv4.1 is probably the most complex protocol IETF has ever attempted to standardize --- and if this is a "minor version" (with >300 pages of new text), I don't want to even think what a "major version" would be like :-)
      I can't claim that I have read the whole spec. It looks unusually well written, so I'm balloting "no objection".
    3. Russ Housley: Discuss [2008-11-30]: I am very pleased that David Black was able to perform a Gen-ART and Transport review. He caught one very important problem. Section 5.10 needs to be rewritten to reference a Unicode document that defines the notion of case for a particular version of Unicode.
      Comment [2008-11-30]: The Gen-ART and Transport review from David Black provides some useful comments. They should be addressed if the document is updated.
    4. Chris Newman: Discuss [2008-12-04]: Section 14.5
      Both UTF-8 and UTF-16 include Unicode characters that have more than two bytes. I _think_ you mean "names containing characters outside of Unicode plane 0 on filesystems that fail to support such characters despite their presence in the Unicode standard"
      Comment [2008-12-04]: The IDNA community which created stringprep has found certain problems with it after deployment.
      First, stringprep is based on NFKC, but it turns out that NFKC canonicalizes some things which should not be canonicalized in some locales...
      Second, the prohibited characters can be overly aggressive for some locales.
      Third, locking to a particular Unicode version is problematic because many operating systems have i18n libraries with Unicode tables for a version of Unicode that was current at the time of the OS release.
      Now as Stringprep remains on the standards track and has not been moved to historic, it is valid process to use it in IETF specifications. However, we also have RFC 5198 (based on NFC) on the standards track as a much lighter-weight alternative. I consider either choice acceptable on the standards track, but recommend the issue be considered carefully in light of the experiences from the IDN community.
    5. Tim Polk: Discuss [2008-12-04]: [This is an updated discuss. Issue #2 is new]
      Issue #1: This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today... To make matters worse, implementers in the security directorate find that LIPKEY and SPKM-3 are underspecified, so interoperability of these options can be problematic.
      I believe that LIPKEY and SPKM-3 should be removed from the mandatory to implement security mechanism list. If the wg feels strongly they should be retained, they should become optional. It would also be helpful if the text on Kerberos was expanded to note that the mandatory to implement algorithm set is now AES with HMAC-SHA1, based on the reference to RFC 4121. Finally, a brief note in the security considerations text on cryptographic algorithms might be helpful.
      Issue #2: The security implications of pNFS are significant. They are clearly documented in section 12.9, but I believe they merit an earlier mention.

    Telechat:

  2. pNFS Block/Volume Layout (Proposed Standard)
    draft-ietf-nfsv4-pnfs-block-10.txt
    Token: Lars Eggert
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-12-04]: Review by Christian Vogt:
      Technical:
      Section 2.2.1 ("Volume Identification") specifies two methods for identifying a position on a disk: The second method is limited to implementations where server and client have the same understanding of the disk size. This method could be generalized...
      Section 2.4 ("Crash Recovery Issues") specifies recovery procedures that a client could initiate following a server crash. These procedures apply in one specific condition, The section should also consider other conditions.
      Section 2.4 ("Crash Recovery Issues") does not explain how a client detects a server crash.
      Editorial: The specification uses undefined acronyms in a couple of places
    2. Tim Polk: Discuss [2008-12-04]: This solution significantly expands the security responsibilities of NFS clients, and there are a number of environments where the mandatory to implement security properties for nfs cannot be satisfied. I believe this information merits documentation in the body of the document.
      Specifically, Section 2.1 Background and Architecture, should document the security responsibilities delegated to pNFS clients and note the limitations in applicability.

    Telechat:

  3. Object-based pNFS Operations (Proposed Standard)
    draft-ietf-nfsv4-pnfs-obj-10.txt
    Token: Lars Eggert
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-12-04]: Section 4.4.4 lists an issue which seems unresolved in the current version of the document. Can we resolve it and/or adopt the already agreed resolution to the document so that the document can be approved?
      I do not think [8] can be an informative reference.
      Comment [2008-12-04]: "To recover from this condition the client should report the error and return the layout using LAYOUTRETURN..."
      Is it really the client that should report the error, not the server?
      The concept "lun" is mentioned only twice in the document, and never explained. Please explain.
      Several cases of Garbled text.

    Telechat:

  4. Sieve Notification Mechanism: mailto (Proposed Standard)
    draft-ietf-sieve-notify-mailto-10.txt
    Token: Lisa Dusseault Note: Barry Leiba to be the expert reviewer for the registry this creates.
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-12-02]: idnits complains about two instances of "MAY NOT", which isn't a valid RFC2119 term. I believe both can be replaced by MUST NOT.
    2. Pasi Eronen: Comment [2008-12-01]: Couple of nits about references (could be fixed with an RFC Editor note)
    3. Cullen Jennings: Discuss [2008-12-01]: It seems like the draft should include a way for a recipricant of these notifies to tell the server to stop sending them.
    4. Chris Newman: Comment [2008-11-17]:
      It "Updates: RFC 3834" because it changes the extension rules from IETF consensus to Specification Required.
      The term "URI Header" is not defined anywhere.
    5. Tim Polk: Comment [2008-12-02]: The message composition guidelines in section 2.7 are very weak. As far as I can tell, the only field that is required to be included is the "Auto-Submitted: auto-notified" header field. Everything else is a SHOULD. Is that really the wg's intention?
    6. Dan Romascanu: Comment [2008-12-03]: The current IESG Write-up is replicating the whole PROTO shepherd write-up.

    Telechat:

  5. Dual Stack Mobile IPv4 (Proposed Standard)
    draft-ietf-mip4-dsmipv4-08.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-12-04]:
      1. I have some difficulties in understanding how the foreign agent care-of address mode works with when tunneling IPv6 to the CoA.
      2. Section 4.3.2 says "The home agent SHOULD check that all inner IPv6 packets received from the mobile node over a tunnel [..] include a source address that falls under the registered IPv6 prefix(es) for that mobile node." I don't quite see why this is "SHOULD" instead of "MUST"?
      3. Section 4.3.2 says that Minimal Encapsulation (RFC 2004) could be used for IPv6 traffic, too -- but I can't quite see how this would work
      4. Section 4.8: RFC 3519 requires that the "Next Header" field in the Mobile Tunnel Data message header matches the value of the "Encapsulation" field in Registration Reply. Wouldn't just setting the "Next Header" to IPv6 mean the packet is dropped?
      5. Section 4.6.1 seems to suggest tunneling IPv6 traffic to the home agent even if no DSMIPv4 extensions were included in registration reply (and MN does not know that the HA supports DSMIPv4 -- and even if it does, it may not support DHCPv6 PD). Is this a good idea? Wouldn't it be better to explicitly signal that DHCPv6 PD will be used (and a tunnel for link-local traffic is set up) with an extension in registration request/reply?
      6. Section 4.3.3, says that MLD must be tunneled "between the mobile node and the home agent, bypassing the foreign agent". Does this mean "tunneled to the IPv4 HoA"?
      7. Section 4.5 says that "the mobile node SHOULD assume that these IPv6 prefixes are rejected" if they're not included in the reply. What are the circumstances when the MN can assume they were *not* rejected, and what does it do then? (That is, why this is not a MUST?)
      Then to the usual issues with specs that do IP tunneling:
      • The spec needs to say something about fragmentation and path MTU discovery.
      • The spec should say something about the DSCP field and ECN bits.
      • The spec says IPv6-in-IPv4 tunneling is done as specified in RFC 4213. We should add a paragraph highlighting some of the less-than-obvious impacts of RFC 4213:
    2. Tim Polk: Comment [2008-12-03]: updated comment: Issue #1 is new issue; Issue #2 has been addressed in email for the authors already.
      1. The IPv6 Prefix Reply Extension is defined as a skippable extension. Is there an advantage to using a skippable extension for the prefix reply?
      2. The text in section 4.5, list item 2) apparently assumes that the code value in the registration reply header is set to an accept code, but this isn't stated.
    3. Magnus Westerlund: Comment [2008-12-04]: Does this MIP4 extension deal with the case when there is a v4<->v6 address family translator between the MN and the FN or HA? Can this operate in such an environment without an application level gateway that support MIP4?

    Telechat:

  6. Extended URLFETCH for binary and converted parts (Proposed Standard)
    draft-cridland-urlfetch-binary-03.txt
    Token: Chris Newman Note: Eric Burger is document shepherd. Note this is a lemonade WG document despite the name.
    Extracted from Balloting:
    1. Russ Housley: Discuss [2008-12-03]: The Gen-ART Review by Pete McCann includes a concern with the ABNF: "I could not parse the ABNF as some productions seemed to be missing"
    2. Dan Romascanu:Comment [2008-12-04]:I suggest to explain or expand what is URLAUTH and URLFETCH at the start of thedocument. The terms are being used in the title, Anstract and then body of the document without any explanation.

    Telechat:

  7. The IMAP NOTIFY Extension (Proposed Standard)
    draft-ietf-lemonade-imap-notify-07.txt
    Token: Chris Newman Note: Eric Burger is document shepherd
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-12-02]: Based on the discussion that followed the Gen-ART Review by Brian Carpenter, I expected to see a forward reference added to the 'Overview and rationale' section

    Telechat:

  8. Measures for making DNS more resilient against forged answers (Proposed Standard)
    draft-ietf-dnsext-forgery-resilience-09.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-12-01]: Sections 4.5, 7.1 and 9.2 suggest that the port range 1-1024 should be avoided when randomizing. The document needs some additional text that clarifies the tradeoffs surrounding this recommendation. The document should recommend that a mechanism exist by which specific ports can be excluded from being used for randomization.
    2. Pasi Eronen: Discuss [2008-12-02]: there's a normative reference to an informational RFC. If that would have been mentioned in the IETF Last Call message, everything would be fine.... but it was not.
    3. Cullen Jennings: Comment [2008-12-01]: I'm wondering about the case where the resolver is behind a NAT, and the attacker can cause the NAT to do many thousands of DNS queries in a a few minutes, the randomization of ports can cause complete depletion of all ports on the NAT resulting in failure of all applications behind the NAT.
    4. Mark Townsley: Discuss [2008-12-03]: Holding just to be sure that Cullen's Comment is considered. Unfortunately, I don't think we can ignore NATs here.

    Telechat:

  9. Multiple Care-of Addresses Registration (Proposed Standard)
    draft-ietf-monami6-multiplecoa-10.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-12-03]:
      • Sections 9.3.1 and 9.3.2 talk about the HA checking the outer source address of reverse-tunneled ESP protected packets, but RFC 3775 says it's not done when using ESP.
      • saying "the Mobile IPv6 stack [...] MUST verify that the source address [...] before decapsulating" would not be correct anyway
      • The last bullet of Section 9.3.2: every tunnel mode IPsec SA has a single tunnel header destination address, so unless the goal is to have this document update RFC 4301, multiple SAs are needed if IPsec-protected payload traffic is sent simultaneously to multiple CoAs.
      • Section 5.4 and 5.6.3: text says the care-of address field SHOULD be omitted when deleting a binding. Why "SHOULD" instead of "MUST"
      In addition, the following places probably need some attention and possibly fixing:
      • Section 4.2 should explicitly say that the BID mobility option sent to a correspondent node MUST NOT contain an IPv4 care-of address.
      • Section 5.1, "the value should be an integer between..." should be "the value *is* an integer between..." (it can't be anything else)
      • Sections 5.2 and 6.2 say that when the BID option contains the care-of address, the alternate care-of address option must not be used. This text should probably say something about the IPv4 CoA option as well.
      • Section 6.2, 6th bullet: the sub-bullets do mention the possibility of an IPv4 care-of-address, but they're not totally aligned with DSMIPv6.
      • All mentions of the RFC 5268 Link-Layer Address (LLA) option probably should be to the Mobility Header Link-Layer Address (MH-LLA) option instead (LLA is a neighbor discovery option).
      • RFC 5268 and ID-DSMIPv6 need to be normative references.
      • The acronym "NDP" is never expanded in the document
    2. Russ Housley: Discuss [2008-12-02]: Following the in-depth Gen-ART Review by Elwyn Davies, Ryuji Wakikawa indicated that an update to the document would be made to address the comments. That update has not been posted yet.

    Telechat:

  10. NFSv4 Minor Version 1 XDR Description (Proposed Standard)
    draft-ietf-nfsv4-minorversion1-dot-x-10.txt
    Token: Lars Eggert Note: Brian Pawslowski (beepy@netapp.com) is the document shepherd.
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-12-04]: I found it annoying that if you extract this file with the extract script from one of the other NFSv4 drafts (I used the one in pnfs_obj), the end result does not compile. Something to do with the different grep patterns you used in them.
    2. Cullen Jennings: Discuss [2008-12-02]: The license of this code should be made clear.
    3. Chris Newman: Comment [2008-12-03]: I support Cullen's discuss. I note that RFC 5378 section 6 last paragraph forbids publication of this document with the present copyright notices.
      Let me suggest a path forward:
      1. The boilerplate should be updated to RFC 5378 boilerplate.
      2. The copyright notices in the code should be removed or should be changed to follow the RFC 5378 boilerplate.
    4. Dan Romascanu: Comment [2008-12-03]: If the description in this document covers operations and features from NFSv4.0 then RFC 3530 should be a normative reference.

    Telechat:

  11. Reserved IPv6 Interface Identifiers (Proposed Standard)
    draft-ietf-6man-reserved-iids-03.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-12-01]: This document appears to only create an IANA registry for reserved interface IDs, but doesn't actually update any of the specifications that generate such IDs to say that the values in the IANA registry must be avoided.

    Telechat:

2.1.2 Returning Items

  1. GIST: General Internet Signalling Transport (Proposed Standard)
    draft-ietf-nsis-ntlp-17.txt
    Token: Magnus Westerlund Note: RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation and also include some motivation behind your decision.
    Extracted from Balloting:
    1. Ross Callon: Comment [2007-04-03]: I changed my vote to "abstain" because I still feel that this should be "experimental", but other ADs don't agree
    2. Brian Carpenter: Comment [2007-03-16]: I'm very doubtful about the real deployability of GIST; these extracts say why:
      "This specification does not define mechanisms for GIST to manage multiple parallel routes or an unstable route."
      "GIST messages will generally pass through NATs, but unless the NAT is GIST-aware, any addressing data carried in the payload will not be handled correctly."
      Is it certain that flow splitting can't be handled by an extension to the route change mechanism?
    3. Lars Eggert: Comment [2008-03-26]: (empty)
    4. Pasi Eronen: Comment [2008-12-03]: The latest version no longer uses the Router Alert option, so it probably will not cause harm to the existing infrastructure.
      I do agree with Chris's comment that this is unlikely to be useful or deployed, but I am voting no objection because this is in the WG charter
    5. Bill Fenner: Comment [2006-09-27]: No Further Objection. My concerns are adequately covered by several other DISCUSSes.
    6. Cullen Jennings: Comment [2008-04-03]: Both the routing AD have abstained on this because they do not believe it is appropriate for internet routing. I have heard their arguments, believe they are sound, and support their position.
    7. Chris Newman: Comment [2007-04-12]: This document is so long and complex that I consider it highly unlikely it will deploy. Because the WG delivered on its charter item I will vote no objection. Were this an individual submission, I would probably abstain.
    8. Tim Polk: Comment [2008-03-27]: I have a vaguely uneasy feeling on this document: the complexity seems to be substantial. I am joining the ABSTAINs for now, I could change my position if convinced this is both implementable and not dangerous to the Internet.
      If I do change my position, I would move to DISCUSS to address the following issue.
      Support for TLS is required, but different modes may be selected (e.g., different ciphersuites and authentication mechanisms). These changes significantly impact the security provided (and as a result, the degree to which the requirements in 4081 are met.) The security considerations section should elaborate on the impact of server-only vs. mutually authenticated TLS, as well as alternative authentication procedures, with respect to the various requirements.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. IESG Procedures for Handling of Independent and IRTF Stream Submissions (BCP)
    draft-housley-iesg-rfc3932bis-06.txt
    Token: Jari Arkko Note: Diff: http://www.arkko.com/ietf/iesg/rfc3932bisdiff.html
    Extracted from Balloting:
    1. Cullen Jennings: Discuss [2008-12-02]: I think it is important that the non IETF stream documents are not in way confusable with an IETF standard by people unfamiliar with I* process. This document asserts that the stream-header draft will do that but if that text is still changing, I sort of like to see that text at same time as approving this. I expect to clear this discuss with no changes to this document but I would like to make sure we don't have an issue here before proceeding with removing IESG notes on non IETF stream documents.
      Comment [2008-12-02]: (empty)
    2. Dan Romascanu: Discuss [2008-12-04]: I have similar concerns as expressed by Cullen. At this point in time I am not ready to approve this document without seeing what is the specific text that the documents that define the other streams include and make mandatory in order to make clear that the RFC is not the product of the IETF and did not undergo an IETF review process.
      "It must also be very clear throughout the document that it is not an IETF product and is not a standard." This is much weaker and less clear than the current IESG note and makes no requirement of a boilerplate type of text that would make the statement clear and place it at a standard and visible place.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. (none)

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Requirements for Replacing AppleTalk (Informational)
    draft-cheshire-dnsext-nbp-07.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-12-04]: I think the document should be clearer whether these requirements represent some kind of IETF consensus, or just opinions of the authors.
      I agree with Chris that Section 6 should be more realistic about the security goals: things like determining the authenticity of received information, or authority to request some information, can't usually be done with zero configuration.
      Besides, the problem solved by DNSSEC (authenticating a hierarchical delegation structure) is quite different from securing an AppleTalk NBP like protocol (even if the messages re-use DNS formats).
      Section 7 should probably be clearer what actions IANA is expected to take when this document is approved (I'm guessing it's "none", but then the text should say "This document has no IANA actions."). [Holding a discuss for IANA]
    2. Cullen Jennings: Comment [2008-12-01]: This needs a ballot.
    3. Chris Newman: Comment [2008-12-02]: I found the security considerations weak, albeit tolerable for this sort of informational document.
      Some discussion of the usability/deployability/security tradeoffs between a zeroconf home network and a fully managed DNSSEC infrastructure would be informative. Further, I suspect it's a critical requirement to replace Appletalk NBP that "no security" be a protocol option since there's no way to get something with the same ease-of-use/ease-of-deployment profile in a home network.
      Right now there are two security options proposed: none or manually configured DNS unicast w/ DNSSEC... there are scenarios where I might want some sort of middle ground without having to administer a DNS infrastructure... Has any sort of leap-of-faith SSH-style keying been considered within this framework?
      Comment [2008-12-02]: Section 3.15 (Immediate and Ongoing Information Presentation) describes user interface requirements rather than the underlying protocol requirements. I suggest revising this section in terms of the protocol requirements.
    4. Tim Polk: Comment [2008-12-02]: Section 3.15 describes user interface requirements rather than the underlying protocol requirements. I suggest revising thissection in terms of the protocol requirements.
    5. Dan Romascanu: Comment [2008-12-04]: I find the name of the document and of the page headers completely misleading. IMO the name should be 'Requirements for Replacing AppleTalk Name Binding Protocol (NBP)'.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

5. IAB News We can use

1256 EDT break

1305 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

6. Management Issues

  1. Confirm additional port expert [IANA #209096] (Michelle Cotton)

    Telechat:

  2. Executive session to discuss Appeal of DNSOP WG Decision of September 13, 2008 (Magnus Weserlund)

    Telechat:

  3. CEA Media Type Application "cea-2018+xml" (Russ Housley)

    Telechat:

  4. IANA expert for TLS registries (Pasi Eronen)

    Telechat:

  5. Request to the RFC Editor to expedite processing of the CAPWAP Protocol Specification (Dan Romascanu)

    Telechat:

  6. Approval of application/emma+xml media type (Chris Newman)

    Telechat:

  7. Telechat schedule for January (Tim Polk)

    Telechat:

  8. RFC 1122 updates RFC 0793 (Lars Eggert)

    Telechat:

  9. IANA Registry bugs surrounding the TOS byte. (Lars Eggert)

    Telechat:

7. Agenda Working Group News

1341 EDT Entered executive session