IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-08-27. 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. An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources (Proposed Standard)
    draft-ietf-simple-xcap-diff-13
    Token: Robert Sparks; Note: Ben Campbell is taking over as the document Shepherd
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-08-25]:
      Figure 1 isn't entirely clear to me. What do the "-" and "*" symbols mean?
      In the sentence immediately before Figure 1, s./how corresponding/how the corresponding/ ?
      There are no instructions to IANA in section 7.1. Will IANA know what to do with that section?
    2. Alexey Melnikov: Comment [2009-08-27]:
      1. Introduction
      "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML documents stored on a server. These XML documents serve as configuration information for application protocols. As an example, resource list [RFC4662] subscriptions (also known as presence lists) allow a client to have a single SIP subscription to a list of users, where the list is maintained on a server. The server will obtain presence for those users and report it back to the client. This application requires the server, called a Resource List Server (RLS), to have access to the list of presentities."
      I think the first use of a term like "presentity" needs an Informative Reference.
      3. Structure of an XCAP Diff Document
      "The <document> element has one mandatory attribute, "sel", and a two optional attributes, "new-etag" and "previous-etag". The "sel" attribute of the <document> element identifies the specific document within the XCAP root for which changes are indicated. Its content MUST be a relative path reference, with the base URI being equal to the XCAP root URI. The "new-etag" attribute provides the entity tag (ETag) for the document after the application of the changes, removal of a document, the "previous-etag" MUST only be included and the "new-etag" attribute will not be present."
      I suggest rewording the last sentence:
      "If the change being reported is the removal of a document, only the "previous-etag" MUST be included and the "new-etag" attribute MUST NOT be present."
      "In a corner case where the content of this element cannot be presented for some reason, although it exists in the XCAP document, the <element> element MUST NOT have any child nodes."
      Can you please elaborate more on the corner case?
      "Each <attribute> element indicates the existing attribute content ofan XCAP document. It has one mandatory attribute, "sel", and oneoptional attribute, "exists". The "sel" attribute of the <attribute> element identifies an XML attribute of an XCAP document. It is a percent endoced relative URI following XCAP conventions when"
      typo: encoded
    3. Tim Polk: Discuss [2009-08-26]:
      The security considerations are clear and factual, but may leave the reader with the wrong impression regarding the importance of protecting XCAP diff documents. This document states:
      "[....] if the document itself is sensitive and requires confidentiality, integrity or authentication, then the same applies to the XCAP diff format. Therefore, protocols which transport XCAP diff documents must provide sufficient security capabilities for transporting the document itself."
      This is all true, but does not indicate whether XCAP documents are likely to be sensitive, or what the typical transport capabilities are likely to be.
      The Security Considerations of the XCAP spec (RFC 4825) are very clear about this:
      "Frequently, the data manipulated by XCAP contains sensitive information. To avoid eavesdroppers from seeing this information, it is RECOMMENDED that an administrator hand out an HTTPS URI as the XCAP root URI. This will result in TLS-encrypted communications between the client and server, preventing any eavesdropping. Clients MUST implement TLS, assuring that such URIs will be usable by the client."
      This is probably obvious to a reader with sufficient XCAP expertise, but I believe that the first paragraph needs to supplemented with a note that TLS-encrypted communications are commonly employed for transporting XCAP documents, and point to 4825 for further discussion of the security requirements for XCAP documents.
      In the following paragraph, it would be helpful if this document suggested a SIP baseline for providing a similar of security attributes. Some warning about hop-by-hop vs. end-to-end security would be helpful as well.
      Comment [2009-08-26]: I greatly appreciated the thorough treatment of the semantics for previous-etag and new-etag when they appear in combination and when each appears alone. I am afraid I missed something subtle with respect to new-etag appearing alone, though. I understand the scenario where the document was just created, but when would the "document exists" scenario be invoked? In this case, the document hasn't changed, so why would there be a diff document at all?
    4. Dan Romascanu: Discuss [2009-08-27]:
      The Security and OPS review performed by David Harrington raised a couple of issues which were not answered completly in the discussion that followed. I would like to discuss them further before approving this document and decide whether text should be added to warn about the potential issues in deployment.
      1. What happens if multiple diffs are applied in different orders? Especially it is not clear what happens if many notifiers (diff-generators) apply changes for the same document - would the different clients be able to read these changes in a consistent manner?
      2. It looks (and the authors seem to acknowledge) that deployment on large scale is a problem. This can also be a potential source of DOS attacks, with a client sending repeated small changes that each needs to be propagated to all the other clients. I do not know if there is any solution on this respect but I think that some warning text on this respect should be added.
      Comment [2009-08-27]:
      1. The OPS review asked about the need for a mechanism to specify which levels of related configurations must be present similar to the one in configuration control systems. This diff format specification does not provide a mechanism for doing versioning and coordination of incremental changes. Although it is not clear that this is a mandatory requirement for xcap it is certainly good practice, and it would be good to have this addressed (or explain why it is not needed).
      2. The XCAP and XCAP-diff documents do not specify how to manage the underlying XML documents, or how to reflect incremental changes in a management interface.
      XCAP is a type of application-specific HTTP, and the XCAP spec discusses the difficulty of differentiating XCAP traffic from other HTTP traffic, such as at a firewall. As a result, it would seem to be difficult to monitor XCAP-specific faults and performance by doing stream analysis; this would seem to call for having the server and client include support for providing management information, since the XCAP server and XCAP client CAN easily determine which traffic is XCAP related.
      An information model describing the data needed for monitoring the XCAP protocol, measuring protocol performance, measuring any impact on network performance, and standardization of operational configuration for the XCAP protocol are simply not discussed. There is no discussion in the XCAP spec or the XCAP-diff spec that explains why management is not needed for XCAP or XCAP-diff.
      I am not satisfied with the response provided by one of the editor that this is an implementation issue. It may be true that manageability may be addressed in a different place but some reference that the issues were considered and how they are addressed or why they need not be addressed would be useful to be included.

    Telechat:

  2. IP Performance Metrics (IPPM) for spatial and multicast (Proposed Standard)
    draft-ietf-ippm-multimetrics-11
    Token: Lars Eggert; Note: The document shepherd is Matt Zekauskas (matt@internet2.edu)
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-08-27]:
      This specification is a solid and useful piece of work. However, before recommending the publication of this specification as an RFC, I would like to talk about the following.
      The document uses the term 'host' to refer to measurement points, despite their role in the communications. For instance:
      "A metric is said to be spatial if one of the hosts (measurement collection points) involved is neither the source nor a destination of the measured packet(s)."
      The traditional terminology is of course hosts, routers, and nodes. My read of RFC 2330 is that it tries to be accurate about referring to entities as routers when they are indeed routers. It is true that routers are hosts too, but saying 'host' when a packet passes through a router is somewhat misleading, in my opinion. I wonder if the term node would have been more appropriate for some of this, or following the model in RFC 2330.
      Comment [2009-08-27]: The term "ipdv" was introduced here for the first time, please add a reference or a term definition:
      o Type-P-Spatial-One-way-ipdv-Vector divides an end-to-end Type-P-One-way-ipdv into a spatial vector of ipdv singletons.
    2. Ralph Droms: Comment [2009-08-25]: First sentence of section 3 needs a closing ']'
      Section 9.1, 4th para, s/transit/transmit/
    3. Pasi Eronen: Comment [2009-08-26]: Stephen Farrell's SecDir reviewed found some editorial nits that should be fixed:
      http://www.ietf.org/mail-archive/web/secdir/current/msg00943.html
    4. Adrian Farrel: Discuss [2009-08-25]:
      Section 10
      Shouldn't the must/should language here all be in RFC 2119 form? It seems to be mixed.
      Section 11
      This section needs to highlight that path reporting mechanisms (such as indicated here) can be used to determine where in a network to attack a traffic flow.
      Spatial reporting may indicate which nodes on a path are most vulnerable to attack.
      Both of these issues can be determined by inspection without any need to attack the measurement packets themselves.
      Comment [2009-08-25]:
      Figure 2
      This would benefit from some explanation.
      I presume 'x' does not have the same quality as 'X' although 'X' is not referenced.
      It is not clear whether this is an example such that all nodes are candidate points of interest, but those 'x' just happen to not be points of interest.
      Is there any significance in Figure 2 using 1,2,3,J where Figure 1 used 1,2,3,I?
      Is the figure supposed to imply labeling of the 'X' hosts as 1,2,3,J?
      Nice to expand "ipdv" on first use.
      Section 4.1: "Monitoring the decomposed performance of a multicast tree based on of MPLS point-to-multipoint communications."
      s/on of/on/
      Figure 6
      I suppose that this only applies for J[n] > 0
      Obviously, it would be pointless to compute if no packets were received. Need to say so?
      Section 9.1
      OLD
      However, it may result in a lost of information. As all measured singletons are not available for building up the group matrix, the real performance over time can be hidden from the result.
      NEW
      However, it may result in a loss of information. As not all measured singletons are available for building up the group matrix, the real performance over time can be hidden from the result.
      Section 9.2: "To prevent any bias in the result, the configuration of a one-to-many measure must take in consideration that intrically more packets will to be routed than sent (copies of a packet sent are expected to arrive at many destination points) and selects a test packets rate that will not impact the network performance."
      "intrically"?
      Do you mean "intrinsically" or "intricately"? Maybe just delete the word and let "more" stand on its own.
      Section 10: s/documents defines/documents define/
      But actually...
      "Usually IPPM WG documents defines each metric reporting within its definition."
      ...is either circuitous or has no meaning!
      Section 10.1.2: "It is highly suggested to use the TTL in IPv4, the Hop Limit in IPv6 or the corresponding information in MPLS."
      Is "highly suggested" language for inclusion in draft-ietf-rfc2119bis-00.txt?
      Section 13: "Metrics defined in this memo Metrics defined in this memo are"
      Duplicate words.
      Section 13: You might help IANA by making it clear that each "nn" is a different number, possibly by using aa, bb, cc, etc.
    5. Dan Romascanu: Comment [2009-08-27]:
      In Section 10: "This document defines the reporting of all the metrics introduced in a single section to provide consistent information, to avoid repetitions and to conform to IESG recommendation of gathering manageability considerations in a dedicated section."
      While it is true that some of the IESG members hold the opinion that gathering manageability considerations in a dedicated section is a good thing, there is no IESG recommendation on this respect.
    6. Robert Sparks: Comment [2009-08-26]: Notation nits:
      Figure 4's right-most column has repeated R3's where it meant R1, R2, R3
      The paragraph below that figure talks about "observed at M points of interest" where I think it meant "n points".
      As discussed in email, there is a mix of RnMD and RnDM in section 8.3 that should be the same.
      As discussed in email, Ln(k) in figure 10 and L(k,n) in figure 11 could useadditional explanation.

    Telechat:

  3. OSPFv2 HMAC-SHA Cryptographic Authentication (Proposed Standard)
    draft-ietf-ospf-hmac-sha-06
    Token: Ross Callon
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2009-08-27]: I agree with Tim that SHA-224 is of questionable value here (and so is SHA-384, IMHO -- it's just a truncated version of SHA-512).
    2. Adrian Farrel: Comment [2009-08-25]: Some nits you should address to improve the polish if you have the document open for edit.
      RFC Editor will ask you to reduce the number of names on the front cover in line with the guidelines.
      Section 2: "All OSPF protocol exchanges are authenticated. Notwithstanding the exact same statement being present in RFC 2328 it is hard to claim that the Authentication Type "Null Authentication" represents authentication in action."
      Perhaps s/are/can be/
      Section 3.2: "RFC 2328 defined an OSPFv2 Security Association (OSPFv2 SA) in Section D.3, pages 228 and 229. However, the term is new to this document."
      Not clear what the second sentence means.
      Section 3.2: There is a fair amount of "should". Does this need to be 2119 language?
      Section 3.2 Authentication Algorithm
      "THis information should never be sent over the wire in cleartext form."
      s/THis/This/
    3. Russ Housley: Discuss [2009-08-26]:
      Section 3.2 defines Authentication Algorithm and Authentication Mode. I do not think these are separable in the manner described. I would be much more comfortable with the use of Authentication Algorithm with the choices of HMAC-SHA-256, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, HMAC-SHA-512, and Keyed-MD5. Please see draft-ietf-saag-crypto-key-table-00.txt. Please consider the other ideas presented in this draft.
      The document have the following requirements for the various HMAC algorithims:
      - MUST include support for HMAC-SHA-256
      - SHOULD include support for HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, and HMAC-SHA-512
      - SHOULD also include support for Keyed-MD5
      This seems like a lot of SHOULD support algorithms. Perhaps some of them out to be MAY support algorithms.
      Some guidance to product planners about the mandatory to implement requirements in the future is highly desirable. I assume that support for Keyed-MD5 will be dropped in the future. Is HMAC-SHA-1 also in this same situation? If so, please say so.
    4. Cullen Jennings: Discuss [2009-08-27]: On the call, I would like to talk about the number of authors on this. At the end of the the iesg-secretary can change my position to no-obj.
    5. Alexey Melnikov:Discuss [2009-08-26]:
      IANA CONSIDERATIONS
      "There are no IANA considerations for this document."
      I don't think this is correct. The IANA considerations section should say that the definition of "Cryptographic authentication" authentication method in the "Open Shortest Path First (OSPF) Authentication Codes" registry (<http://www.iana.org/assignments/ospf-authentication-codes>) should be updated to also point to this document.
      Comment [2009-08-26]:
      3. Cryptographic authentication with NIST SHS in HMAC mode
      The algorithms used to generate and verify the message digest are specified implicitly by the secret key."
      And the secret key is identified by the KeyID. Maybe you should say that here.
      3.2 OSPFv2 Security Association
      Authentication Algorithm
      "This indicates the authentication algorithm to be used. THis information should never be sent over the wire in cleartext form."
      While this is true, I think this is a bit misleading: this information is never sent over the wire (in OSPF itself). Or am I wrong about that?
      "Currently valid values are: MD5, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512."
      I was expecting to see an IANA registry for this, but found that each mechanism is identified by the hash length field ("Auth Data Len"). Did the WG discussed alternatives, for example by defining a new "Authentication Method" code(s)?
    6. Tim Polk: Comment [2009-08-26]: I believe the SHOULD list in section 3 is too long to have real value. I would suggest retaining HMAC-SHA-256 as MUST, with Keyed-MD5 and HMAC-SHA-1 as SHOULD, and relegate the others to MAY.
      I also wonder if SHA-224 is worth including at all, given that we would only save 32 bits on the wire. Would operators find this a compelling feature?

    Telechat:

  4. Alarms in SYSLOG (Proposed Standard)
    draft-ietf-opsawg-syslog-alarm-02
    Token: Dan Romascanu; Note: Scott Bradner (sob@harvard.edu) is the document shepherd
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-08-26]:
      The document says:
      "Support of the "alarm" SD-ID is optional, but once supported some of the SD-PARARMS are mandatory."
      but at this point in the document the terms SD-ID and SD-PARARMS have not been introduced yet. And there isn't even a forward reference. Is it SD-PARARMS, really, or SD-PARAMS?
    2. Ralph Droms: Comment [2009-08-26]: Very minor readsbility nits:
      Reorder sections 3.1-3.6 to match the order of the list in section 3.
      Reorder the bullet list in section 3.3 to match the order of the list in section 2.
      "trendIndication" in section 3.5 could use a clearer definition. How is trendIndication "[s]imilar to the definition of perceived severity"? Perhaps trendIndication is "related to perceived severity, indicating the trend of the perceived severity relative to previously reported values of perceived severity for the same alarm source"?
    3. Pasi Eronen: Discuss [2009-08-26]: From Rob Austein's SecDir review: it's not clear what e.g. 'If the "alarm" SD-ID is supported, the "resource" SD-PARAM MUST be supported' (and other similar sentences) mean. Does it mean that if the "alarm" SD-ID is included in a syslog message, the "resource" SD-PARAM MUST be included? (Or if not, what is meant by "supported" here?)
      Comment [2009-08-26]: Couple of typos in Section 4:
      'APP-NAME is "su"' -> 'APP-NAME is "evntslog"'
      'exampleSDID@0' -> 'exampleSDID@32473'
      'resourceURI =' -> 'resourceURI='
    4. Adrian Farrel: Comment [2009-08-25]: Nits you should fix to reduce the load on the RFC Editor if you are editing the document.
      Have a look to see whether you are consistent in your use of "syslog," "Syslog," and "SYSLOG."
      idnits says...
      == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines
      == Missing Reference: 'Syslog' is mentioned on line 225, but not defined
      ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266)
      Abstract is a little hard to parse
      "It includes the mapping of ITU perceived severities onto syslog message fields and a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB."
      What maps onto what?
      Section 1: "defines a mapping of syslog severity to the severity of the alarm."
      Which way is the mapping defined in this document? I think the mapping is from alarm severity to syslog severity.
      Should include references to RFC3877, X.733 and X.736 where they are mentioned.
      Section 2
      s/severities which are useful/severities which it is useful/
      s/A STRUCTURED-DATA element is defined/A STRUCTURED-DATA element is defined in this document/
      Section 3: s/The following are defined/The following are defined in this document/
      Section 6: It would be really helpful to IANA and would make certain that you get the results you want if you name the registry from which you wish IANA to make these allocations.
      Section 8.2 appears to have some double-double quotes
    5. Russ Housley: Comment [2009-08-25]: Please review the comments provided in the Gen-ART Review by Suresh Krishnan:
      * Please replace reference to obsolete RFC1738 with a reference to RFC4248 or RFC4266 or both depending on what is required.
      * Section 4: Replace the nonexistent reference [Syslog] with [RFC5424] if that is what you intended to use.
    6. Alexey Melnikov: Comment [2009-08-21]:
      3. Alarm STRUCTURED-DATA Elements
      "Support of the "alarm" SD-ID is optional,"
      s/optional/OPTIONAL ?
      3.6. resourceURI
      "If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM SHOULD be supported. This item uniquely identifies the resource under alarm."
      "The value of this field MUST conform to the URI definition in [RFC1738] and its updates. In the case of an SNMP resource, the"
      This RFC was obsoleted 3 times. This should be pointing to RFC 3986 instead.

    Telechat:

  5. Binding Revocation for IPv6 Mobility (Proposed Standard)
    draft-ietf-mext-binding-revocation-10
    Token: Jari Arkko; Note: Julien Laganier (julien.laganier.ietf@googlemail.com) is the document shepherd
    Extracted from Balloting:
    1. Ralph Droms: Discuss [2009-08-26]: While these issues are editorial and/or clarifying questions, I think they need to be addressed before this doc is published.
      In section 6, where are the Payload Proto and Header Len fields defined?
      The text describing the Mobility Options in section 6.1 wasn't clear to me. Does the first sentence imply that the field should be padded out to a multiple of 8 octets? How does the padding work and how is the beginning of the padding differentiated from a TLV?
      Is the Home Network Prefix option allowed when the P bit is not set?
      s/mandatory/< something from RFC 2119>/ throughout
      What are the RFC 2119 requirements for the IPv4 Home Address option?
      What are the identification semantics for these options; i.e., how are they used to "identify the specific binding or bindings"?
      What are the identification semantics in the case no options are present? Match all; match none, ???
      The text in section 6.2 about the use of Mobility Options is similarly unclear. Can Mobility Options be included (doc says "not required") when the Status field indicates succes? How are the Mobility Options interpreted in the case of success?
      "The mobility option(s) are usually used to communicate information of the bindings that failed the revocation procedure" - how else are they used, when would they not be used, how to they communicate the information about failure?
      Comment [2009-08-26]:
      Section 4, Security Model and Section 14, Security Considerations seem to mostly overlap. I suggest combining the two sections under Security Considerations.
      Is there a reason not to simply define two Mobility Header Types, Binding Revocation Indication and Binding Revocation Acknowledgment, rather than a single Binding Revocation message with two sub-types?
      Related editorial nits - the IANA considerations section might be edited for clarity.
      Identify explicitly that the new message types come from the "Mobility Header Types" registry
      s/namespace/registry/ throughout?
      There are redundant or conflicting instructions for adding new entries to specific registries and the blanket rules for "reserved values" in the last sentence
      From section 7.1:
      "In the BRI message, the initiator MUST set the Sequence Number field to the next sequence number available for Binding Revocation."
      But section 6.1 includes "It could be a random number." in the definition for the sequence number field. These two definitions seem to be in conflict.
      In section 7.2:
      "If a mobility node receives a Binding Revocation Indication message with the Revocation Trigger field is set to a value that NOT supported"
      I assume this should read "is NOT supported" (why is NOT capitalized?); does this mean not supported by the receiving mobility node, not supported in the protocol, ???
      In section 7.3, I assume retransmission only occurs when the sending mobility entity set the A bit in the Binding Revocation Indication message?
      Would it be possible to reorder the bits in the Indication and Ack messages so the P, V and G bits fall in the same place in both messages?
      I wonder if there is a potential for confusion about the inclusion of mobility options based on text in different parts of the doc. I think it would clarify the doc to give rules for mobility options in the specific sections describing the processing performed by the different mobility entities. That is, the blanket rules in sections 6.1 and 6.2 might be in conflict with specific rules, for example, in section 9.1.1. Unless there is some rule in sections 6.1 and 6.2 that apply universally to all messages, I suggest leaving out the options lists form those sections and put the explicit options in each of the appropriate subsections of sections 9, 10, 11 and 12.
    2. Pasi Eronen: Discuss [2009-08-26]: I have reviewed draft-ietf-mext-binding-revocation-10, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document.
      Sections 9.1.1 and 10.1.1 seem to assume some kind of "wildcard" functionality for the Mobile Node Identifier Option, but I can't find any text specifying the exact syntax of those wildcards?
      In several places, the text talks about mobile node's NAI -- does this specification requiring using Mobile Node Identifier Option subtype 1, or would it also work with other subtypes?
    3. Adrian Farrel: Comment [2009-08-25]: Would it be wise to have IANA track the flags in the Binding Revocation Indication and Binding Revocation Acknowledgement messages?
    4. Russ Housley: Discuss [2009-08-27]: The Gen-ART Review by Ben Campbell on 25-Aug-2009 is comprehensive. Please address the major issue concerning the security considerations, and please consider the oher points that Ben raises.
      http://www.softarmor.com/rai/temp-gen-art/draft-ietf-mext-binding-revocation-10-campbell.txt
    5. Tim Polk: Comment [2009-08-27]: I support Pasi's discuss on wildcards and Robert's discuss on implicit revocation.
      As far as I can tell, global revocation was not included in the IPv4 analog (in 3543); any word on the IPv4 experiences that indicates this feature is necessary?
    6. Robert Sparks: Discuss [2009-08-26]: Agree with Pasi's discuss on wildcards.
      I'm concerned about the new (is it new to the protocol suite?) semantic this document adds that allows revoking an implicit set rather than an explicit list of things. This seems to allow revoking things the element sending the BRI may not know about. It also seems to bring up harder questions of authorization policy that the document currently waves out of scope. Why isn't some discussion of the potential dangers of allowing example.net to indicate revocation of bindings related to example.com warranted?

    Telechat:

  6. Extended MKCOL for WebDAV (Proposed Standard)
    draft-ietf-vcarddav-webdav-mkcol-06
    Token: Alexey Melnikov; Note: Julian Reschke <julian.reschke@greenbytes.de> agreed to shepherd the document
    Extracted from Balloting:
    1. (none)

    Telechat:

  7. Network Time Protocol (NTP) Server Option for DHCPv6 (Proposed Standard)
    draft-ietf-ntp-dhcpv6-ntp-opt-04
    Token: Ralph Droms; Note: Brian Haberman (brian@innovationslab.net) is the document shepherd
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2009-08-27]: I agree with Russ that this document should have a paragraph explaining its relationship to RFC 4075 (which is being obsoleted by this document), describing briefly why RFC 4075 is obsoleted (and what is added here), and saying that the use of RFC 4075 is no longer recommended.
      Glen Zorn's SecDir review also identified a number of places that would benefit from some clarification of the text, and provided editorial comments that should be taken into account.
    2. Adrian Farrel: Discuss [2009-08-26]: A quick Discuss-Discuss that I hope the other ADs can address for me during the telechat...
      What happens to the code point assigned by RFC 4075 if that RFC is obsoleted by this RFC, and this RFC does not take over the definition of that code point?
    3. Russ Housley: Discuss [2009-08-25]: This document will obsolete RFC 4075 (once approved). Please help developers by including a section or appendix that summarizes the chnges from RFC 4075 to this document.
      Comment [2009-08-25]: As pointed out in the Gen-ART Review by Sean Turner on 2009-08-12:
      In section 4: s/To to enable/To enable/
    4. Cullen Jennings: Discuss [2009-08-27]: It seems like a DHCP server may want to continue advertising 4075 style information as a transition strategy to this. I'd like to talk about if this should obsolete 4075
    5. Alexey Melnikov: Discuss [2009-08-21]: I only have a minor blocking comment on this document:
      3. NTP Server Option for DHCPv6
      "[...] The option itself does not contain any value. Instead, it contains one or several suboptions that carry NTP server or SNTP server configuration information. This option MUST include one, and only one, time source suboption. The currently defined time source suboptions are: NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR, NTP_OPTION_SRV_FQDN. It carries the NTP server or SNTP server location, as a unicast or multicast IPv6 address or as an NTP server or SNTP server FQDN. More time source suboptions may be defined in the future."
      The last sentence implies that this needs a new IANA registry, but this registry is not defined in the document.
      Comment [2009-08-21]:
      3.3. NTP Server FQDN Suboption
      "FQDN: Fully Qualified Domain Name of the NTP server or SNTP server. This field MUST be encoded as described in [RFC3315], section 8."
      I think this should be clearer that IDN names are not allowed here.
    6. Tim Polk: Discuss [2009-08-26]: There are three issues I would like to addressed before this document is published.
      (1) This document is unclear with respect to the inclusion of other suboptions in addition to the one and only one time source supotion.
      Section 2.1 indicates that only server location will be included:
      "While the NTP specification defines a comprehensive set of configuration parameters, modification of those parameters is best left to the decision of the client itself. The DHCPv6 option for NTP is then restricted to server location."
      Section 3 indicates that all configuration information related to an NTP server will appear in suboptions, and implies that other suboptions could appear (beyond time source). From the first paragraph:
      "This option serves as a container for all the information related to one NTP server or SNTP server."
      From the second paragraph:
      "The option itself does not contain any value. Instead, it contains one or several suboptions that carry NTP server or SNTP server configuration information. This option MUST include one, and only one, time source suboption."
      Does the working group intend to limit the set of suboptions that can appear to the time source suboptions, or is it just that this is the only relevant suboption defined to date?
      (2) There are two statements in section 2.1 that I could not wrap my brain around.
      (2a) First, I had trouble with the second sentence of the first paragraph. The first two sentences are:
      "The NTP service is publicly offered on the Internet by a number of organizations. Those servers can be used but not abused, so any method which is tasked to disseminate locations of NTP Servers must act responsibly in a manner that does not lead to public server overloading."
      I actually believe that those servers *can* be abused, and that abuse may be hard to correct with hardcoded configuration. This option is designed to support responsible use of thes public resources. Is that what was meant here?
      (2b) At the end of the second paragraph of section 2.1, the document states:
      "DNS can be used to redirect misconfigured clients to an unexisting IPv6 address instead of having to change the address of the NTP server itself."
      What is an "unexisting IPv6 address"?
      (3) In section 4, the FQDN example provides the exact encoding, but the unicast and multicast examples do not provide the encoding for the addresses. For consistency and utility, the unicast and multicast examples should provide the exact encoding.
      Comment [2009-08-26]: In addition to identifying items (2a) and (3) above, Glen Zorn's (late) secdir review dated August 24 provides some suggested wording changes. I would encourage the authors to review Glen's suggestions and incorporate those that they find helpful.
    7. Dan Romascanu: Comment [2009-08-27]: I support the DISCUSSes by Russ and Adrian concerning the relationship with RFC 4705.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer (Proposed Standard)
    draft-green-secsh-ecc-08
    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...
    Token: Tim Polk; Note: Jeffrey Hutzelman (jhutz@cmu.edu) is document shepherd
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2009-08-26]: I have reviewed draft-green-secsh-ecc-08, and have couple of concerns that I'd like to discuss before recommending approval of the document:
      Section 3.1.2, last paragraph, is not consistent with the definition of "mpint" type in RFC 4251, which specifies slightly different octet string encoding for integers.
      In Section 6.1, the document doesn't tell which ASCII representation of OIDs is used. The reference [ASN1] usually uses space-separated ASCII representation, but the example in Section 6.3 suggests that dot-separated might be the intended one.
    2. Russ Housley: Comment [2009-08-25]: Please consider the changes raised in the Gen-ART review by Miguel Garcia, which canbe found here:
      http://www.softarmor.com/rai/temp-gen-art/draft-green-secsh-ecc-08-garcia.txt

    Telechat:

  2. IESG Procedures for Handling of Independent and IRTF Stream Submissions (BCP)
    draft-housley-iesg-rfc3932bis-08
    Token: Jari Arkko; Note: There is no document shepherd
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-08-13]: Holding a Discuss until -08 is posted and the IESG (including Cullen) has had a chance to look at the document.
    2. Ross Callon: Comment [2008-12-04]: I agree with the DISCUSS comments by Cullen and Dan, but will let them hold the DISCUSS votes.
    3. Adrian Farrel: Comment [2009-04-23]: A bunch of comments. The RFC Editor might catch some of these, but not all. Check carefully because some of them have a subtle effect on the meaning.
      1. Abstract: The Abstract contains an unnecessary note to the RFC Editor
      {{{ RFC Editor: Please change "RFC XXXX" to the number assigned to this document prior to publication. }}}
      There is no reference to "RFC XXXX" in the document.
      2. Section 1: "Documents published in streams other than the IETF Stream may not"
      s/may/might/
      3. Section 1A "Once these procedures are fully adopted, the IESG will continue to be responsible only for checking for conflicts between the work of the"
      s/will continue to be responsible only/will be responsible only/
      4. Section 2: s/IRTF stream/IRTF Stream/
      5. Section 3: s/publications as RFC/publication as RFCs/
      6. Section 3: s/types of conclusions/types of conclusion/
      7. Section 3: s/for <X>/for WG <X>/
      8. General: Would be nice to consistent about "Independent Stream" or "Independent Submission Stream"
    4. Dan Romascanu: Comment [2008-12-04]: The current combination of rfc3932bis and 'IAB Headers and Boilerplate' leaves out an important message that was included in the IESG Note.
      Let us take the text for IRTF stream documents. The text in draft-iab-streams-headers-boilerplates-04.txt
      IRTF Stream: "This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This document has been approved for publication by the IRSG. It is not a product of the IETF and is therefore not a candidate for any level of Internet Standard; see section Section 2 of RFCXXXX."
      is much weaker IMO than the text in the RFC 3932 IESG note:
      "This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols."
      Missing to say 'is not based on IETF review' is essential IMO.
      I sent a note to the IAB, as the fix should be in the IAB document.

    Telechat:

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. NAT Behavior Discovery Using STUN (Experimental)
    draft-ietf-behave-nat-behavior-discovery-07
    IPR: Nortel Networks Statement about IPR in draft-ietf-behave-nat-behavior-discovery
    IPR: Nortel Networks Updated Statement about IPR claimed in draft-ietf-behave-nat-behavior-discovery
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2009-08-10]: This is a good document & I have a few comments. Most of the comments are minor; the question about discovering a STUN server with this new usage supported is probably the biggest issue. But it's probably not a blocking issue, so I plan to clear this DISCUSS and let the authors handle this input as they will, after getting a chance to discuss on the telechat.
      Section 1.
      Got really confused reading this paragraph for a number of reasons: agency, context, and obsolete references.
      "The applications of this STUN usage are very different than the original use of RFC3489 [RFC3489], which was intended for static determination of device behavior. The NAT Behavior Discovery STUN usage makes an explicit statement that it is not, and cannot be, correct 100% of the time, but is still very useful. More generally, one of the important differences between 3489 and ICE is that ICE ensures there is always a fallback to TURN, and thus avoids the problem experienced by 3489-based applications that tried to determine in advance whether they would need a relay and what their peer reflexive address will be, which are both impossible. This STUN usage requires an application using it to have a fallback, but unlike ICE's focus on the problems inherent in VoIP sessions, doesn't assume that it will only be used to establish a connection between a single pair of machines, and so alternative fallback mechanisms may make sense. For example, in a P2P application it may be possible to simply switch out of the role where such connections need to be established or to select an alternative indirect route if the peer discovers that, in practice, 10% of its connection attempts fail."
      If I was able to interpret correctly, then this restatement *ought* to be correct and provide a little more context. In addition, it reflects that STUN is now RFC5389, which probably needs to be fixed elsewhere too. "This STUN usage" is also pretty hard to qualify when other STUN usages are also being discussed ("the STUN usage defined in this specification" is clear but long), so it would be good to give this STUN usage a name...?
      The applications of this STUN usage differ from the original use of STUN (originally [RFC3489], now [RFC5389]). This specification acknowledges that the information gathered in this usage is not, and cannot be, correct 100% of the time, whereas STUN focused only on getting information that could be known to be correct and static.
      This specification can also be compared to ICE. ICE avoids the problem experienced by applications using STUN to determine in advance whether they would need a relay and what their peer reflexive address will be, which are both impossible [are these really individually impossible or just impossible to do together or impossible to do in advance?]. ICE avoids this problem by falling back to TURN, another usage of STUN. ICE focuses on problems inherent in VoIP sessions, which require a connection between a single pair of machines. The STUN usage defined in this specification requires an application using it to have a fallback, but doesn't assume that it will only be used to establish a connection between a single pair of machines, and so alternative fallback mechanisms may make sense. For example, in a P2P application it may be possible to simply switch out of the role where such connections need to be established or to select an alternative indirect route if the peer discovers that, in practice, 10% of its connection attempts fail.
      Section 2.: The acronym expansion for STUN has changed, it's Session Traversal Utilities, not Simple traversal Under.
      "NAT/FW" is not defined... I assume this is "NAT/Firewall"?
      Section 3.6 "3.6. Detecting Generic ALGs" --> define or expand ALG acronym
      Section 5.1: The first phrase in this section implies that the client could configured with a transport address to a STUN server supporting this usage, but how would it know? Couldn't it be configured with a transport address to a STUN server that does *not* support the usage? Is there a way of testing support for this usage that can't be conflated with a NAT failure?
      Section 7.3A "It is useful for detecting twice NAT configurations." --> Should this be "double NAT configurations"?
    2. Russ Housley: Comment [2009-08-25]: Please consider the changes raised in the Gen-ART review by Pete McCann. Pete reviewed -06, but the changes needed to address his comment were not made in -07. The review can be found here:
      http://www.softarmor.com/rai/temp-gen-art/draft-ietf-behave-nat-behavior-discovery-06-mccann.txt
    3. Cullen Jennings: Discuss [2009-08-27]: The usage of RESPONSE-TARGET seems like it would only need to allow the response port, not IP address to be changed. This would improve the security situation. Why is the IP address allowed to change?
    4. Dan Romascanu: Discuss [2009-08-27]:
      1. The document presents as principal usage of NAT behavior discovery network diagonstics for 'network administrator or system programmer trying to determine the causes of network failure; particularly when behavior varies by load, destination, or other factors that may be related to NAT behavior'. This almost sounds like another OAM layer, or duplicating the OAM layer functionality. It is not clear however how this is going to be activated, will this run permanently or on demand, how are results being collected by an operator using discovery as a diagnostics tool
      2. I do not understand well what 'experimental success' section 2.3 refers to. This is not about the success of the experiment of the discovery method, but rather about whether an application can improve its behavior. Using the 'Experimental Success' title for this section is confusing.
      Comment [2009-08-27]: At the end of Section 1:
      "If a draft specifies the use of any portion of this STUN usage, that draft MUST document"
      Probably some other term than 'draft' should be used
    5. Robert Sparks: Comment [2009-08-26]: There are a few constants called out in the document (15 minutes for holding an unused port, not generating more than ten new transactions per second, etc.). Providing some motivation for the values you chose would be useful.
      In section 6.1, "ensure that it does not generate a Response on a particular address"
      should be
      "ensure that it does not generate a Response to a particular address"
      The sentence after that would really benefit from simplificaiton.
      Nits: The end of section 2.2: "these two requirements" point back to a list of 3 things.
      2nd paragraph of 4.5: "Section Section"
      Just before 5.1: expand RTOs

    Telechat:

  2. MPLS Forwarding Benchmarking Methodology for IP Flows (Informational)
    draft-ietf-bmwg-mpls-forwarding-meth-05
    Token: Ron Bonica
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-08-26]: This sentence in Section 2 doesn't parse:
      "The fact that MPLS forwarding places a different burden on the resources of the network forwarding devices from that of IP forwarding, MPLS forwarding benchmarking specifics are desired."
    2. Adrian Farrel: Discuss [2009-08-26]: This is a fine document, and I'm glad you produced it. I have a couple of questions I'd like to see resolved before it moves forward for publication.
      IPv6 support?
      I think it is your intention to support IPv6.
      Section 4.1.8 says that the Ethertype should be checked/reported against "0x8847 or 0x8848 vs. 0x0800"
      You need to add 0x86DD.
      That said, a common behavior for carrying IPv6 in MPLS is to use the IPv6 explicit null label. I assume you require this facility to be configured off. You might say so somewhere to help people understand how to keep the label stack to depth 1.
      Frame Loss and Misdelivery
      Early in section 4.1.8 you have:
      "Specifically, traffic loss (also referred to as frame loss) is defined as the traffic (i.e. one or more frames) not received where expected (i.e. received on incorrect port, or received with incorrect layer2 or above header information etc.)."
      But then you say...
      "An even greater level of verification would be to check if the correct label was pushed, but that is out of scope for these tests."
      I'm surprised.
      You check that the packets arrive on the correct Bn. in other words you check that the port forwarding is correct. But you don't think that the label imposition/swap is also an important feature? MPLS is no use unless the correct label has also been applied. You might as well not bother checking that the output port is correct.
      I think label checking is a fundamental part of frame loss evaluation.
      Why is this out of scope?
      Note that 6.1.2 says...
      "The test tool must receive MPLS packets on receive ports Bp (from DUT) with the same label values that were advertised using the label distribution protocol."
      I think you need to clarify section 6.3 to state that a misdirected frame (i.e. received on the wrong Bn) is considered as lost. This is not clear from RFC 2544 or even from RFC 1242 (referenced by 2544).
      Then you have to decide whether a frame with the wrong label is "lost". I think it is.
      Section 6: There is an interesting assumption in...
      "However, if the forwarding throughput of the DUT is more than that of the media rate of a single port, then additional ports on A and B Modules MUST be enabled so as to exceed the DUT's forwarding throughput."
      That is, what happen if the DUT is spec'd such that its forwarding throughput capability is greater than the capacity of half of its ports?
      The problem is also more subtle than described because the traffic sent into the collected An must not result in any one Bn being overloaded.
      Section 6.1.2
      "The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE (FTN) mapping table per [RFC3031]) must contain non-reserved MPLS label values as the outgoing and incoming labels for the learned IP prefixes, resulting in MPLS-to-MPLS forwarding operation e.g. label swap.
      The FTN is not used in label swapping. You may refer to the Incoming Label Map (ILM) identifying an entry in the NHLFE. Or you can talk about the Label Forwarding Information Base (LFIB).
      This is also the case for 6.1.3 and 6.1.4.
      Section 6.5
      "Note that BMWG plans to produce a separate document focusing on 'reset' aspects of benchmarking in order to ensure clarity and consistency in reset procedures beyond what's specified in RFC2544."
      This document does not specify the reset procedures. The text below describes the MPLS forwarding benchmarking specific setup that will have to be used in conjuction with the procedures from the separate document to make this test case meaningful."
      I think you would have got away with this had you already started such a document or at least if you had a charter milestone. But it looks very much to me that this might not happen.
      Can you give any assurances that say that it wouldn't be better to delete this section?
      Comment [2009-08-26]: A variety of nits...
      Figure 1: The text refers to DUT ports DA1...DAp and DB1...DBp, but the figure only shows DA1, DA2, DB1, and DB2.
      Section 4: "p => 2" might more usually be expressed as "p >= 2"
      Section 4.1.1: I am uncomfortable with the equation of "remote network" with "MPLS FEC". Perhaps you can say "IP Prefix FEC".
      Section 4.1.2: Is the term "highly RECOMMENDED" a new contribution for draft-ietf-rfc2119bis-00.txt?
      I think you can either stay with "RECOMMENDED" or move to "MUST".
      Section 4.1.4.1: "This document requires only a single entry in the MPLS label stack in an MPLS packet."
      I think you intend to go further, don't you? Specifically, you don't support more than one label in the stack.
      Section 4.1.4.4: s/Section 4.1.3.1/Section 4.1.4.1/
      Section 4.1.5: Your section numbers referenced are out by -0.0.1
      See 4.1.4.1, 4.1.4.2, and 4.1.3.
      May be endemic. Check the whole document.
      Section 4.1.7: s/vaue/value/
    3. Russ Housley: Discuss [2009-08-25]: Please see section 4 of this IESG statement:
      http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html
      IETF Last Call is needed for this document.

    Telechat:

  3. Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks (Informational)
    draft-ietf-mext-aero-reqs-04
    Token: Jari Arkko; Note: Document Shepherd is Marcelo Bagnulo Braun <marcelo@it.uc3m.es>
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-08-26]: I found this to be a particularly well-written document. I wish half the requirements documents I read were half as good.
    2. Russ Housley: Comment [2009-08-25]: Please consider the comments in the Gen-ART Review by Vijay Gurbani posted on 20-Aug-2009:
      1) What is the "Gatelink system"? There are at least two instances of it in the draft. Any reference or a short sentence describing this would help the reader not verbose in this particular domain.
      2) Missing closing bracket ')' in Section 2.1.1, third paragraph, third line; i.e., should be "... in Appendix A.)"
    3. Cullen Jennings: Comment [2009-08-27]: I don't believe these requirements adequately cover the requirements for ATS data. For example, "Req3 - Latency" is a solution to mitigate latency, not an actual requirement that bounds latency.

    Telechat:

  4. Application of Ethernet Pseudowires to MPLS Transport Networks (Informational)
    draft-ietf-pwe3-mpls-transport-04
    Token: Ralph Droms; Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd; Was deferred by Ross Callon on 2009-08-13
    Extracted from Balloting:
    1. Adrian Farrel: Discuss [2009-08-12]: Discuss-Discuss
      Despite the fact that I *hate* the concept of a Discuss-Discuss, I want to have a discussion on the telechat with the rest of the IESG before we proceed with this draft. I hope to remove this part of the Discuss during the call without the need for involvement of the document shepherd or the authors.
      The MPLS-TP work is pretty sensistive both from inter-SDO politics and for commercial reasons. This draft dates back to a time before the current cooperative agreement between the IETF and ITU-T to work jointly on MPLS-TP. The draft was originally conceived to demonstrate that (some of) the requirements of MPLS-TP could be met using existing MPLS and pseudowire tools.
      It has been last called on the PWE3 WG mailing list, and was also last called to the MPLS WG list, but it did not form part of the MPLS-TP effort.
      I want to be sure that this work is necessary and politically advisable, as well not conflicting with the MPLS-TP work. This is notwithstanding the text in Section 1 that says:
      "It is recognised that it is possible to design a more efficient method of satisfying the requirements, and the IETF anticipates that improved solutions will be proposed in the future."
      Discuss
      Section 1 references requirements 30 and 31 in I-D.ietf-mpls-tp-requirements. The requirements numbering must have changed since this was written. You probably mean 31 and 32.
    2. Russ Housley: Comment [2009-08-13]: The Gen-ART Review by Gonzalo Camarillo on 20-Jul-2009 includes a few things that should be considered:
      All acronyms need to be expanded on their first use. This includes the title and the abstract of the draft.
      Generally, abstracts should not contain references. I suggest removing the reference to RFC 4448 from it.
    3. Dan Romascanu: Discuss [2009-08-12]: This is a DISCUSS-DISCUSS which I plan to clear after or during the telechat after making sure that the IESG debated all aspects of the decision to approve this RFC as Informational. Sections 2, 3 and 4 seem to include normative text, requirements, and even more - usage of control words, provisioning methods, etc. I understand that requirements in PWE3 are being described by Informational RFCs in PWE3 but in this case we are discussing about using PWE3 trnasport for MPLS-TP. Are we not going to be in the situation that these documents need to be PS or BCP?

    Telechat:

