IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-09-24. These are not an official record of the meeting.

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

Corrections from:

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. iCalendar Transport-Independent Interoperability Protocol (iTIP) (Proposed Standard)
    draft-ietf-calsify-2446bis-09
    Token: Lisa Dusseault
    Extracted from ballot 2868:
    1. Adrian Farrel: Comment [2009-09-20]: Looks like you cleared up the issue raised in Erratum 1709. (http://www.rfc-editor.org/errata_search.php?eid=1709) You might ask your AD to close the Erratum record.
    2. Russ Housley: Comment [2009-09-22]: The Gen-ART Review by Vijay K. Gurbani posted on 16-Sep-2009 points out two nits:
      1) S6.1.4 is about eavesdropping and not data integrity, right? But the misuse suffered by a cleartext iCalendar object is given both treatments: lack of privacy and loss of data integrity. A simple suggestion would be to remove "and/or changed" from S6.1.4, and have a new paragraph as follows:
      "Data Integrity
      "The iCalendar object is constructed with human-readable clear text. Any information contained in an iCalendar object may be changed by unauthorized persons while the object is in transit."
      2) Acknowledgments: s/S.Silverberg/S. Silverberg/
    3. Alexey Melnikov: Discuss [2009-09-24]: This is an important document and I don't want to be blocking it for any significant period of time. However I have a list of relatively minor issues that needs to be addressed, or at least discussed:
      1). I am holding a DISCUSS on behalf of IANA:
      --On September 14, 2009 7:22:20 PM +0000 Amanda Baber via RT <drafts-lastcall@iana.org> wrote:
      IANA has reviewed draft-ietf-calsify-2446bis-09.txt, which is currently in Last Call, and has the following questions/comments:
      - In section 3.6 you define a set of Status Replies but those values are not put into a registry. Do you want a registry of status values?
      Cyrus: After discussion with a few people the general feeling is that we should have a status code registry. Whilst it would have been best to have that in the 2445bis document (about to be published now) it can reasonably go in this document. I propose that I generate a new -10 version of the draft with the new registry defined.
      2).
      A.2. Deprecated features
      "The "THISANDFUTURE" option for the "RANGE" parameter was removed in [I-D.ietf-calsify-rfc2445bis] and references to that have been removed in this document too."
      I can still find several references to THISANDFUTURE in the document. I think this paragraph just needs to be deleted.
      Comment [2009-09-24]:
      I don't think the reference to [I-D.ietf-calsify-rfc2447bis] is Normative.
      In Section 1.4: 
         | COUNTER        | The Counter method is used by an "Attendee" to   |
   |                | negotiate a change in an iCalendar objecy.       |

      typo: object
      3.2.2.3. Delegating an Event to another CU
      "In response to the request, the "Delegate" MUST send a "REPLY" method to the "Organizer" and optionally, to the "Delegator". The "REPLY" method SHOULD include the "ATTENDEE" property with the "DELEGATED-FROM" parameter value"
      The SHOULD sounds a bit too weak here.
      3.2.5. CANCEL
      "The "Organizer" is MUST send a "CANCEL" message to each "Attendee" "
      s/is//
      3.3.3. REPLY 
         |   REQUEST-STATUS   | 0+       |                                   |

      Not 1+?
      3.7.2. Attendee Property Considerations
      "There are valid [RFC5322] addresses that represent groups."
      Do you mean email addresses that represent groups, or Group syntax in To: header field?
      I think the reference to RFC 5321 is more suitable here. In particular it doesn't allow RFC 5322 comments and you probably don't want to imply that they might be allowed here.
      5.1.1. Event-Related Fallbacks 
         +----------------+--------------------------------------------------+
   | Method         | Fallback                                         |
   +----------------+--------------------------------------------------+
   | PUBLISH        | Required                                         |
   | REQUEST        | PUBLISH                                          |
   | REPLY          | Required                                         |
   | ADD            | Required if recurrences supported, otherwise     |
   |                | reply with a REQUEST-STATUS "2.8;Success,        |
   |                | repeating event ignored.  Scheduled as a single  |
   |                | component." and schedule as a single component.  |
   | CANCEL         | Required                                         |
   | REFRESH        | Required                                         |
   | COUNTER        | Reply with "Not Supported"                       |
   | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs,  |
   |                | otherwise reply with "Not Supported"             |
   +----------------+--------------------------------------------------+

      This table is not very clear which requirements apply to Organizer and which requirements apply to Attendees. (Similar comment about other tables)
      5.1.1. Event-Related Fallbacks 
         +-----------------+-------------------------------------------------+
   | Component       | Fallback                                        |
   | Property        |                                                 |
   +-----------------+-------------------------------------------------+
 [...]
   | DURATION        | Reply with "Not Supported"                      |

      I am surprised to find that support for DURATION is optional. (The same comment for VTODO) Is this stated somewhere in rfc2445bis?
      5.1.2. Free/Busy-Related Fallbacks 
         +---------+---------------------------------------------------------+
   | Method  | Fallback                                                |
   +---------+---------------------------------------------------------+
   | PUBLISH | Implementations MAY ignore the METHOD type.  The        |

      I am confused by "MAY ignore the METHOD type". I think a good implementation needs to check it.
      6.2.1. Use of [RFC1847] to secure iTIP transactions
      "[...] Implementations MAY provide controls for users to disable this"
      What is "this" referring to here? Use of S/MIME in general, or use for a particular purpose?
      7. IANA Consideration
      "This documents defines the following values for the iCalendar "METHOD" property and these should be added to the Methods Registry defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]:"
      Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis] doesn't define which template needs to be used for registrations. It took me a couple of minutes to figure out that the registration template from Section 8.2.6 of [I-D.ietf-calsify-rfc2445bis] needs to be used.
    4. Tim Polk: Discuss [2009-09-24]: This discuss is simply a placeholder for the changes proposed and agreed during discussions between the authors and the secdir reviewer.
    5. Dan Romascanu: Comment [2009-09-23]: The OPS-DIR review by Menachem Dodge brought up the following issues and nits:
      1. This document obsoletes RFC 2446. The modifications are listed in Appendix A – "Differences from RFC 2446". It would be useful to have text that discusses any possible interworking issues that may occur between implementations of this document and implementations of RFC 2446.
      2. It would be helpful to have an abbreviations section to refer to as needed, or to exapnd acronyms at first occurence.
      Example:
      CS - Calendar Service
      CU - Calendar User
      3. A few minor corrections:
      a. Page 9: Section 1.4 Methods
      Within the table for the method COUNTER.
      "objecy"
      OLD -> COUNTER | The Counter method is used by an "Attendee" to negotiate a change in an iCalendar objecy.
      SUGGESTED -> COUNTER | The Counter method is used by an "Attendee" to negotiate a change in an iCalendar object.
      b. Page 53
      OLD -> The "Organizer" is MUST send a "CANCEL"
      SUGGESTED -> The "Organizer" MUST send a "CANCEL
    6. Robert Sparks: Comment [2009-09-22]:
      Section 5.2.1 recommends holding onto CANCEL messages that can't be correlated to a REQUEST when they arrive (because of reordering on store-and-forward transports perhaps). The security considerations section should discuss when to stop doing this (bad-guys can make up a lot of CANCELs). Something similar to the flood mitigation discussed in 6.2.2 paragraph 2 would work.
      The first paragraph of 6.2.2 recommends that CUs be given the choice to honor an Organizer change. I think it would be useful guidance to implementers to point out here that if individual CUs in that set make different choices, future changes by _either_ of the resulting Organizers will not be accepted by all of the CUs. The protocol will not malfunction (as far as I can tell), but the original set of CUs may end up attending two different meetings. (Implementers could, in turn, provide guidance to users making that choice or to let Organizers know that their attempt to make a change was not wholly accepted).

    Telechat:

  2. Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (Proposed Standard)
    draft-ietf-dnsext-dnssec-rsasha256-14
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@shinkuro.com) is the document shepherd.
    Extracted from ballot 2978:
    1. Russ Housley: Comment [2009-09-22]: The Gen-ART Review by Gonzalo Camarillo on 15-Sep-2009 includes two editorial comments:
      1) Acronyms should be expanded on their first use (including the title of the draft and the Abstract).
      2) The paragraph referencing RFC 2119 is located at the end of the Introduction. Normally, it is placed in a section on its own called Terminology instead, which comes right after the Introduction. This is truly a very minor comment and I leave it up to the author to decide whether to leave it as is or to move the text into a new section.
    2. Tim Polk: Discuss [2009-09-23]: This is a "discuss-discuss". I will move to Yes on the call, but would like to consider the following issue from Kurt Zeilenga's secdir review:
      "I do note that the document appears to place an additional recommendation upon implementors of DNSSEC (in Section 5.1) yet does not "update" any DNSSEC specification. It may be appropriate for this I-D to "update" (upon approval/publication) DNSSEC specifications."
      For completeness, section 5.1 is included here in its entirety:
      5.1. Support for SHA-2 signatures
      DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the RSA/SHA-2 algorithms as defined in this document.

    Telechat:

  3. Keying Material Exporters for Transport Layer Security (TLS) (Proposed Standard)
    draft-ietf-tls-extractor-07
    Token: Pasi Eronen
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    Extracted from ballot 3107:
    1. Jari Arkko: Discuss [2009-09-24]: This is an excellent document and I will vote Yes. However, before this I would like to discuss one issue. I think this is just an oversight and you actually intended to be stricter here. Section 3 says:
      "This specification does not mandate a single mechanism for agreeing on such context; instead, there are several possibilities that can be used (and can complement each other). For example:
      "o One important part of the context -- which application will use the exported keys -- is given by the disambiguating label string (see Section 4)."
      However, I believe that using distinct distinguishing labels is actually central to the security of this mechanism. When I read the rest of the document, this seemed to be the intention, but AFAICT it was never explicitly stated. The above text excerpt appears to say that the label is just one of the example ways. May I suggest the following formulation:
      "This specification does not mandate a single mechanism for agreeing on such context; instead, there are several possibilities that can be used (and can complement each other). For example:
      "o ... all the examples except the first one ...
      "No matter how the context is agreed, it is required that it has one part that indicates which application will use the exported keys. This part is the disambiguating label string (see Section 4)."
    2. Adrian Farrel: Comment [2009-09-20]: I think that the RFC 2119 "MUST" in section 6 is overkill.
    3. Alexey Melnikov: Comment [2009-09-23]: I've vote Yes on this document, as I believe it is very important.
      However I have a couple minor comments and would like to see an email response to them and/or RFC Editor notes:
      1). In Section 4 and similar text in Section 6:
      "Labels here have the same definition as in TLS, i.e., an ASCII string with no terminating NULL."
      Ideally I would like to see ABNF here.
      But anyway, did you mean: any CHAR character which is not a CTL: 
        CHAR           =  %x01-7F
                    ; any 7-bit US-ASCII character,
                    ; excluding NUL

  CTL            =  %x00-1F / %x7F
                    ; controls

      (as defined in in Appendix B.1 of RFC 5234)?
      2). In Section 4:
      "The context value allows the application using the exporter to mix its own data with the TLS PRF for the exporter output. One example of where this might be useful is an authentication setting where the client credentials are valid for more than one identity; the context value could then be used to mix the expected identity into the keying material, thus preventing substitution attacks. The context value" length is encoded as an unsigned 16-bit quantity (uint16)
      I think a reference to Section 4.4 of RFC 5246 would help a reader who is not active in the TLS WG.

    Telechat:

  4. Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (Proposed Standard)
    draft-ietf-dime-pmip6-04
    Token: Dan Romascanu
    Extracted from ballot 3124:
    1. (none)

    Telechat:

  5. Trust Anchor Format (Proposed Standard)
    draft-ietf-pkix-ta-format-03
    Token: Tim Polk
    Extracted from ballot 3163:
    1. Alexey Melnikov: Discuss [2009-09-22]: This is a fine document. I only have one minor concern about it:
      2.4. Trust Anchor Title
      "TrustAnchorTitle ::= UTF8String (SIZE (1..64))
      :taTitle is OPTIONAL. When it is present, it provides a human readable name for the trust anchor. The text is encoded in UTF-8 [RFC3629], which accommodates most of the world's writing systems.
      BCP 18 (RFC 2277), section 4.2 says:
      "Protocols that transfer text MUST provide for carrying information about the language of that text.
      "[...]
      "Note that this does NOT mean that such information must always be present; the requirement is that if the sender of information wishes to send information about the language of a text, the protocol provides a well-defined way to carry this information."
      So the document would need to have a normative reference to RFC 5646 and some text about use of language tags.
    2. Dan Romascanu: Discuss [2009-09-23]:
      1. I cannot find draft-ietf-pkix-ta-mgmt-reqs-03. As this specification is mentioned in the Abstract as the requirements that 'the structures defined in this document are intended to satisfy' I think that having this reference available at the time of the approval is necessary, even if the reference is Informational
      2. What is the role of the version? Right now there is only one value which is also the DEFAULT
      "TrustAnchorInfoVersion ::= INTEGER { v1(1) }"
      New versions are supposed to be issued only by obsoleting this document?
    3. Magnus Westerlund: Discuss [2009-09-21]:
      Section 2.1,
      "This section describes the TrustAnchorInfo structure."
      In what formal syntax language is used in this section? Please include a reference to the format used. This also applies to the other places in the document where the format is used. Probably a statement in section 1.1. could ensure that this is made clear.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Change Process for the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-peterson-rai-rfc3427bis-03
    Token: Russ Housley
    Extracted from ballot 3030:
    1. Jari Arkko: Comment [2009-09-24]:
      "References to the Transport Areas have been changed to point to the RAI ADs"
      s/Areas/Area Directors (ADs)/?
    2. Adrian Farrel: Discuss [2009-09-23]: I can't begin to express how important I think this work is. i want ot vote "Yes". But...
      In support of the Discusses about the "Updates RFC3696" I would like to point out that this document also updates the IANA policy in RFC 3265 and should be flagged with an "Updates" accordingly.
      I think that section 8 needs to be recast from the useful change log that was in place as the I-D was developed (but which the RFC Editor might be tempted to remove) into a description of the changes in the new RFC-to-be compared with RFC 3427. This is just a matter of merging the sections and sorting out the titles. (Hopefully this *is* all the changes.)
      Comment [2009-09-23]: Nit if you are editing the document
      Section 2.1
      s/life of the working group exists/life of the working group/
    3. Alexey Melnikov: Discuss [2009-09-22]:
      References [3], [4], [6] are not defined (it looks like you've changed the way how you reference documents). You also need to make sure they are listed as Normative/Informative.
      RFC 3969 is not listed as a Normative Reference.
      Comment [2009-09-22]: I am agreeing with Magnus' DISCUSS.
      4.1. SIP Event Packages
      "6. The proposed package MUST be clearly documented in an (Individual) Informational RFC, and registered with IANA. The package MUST document all the package considerations required in Section 5 of SIP events [6]."
      Is it Ok for documenting new even packages in Standard Track or Experimental individual submissions though AD?
    4. Tim Polk: Discuss [2009-09-23]: Steve Hanna's secdir review (28 July 2009) raised significant issues regarding the adequacy of security review under the relaxed IANA registration rules. Has there been a response to this review? I have not seen one...
    5. Dan Romascanu: Discuss [2009-09-24]: I am a supporter of the changes brought recently in RAI and I believe that they have already had a positive impact on having new work examined and approved faster and taking out of limbo a few items that were long stuck in SIP, SIPPING or other. I plan to vote 'yes' on this document but I have concerns about the following two pieces of text:
      In Section 2.2 the following seems umbiguous and open to unwanted interpretations:
      "While it does not have the traditional deliverables of a working group, DISPATCH may at the discretion of its chairs adopt milestones such as the production of charter text for a BoF or working group, a "-00" problem statement document that explicates a proposed work effort, or a document explaining why a particular direction for standards development was not pursued."
      I am concerned by the 'at the discretion of its chairs' aspect. DISPATCH plays a role of filter and decides to a large extend what is being done or not done in the RAI area. If a certain proposal would fall within the clear realm of another WG best chances would be that adding such work items would be a subject for rechartering. Leaving such decisions completly at the discretion of the chairs seems inapropriate.
      Actually I do not see this words aplied in the DISPATCH practice up to now. The charter and list of deliverables was not updated by the chairs or IESG action from the WG approval. On the other hands the WG undertook new items and this is fine - but this is known only to those who followed closely the WG list. I think that the wording here should mention that such decisions belong to the chairs in consultation with the ADs, that they need to be displayed on the WG page, and the IESG informed about new work items.
      In Section 3:
      "The DISPATCH working group may also evaluate and approve proposals for extensions if the requirements are judged to be appropriate to SIP, but are not sufficiently general for standards track activity."
      It is not clear what is approved here. From Section 2.2 I understand that
      DISPATCH identifies and makes recommendations about new work in the SIP space and identifies the proper venue, but does not undertake the work itself. If a work is 'not sufficiently general for standards track activity' what kind of recommendation is being made?
      Comment [2009-09-24]: Section 5:
      "3. Documents that specify Informational headers pass through an Expert Review system."
      Are these experts already in place or do they need to be nominates as this document is approved?
    6. Magnus Westerlund: Discuss [2009-09-21]:
      Section 7.1:
      To me this appears to be an update of RFC 3969. The intent is clearly to change the IANA consideration section in RFC 3969, I think this should be made clear with an "Updates" header referencing 3969 and in abstract and introduction.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Presence Interdomain Scaling Analysis for SIP/SIMPLE (Informational)
    draft-ietf-simple-interdomain-scaling-analysis-08
    Token: Robert Sparks
    Note: Ben Campbell is document shepherd
    Extracted from ballot 3147:
    Extracted from ballot 2925:
    1. Adrian Farrel: Discuss [2009-09-23]: A good and thorough job. Thank you.
      The Security Considerations section seems light on two counts.
      Firstly, the very scaling problems that are described constitute a security issue since they will gum up the network, CPU, and memory. To what extent is a system at risk for the uncontrolled use of presence subscriptions? Can an attack be mounted by simulating a larger number of subscriptions?
      Secondly, it is worth examining the impact on all of the scaling that is introduced by applying security to the messages that are exchanged. Of course, it should be noted that disabling security to achieve better scaling is not recommended, but there may be choices and implictions.
      Fix this with a couple of new paragraphs in an RFC Editor note.
      Comment [2009-09-24]: I love the new standard unit "dozens of gigabytes of presence traffic per day"
    2. Tim Polk: Comment [2009-09-24]: I support Adrian's discuss.
    3. Dan Romascanu: Comment [2009-09-24]: I like the document and I salute this work - it's one of the first I see anaysing impact of a succesful protocol or application on the Internet load and CPU losd of the hosts and servers. I would have liked to see also some mention of the impact and scalability aspects of the management systems and operator tools. Although that impact is not direct and as easy measurable, it is a serious concern for operators when dealing with succesful protocols.

    Telechat:

  2. Building Automation Routing Requirements in Low Power and Lossy Networks (Informational)
    draft-ietf-roll-building-routing-reqs-07
    Token: Adrian Farrel
    Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd
    Extracted from ballot 3018:
    1. Jari Arkko: Discuss [2009-09-24]: This was an overall very good document, and I'm prepared to ballot Yes on it. However, before doing so I wanted to raise a few issues. My main concern is that the document is in places imprecise about the layering architecture, and I believe there are certain functions which work best at higher layers, not in routing. I think we generally agree on these things, so it should be just a matter of clarifying the requirements. There were also a few other imprecise statements, which again should be easy to clarify.
      Here are the details:
      "This demands an adaptive routing protocol to allow for route optimization as the network stabilizes."
      Wouldn't a bigger problem be loops or simply dropping traffic when it no longer matches what the router thinks it should be receiving? And isn't there rather a role for better higher-layer application behaviour, such as not blasting everything from the buffer during the first millisecond that the network appears to be up again?
      5.1.2. Local Testing
      "During installation, the room sensors, actuators and controllers SHOULD be able to route packets amongst themselves without requiring any additional routing infrastructure or routing configuration."
      This requirement is quite imprecise. For instance, is operation on a local area network sufficient for this? Using link local addresses? Or do you require some non-router devices to actually take on the task of routing between multiple subnets? But this seems contradictory to them not being the routers. If the network employs wireless, how do the sensors know what parts of the wireless should be configured as one or the other subnet? Or do you mean full ad hoc routing behaviour here?
      5.3.1.2. Device Mobility across LLNs
      "A mobile device may move across LLNs, such as a wheel chair being moved to a different floor.
      "A mobile device that moves outside its original LLN SHOULD reestablish end-to-end communication to a fixed device also in the new LLN within 10 seconds after the mobile device ceases movement. The network convergence time should be less than 20 seconds once the mobile device stops moving."
      This is a reasonable requirement, but the document lacks some discussion that I think would be relevant for guiding further work in this area.
      It seems that the above requirements have been stated with a routing fabric solution in mind. That is only one possible solution among many: mobility at L2, mobility through routing, e2e mobility at the IP layer, transport layer, applications.
      I believe it is important that the documents clearly specify either what the expectation is (if you have some arguments why one type of a solution is absolutely required), or point out that ways to satisfy this requirement exist at multiple layers.
      "Proxies with unconstrained power budgets often times are used to cache the inbound data for a sleeping device until the device awakens. In such cases, the routing protocol MUST discover the capability of a node to act as a proxy during route calculation; then deliver the packet to the assigned proxy for later delivery to the sleeping device upon its next awakened cycle."
      I believe we are mixing layers of communication here. The routing fabric should not be aware of the fact that something is acting as a proxy. Most proxy deployments that I have seen are at the application layer, and may even involve protocol translation to get to the end point perhaps even using a non-IP protocol.
      "Communication routes MUST adapt toward the chosen metric(s) (e.g. signal quality) optimality in time."
      What does "adapt toward chosen metric optimality" mean? Maybe I'm just not understanding the expression you used...
      Comment [2009-09-24]: The empty lines in Figure 1 make the viewing the picture hard.
      "Fire systems are much more uniformly installed with smoke detectors installed about every 50 feet."
      The rules on this are variable, but I have actually not come across a distance metric. Typically, there is a requirement to have at least one detector per floor per firewalled area, or even one per room.
      "These cameras are atypical endpoints requiring upwards to 1 megabit/second (Mbit/s) data rates per camera as contrasted by the few Kbits/s needed by most other FMS sensing equipment."
      The deployment models differ again, though. Some devices operate in motion detection mode, others stream continuously, and yet others operate as web servers and are used on a per need basis.
      "A ten minute power outage may require many hours to regain building control. Traffic flow may increase ten-fold until the building control stabilizes."
      I wish it were made clearer that this is an undesirable state of affairs.
      "Typically, sensor battery life (2000mah) needs to extend for at least 5 years when the device is transmitting its data (200 octets) once per minute over a low power transceiver (25ma) and expecting a application acknowledgement. This requires a highly efficient routing protocol that minimizes hops and hence latency in end-to-end communication. The routing protocol MUST take into account node properties such as 'Low-powered node' which produce efficient low latency routes that minimize radio 'on' time for these devices."
      There are of course wireless sensors in a building network. However, I have serious trouble believing that the router nodes need to be in this mode. Does this requirement mean that the routers have to save power for themselves (which would be a major research project) or merely that small or at least predictable latency would save energy for hosts? Please clarify.
    2. Tim Polk: Discuss [2009-09-24]: This is a good document, a clear read (thanks!), and I support its publication. However, I do think one issue needs to be revisited before publication.
      I believe the bar for authentication is set too low. Physically wired systems depend to some degree on the physical security of the building - to add a rogue element, you not only need to access the building, you probably need to rip out some drywall! Another contributing factor is my own paranoia - even in owner occupied facilities, I see a higher threat level than indicated in the spreadsheet (emailed in response to Derek Atkins' secdir review). Not everyone gets along with their neighbors, and being able to shut down HVAC or lighting is a very effective form of harassment.
      I believe that authentication should be mandatory to implement, and should be a MUST for joining the network unless explicitly configured otherwise. That is, authentication should be the default.
      I also believe the device needs to be capable of re-authenticating when the network fragments or key devices fail. (E.g., if the device is only authenticated to its neighbors but they all have failed, the device might need to authenticate again to its new neighbors. Perhaps that is considered a join?) The current text in 5.8.1. implies authenticate once, be done with it... perhaps I am misreading this?
    3. Robert Sparks: Comment [2009-09-22]: Adrian's Discuss points to feedback I provided to version -05 of this document. Please consider the points in that review that aren't also called out in Discuss a "Comment".
    4. Magnus Westerlund: Comment [2009-09-23]: Agree with Russ that the security requirements seems backwards. To me it appears that the protocol MUST have authentication, but it may not be used for specific reasons. However, I don't want to be in a building that deploys these systems without a security model. Especially if you they are using wireless communication.

    Telechat:

  3. Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (Informational)
    draft-ietf-opsawg-operations-and-management-09
    Token: Dan Romascanu
    Extracted from ballot 3099:
    1. Ralph Droms: Comment [2009-09-22]: I found the document to be well-written and informative.
      After reading the Abstract, I expected the document itself to describe, explain and give recommendations about considerations for protocol designers and document writers. There are, indeed, many such considerations. I have two concerns:
      1. Some of the considerations include suggestions or are phrased in the form of a question without giving any recommendations about how to evaluate alternatives. For example, section 3.3 includes a paragraph about propagation of fault information and asks a question about async notification or polling. I think it would be helpful to add a few words about whether async notifications/polling is an either/or decision or other issues that the question is intended to point out. Section 3.3.3 describes root cause analysis without giving any advice about how the consideration of root cause analysis might affect protocol design or operation.
      2. Some of the considerations gove advice about operations that are not necessarily directly related to protocol design or documentation. For example, section 3.3.4 gives advice about fault isolation; is that advice intended to suggest that the protocol designer should include features in the protocol to make fault isolation easy? Or is it a suggestion to the network administrator about how to debug a network problem?
    2. Pasi Eronen: Comment [2009-09-24]:
      I agree with Cullen that the draft should make it more clear why it's Informational instead of BCP (e.g., while there's lot of useful information in it, we don't really have IETF wide consensus that these guidelines are equally appropriate for all IETF work).
      I also agree with Robert that much of the document is about managing routers/networks, and probably less applicable to applications.
    3. Adrian Farrel: Comment [2009-09-20]:
      Section 7
      s/Farrell/Farrel/ (if you don't mind :-)
      The Appendix is not directly referenced in the body of the text, but is actually a rather useful tool. You might include a pointer in Section 1.2 where you say...
      "This document discusses the importance of considering operations and management by setting forth a list of guidelines and a checklist of questions to consider"
    4. Russ Housley: Comment [2009-09-22]: The Gen-ART Review by Miguel Garcia on 21-Sep-2009 suggests that acronyms be expanded on first occurrence and add a references to them (if there are documents). This includes: SNMP, SYSLOG, COPS, XML, RADIUS, DIAMETER, NETCONF, IPFIX, DMTF, TMF, RMON, and NMS.
    5. Cullen Jennings: Discuss [2009-09-23]: I like this document and think there is great information in it.
      Section 1.1 and section 4 need a bit of word smithing after the document was moved from BCP to informational. I don't think they can say that a "a WG should" do X or the "Manageability Considerations section should". I think the text can be change dot be more like "It is useful if documents describe ...." Does this sounds like a reasonable change?
    6. Tim Polk: Comment [2009-09-24]: I support Cullen's discuss with respect to clarifying language to be consistent with the intended status of Informational.
    7. Robert Sparks: Discuss [2009-09-22]: This document contains a wealth of good advice and I am glad we are producing it. However, I have a few questions to work through before recommending publication:
      The document is still strongly influenced by its genesis in routing. It is easy to see how to apply its advice when it is natural to talk about an application or a deployment in terms of the protocol, particularly when a configuration action on a network element maps directly into a configuration action in the protocol.
      It is less obvious how to apply much of the advice when the protocol is a component or framework - when there are layers between the outward interface of the managed elements and the knobs in the protocols (TLS, SASL, S/MIME, PIDF, PIDF-LO, RTP, ...). Would it be possible to add guidance on how to apply the recommendations in those kinds of documents? Would it make sense to add/make more explicit a discussion on reveiwing managability of the interfaces that components expose to the to-be-managed applications that are going to use them?
      Similarly, some of the "link", "node", and "packet" vocabulary becomes awkward when you start applying this to protocols that are higher in the stack. Can the language be abstracted to make it clearer what consideration discussion you're trying to stimulate in those cases?
      I can be talked into waiting for future documents to address those concerns - the guidance here for the protocols that the recommendations can easily be applied to is worth publishing as soon as we can. But we need to address the above questions before we start to consider _requiring_ these considerations in all submissions.
      Comment [2009-09-22]:
      The last paragraph of 2.2 could be generalized - speed is not the only thing that time changes.
      The guidance in the last paragraph before section 3.1 starts should also point to the cases where focusing on instumenting servers might mask problems - instrumentation in clients may be the only thing that can provide information to the operator.
      In section 3.1 "Information models should come from the protocol WGs" -- not all protocols come from WGs.
      "some planned companion documents" is a phrase that will not age well once this is in RFC-stone. Can it be replaced with something a little less time-sensitive?
      Consider changing the "must not" on the second line of page 9 to "MUST NOT" (or not).

    Telechat:

  4. Other Certificates Extension (Experimental)
    draft-ietf-pkix-other-certs-05
    Token: Tim Polk
    Extracted from ballot 3128:
    1. Cullen Jennings: Discuss [2009-09-24]: I simply don't understand the use case of where this would be used. I don't have any problem with the mechanism, I just like the use case explained better of when one should use this.

    Telechat:

  5. Scaling Requirements for Presence in SIP/SIMPLE (Informational)
    draft-ietf-sipcore-presence-scaling-requirements-02
    Token: Robert Sparks
    Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd.
    Extracted from ballot 3147:
    1. Ralph Droms: Comment [2009-09-23]: Editorial comments/clarifications. Abstract and first para of intro:
      Abstract
      "The document lists requirements for optimizations of SIP/SIMPLE that will allow for greater scalability of presence by reducing the load on the network and the presence servers due to inter-domain presence subscriptions."
      If the WG is comfortable with SHOULD in these three requirements, then OK but I'm a little surprised these aren't MUST.
      "o REQ-001: The solution SHOULD NOT deprecate existing protocol mechanisms defined in SIP/SIMPLE.
      "o REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate with clients and servers that implement new presence scaling features.
      "o REQ-003: The solution SHOULD NOT constrain any existing RFC functional requirements for presence."
      Slight re-wording for precision?
    2. Adrian Farrel: Comment [2009-09-23]: Per my Discuss on draft-ietf-simple-interdomain-scaling-analysis there will be some further scaling considerations related to security, I think.
      REQ-004 is good, but refers to "existing security requirements."
      Are there, however, additional requirements that the need for scaling should put on security for presence subscription?
    3. Russ Housley:Comment [2009-09-24]: The Gen-ART Review by Christian Vogt on 22-Sep-2009 raised a few points:
      - It would be worth mentioning in the introduction of the document what the expected result of this document should be. Obviously, we are expecting (or hoping for) an improvement in the scalability of SIP/SIMPLE, but this should be made explicit. Also, do we have estimates of how much SIP/SIMPLE will improve?
      - The document only talks about "optimizations" to which the defined requirement should apply. How about other types of protocol enhancements, such as functional extensions? Wouldn't the defined requirements apply to those just as well?
    4. Dan Romascanu: Comment [2009-09-24]:
      1. REQ-009: Presence systems (intra- or inter-domain) SHOULD scale in linear proportion to the number of watchers and presentities in the system.
      To what does 'in linear proportion' refer to? I suspect it is related to the number of messages, state size, and management and processing load - it would be good to make this explicit.
      2. It would have been useful to discuss and add a requirement about the scalability of the management applications and operational tools. As presence systems increase in number and complexity they still need to remain manageable and operational - this aspect is not discussed at all in the document.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Addition of the new values to use the SEED Cipher Algorithm in the Multimedia Internet KEYing (MIKEY) (Informational)
    draft-seokung-msec-mikey-seed-03
    Token: Tim Polk
    Note: Brian Weis (bew@cisco.com) is the document shepherd.
    Extracted from ballot 3063:
    1. Adrian Farrel: Discuss [2009-09-23]: Discuss-Discuss (will clear on the call)
      I note that the IANA registries that are added to have "undefined" registration procedures (presumably because section 4.2.9 of RFC 3830 is vague). But section 10 of RFC 3830 says that "Unless explicitly stated otherwise, values in the range 0[240 for each name space SHOULD be approved by the process of IETF consensus."
      We had an IETF last call, so all is well.
      Would someone take the action of helping IANA get the registries updated?
    2. Russ Housley: Discuss [2009-09-22]: The Gen-ART Review by Spencer Dawkins on 3-Aug-2009 deserves a response. The review can be found at:
      http://www.softarmor.com/rai/temp-gen-art/draft-seokung-msec-mikey-seed-03-dawkins.txt
    3. Cullen Jennings: Discuss [2009-09-24]: The way this is written it seems like it needs to update 3830. However, if it is going to update 3830, it brings up the question of if it needs to be PS or not. To be interoperable, it is unclear to me how this will be negotiated and what security advice should be provided about using say AES or SEED when both are available.
    4. Dan Romascanu: Comment [2009-09-24]: I have a similar concern as the one expressed by Cullen, considering whether this document should not be marked as updating RFC 3830. It is difficult to understand how people reading that RFC would be aware that the one byte registries defined in 6.10.1.b and 6.10.1.d have more values assigned - they need to go and look into the IANA registries to figure out and this looks clumsy.

    Telechat:

  2. ECP Groups for IKE and IKEv2 (Informational)
    draft-solinas-rfc4753bis-00
    Token: Tim Polk
    Extracted from ballot 3164:
    1. Pasi Eronen: Discuss [2009-09-24]:
      Should this document also update RFC 5114? (The format of KE payloads and shared secret is specified on group-by-group basis, and 5114 defines two new ECP groups that use the RFC 4753 version of shared secret/KE payload. Note that
      Given the confusion about the KE payload/shared secret encoding, I think Section 8 should explicitly note that some other elliptic curves (such as those in RFC 2409) might use different formats.
      I agree with Adrian that the document should be clearer about what's being changed compared to RFC 4753, and the reasons for this change (especially since the text in RFC 4753 is not unambiguous, and is a totally reasonable design decision).
    2. Adrian Farrel: Discuss [2009-09-21]: I appreciate that the changes to the document are very small, and I hope that these Discuss issues are equally small and can be resolved simply.
      It is really helpful if a bis revision of an RFC includes a section that sets out the changes from that RFC.
      Although the only change in the registry is to the referenced RFC, shouldn't this bevertheless be shown to the designated expert for the registry?
      Shouldn't you update the reference to RFC 2409 to read RFC 4306 and remove all reference to IKE (not IKEv2)? It is my understanding that 4306 obsoleted 2409, so we should no longer be describing extensions to 2409
      I am not sure what the value is of using 2119 langauge in this Informational document. For example in 3.1...
      "IKE and IKEv2 implementations SHOULD support an ECP group with the following characteristics."
      Does this Informational document attmept to direct the content of IKEv2 implementations? Doesn't that mean that it has to be PS and update 4306?
      Comment [2009-09-21]: Nit
      The Abstract should no longer refer to the ECP Groups as "new".

    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)

1239 EDT break

1245 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Multipath TCP (mptcp)
    Token: Magnus

    Telechat:

4.1.2 Proposed for Approval

  1. Virtual World Region Agent Protocol (vwrap)
    Token: Alexey

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Behavior Engineering for Hindrance Avoidance (behave)
    Token: Magnus

    Telechat:

  2. Access Node Control Protocol (ancp)
    Token: Ralph

    Telechat:

4.2.2 Proposed for Approval

  1. IP Flow Information Export (ipfix)
    Token: Dan

    Telechat:

  2. Network Endpoint Assessment (nea)
    Token: Tim

    Telechat:

5. IAB News We can use

  1. Olaf: incredibly ill-prepared: I've forgotten what we wanted to bring to you... not RFCed issue; I'll look for it
  2. Jari: what about 3932bis
  3. Olaf: we didn't: at this moment it's your discussion, please let us know when you converge, hopefully it will be easy
  4. Russ: raised very briefly, no concerns raised at that time; some folks needed to review the discussion
  5. Jari: this isn't IESG-side only
  6. Russ: proposed text out there; Jari has asked, "did we get it right?"
  7. Olaf: I'll make "your view" explicit to IAB
  8. Jari: you'll get that next week

6. Management Issues

  1. Appointment of Language Tag expert reviewer as per draft-ietf-ltru-4646bis-23 (Alexey Melnikov)

    Telechat:

  2. Link Relations Request [IANA #259813] (Michelle Cotton)

    Telechat:

  3. Approval of application/xslt+xml Media Type (Alexey Melnikov)

    Telechat:

  4. Expert for PSAMP selectorAlgorithm Identifiers [IANA #233539] (Michelle Cotton)

    Telechat:

  5. Removal of registry page (ip-xns-mapping) [IANA #164140] (Michelle Cotton)

    Telechat:

  6. Potential Chinese Venue (Russ Housley)

    Telechat:

  7. LCT Header Extension (Magnus)

    Telechat:

7. Agenda Working Group News

1411 EDT Adjourned