3.1.2 Returning Items

  1. Extensions to OSPF to Support Mobile Ad Hoc Networking (Experimental)
    draft-ietf-ospf-manet-or-02
    IPR: Cisco's Statement of IPR related to draft-ietf-ospf-manet-or-02
    Token: Ross Callon
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-01-15]:
      "Note that the active overlapping relays selection algorithm is implementation specific, and the above is simply a suggested algorithm. However, the behavior of the overlapping relays MUST follow that specified in the "Flooding and Relay Decisions" Section. Moreover, the same selection algorithm MUST be used by all nodes within an area."
      This should be raised earlier in the document. As written, the spec does not provide an interoperable solution. This may not be required for an experimental specification, but at the very least the reader should know about this after reading the introduction.
      "attached to the broadcast network. Such desginated routers must be"
      typo
      Thomas Narten's quick review reaction was this:
      When you do incremental updates, there are all sorts of failure edge cases. Its a lot like how to correctly do a sliding window protocol. Just skimming the document, its not presented in a way that explains the basic idea behind the details. For correctness, you need equivalent of 3 way handshake to be sure both sides are synchronized w.r.t. shared state.
    2. Ross Callon: Comment [2009-01-15]: I think that it is very unfortunate that we can't agree on one single standards track approach for supporting MANET networks with OSPF. However, I understand the difficulty here, and under the circumstances probably the least bad approach is to progress all three as experimental, and then hope to sort out differences with the aid of operational experience.
    3. Ralph Droms: Comment [2009-08-26]:
      It's only necessary to cite the reference for a citation to a doc on first mention; reading, e.g., "...modifications to [OSPFv3] to support..." throughout the doc is distracting.
      Acronym expansion for LSA?
      Are there some links missing or other typos in this network map? 
            +---+I11        I21+---+I23   | 
      |RT1|-+----------+-|RT2|------|N1 
      +---+ |          | +---+      | 
      |                |   VI22 
      |                |   + 
      |                |   | 
      |                |   | 
      |                |   | 
      |                |   | 
      |                |   + 
      |                |   ^I41 
      +---+ |          +---+ 
      |RT3|-+        +-|RT4| 
      +---+I31      I42+---+

      E.g., should the leftmost vertical bars be shifter right 6 or so spaces?
    4. Adrian Farrel: Discuss [2009-08-26]: Sorry to point this out, but you have an Experimental I-D that is requesting the allocation of two bits in the Router-LSA Router Options field. RFC 4940 sets the allocation policy as Standards Action which (of course) demands a Standards Track RFC.
      (I guess IANA might also ask you why you have left bit 14 undefined, but I guess you know some other I-D in the pipeline.)
      (I'm also slightly nervous about the consequences of an Experimental RFC creating a new protocol field and registry where there was previously a zero, but I can't see how this would cause harm.)
      PS. I have just been a victim of a similar issue with an OSPFv2 Experimental RFC. It sucks!
    5. Alexey Melnikov: Discuss [2009-08-26]: I generally like the document, but I have some minor concerns described below:
      Section 3.2.1 says:
      "A new I bit is defined in the OSPFv3 option field. The bit is defined for Hello packets and indicates that only incremental information is present. See Section 3.4 for placement of the I bit within the OSPFv3 options field."
      And section 3.4 says:
      Two new option bits are defined in the OSPFv3 Options Field (defined in [OSPFv3], A.2) as follows:
      I bit - defined in Section 3.2.1: The I bit is only defined for Hello packets and indicates that only incremental information is present.
      F bit - defined in Section 3.3.5: The F bit indicates that the node supports the Optimized Flooding mechanism as specified in this draft.
      So Section 3.4 doesn't really define the placement of the I bit, but the section 5 does.
      5. IANA Considerations
      "New TLV type codes are defined from LLS [LLS] TLV types values. 
            TLV Name                      TLV Type 
      --------                      --------
      State Check Sequence TLV          3
      Neighbor Drop TLV                 4
      Request From TLV                  5
      Full State For TLV                6
      Active Overlapping Relay TLV      7
      Willingness TLV                   8

      Unless I am mistaken, this conflicts with the current allocations in <http://www.iana.org/assignments/ospf-lls-tlvs/ospf-lls-tlvs.xhtml>.
      Comment [2009-08-26]:
      1.2 Motivation for extending OSPF to support MANETs
      "The second motivation is that OSPF is a well understand and widely"
      s/understand/understood
      3.2.2 State Check Sequence TLV (SCS TLV)
      "SCS Number: A circular two octet unsigned integer indicating the"
      This should say that it is in network byte order.
      3.3.6 Active Overlapping Relay TLV (AOR TLV)
      "Reserved - Reserved for future use and MUST be ignored upon reception."
      I think this should say that the value MUST be set to 0 by the sender.
    6. Tim Polk: Discuss [2009-08-27]: [This is a revised discuss, reflecting changes in the -02 draft].
      Ran Canetti provided significant comments in a secdir review that was posted on 2 January 2009.
      The security considerations in the -02 draft is a significant improvement, and does begin to address his general concerns. However, it does not completely address the three specific examples highlighted in his review.
      The new text DOES clearly addresses Ran's second issue, which focused on increased instability of wired networks arising from connection with a MANET.
      The new text does not fully address the first issue (false attestations from authentic but malicious sources) and I did not see anything regarding the third issue (locating and disconnecting undesirable endpoints).
      Please consider whether this issues constitute real security threats. If they do, please draft some brief text (or include a pointer if they are addressed in other documents). If you believe these issues are not real threats, please let me know why they do not apply.

    Telechat:

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

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)

1256 EDT break

1301 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. SIP Common Log Format (clf)
    Token: Robert

    Telechat:

4.1.2 Proposed for Approval

  1. Multicast Mobility (multimob)
    Token: Jari

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Internationalized Domain Names in Applications, Revised (idnabis)
    Token: Lisa

    Telechat:

  2. DNS Extensions (dnsext)
    Token: Ralph

    Telechat:

5. IAB News We can use

  1. Dave: nothing, we didn't meet yesterday; various individuals working individually

6. Management Issues

  1. Status of 128.66.0.0/16 [IANA #256883] (Michelle Cotton)

    Telechat:

  2. Tracking changes to WG charters (Alexey Melnikov)

    Telechat:

  3. Should ADs have access to passwords to mailing lists for their respective areas? (Alexey Melnikov)

    Telechat:

  4. Two chairs from the same company (Dan Romascanu)

    Telechat:

  5. 3932bis discussion (Russ Housley)

    Telechat:

  6. Approval of expert for RFC 2616 (http-parameters registry) (Michelle Cotton)

    Telechat:

7. Agenda Working Group News

1410 EDT Adjourned