IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2010-02-18. These are not an official record of the meeting.

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

Corrections from: Adrian, Dan, Russ

1 Administrivia

  1. Roll Call 1134 EST 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 Submissions

2.1.1 New Items

  1. Discovering the Local Location Information Server (LIS) (Proposed Standard)
    draft-ietf-geopriv-lis-discovery-13
    Token: Cullen Jennings
    Note: Alissa Cooper (acooper@cdt.org) is the document shepherd.
    Discusses/comments (from ballot 3173):
    1. Jari Arkko: Comment [2010-02-18]:
      I support the Lars/Ralph Discuss, and the way to resolve that is to get the review the DHC WG.
    2. Ralph Droms: Discuss [2010-02-17]:
      Following up on Lars' DISCUSS, the current version of the spec has not, as far as I know, been reviewed by the dhc WG.
    3. Lars Eggert: Discuss [2010-02-16]:
      I'm surprised to see a DHCPv4/6 option standardized out of GEOPRIV. Has the DHC WG reviewed this?
    4. Lars Eggert: Comment [2010-02-16]:
      Section 2., paragraph 1:
      What if I have multiple access interfaces connected to multiple operators, all of which operate LIS servers that satisfy the criteria for use?
      Section 5., paragraph 2:
      Nit: s/probablity/probability/
    5. Pasi Eronen: Discuss [2010-02-18]:
      While relying on DHCP seems unavoidable here, normally HTTPS does not rely on DNS to work securely.
    6. Pasi Eronen: Comment [2010-02-18]:
      The regexp in Section 4 is wrong; "*." should be ".*"
    7. Adrian Farrel: Discuss [2010-02-18]:
      It might be valuable to note that there could be more than one LIS for any access network and that the device makes the choice based on local policy.
    8. Adrian Farrel: Comment [2010-02-18]:
      Section 2.2 begins "A Device MUST avoid performing LIS discovery..."
      I find this use of RFC 2119 a little vague.
      Nits...
    9. Alexey Melnikov: Discuss [2010-02-13]:
      2. LIS Discovery Procedure:
      I would like to see more justification of why the option 15 is not acceptable/sufficient for LIS discovery.
    10. Alexey Melnikov: Comment [2010-02-13]:
      1. Introduction and Overview:
      URI schemes need references to the correponding RFCs.
    11. Tim Polk: Comment [2010-02-18]:
      I support Pasi's discuss, which addresses the same issue as my comment...
      I have retained the text of my comment, since authors may want to read this with Pasi's discuss.
    12. Robert Sparks: Discuss [2010-02-16]:
      1) The document currently places requirements on a LIS implementation... This is out of place in this document.
      2) I encourage adjusting the language at the beginning of section 2.1.

    Telechat:

  2. A Uniform Resource Identifier for Geographic Locations ('geo' URI) (Proposed Standard)
    draft-ietf-geopriv-geo-uri-04
    Token: Cullen Jennings
    Note: Richard Barnes (rbarnes@bbn.com) is the document shepherd.

    Discusses/comments (from ballot 3226):
    1. Jari Arkko: Discuss [2010-02-18]:
      This ignores IMO a very important client application: passing Geo URIs around from one place to another. A client need not understand the format to do it.
    2. Lisa Dusseault: Discuss [2010-02-18]:
      I didn't find an expert review in email or in the document history. RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.
    3. Lars Eggert: Discuss [2010-02-16]:
      Section 3.4.4., paragraph 1:
      According to this definition, two locations with the same coord-a, coord-b and coord-c but different uncertainty parameters will NOT be identical. Isn't that counter-intuitive?
      Section 3.4.4., paragraph 5:
      What if the given coord-c is identical to the altitude of the Earth's physical location at the given latitude and longitude; are the two identical then?
      Section 9.1., paragraph 1:
      please either tighten the ABNF so that it does not allow to express invalid locations (preferred), or otherwise specify which locations are valid and which are not.
    4. Alexey Melnikov: Discuss [2010-02-18]:
      1) 8.2.2. Registration Policy:
      I assume registrations through Designated Expert (without a specification) are not allowed?
      2) 8.3.2. Registration Policy:
      Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?
      3) 11.2. Informative References: [WGS84]
      This looks like a Normative Reference.
    5. Alexey Melnikov: Comment [2010-02-18]:
      1) The URI registration template is missing the "Security considerations" section.
      2) crslabel: these are case-insensitive? I am also agreeing with Robert's comment which is similar.
      3) pnum: So you want "-0" to be valid? If yes, please state that explicitly in the document.
      4) 8.3.1. Registry Contents: "Reference to the definition of the CRS itself..." This sentence is not readable
      5) 9.2. Location Privacy: typo
    6. Tim Polk: Discuss [2010-02-16]:
      Section 5 states that just one operation is defined: location dereference. However, section 3.4.4 describes URI comparison rules. Perhaps I am missing something, but that seems like two operations to me.
    7. Robert Sparks: Discuss [2010-02-16]:
      (empty)
    8. Robert Sparks: Comment [2010-02-16]:
      Please add an explicit statement on whether case is sensitive when comparing parameter names and values.

    Telechat:

  3. Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (Proposed Standard)
    draft-ietf-ccamp-gmpls-dcsc-channel-ext-03
    Token: Adrian Farrel
    Note: Deborah Brungard (db3546@att.com) is the document shepherd.
    Discusses/comments (from ballot 3315):
    1. Alexey Melnikov: Comment [2010-02-14]:
      3.1. Generalized Channel_Set LABEL_REQUEST Object:
      But Section 3.2 says that it is "based on" the latter?
      3.2. Generalized Channel_Set LABEL Object:
      Question: how can one determine size of a Channel_Set Sub-Object?
    2. Dan Romascanu: Comment [2010-02-16]:
      Nevil Brownlee made the following comment in his OPS-DIR review... I believe that Nevil is correct and the impact on the format of other label related objects is unclear.
    3. Magnus Westerlund: Discuss [2010-02-18]:
      Section 3.2: I do like to know what the recommendation is on handling fragmentation is. But the reference points into the void.

    Telechat:

  4. DHCPv4 Vendor-specific Message (Proposed Standard)
    draft-ietf-dhc-dhcpv4-vendor-message-01
    Token: Ralph Droms
    Note: Ted Lemon (mellon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot 3331):
    1. Jari Arkko: Comment [2010-02-18]:
      I support the Robert Sparks Discuss about better guidance (and perhaps even some mandatory rules).
      I think we need to ask why we are doing this document. Is this a companion document to the other proposals that I am getting for ND option vendor extensions?
    2. Pasi Eronen: Discuss [2010-02-16]:
      Section 1 says "New message codes are assigned through IETF Standards Action". According to the registry and RFC 2939, the policy is currently "IETF Consensus" -- is this just a typo, or is the intent to change the policy?
    3. Adrian Farrel: Discuss [2010-02-13]:
      I don't think it is correct to suggest that a purpose of this is experimentation. Experiments are not supposed to escape into the wider Net and an experimental message would be treated differently from a vendor-specific message.
    4. Adrian Farrel: Comment [2010-02-13]:
      I support Alexey's Discuss wrt mandating the behavior of non-supporting nodes.
      section 4: option-len: I think this should s/vendor-option-data/option-data/
      Section 1: If I am not mistaken, the registry and RFC 2939 say "IETF Consensus".
    5. Russ Housley: Discuss [2010-02-14]:
      Two concerns were raised in the Gen-ART Review by Elwyn Davies that need to be addressed...
    6. Russ Housley: Comment [2010-02-14]:
      s4, top of page 5: 'Option codes 0 and 255 have no pre-defined interpretation or format': This comment (duplicated from RFC 3925) is confusing to the uninitiated reader.
    7. Alexey Melnikov: Discuss [2010-02-13]:
      1) In Section 3: This sounds as if this document is trying to put requirements on implementations that are not compliant with this document.
      2) In Section 4: This reference looks Normative to me... Are you talking about subopt-code here?
      3) In Section 4: This reference looks Normative to me.
    8. Alexey Melnikov: Comment [2010-02-13]:
      In Section 3: The second MUST almost raises to the level of DISCUSS. What are the good practices you are talking about... it is not clear how this MUST can be satisfied.
    9. Tim Polk: Comment [2010-02-16]:
      (1) I support Adrian's discuss regarding experimentation.
      (2) I support Alexey's discuss regarding section 3 imposing requirements on clients that do not implement this specification.
    10. Dan Romascanu: Discuss [2010-02-16]:
      Section 4 - the document specify that option-len and subopt-len are expressed in octets
    11. Dan Romascanu: Comment [2010-02-16]:
      1. I support Adrian's DISCUSS that mentioning experimental purposes is not appropriate.
      2. I support Russ's DISCUSS that 'MUST use good networking practices' includes a too vague construct
      3. The IANA considerations section should note that the the document makes use of the IANA enterprise id numbers registry.
    12. Robert Sparks: Discuss [2010-02-17]:
      Should this document contain (or point to) more guidance that would encourage the use and development of interoperable DHCP options?

    Telechat:

  5. DHCPv6 Vendor-specific Message (Proposed Standard)
    draft-ietf-dhc-dhcpv6-vendor-message-01
    Token: Ralph Droms
    Note: Ted Lemon (mellon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot 3332):
    1. Jari Arkko: Comment [2010-02-18]:
      See my comment in the DHCPv4 companion document.
    2. Adrian Farrel: Discuss [2010-02-13]:
      My Discuss is identical to the issue I raised for draft-ietf-dhc-dhcpv4-vendor-message. I would be happy to see the reference to experimentation removed from the Abstract and the Introduction.
    3. Adrian Farrel: Comment [2010-02-13]:
      I also support Alexey's Discuss on this document. This work should not attempt to define procedures for non-supporting nodes, but must reference the base spec.
    4. Russ Housley: Discuss [2010-02-14]:
      s3, para 3: This paragraph contains weasel words about 'good networking practices' that 'MUST be used'. This is untestable as it stands.
    5. Alexey Melnikov: Discuss [2010-02-13]:
      1) In Section 3: This sounds as if this document is trying to put requirements on implementations that are not compliant with this document.
    6. Tim Polk: Comment [2010-02-16]:
      I support Adrian and Alexey's discuss positions.
    7. Dan Romascanu: Comment [2010-02-17]:
      1. I support Adrian's DISCUSS that mentioning experimental purposes is not appropriate.
      2. I support Russ's DISCUSS that 'MUST use good networking practices' includes a too vague construct ('good networking practices') for a mandatory to implement statement.
      3. The IANA considerations section should note that the the document makes use of the IANA enterprise id numbers registry.
    8. Robert Sparks: Discuss [2010-02-17]:
      Should this document contain (or point to) more guidance that would encourage the use and development of interoperable DHCP options?

    Telechat:

2.1.2 Returning Items

  1. Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. (Proposed Standard)
    draft-ietf-avt-app-rtp-keepalive-07
    Token: Cullen Jennings
    Discusses/comments (from ballot 3020):
    1. Lars Eggert: Comment [2009-10-19]:
      Section 1., paragraph 15: since redundant keepalives waste bandwidth and energy, do we want to say they're NOT RECOMMENDED?
    2. Adrian Farrel: Comment [2010-02-16]:
      Title: s/maintaining/keeping/
      Need to expand acronyms the first time they show up in the document body For example, ICE
      You might also reasonably explain *why* this document does not apply to ICE agents.
    3. Alexey Melnikov: Comment [2009-10-19]:
      This looks like one big hack, but Ok.
    4. Tim Polk: Discuss [2010-02-16]:
      (1) Given that it is declarative (and not subject to negotiation) I do not understand the utility of the a=rtp-keepalive SDP attribute.
      (2) [Similar to Robert's discuss] Perhaps it would be better to recognize multiplexing RTCP and RTP as the recommended solution, forbid the incorrect version number solution, and let applications pick their poison when a =rtcp-mux does not appear in the answer.
      (3) While a peer is required by RFC 3530 to "ignore packets with payload types it does not understand", that does not preclude examination by the peer in an attempt to determine if it is under attack. Since falling back to the alternative indicates the peer is not aware of this specification, the Cons for section 4.6 should note that the peer may consider the keepalive traffic a DOS attack and terminate the connection.
    5. Dan Romascanu: Comment [2010-02-17]:
      I support the DISCUSSes from Robert and Magnus.
    6. Robert Sparks: Discuss [2010-02-16]:
      I support the conclusion that multiplexing RTCP and RTP is the RECOMMENDED solution and that the other mechanisms are NOT RECOMMENDED. However, I think the document's current approach of making falling back to sending RTP with an unknown payload type RECOMMENDED is a mistake... I think this document should keep the discussion of these alternate techniques, and even point out that of the alternatives other than multiplexing RTP/RTCP, sending unsolicited payload types breaks fewer things. But putting that forth as a Proposed Standard way to behave is not the right thing to do.
    7. Magnus Westerlund: Discuss [2010-02-17]:
      1. RTCP is an integral part of RTP. There are a number of mechanism that doesn't work unless also the RTCP flows are kept alive. To me this document can't rule RTCP out of scope.
      2. Section 4.6: This solution does not discuss which SSRC should be used.
      3. Section 4: In general I am missing a discussion on which solutions results in RTCP reporting on the keep-alive packets.
      4. Section 6.1, first paragraph: T.140 requires that for the SSRC(s) one is using that the sequence number space is continous. If one switches to another media format, and do not attempt to use them intermixed it can work.
      5. section 5: What is the interpretation of the a=rtp-keepalive attribute in multicast sessions?
      6. Section 7: I agree with minimal value for Tr of 15 seconds. It makes sense when sent over UDP. However, a significant larger value, like 5 to 15 min makes more sense for TCP.
    8. Magnus Westerlund: Comment [2010-02-17]:
      Section 1, first bullet: The failure to mention RTSP and streaming seems strange.
      Section 1, bullet 3: Can you mention any codec that would produce CN with longer interval than 1 second?
      Section 3, REQ-9: This is not a requirement, it is a statement about the world.
      Section 4: The subsections on the potential solutions does not discuss how they meet the requirements.
      Section 4.3: How can it be a con to require SDP signaling when you state in REQ-8 that is desirable. In fact only REQ-7 isn't supported by this solution which is a pretty good Pro list.
      I think my comments and discusses around 4.6 supports Robert Sparks discuss that the solution does not come without issues.

    Telechat:

  2. Rbridges: Base Protocol Specification (Proposed Standard)
    draft-ietf-trill-rbridge-protocol-15
    Token: Ralph Droms
    Note: Erik Nordmark (erik.nordmark@sun.com) is the Document Shepherd.
    Discusses/comments (from ballot 3286):
    1. Ross Callon: Discuss [2010-02-18]:
      I would like to discuss during the telechat whether or not we should require two interoperable implementations prior to proposed standard status on a protocol that is this complex. I would be fine with experimental status, or with waiting for two implementations before publishing as proposed standard.
    2. Pasi Eronen: Comment [2010-01-20]:
      I found the document surprisingly well-written and easy to understand (despite the complex topic).
    3. Adrian Farrel: Discuss [2010-02-18]:
      1. Implementation: If this work was in the Routing Area I would consider it sufficiently large to require two independent implementations and would hope for evidence of interoperability. However, it is not, so this Discuss point is to ask the Int ADs to consider whether this work should really go onto the Standards Track with (according to the proto-writeup) no implementations of the current revision.
      2. Scope: I think that, not withstanding the reference to RFC 5556 at the very end of Section 1, I would like to see a clear statement that this document anticipates that the protocol deployment is limited to LANs, and that wider deployment is for further study.
      3. Usage of confidence levels: Per the Routing Area Directorate review by Acee Lindem, one major issue seems to be still open.
      The document should explain the philosophy and usage of confidence level with respect to the {port, VLAN, MAC address} tuples.
    4. Adrian Farrel: Comment [2010-02-18]:
      Please close on the minor comments and nits raised in Acee Lindem's Routing Area Directorate review.
    5. Tim Polk: Discuss [2010-02-17]:
      discuss-discuss: do we need to establish IANA registries for the Version (V) and Reserved (R) bits in sections 3.2. and 3.3? Since each field is only two bits, it seems important to ensure that IETF standards action be required to allocate new values.
    6. Tim Polk: Comment [2010-02-17]:
      Stylistic quibbles with section 3: ...
      Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3], are there any constraints on Op-length to ensure that the 64 alignment is maintained? (Found the answer in section 4, but wonder if it should be mentioned earlier!)
      Section 3.7.3, fourth bullet, first sentence: Sorry to nitpick, but should we explicitly state that when the most significant bit is set to 1, this indicates the nickname value was configured?
      Section 4.1.1, first paragraph after Figure 4.2: Another Nit, but if RBridges are permitted to support a subset of the VLAN IDs, couldn't we have a situation where two implementations supported disjoint ranges and were not interoperable?
      Section 4.1.3, second paragraph first sentence: Shouldn't this sentence state that TRILL frames forwarded by a transit RBridge use the priority present in the Outer.VLAN tag as received?

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. DNS SRV Resource Records for AFS (Proposed Standard)
    draft-allbery-afs-srv-records-04
    Token: Alexey Melnikov
    Note: Jeffrey Hutzelman (jhutz at cmu dot edu) is the document shepherd.
    After discussing this with Jari I am thinking that the normative downreference to RFC 1183 (Experimental) is Ok in this case. Note that this downref was explicitly called out in the IETF LC announcement.

    Discusses/comments (from ballot 3306):
    1. Lars Eggert: Comment [2010-02-16]:
      Section 4., paragraph 8: Are AFS cell names required to be valid domain names?
    2. Adrian Farrel: Comment [2010-02-18]:
      I support Tim's Discuss and note further that RFC 1183 says... "This memo defines five new DNS types for experimental purposes..." This
      Isn't the correct thing to do here to obsolete RFC 1183 rather than updating some bits and deprecating other bits?
    3. Tim Polk: Discuss [2010-02-16]:
      I would like to consider whether this document should be standards track or informational. It feels informational to me.
    4. Robert Sparks: Discuss [2010-02-16]:
      The following sentence (from the end of page 5) needs clarification "This server ordering MAY be done either per call or for the lifetime of the DNS SRV RR information".
      It's not clear what "call" means in this context... If the intent was, instead, to note that the implementation could rerun the weighted-selection algorithm without re-querying DNS, that should be stated more clearly.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. ICMP attacks against TCP (Informational)
    draft-ietf-tcpm-icmp-attacks-10
    Token: Lars Eggert
    Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
    Discusses/comments (from ballot 2030):
    1. Alexey Melnikov: Comment [2010-02-18]:
      Should [I-D.ietf-tsvwg-port-randomization] reference be Normative?
    2. Tim Polk: Discuss [2010-02-17]:
      discuss-discuss: The working group summary in the IESG writeup states "The WG did not reach consensus that the IETF should recommend the mitigation techniques documented in this document due to a number of associated drawbacks, although some of the these techniques are widely implemented in popular TCP stacks."
      Perhaps I am missing something, but I did not see any documentation of the associated drawbacks. I think that is important for this document.
    3. Tim Polk: Comment [2010-02-17]:
      section 7.3.2, figure 3 line 2: DATA size should be 1460, not 1500
      Section 7.3.5, figure 6 line 8: for this example, shouldn't TCPseq#=201 or 301?
    4. Dan Romascanu: Discuss [2010-02-18]:
      "Most of the these counter-measures can be implemented while still remaining compliant with the current specifications, as they simply describe reasons for not taking the advice provided in the specifications in terms of "SHOULDs", but still comply with the requirements stated as "MUSTs"."
      Why only 'most' and not 'all'? Which are the exceptions? I could not find anything in the counter-measures description excepting maybe the ambiguity in the specification about ICMP message type 3 code 3 described in 5.1 and 5.2. Are there other that I missed? Should not this be explained in a more detailed manner?
    5. Magnus Westerlund: Comment [2010-02-18]:
      Section 7.1: Actually the reported MTU can be lower than 1280. The proper response if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation header.

    Telechat:

  2. Location Hiding: Problem Statement and Requirements (Informational)
    draft-ietf-ecrit-location-hiding-req-02
    Token: Cullen Jennings
    Discusses/comments (from ballot 2959):
    1. Jari Arkko: Comment [2010-02-17]:
      Req-3: "The solution MUST offer automated discovery of servers and other behavior, i.e., no manual configuration can be assumed."
      I am confused by the phrase "other behaviour" in this context.
    2. Russ Housley: Discuss [2010-02-16]:
      The Gen-ART Review by Ben Campbell on 16 Feb 2010 raised one question that ought to be addressed. In the first bullet of Section 3.3, the MUST in a section entitled "Desirable Properties" is confusing.
    3. Russ Housley: Comment [2010-02-16]:
      Ben also raised some editorial questions, please consider them.
    4. Alexey Melnikov: Comment [2010-02-14]:
      This document only has 1 normative reference which is RFC 2119. I don't believe this is correct, several other references are needed to properly understand requirements.
    5. Tim Polk: Discuss [2010-02-18]:
      it seems that these requirements should be in addition to the requirements specified in [I-D.ietf-geopriv-lbyr-requirements]. The document does not say that anywhere, and the specification of [I-D.ietf-geopriv-lbyr-requirements] as informative adds to my confusion.
    6. Dan Romascanu: Discuss [2010-02-18]:
      Req-6: "The solution MUST work if PSAP boundaries have holes."
      I do not see how the requirement can be understood without understanding the concept of holes in PSAP or LoST service boundaries. This being a MUST requirement it looks to me like [I-D.ietf-ecrit-specifying-holes] should be a Normative rather than Informative reference.

    Telechat:

  3. PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) (Informational)
    draft-ietf-pce-p2mp-req-05
    Token: Ross Callon
    Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3322):
    1. Tim Polk: Comment [2010-02-18]:
      (empty)
      Should the second occurrence of PCC be PCE? To be clear, I am confused as to who chooses the format...

    Telechat:

  4. MPLS-TP Network Management Framework (Informational)
    draft-ietf-mpls-tp-nm-framework-04
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    Discusses/comments (from ballot 3323):
    1. Russ Housley: Comment [2010-02-14]:
      The Gen-ART Review by Pete McCann on 2010-02-05 raises two points that should be considered
    2. Tim Polk: Discuss [2010-02-18]:
      This discuss is a placeholder to ensure that some enhancements to the security considerations (identifed based on the secidr review) are not forgotten.
    3. Dan Romascanu: Discuss [2010-02-18]:
      1. I was expecting to find some text describing the relationship between the management framework and the OAM framework. How are for example OAM services configured by management. How can OAM messages be used to fill in status or performance information?
      2. I find the performance management section changed to less than minimum and missing important information. I am confused by the definition of pro-active management - does this mean management performed by synthetic traffic generated for PM purposes? If this is ITU-T terminology I would like to see a reference. If we are talking about the need to limit reporting information, then the method of thresholding performance management objects (e.g. counters) and sending alerts in cases of exceptions is well known and deployed in IETF standards (see RMON and RMON-2) - I think that it should be mentioned. Also, in the last exchange with Eric Gray hementioned adding a statement to the effect that an MPLS-TP NE MUST support collection of loss and delay measurement data. I do not see this in the current version.
      3. In the Security Considerations section the issue of authorizing access to the management information does not apply only to protect against eavesdropping, but also or especially to defend against mis-configuration or mal-configuration. Also, the reference to Section 4.3 of the Security Framework for MPLS and GMPLS Networks refers to OAM traffic but not to management traffic. If that analysis and the security practices apply also to management traffic this needs to be said explicitly.
    4. Magnus Westerlund: Comment [2010-02-18]:
      Section 7.1: Actually the reported MTU can be lower than 1280. The proper response if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation header.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support (Informational)
    draft-zorn-radius-pkmv1-10
    Token: Dan Romascanu
    Discusses/comments (from ballot 3148):
    1. Pasi Eronen: Discuss [2010-02-17]:
      Section 6: "this document does not define a method for doing so securely" sounds very strange, because the next sentence does define a recommended method for doing exactly that.
      That method is IMHO fine... but since it's a key part of the specification, the use of this attribute should be described in e.g. Section 3, and it should be listed in Section 4.
    2. Pasi Eronen: Comment [2010-02-17]:
      Sections 3.1/3.2 say "It is possible that the size of the SS/CA certificate may exceed the maximum size of a RADIUS attribute".
      A certificate compliant with 802.16-2004 is always longer than 255 bytes, so perhaps something like "the size usually exceeds" (or "the size exceeds") would be more accurate.
    3. Adrian Farrel: Discuss [2010-02-18]:
      I don't understand why it is Informational. It seems to define stuff for implementation, and it seems to do that defining within the IETF (i.e. it is not a report of work done elsewhere).
    4. Tim Polk: Discuss [2010-02-18]:
      I have concerns about the hard size limits for two of the attributes.

    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)

1304 EST break

1309 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Session Recording Protocol (srp)
    Token: Cullen

    Telechat:

  2. Constrained RESTful Environments (core)
    Token: Lisa

    Telechat:

4.1.2 Proposed for Approval

  1. Keying and Authentication for Routing Protocols (karp)
    Token: Ross

    Telechat:

  2. Peer to Peer Streaming Protocol (ppsp)
    Token: Lars

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. ADSL MIB (adslmib)
    Token: Dan

    Telechat:

4.2.2 Proposed for Approval

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

    Telechat:

  2. Inter-Domain Routing (idr)
    Token: Ross

    Telechat:

5. IAB News We can use

  1. DaveO: IAB statement RPKI... trust anchor...
  2. Ross: quite a bit of comment on mailing-lists
  3. DaveO: not clear to me this affects the WG at all; second thing, we confirmed IESG slate; couple of documents nearing completion; we're inviting new IAB members to our next meeting; I'm stepping down an IESG liaison; I'll do the best I can passing the torch (don't know when you'll have new liaison)
  4. Dan: when will the IAB decide on who the new liaison to the IESG will be?
  5. DaveO: we attempt to name new liaison when we impanel the IAB
  6. Ross: hard to delay it... new IAB seated _during_ Anaheim
  7. DaveO: I'm not going to try to push it

6. Management Issues

  1. Registration of media type application/iptv_rtsp (Alexey Melnikov)

    Telechat:

  2. Expert for RFC 5563 [IANA #299221] (Michelle Cotton)

    Telechat:

  3. Expert for draft-nottingham-http-link-header [IANA #294442] (Michelle Cotton)

    Telechat:

  4. Independent Submissions -- IESG Notes Review (Sandy Ginoza)

    Telechat:

  5. Media type registration: application/iptv_rtsp (Robert Sparks)

    Telechat:

  6. netlmm ipv4 doc re-review (Jari Arkko)

    Telechat:

  7. 77th Agenda (Wanda Lo)

    Telechat:

  8. Multicast Expert (Michelle)

    Telechat:

7. Agenda Working Group News

1501 EST Adjourned



Appendix: Snapshot of discusses/comments

(at 2010-02-18 08:30:40 PST)

draft-ietf-geopriv-lis-discovery

  1. Jari Arkko: Comment [2010-02-18]:
    I support the Lars/Ralph Discuss, and the way to resolve that is to get
    the review the DHC WG. Our process for DHCP option development is to
    host it in the "user" working group (such as GEOPRIV), but run
    simultaneous WGLCs also in DHC WG. This ensures that both the use case
    and DHCP encoding is done correctly.
  2. Ralph Droms: Discuss [2010-02-17]:
        Following up on Lars' DISCUSS, the current version of the spec has not, as far
    as I know, been reviewed by the dhc WG.  I've asked the WG chairs for their
    review and feedback.  The syntax of the options is modeled on and compatible
    with the syntax of other options that carry DNS names or FQDNs, so I anticipate
    that the syntax will be acceptable. 
        
  3. Ralph Droms: Comment [2010-02-17]:
    
        
  4. Lars Eggert: Discuss [2010-02-16]:
        
    Section 3.1., paragraph 0:
    > 3.1.  Domain Name Encoding
    
      DISCUSS: This discuss can probably be cleared up quickly. I'm
      surprised to see a DHCPv4/6 option standardized out of GEOPRIV. Has
      the DHC WG reviewed this? 
        
  5. Lars Eggert: Comment [2010-02-16]:
    Section 2., paragraph 1:
    >    A device that has multiple network interfaces could potentially be
    >    served by a different access network on each interface, each with a
    >    different LIS.  The device SHOULD attempt to discover the LIS
    >    applicable to each network interface, stopping when a LIS is
    >    successfully discovered on any interface.
    
      What if I have multiple access interfaces connected to multiple
      operators, all of which operate LIS servers that satisfy the criteria
      for use? According to the outlined procedure, I'd only ever use one of
      them. Does it truly not matter which LIS I use? How does this
      procedure intersect with what the MIF WG is doing?
    
    Section 5., paragraph 2:
    >    methods are described here that can limit the probablity of, or
    
      Nit: s/probablity/probability/
  6. Pasi Eronen: Discuss [2010-02-18]:
        I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
    concern that I'd like to discuss before recommending approval of the
    document:
    
    While relying on DHCP seems unavoidable here, normally HTTPS does not
    rely on DNS to work securely. I'd like to see a better rationale for
    ignoring important security advice from the NAPTR specifications (most
    of Section 8 of RFC 3958). "More compatible with existing HTTP client
    software" seems rather vague, especially considering we're talking
    about new HELD client software, and not e.g. existing web browsers.
    
    LoST (RFC 5222) did use this approach, too, but only after concluding
    that the approach recommended in RFC 3958 would not have worked well
    in that particular context (where large number of inputs map to a
    very small number of LoST servers, and the LoST server is not even 
    aware of all the possible inputs). Here the situation seems quite 
    different: the location server needs to be aware of the access networks
    that have delegated to it (in order to properly determine the location). 
        
  7. Pasi Eronen: Comment [2010-02-18]:
    The regexp in Section 4 is wrong; "*." should be ".*"
  8. Adrian Farrel: Discuss [2010-02-18]:
        A relatively small Discuss that I hope will cause you no trouble.
    
    It might be valuable to note that there could be more than one LIS
    for any access network and that the device makes the choice based on
    local policy.
    
    In particular, in step 2 of figure 1 the result may be more than one
    URI. Or the "N" path from step 3 should return to step 2. 
        
  9. Adrian Farrel: Comment [2010-02-18]:
    Section 2.2 begins
    
       A Device MUST avoid performing LIS discovery over a VPN network
       interface unless discovery on other interfaces is unsuccessful.  A
       LIS discovered in this way is unlikely to have the information
       necessary to determine an accurate location.
    
    I find this use of RFC 2119 a little vague. In trying to parse it, I
    think I concluded...
    
       A device MUST NOT attempt LIS discovery over a VPN network interface
       until it has attempted and failed to perform discovery on all other
       non-VPN interfaces. A device MAY perform discovery over a VPN network
       interface if it has first attempted discovery on non-VPN interfaces, 
       but a LIS discovered in this way is unlikely to have the information
       necessary to determine an accurate location.
    
    Note s/Device/device/
    
    ---
    
    Nits:
    
    Section 1
    
       for providing that location information to devices with an access
       network.  The LIS uses knowledge of the access network and its
    
    This is hard to parse and it is only when we get to the definitions 
    later that we discover it means:
    
       for providing that location information to devices with attached
       access networks used to provide Internetr access.  The LIS uses
       knowledge of the access network and its
    
    ---
    
    Section 1.1
       The bulk of DHCP information is largely static
    
    That looks like a double vagueness :-)
    Either
       The bulk of DHCP information is static
    Or
       The DHCP information is largely static
  10. Alexey Melnikov: Discuss [2010-02-13]:
        This is a fine document, I only have one issue that I would like to discuss
    before recommending its approval:
    
    2.  LIS Discovery Procedure
    
       A device MUST support discovery using the access network domain name
       DHCP option (Section 3) as input to U-NAPTR resolution (Section 4).
       If this option is not available, DHCPv4 option 15 [RFC2132] is used.
    
    I would like to see more justification of why the option 15 is not
    acceptable/sufficient for LIS discovery.
    
       Other domain names MAY be used, as described in Section 3.4. 
        
  11. Alexey Melnikov: Comment [2010-02-13]:
    1.  Introduction and Overview
    
       This document describes a process that a device can use to discover a
       LIS.  This process uses a DHCP option and the DNS.  The product of
       this discovery process is an http: or https: URI, which identifies a
    
    URI schemes need references to the correponding RFCs.
    
       LIS.
  12. Tim Polk: Comment [2010-02-18]:
    I support Pasi's discuss, which addresses the same issue as my comment, but more
    concisely
    and eloquently.  I have retained the text of my comment, since authors
    may want to read this
    with Pasi's discuss.
    
    The security considerations paragraph on "https:" URIs does a nice job of
    explaining the 
    rationale for the differences with RFC 3958 (compatibility with
    existing client software) but
    fails to explain the security ramifications.
    
    Specifically, the authentication process authenticates the LIS against the
    output of the 
    U-NAPTR process, but does not verify that the discovery process
    identified an LIS that is
    appropriate for the requested domain.  If the attacker
    has compromised stages 1 or 2, the
    process provides an authenticated connection
    to the attacker's rogue LIS.  If the process
    satisfied the requirements from
    3958, the https connection would authenticate the LIS
    against the domain name
    used as input to the U-NAPTR process.  An attacker would need to
    compromise
    stage 1 (and provide a falsified domain name) to succeed and the
    vulnerability
    of the DNS would not be an issue.
  13. Robert Sparks: Discuss [2010-02-16]:
        I've been following this document closely, and support its publication. I've
    spotted two things in a final review that I think need attention.
    
    1) The document currently places requirements on a LIS implementation (in
    section 2.2 paragraph 2). This is out of place in this document. I think this
    should point to the guidance in HELD instead. (Non-normative reinforcement of
    the guidance in HELD would make sense here).
    
    2) I encourage adjusting the language at the beginning of section 2.1.
    The group
    put effort into discussing this point, and the resulting changes in the document
    don't leave the first sentence standing well on its own. In particular,
    deployments with residential gateways that are doing the right things with DHCP
    option 15 won't run into the trouble the sentence originally was calling out.
    Here is some proposed alternate text for that first paragraph:
    
       The options available in residential gateways will affect the
       success of this algorithm in residential network scenarios.
       A fixed wireline scenario is described in more detail in Section 3.1 of
       [I-D.ietf-geopriv-l7-lcp-ps].  In this fixed wireline environment an
       intervening residential gateway exists between the device and the
       access network.  If the residential gateway does not provide the
       appropriate information to the devices it serves, those devices 
       are unable to discover a LIS. 
        
  14. Robert Sparks: Comment [2010-02-16]:
    
      

draft-ietf-geopriv-geo-uri

  1. Jari Arkko: Discuss [2010-02-18]:
        This is a GREAT document, and much needed. Thank
    you for writing it!
    
    I will ballot Yes, however, there was one small issue
    that I wanted to draw your attention to first:
    
       Like other new URI schemes, the 'geo' URI requires support in client
       applications.  Users of applications which are not aware of the 'geo'
       scheme are likely not able to make direct use of the information in
       the URI. 
    
    This ignores IMO a very important client application: passing Geo
    URIs around from one place to another. A client need not understand
    the format to do it. 
        
  2. Jari Arkko: Comment [2010-02-18]:
    
        
  3. Lisa Dusseault: Discuss [2010-02-18]:
        I didn't find an expert review in email or in the document history.  Was one
    done?  RFC4395 requires expert review even for URI schemes registered in IETF
    consensus documents.  I believe it hasn't been done because there's no
    provisional entry for geo in the IANA schemes table.
    
    It seems that the ability to have different forms is a requirement to give
    flexibility.  However, that requirement weakens the ability of the URI to be
    compared to see if two people are at the same or nearby location.  Can the
    preference for WGS-84 be explained in those terms to implementers?  If
    implementers prefer WGS-84, then comparison will be possible more frequently.
    
    Similarly, is there a possible way to limit 'u' so that the URIs are more
    frequently comparable?  I'm making up stuff at this point, but lets say there's
    a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and
    100m uncertainty.  If those classes of devices used those values rather than an
    uncertainty of 7.4m or 14m, then u values would match up more frequently.
    
    The "/" looks like it can be used in parameters.  We should check the URI spec
    but I believe that is not recommended.
    
    "Future specifications of additional parameters
       might allow the introduction
    of non-ASCII values."
     --> It should be stated that these would have to be
    ASCII-encoded in some way.  GEO URI handling libraries should know up front what
    character ranges to expect, and the ABNF currently defines that as ASCII only.
    The additional of an optional parameter with Unicode values needn't break that
    if the Unicode values are encoded in an appropriate ASCII encoding.
    
    Final point:  I found some excellent advice here:
    http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
    "Provide more examples of actual URIs or URNs than you think people will need.
    Along with an example, explain how that example would be assigned, derived, and
    if applicable, dereferenced."
    
    At present, the spec only contains one minimal example of URIs.  URI schemes are
    often implemented by people who just scan examples and infer how to interpret
    them (or at best, read a couple paragraphs where they can't just guess) so it's
    important to include examples of optional parameters and of comparison. 
        
  4. Lisa Dusseault: Comment [2010-02-18]:
    
        
  5. Lars Eggert: Discuss [2010-02-16]:
        
    Section 3.4.4., paragraph 1:
    >    Two 'geo' URIs are equal when they use the same CRS, and <coord-a>,
    >    <coord-b>, <coord-c> and 'u' value are mathematically identical
    >    (including absent <uval> meaning undefined 'u' value).
    
      DISCUSS: According to this definition, two locations with the same
      coord-a, coord-b and coord-c but different uncertainty parameters will
      NOT be identical. Isn't that counter-intuitive? (I'm guessing that the
      uncertainty parameter is expected to be set based on the positioning
      method.) A more intuitive definition of equivalence would declare two
      locations equal when their  uncertainty spaces intersect.
    
    Section 3.4.4., paragraph 5:
    
    >    A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be
    >    considered equal to a URI containing a <coord-c>, even if the
    >    remaining <coord-a>, <coord-b>, and their 'u' values are equivalent.
    
      DISCUSS: What if the given coord-c is identical to the altitude of the
      Earth's physical location at the given latitude and longitude; are the
      two identical then? (They should be according to the interpretation
      rules in Section 3.4.5.)
    
    Section 9.1., paragraph 1:
    
    >    The URI syntax (Section 3.3) makes it possible to construct 'geo'
    >    URIs which don't identify a valid location.  Applications MUST NOT
    >    use URIs with such values, and SHOULD warn the user when such URIs
    >    are encountered.
    
      DISCUSS: Then please either tighten the ABNF so that it does not allow
      to express invalid locations (preferred), or otherwise specify which
      locations are valid and which are not. 
        
  6. Lars Eggert: Comment [2010-02-16]:
    
        
  7. Alexey Melnikov: Discuss [2010-02-18]:
        This is a good document and I will be voting Yes once my issues (which are
    mostly minor) are resolved/discussed:
    
    1) 8.2.2.  Registration Policy
    
       The Registration Policy for 'geo' URI Parameters and their value
       definitions shall be "Specification Required, Designated Expert", as
       defined in [RFC5226].
    
    Specification Required already implies Designated Expert.
    I assume registrations
    through Designated Expert (without a specification) are not allowed?
    
    2) 8.3.2.  Registration Policy
    
       The registration policy for the "'geo' URI 'crs' Parameter Values"
       Registry shall be "Specification Required, IESG Approval" as defined
    
    Are "Specification Required" and "IESG Approval" two equal alternatives, or are
    both required at the same time?
    
    3) 11.2.  Informative References
    
       [WGS84]    National Imagery and Mapping Agency, "Department of
                  Defense World Geodetic System 1984, Third Edition",
                  NIMA TR8350.2, January 2000.
    
    This looks like a Normative Reference. 
        
  8. Alexey Melnikov: Comment [2010-02-18]:
    1) The URI registration template is missing the "Security considerations"
    section.
    
    2)
                 crslabel      = "wgs84" / labeltext
    
    Just to double check: these are case-insensitive?
    
    I am also agreeing with Robert's comment which is similar. Note that case-
    insensitivity affects how URIs are compared for equality.
    
    3)
                 pnum          = 1*DIGIT [ "." 1*DIGIT ]
                 num           = [ "-" ] pnum
    
    So you want "-0" to be valid?
    If yes, please state that explicitly in the document.
    
    4)
    8.3.1.  Registry Contents
    
       o  Reference to the definition of the CRS itself, preferably as well
          known URNs (if available).
    
    This sentence is not readable, especially the part after the comma.
    Did you mean ", preferably together with known URNs (if available)"?
    
    5)
    9.2.  Location Privacy
    
       A 'geo' URI by itself is just an opaque reference to a physical
       location, expressed by a set of spatial oordinates.  This does not
    
    typo: coordinates
  9. Tim Polk: Discuss [2010-02-16]:
        Section 5 states that just one operation is defined: location dereference.
    However, section 3.4.4
    describes URI comparison rules.  Perhaps I am missing
    something, but that seems like two
    operations to me.  Perhaps I misunderstand
    "operation" in this context?
    
    (I will clear on the call regardless of how the sponsoring AD wants to resolve
    this.) 
        
  10. Tim Polk: Comment [2010-02-16]:
    
        
  11. Robert Sparks: Discuss [2010-02-16]:
         
        
  12. Robert Sparks: Comment [2010-02-16]:
    Please add an explicit statement on whether case is sensitive when comparing
    parameter names and values.

draft-ietf-ccamp-gmpls-dcsc-channel-ext

  1. Alexey Melnikov: Comment [2010-02-14]:
    3.1. Generalized Channel_Set LABEL_REQUEST Object
    
       The Generalized Channel_Set LABEL_REQUEST object is used to indicate
       that the Generalized Channel_Set LABEL Object is to be used with the
       associated LSP.  The format of the Generalized Channel_Set
       LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST
       object
    
    But Section 3.2 says that it is "based on" the latter?
    
       and uses a C-Type of TBA.
    
    3.2. Generalized Channel_Set LABEL Object
    
       The Channel_Set Sub-Object size is measured in bytes and MUST always
       be a multiple of 4, and at least 4, and has the following format:
    
    Question: how can one determine size of a Channel_Set Sub-Object?
  2. Dan Romascanu: Comment [2010-02-16]:
    Nevil Brownlee made the following comment in his OPS-DIR review: 
    
    'The text: section 3.3 says: "As such the formats of the other label related
    objects are also impacted."
    It doesn't say anything about how they'd be
    impacted, and it's not obvious to me why there should be any such impact.
    Maybe
    a few words to clarify that would be useful?'
    
    I believe that Nevil is correct and the impact on the format of other label
    related objects is unclear.
  3. Magnus Westerlund: Discuss [2010-02-18]:
        Section 3.2:
    
    Note that the size of the sub-object may result in a
             Path message being larger than a single unfragmented IP packet.
             See section 4.4 for an example of how this case may be handled.
    
    This is likely a trivial discuss to resolve. However, I do like to know what the
    recommendation is on handling fragmentation is. But the reference points into
    the void. So please fix the reference and I will review the actual text you are
    pointing on. If you don't have anything on how to handle fragmentation I would
    like to discuss the necessity for it. 
        
  4. Magnus Westerlund: Comment [2010-02-18]:
    
      

draft-ietf-dhc-dhcpv4-vendor-message

  1. Jari Arkko: Comment [2010-02-18]:
    I do not object to this document going forward, but I support the
    Robert Sparks Discuss about better guidance (and perhaps even some
    mandatory rules).
    
    Furthermore, upleveling a bit, I think we need to ask why we are doing
    this document. Is this a companion document to the other proposals that
    I am getting for ND option vendor extensions? When I pushed for the
    actual reason to do them, the answer ended up being "because there are
    some BBF extensions that we need but would probably not go through the
    IETF". Some of such usage is useful stuff that simply has to be specified
    and some is questionable (think DHCP authentication).
    
    However, vendor specific options/messages are not the only way to do
    these extensions. Here's a couple of other options:
    
    - SDO-specific container for their things (and this cannot then easily
      be used by vendor extensions. i'm not sure I *want* vendor extensions
      to DHCP state machine to begin with, though).
    
    - SDO-specific extension for particular functionality that we just 
      approve and hold our nose (and then this cannot be used for any
      extensibility later).
    
    - Generic SDO extension
    
    - Generic extension for vendors and SDOs
    
    Your preferences may vary with regards to the best approach here. I'm
    personally happiest with the first two options.
    
    In any case, I would like to understand better the real drivers behind
    this work.
  2. Pasi Eronen: Discuss [2010-02-16]:
        I have reviewed draft-ietf-dhc-dhcpv4-vendor-message-01, and have one
    small question that I'd like to discuss before recommending approval
    of the document:
    
    Section 1 says "New message codes are assigned through IETF Standards
    Action". According to the registry and RFC 2939, the policy is
    currently "IETF Consensus" -- is this just a typo, or is the intent to
    change the policy? 
        
  3. Pasi Eronen: Comment [2010-02-16]:
    
        
  4. Adrian Farrel: Discuss [2010-02-13]:
        I think adding a vendor-specific message to DHCP is a fine thing to do.
    
    However, I have a relatively minor issue with the current text. I don't think it
    is correct to suggest that a purpose of this is experimentation. Experiments are
    not supposed to escape into the wider Net and an experimental message would be
    treated differently from a vendor-specific message.
    
    While it is true that a vendor may choose to experiment under their enterprise
    number, the fact that it is an experiment is actually hidden from the world, and
    we don't consider listing all of the other uses to which this message might be
    put.
    
    I would be happy to see the reference to experimentation removed from the
    Abstract and the Introduction. 
        
  5. Adrian Farrel: Comment [2010-02-13]:
    I support Alexey's Discuss wrt mandating the behavior of non-supporting nodes.
    You cannot do that and must refer back to the standard processing of unknown
    messages.
    
    In section 4 you have:
          option-len          5 plus the length of the vendor-option-data.
    I think this should s/vendor-option-data/option-data/
    
    Section 1 says:
       DHCPv4 [RFC2131] specifies a mechanism for the assignment of
    addresses and configuration information to nodes.  The protocol
       provides for
    256 possible message codes, of which a small number are
       assigned
    ([DHCPv4Params]).  Each of the assigned message codes have
       specific purposes.
    New message codes are assigned through IETF
       Standards Action.
    If I am not
    mistaken, the registry and RFC 2939 say "IETF Consensus". I don't think this
    changes your work, but you need to fix the document.
  6. Russ Housley: Discuss [2010-02-14]:
        
      Two concerns were raised in the Gen-ART Review by Elwyn Davies
      that need to be addressed:
    
      s3, para 3: This paragraph contains weasel words about 'good
      networking practices' that 'MUST be used'.  This is untestable
      as it stands.  Is this anything more than dealing with non-replies,
      not flooding the network with repeats, and not hanging up if the
      partner never does answer?  Also, servers or clients that do not
      (yet) implement this capability do not have a defined behaviour
      when receiving this new type of message.  There is a assumption
      that they will be silently dropped without causing any problems.
    
      s7 and s4, next to last para: s4 specifies RFC 3396 as 'MUST support'
      This makes RFC 3396 a normative reference, not informative.  Arguably
      the last para of s4 makes RFC 3925 normative as well. 
        
  7. Russ Housley: Comment [2010-02-14]:
      s4, top of page 5: 'Option codes 0 and 255 have no pre-defined
      interpretation or format':  This comment (duplicated from RFC 3925)
      is confusing to the uninitiated reader.  If I understand correctly,
      this is intended to contrast with the 'basic' options in DHCPv4 where
      options 0 and 255 are 'special' - i.e. no length code.  I suggest
      adding at the beginning of the sentence: 'Unlike option codes in
      DHCPv4 [RFC2131], option codes 0...'.
  8. Alexey Melnikov: Discuss [2010-02-13]:
        I generally don't object to this document going forward, however I believe there
    are some minor points that needs to be addressed/discussed first:
    
    1) In Section 3
    
       Clients and servers MAY chose to support this message; those that do
       not, MUST discard the message.  Relay agents SHOULD relay these
       messages as they would other DHCPv4 messages unless the relay agent
       understands the specific message and knows that the message was
       directed at it.
    
    This sounds as if this document is trying to put requirements on implementations
    that are not compliant with this document.
    Is this section just describes
    something which follows from DHCPv4
    extensibility rules?
    
    2) In Section 4:
    
       The option-data field MUST be encoded as a sequence of code/length/
       value fields of identical format to the DHCP options field and is
       identical to the option-data field of Vendor-Identifying Vendor
       Options [RFC3925].
    
    This reference looks Normative to me.
    
       The option codes are defined by the vendor
       identified in the enterprise-number field and are not managed by
       IANA.  Option codes 0 and 255 have no pre-defined interpretation or
    
    Are you talking about subopt-code here?
    
       format.  Each of the encapsulated options is formatted as follows:
    
    3) In Section 4:
    
       Clients, relay agents, and/or servers supporting the Vendor Message
       Option MUST support [RFC3396].
    
    This reference looks Normative to me. 
        
  9. Alexey Melnikov: Comment [2010-02-13]:
    In Section 3:
    
       Applications using these messages MUST NOT assume that all DHCPv4
       clients, relay agents, and servers support them and MUST use good
       networking practices when transmitting and retransmitting these
       messages.
    
    The second MUST almost raises to the level of DISCUSS.
    What are the good practices you are talking about and is the following
    sentence describes one of them:
    
       For some applications, it may be appropriate to use
       Vendor-Identifying Vendor Options [RFC3925] in a standard DHCPv4
       exchange to negotiate whether the end-points support the vendor-
       specific message.
    
    ? If not, then it is not clear how this MUST can be satisfied.
    In that case you need a reference here.
  10. Tim Polk: Comment [2010-02-16]:
    (1) I support Adrian's discuss regarding experimentation.
    
    (2) I support Alexey's discuss regarding section 3 imposing requirements on
    clients that do not
    implement this specification.  If that is the intention,
    shouldn't this specification update 2131?
  11. Dan Romascanu: Discuss [2010-02-16]:
        Section 4 - the document specify that option-len and subopt-len are expressed in
    octets 
        
  12. Dan Romascanu: Comment [2010-02-16]:
    1. I support Adrian's DISCUSS that mentioning experimental purposes is not
    appropriate.
    
    2. I support Russ's DISCUSS that 'MUST use good networking practices' includes a
    too vague construct ('good networking practices') for a mandatory to implement
    statement.
    
    3. The IANA considerations section should note that the the document makes use
    of the IANA enterprise id numbers registry. While this is mentioned previously
    in the document (in Section 4) it is not noted in the IANA considerations
    section. While no specific action item is requested of IANA it is a
    consideration.
  13. Robert Sparks: Discuss [2010-02-17]:
        Should this document contain (or point to) more guidance that would encourage
    the use and development of interoperable DHCP options? It is currently missing
    any pressure to discourage the replication of already standardized behavior and
    encourage bringing common functionality through the standards process. 
        
  14. Robert Sparks: Comment [2010-02-17]:
    
      

draft-ietf-dhc-dhcpv6-vendor-message

  1. Jari Arkko: Comment [2010-02-18]:
    See my comment in the DHCPv4 companion document.
  2. Adrian Farrel: Discuss [2010-02-13]:
        My Discuss is identical to the issue I raised for draft-ietf-dhc-dhcpv4-vendor-
    message.
    
    I think adding a vendor-specific message to DHCP is a fine thing to do.
    
    However, I have a relatively minor issue with the current text. I don't think it
    is correct to suggest that a purpose of this is experimentation. Experiments are
    not supposed to escape into the wider Net and an experimental message would be
    treated differently from a vendor-specific message.
    
    While it is true that a vendor may choose to experiment under their enterprise
    number, the fact that it is an experiment is actually hidden from the world, and
    we don't consider listing all of the other uses to which this message might be
    put.
    
    I would be happy to see the reference to experimentation removed from the
    Abstract and the Introduction. 
        
  3. Adrian Farrel: Comment [2010-02-13]:
    I also support Alexey's Discuss on this document. This work should not attempt
    to define procedures for non-supporting nodes, but must reference the base spec.
  4. Russ Housley: Discuss [2010-02-14]:
        
      s3, para 3: This paragraph contains weasel words about 'good
      networking practices' that 'MUST be used'.  This is untestable
      as it stands.  Is this anything more than dealing with non-replies,
      not flooding the network with repeats, and not hanging up if the
      partner never does answer?  Also, servers or clients that do not
      (yet) implement this capability do not have a defined behaviour
      when receiving this new type of message.  There is a assumption
      that they will be silently dropped without causing any problems. 
        
  5. Russ Housley: Comment [2010-02-14]:
    
        
  6. Alexey Melnikov: Discuss [2010-02-13]:
        This is similar to one of the DISCUSS issues on draft-ietf-dhc-dhcpv4-vendor-
    message-01.txt. (Note that other issues I raised against draft-ietf-dhc-dhcpv4
    -vendor-message-01.txt are addressed in this document).
    
    1) In Section 3
    
       Clients and servers MAY chose to support this message; those that do
       not, MUST discard the message.  Relay agents SHOULD relay these
       messages as they would other DHCPv6 messages unless the relay agent
       understands the specific message and knows that the message was
       directed at it.
    
    This sounds as if this document is trying to put requirements on implementations
    that are not compliant with this document.
    Is this section just describes
    something which follows from DHCPv6
    extensibility rules? If yes, then rewording
    this paragraph to say "According to [ref] ..." would address my issue. 
        
  7. Alexey Melnikov: Comment [2010-02-13]:
    
        
  8. Tim Polk: Comment [2010-02-16]:
    I support Adrian and Alexey's discuss positions.
  9. Dan Romascanu: Comment [2010-02-17]:
    1. I support Adrian's DISCUSS that mentioning experimental purposes is not
    appropriate.
    
    2. I support Russ's DISCUSS that 'MUST use good networking practices' includes a
    too vague construct ('good networking practices') for a mandatory to implement
    statement.
    
    3. The IANA considerations section should note that the the document makes use
    of the IANA enterprise id numbers registry. While this is mentioned previously
    in the document (in Section 4) it is not noted in the IANA considerations
    section. While no specific action item is requested of IANA it is a
    consideration.
  10. Robert Sparks: Discuss [2010-02-17]:
        (This is a copy of the same comment made for the dhcpv4-vendor-message document)
    
    Should this document contain (or point to) more guidance that would encourage
    the use and development of interoperable DHCP options? It is currently missing
    any pressure to discourage the replication of already standardized behavior and
    encourage bringing common functionality through the standards process. 
        
  11. Robert Sparks: Comment [2010-02-17]:
    
      

draft-ietf-avt-app-rtp-keepalive

  1. Lars Eggert: Comment [2009-10-19]:
    Section 1., paragraph 15:
    >    Note that if a given media uses a codec that already integrates a
    >    keepalive mechanism, no additional keepalive mechanism is required at
    >    the RTP level.
    
      And since redundant keepalives waste bandwidth and energy, do we want
      to say they're NOT RECOMMENDED?
  2. Adrian Farrel: Comment [2010-02-16]:
    Title
    s/maintaining/keeping/
    
    Need to expand acronyms the first time they show up in the document body
    For example, ICE
    
    The "this does not apply to ICE agents" is a bit terse and cryptic. If 
    the reader might not know what an ICE agent is, you should probably 
    describe it. You might also reasonably explain *why* this document 
    does not apply to ICE agents.
  3. Alexey Melnikov: Comment [2009-10-19]:
    This looks like one big hack, but Ok.
  4. Tim Polk: Discuss [2010-02-16]:
        (1) Given that it is declarative (and not subject to negotiation) I do not
    understand the utility
    of the a=rtp-keepalive SDP attribute.  Since the agent
    intends to use this solution if the 
    a=rtcp-mux is not recognized whether the
    rtp-keepalive is recognized or not, it doesn't seem
    to add much value.  Are you
    expecting middleboxes to process this value?  If no entity is
    going to act on
    this information, why send it?
    
    (2) [Similar to Robert's discuss]  I agree that multiplexing RTCP and RTP
    packets is an
    excellent solution.  I also think that incorrect version numbers
    (as specified in 4.5) would be
    a terrible waste, given the limited number of
    possibilities.  The remaining solutions all seem
    to have merit for some
    scenarios, as well as significant drawbacks.  Perhaps it would be better
    to
    recognize multiplexing RTCP and RTP as the recommended solution, forbid the
    incorrect
    version number solution, and let applications pick their poison when a
    =rtcp-mux does not
    appear in the answer.
    
    (3) While a peer is required by RFC 3530 to "ignore packets with payload types
    it does not
    understand", that does not preclude examination by the peer in an
    attempt to determine if
    it is under attack.  Since falling back to the
    alternative indicates the peer is not aware of this
    specification, the Cons for
    section 4.6 should note that the peer may consider the
    keepalive traffic a DOS
    attack and terminate the connection. 
        
  5. Tim Polk: Comment [2010-02-16]:
    
        
  6. Dan Romascanu: Comment [2010-02-17]:
    I support the DISCUSSes from Robert and Magnus.
  7. Robert Sparks: Discuss [2010-02-16]:
        I am happy to see this discussion of ways that have been tried in the past to
    keep NAT bindings alive published. I support the conclusion that multiplexing
    RTCP and RTP is the RECOMMENDED solution and that the other mechanisms are NOT
    RECOMMENDED. However, I think the document's current approach of making falling
    back to sending RTP with an unknown payload type RECOMMENDED is a mistake.
    
    The document argues that this "always works". That is inconsistent with what I
    have observed in the field. We lived through a period where simple un-negotiated
    comfort-noise packets were causing unintended malfunction in several kinds of
    endpoints. It is highly likely that implementations
    seeing a null payload with
    an unsolicited type are going to do something very unexpected.
    
    In general, recommending that elements violate part of a specification because
    some other part of the specification says to ignore that violation is very
    dangerous and will lead to long term interoperability problems. The robustness
    principle being taken advantage of here has two parts - Be conservative in what
    you send ("Don't send things you haven't been told are ok to send") and Be
    liberal in what you receive ("Don't break if the other guy sends you the wrong
    thing") only works when most of the elements do both things. Asking a large part
    of the system to ignore half of that equation removes the robustness.
    
    The same argument this document is making to say it's ok to send these will
    eventually be used by stack or middlebox implementors to drop these packets
    before they get to where they've possibly done any good.
    
    I think this document should keep the discussion of these alternate techniques,
    and even point out that of the alternatives other than multiplexing RTP/RTCP,
    sending unsolicited payload types breaks fewer things. But putting that forth as
    a Proposed Standard way to behave is not the right thing to do. 
        
  8. Robert Sparks: Comment [2010-02-16]:
    
        
  9. Magnus Westerlund: Discuss [2010-02-17]:
        I think there is good value in publishing some of this content. However, some
    things should be addressed prior to the documents approval.
    
    1. RTCP is an integral part of RTP. There are a number of mechanism that doesn't
    work unless also the RTCP flows are kept alive. To me this document can't rule
    RTCP out of scope. It needs to be covered.
    
    And normally it isn't difficult as regular RTCP reports maximum periodic
    interval is shorter than the the bindings. However, there are some important
    configuration considerations that needs to be covered. It will also require
    symmetric usage of RTCP between transport peers.
    
    2. Section 4.6:
    
    This solution does not discuss which SSRC should be used. That has significant
    impact if the solution is possible to use or not. There are a number of RTP
    payload formats that does not handle gaps in RTP sequence number well. T.140
    text is one of these. Thus this solution is only plausible in that case to use a
    different SSRC.
    
    This in its turn has negative impact on one thing. There is implementations that
    are badly implemented in regards to handling multiple SSRC's. They may kill of
    the state for the media sending SSRC. I do agree that they are not standards
    compliant.
    
    3. Section 4:
    In general I am missing a discussion on which solutions results in
    RTCP reporting on the keep-alive packets. At least 4.2 and 4.6 can result in
    reporting on the keep-alive packets. In 4.6 it is not 100% clear what should
    happen so that needs to be made clear to avoid issues.
    
    4. Section 6.1, first paragraph:
    This section is in error. T.140 requires that
    for the SSRC(s) one is using that the sequence number space is continous. If one
    switches to another media format, and do not attempt to use them intermixed it
    can work. Thus, method 4.6 can be used if another SSRC than the ones used to
    transport actual media are used.
    
    I do agree with the second paragraph that for T.140 there is little need to use
    anything else than the idle mechanism.
    
    5. section 5:
    
    What is the interpretation of the a=rtp-keepalive attribute in multicast
    sessions?
    
    6. Section 7: I agree with minimal value for Tr of 15 seconds. It makes sense
    when sent over UDP. However, a significant larger value, like 5 to 15 min makes
    more sense for TCP. This is an area where it is difficult to provide good
    recommendations without considering the underlying transport protocol. 
        
  10. Magnus Westerlund: Comment [2010-02-17]:
    Section 1, first bullet:
    
    I would say that streaming applications is one of the biggest usage of uni-
    directional RTP flows. The failure to mention RTSP and streaming seems strange.
    
    Section 1, bullet 3: To me it appears inaccurate that comfort noise would be
    sent to seldom that a NAT binding would timeout. Can you mention any codec that
    would produce CN with longer interval than 1 second?
    
    Section 3, REQ-9:
    
    This is not a requirement, it is a statement about the world.
    
    Section 4:
    The subsections on the potential solutions does not discuss how they
    meet the requirements.
    
    Section 4.3:
    
    How can it be a con to require SDP signaling when you state in REQ-8 that is
    desirable. In fact only REQ-7 isn't supported by this solution which is a pretty
    good Pro list.
    
    I think my comments and discusses around 4.6 supports Robert Sparks discuss that
    the solution does not come without issues.

draft-ietf-trill-rbridge-protocol

  1. Ross Callon: Discuss [2010-02-18]:
        I think this is important and good work. I would also like to thank the authors
    for completing the last call in the IS-IS working group and adding a normative
    reference to draft-ietf-isis-layer2.
    
    I would like to discuss during the telechat whether or not we should require two
    interoperable implementations prior to proposed standard status on a protocol
    that is this complex. I would be fine with experimental status, or with waiting
    for two implementations before publishing as proposed standard. 
        
  2. Ross Callon: Comment [2010-02-18]:
    
        
  3. Pasi Eronen: Comment [2010-01-20]:
    I found the document surprisingly well-written and easy to 
    understand (despite the complex topic).
  4. Adrian Farrel: Discuss [2010-02-18]:
        This is a mammoth piece of work with a lot of carefully checked detail. Thanks
    for taking the time to check back with the IS-IS working group.
    
    I have three issues for Discussion. The first is targetted only at the Int ADs.
    
    ---
    
    1. Implementation
    
    If this work was in the Routing Area I would consider it sufficiently
    large to
    require two independent implementations and would hope for
    evidence of
    interoperability. However, it is not, so this Discuss point
    is to ask the Int
    ADs to consider whether this work should really go
    onto the Standards Track with
    (according to the proto-writeup) no
    implementations of the current revision.
    Implementation is not just a proof of the correctness of the specification, but
    is a good indicator of whether there is actually a desire for the work.
    
    ---
    
    2. Scope
    
    I think that, not withstanding the reference to RFC 5556 at the very end
    of Section 1, I would like to see a clear statement that this document
    anticipates that the protocol deployment is limited to LANs, and that
    wider deployment is for further study.
    
    ---
    
    3. Usage of confidence levels
    
    Per the Routing Area Directorate review by Acee Lindem, one major issue
    seems to be still open.
    
    >   The document should explain the philosophy and usage of confidence
    >   level with respect to the {port, VLAN, MAC address} tuples. This
    >   discussion should also tie in the confidence configuration in
    >   section 5.1.
    
    Donald Eastlake suggested...
    
    Well, how about something like the following new text:
    
       The confidence level mechanism allows an RBridge campus manager to
       cause certain address learning sources to prevail over others. In a
       default configuration, without the optional ESADI protocol,
       addresses are only learned from observing local native frames and
       the decapsulation of received TRILL data frames. Both of these
       sources default to confidence level 0x20 so, since learning at an
       equal or high confidence overrides previous learning, the learning
       in such a default case mimics default 802.1 bridge learning.
    
       While RBridge campus management policies are beyond the scope of
       this document, here are some example types of policies that can be
       implemented with the confidence mechanism and the rational for
       each:
    
       o  Locally received native frames might be considered more reliable
          than decapsulated frames received from remote parts of the
          campus. To stop MAC addresses learned from such local frames
          from being usurped by remotely received forged frames, the
          confidence in locally learned addresses could be increased or
          that in addresses learned from remotely sourced decapsulated
          frames decreased.
    
       o  MAC address information learned through a cryptographically
          authenticated Layer 2 registration protocol, such as 802.1X with
          a cryptographically based EAP method, might be considered more
          reliable than information learned through the mere observation
          of data frames. When such authenticated learned address
          information is transmitted via the ESADI protocol, the use of
          authentication in the TRILL EASDI LSP frames could make
          tampering with it in transit very difficult. As a result, it
          might be reasonable to announce such authenticated information
          via the ESADI protocol with a high confidence, so it would
          override any alternative learning from data observation.
    
       Manually configured address information is generally considered
       static and so defaults to a confidence of 0xFF while no other
       source of such information can be configured to a confidence any
       higher than 0xFE. However, for other cases, such as where the
       manual configuration is just a starting point which the Rbridge
       campus manager wishes to be dynamically overrideable, the
       confidence of such manually configured information may be
       configured to a lower value. 
        
  5. Adrian Farrel: Comment [2010-02-18]:
    Please close on the minor comments and nits raised in Acee Lindem's
    Routing Area Directorate review.
  6. Russ Housley: Comment [2010-01-17]:
    
        
  7. Tim Polk: Discuss [2010-02-17]:
        This is a discuss-discuss: do we need to establish IANA registries for the
    Version (V) and
    Reserved (R) bits in sections 3.2. and 3.3?  Since each field is
    only two bits, it seems important
    to ensure that IETF standards action be
    required to allocate new values. 
        
  8. Tim Polk: Comment [2010-02-17]:
    Stylistic quibbles with section 3: 
    (1) IMHO, the TRILL header figure should
    include the header Options field.
    (2) Section 3.5 should be renamed "Op-length"
    and should focus on Op-length
    (3) The bulk of the current 3.5 should be moved to
    a new section 3.8 "TRILL Header Options"
    These changes would ensure that the
    figure 3.1 and subsequent list are parallel with
    the remainder of section 3.
    
    Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3],
    are there any
    constraints on Op-length to ensure that the 64 alignment is
    maintained?
    (Found the answer in section 4, but wonder if it should be mentioned
    earlier!)
    
    Section 3.7.3, fourth bullet, first sentence:
    
    Sorry to nitpick, but should we explicitly state that when the most significant
    bit is set to 1,
    this indicates the nickname value was configured?
    
    Section 4.1.1, first paragraph after Figure 4.2
    
    Another Nit, but if RBridges are permitted to support a subset of the VLAN IDs,
    couldn't
    we have a situation where two implementations supported disjoint ranges
    and were not
    interoperable?  Or a I misreading that text?
    
    Section 4.1.3, second paragraph first sentence.
    
    Shouldn't this sentence state that TRILL framesforwarded by a transit RBridge
    use the
    priority present in the Outer.VLAN tag as received?

draft-allbery-afs-srv-records

  1. Lars Eggert: Comment [2010-02-16]:
    Section 4., paragraph 8:
    >        _<service>._<proto>.<name>
    ...
    >    <name> MUST be the AFS cell name for which the identified server
    >    provides AFS services.
    
      Are AFS cell names required to be valid domain names?
  2. Adrian Farrel: Comment [2010-02-18]:
    I support Tim's Discuss and note further that RFC 1183 (which predates 
    the different classifications of RFCs) says...
    
       This memo defines five new DNS types for experimental purposes.  This
       RFC describes an Experimental Protocol for the Internet community,
       and requests discussion and suggestions for improvements.
    
    Isn't the correct thing to do here to obsolete RFC 1183 rather than
    updating some bits and deprecating other bits?
  3. Tim Polk: Discuss [2010-02-16]:
        I will clear on the call after the discussion, but I would like to cosndier
    whether this document
    should be standards track or informational.  It feels
    informational to me. 
        
  4. Tim Polk: Comment [2010-02-16]:
    
        
  5. Dan Romascanu: Comment [2010-02-16]:
    
        
  6. Robert Sparks: Discuss [2010-02-16]:
        The following sentence (from the end of page 5) needs clarification
     "This
    server ordering MAY be done either per call or for the lifetime of the DNS SRV
    RR information".
    
    It's not clear what "call" means in this context. I think the document is trying
    to say that it's an implementation decision on whether to reuse the results of a
    running the weighted-selection algorithm in 2782. If that's the case, I suggest
    more guidance to the implementors on when such reuse is appropriate is needed.
    The load-leveling capabilities the SRV weight field are defeated by reusing the
    results of the calculation.
    
    If the intent was, instead, to note that the implementation could rerun the
    weighted-selection algorithm without re-querying DNS, that should be stated more
    clearly. 
        
  7. Robert Sparks: Comment [2010-02-16]:
    
      

draft-ietf-tcpm-icmp-attacks

  1. Alexey Melnikov: Comment [2010-02-18]:
    Should [I-D.ietf-tsvwg-port-randomization] reference be Normative?
  2. Tim Polk: Discuss [2010-02-17]:
        This is a discuss-discuss.
    
    The working group summary in the IESG writeup states
    
       The WG did not reach consensus that the IETF
       should recommend the mitigation techniques documented in this
       document due to a number of associated drawbacks, although
       some of the these techniques are widely implemented in
       popular TCP stacks.
    
    Perhaps I am missing something, but I did not see any documentation of the
    associated
    drawbacks.  I think that is important for this document.  What do
    others think? 
        
  3. Tim Polk: Comment [2010-02-17]:
    section 7.3.2, figure 3 line 2: DATA size should be 1460, not 1500 (established
    MTU is 1500)
    
    Section 7.3.5, figure 6 line 8: for this example, shouldn't TCPseq#=201 or 301?
    101 has
    already been acknowledged...
  4. Dan Romascanu: Discuss [2010-02-18]:
        I would like to discuss whether the following paragrah does not require more
    specific information:
    
    >  Most of the these counter-measures can be implemented while still
       remaining compliant with the current specifications, as they simply
       describe reasons for not taking the advice provided in the
       specifications in terms of "SHOULDs", but still comply with the
       requirements stated as "MUSTs".
    
    Why only 'most' and not 'all'? Which are the exceptions? I could not find
    anything in the counter-measures description excepting maybe the ambiguity in
    the specification about ICMP message type 3 code 3 described in 5.1 and 5.2. Are
    there other that I missed? Should not this be explained in a more detailed
    manner? 
        
  5. Dan Romascanu: Comment [2010-02-18]:
    
        
  6. Magnus Westerlund: Comment [2010-02-18]:
    Section 7.1:
    
    For IPv6, the
       reported Next-Hop MTU could be as low as 1280 octets (the minimum
       IPv6 MTU) [RFC2460].
    
    Actually the reported MTU can be lower than 1280. The proper response is to send
    if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation
    header.
    
    From section 5 of RFC 2460:
    
       In response to an IPv6 packet that is sent to an IPv4 destination
       (i.e., a packet that undergoes translation from IPv6 to IPv4), the
       originating IPv6 node may receive an ICMP Packet Too Big message
       reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
       is not required to reduce the size of subsequent packets to less than
       1280, but must include a Fragment header in those packets so that the
       IPv6-to-IPv4 translating router can obtain a suitable Identification
       value to use in resulting IPv4 fragments.  Note that this means the
       payload may have to be reduced to 1232 octets (1280 minus 40 for the
       IPv6 header and 8 for the Fragment header), and smaller still if
       additional extension headers are used.

draft-ietf-ecrit-location-hiding-req

  1. Jari Arkko: Comment [2010-02-17]:
    The document says:
    
       Req-3:  The solution MUST offer automated discovery of servers and
       other behavior, i.e., no manual configuration can be assumed.
    
    I am confused by the phrase "other behaviour" in this context. Perhaps
    you should rewrite this to: "... automated discovery of servers and other
    necessary configuration information ..."
  2. Russ Housley: Discuss [2010-02-16]:
        
      The Gen-ART Review by Ben Campbell on 16 Feb 2010 raised one question
      that ought to be addressed.  In the first bullet of Section 3.3, the
      MUST in a section entitled "Desirable Properties" is confusing. If
      it is really a MUST, then perhaps it should be stated as a
      requirement? Otherwise, it should be a SHOULD? 
        
  3. Russ Housley: Comment [2010-02-16]:
      The Gen-ART Review by Ben Campbell on 16 Feb 2010 raised one question
      that ought to be addressed, and I have copied it into my DISCUSS ballot
      position.  Ben also raised some editorial questions, please consider
      them.
  4. Alexey Melnikov: Comment [2010-02-14]:
    This document only has 1 normative reference which is RFC 2119. I don't believe
    this is correct, several other references are needed to properly understand
    requirements. Please check which references are normative and which are truly
    informative.
  5. Tim Polk: Discuss [2010-02-18]:
        I may be missing something, but it seems that these requirements should be in
    addition to
    the requirements specified in [I-D.ietf-geopriv-lbyr-requirements].
    The document does not
    say that anywhere, and the specification of [I-D.ietf-
    geopriv-lbyr-requirements] as informative
    adds to my confusion. 
        
  6. Tim Polk: Comment [2010-02-18]:
    
        
  7. Dan Romascanu: Discuss [2010-02-18]:
        I like the document and I belive that it's ready for approval, but I have a
    rather minor detail to clarify.
    
     Req-6:  The solution MUST work if PSAP boundaries have holes.  (For a
          discussion about holes in PSAP boundaries and their encoding the
          reader is referred to [I-D.ietf-ecrit-specifying-holes].)
    
    I do not see how the requirement can be understood without understanding the
    concept of holes in PSAP or LoST service boundaries. This being a MUST
    requirement it looks to me like [I-D.ietf-ecrit-specifying-holes] should be a
    Normative rather than Informative reference. 
        
  8. Dan Romascanu: Comment [2010-02-18]:
    
      

draft-ietf-pce-p2mp-req

  1. Tim Polk: Comment [2010-02-18]:
    
      

draft-ietf-mpls-tp-nm-framework

  1. Russ Housley: Comment [2010-02-14]:
      The Gen-ART Review by Pete McCann on 2010-02-05 raises two points
      that should be considered:
    
      Section 2.2 seems like a lot of complexity (and acronyms) just to 
      talk about the internal architecture of one box, and to define
      interfaces that won't ever be standardized.
    
      In one place in section 2.2, EMF is expanded to "Element Management
      Function."  In the Terminology and elsewhere, this is "Equipment
      Management Function."
  2. Tim Polk: Discuss [2010-02-18]:
        This discuss is a placeholder to ensure that some enhancements to the
    security
    considerations (identifed based on the secidr review) are not forgotten.
    The
    following addition to the RFC Editor Note would clear this discuss.
    
    In Section 8:
    
    OLD
       Provisions to any of the network mechanisms designed to satisfy the
       requirements described herein need to prevent their unauthorized use
       and provide a means for an operator to prevent denial of service
       attacks if those network mechanisms are used in such an attack.
    
       Solutions need to provide mechanisms to prevent private information
       from being accessed by unauthorized eavesdropping, or being directly
       obtained by an unauthenticated network element, system or user.
    NEW
       The ability for the authorized network operator to access EMF interfaces
       (section 2.3) when needed is critical to proper operation.  Therefore
       the EMF interfaces need to be protected from denial of service conditions
       or attack. The EMF Interfaces that use or access private information
       should be protected from eavesdropping or being accessed by unauthorized
       network elements, systems, or users. 
        
  3. Tim Polk: Comment [2010-02-18]:
    
        
  4. Dan Romascanu: Discuss [2010-02-18]:
        I have reviewed one of the previous versions of this document and provided my
    comments to the WG. Since then I see quite radical changes which mostly improved
    the document, but there are a few aspects left to clarify and possibly correct
    before approving it.
    
    1. I was expecting to find some text describing the relationship between the
    management framework and the OAM framework. How are for example OAM services
    configured by management. How can OAM messages be used to fill in status or
    performance information? If such information is available in another MPLS-TP
    document it should be referenced here.
    
    2. I find the performance management section changed to less than minimum and
    missing important information. I am confused by the definition of pro-active
    management - does this mean management performed by synthetic traffic generated
    for PM purposes? If this is ITU-T terminology I would like to see a reference.
    If we are talking about the need to limit reporting information, then the method
    of thresholding performance management objects (e.g. counters) and sending
    alerts in cases of exceptions is well known and deployed in IETF standards (see
    RMON and RMON-2) - I think that it should be mentioned. Also, in the last
    exchange with Eric Gray hementioned adding a statement to the effect that an
    MPLS-TP NE MUST support collection of loss and delay measurement data. I do not
    see this in the current version.
    
    3. In the Security Considerations section the issue of authorizing access to the
    management information does not apply only to protect against eavesdropping, but
    also or especially to defend against mis-configuration or mal-configuration.
    Also, the reference to Section 4.3 of the Security Framework for MPLS and GMPLS
    Networks refers to OAM traffic but not to management traffic. If that analysis
    and the security practices apply also to management traffic this needs to be
    said explicitly. 
        
  5. Dan Romascanu: Comment [2010-02-18]:
    
        
  6. Magnus Westerlund: Comment [2010-02-18]:
    Section 7.1:
    
    For IPv6, the
       reported Next-Hop MTU could be as low as 1280 octets (the minimum
       IPv6 MTU) [RFC2460].
    
    Actually the reported MTU can be lower than 1280. The proper response is to send
    if I understand RFC 2460 is to send a <= 1280 bytes packet with fragmentation
    header.
    
    From section 5 of RFC 2460:
    
       In response to an IPv6 packet that is sent to an IPv4 destination
       (i.e., a packet that undergoes translation from IPv6 to IPv4), the
       originating IPv6 node may receive an ICMP Packet Too Big message
       reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
       is not required to reduce the size of subsequent packets to less than
       1280, but must include a Fragment header in those packets so that the
       IPv6-to-IPv4 translating router can obtain a suitable Identification
       value to use in resulting IPv4 fragments.  Note that this means the
       payload may have to be reduced to 1232 octets (1280 minus 40 for the
       IPv6 header and 8 for the Fragment header), and smaller still if
       additional extension headers are used.

draft-zorn-radius-pkmv1

  1. Pasi Eronen: Discuss [2010-02-17]:
        I have reviewed draft-zorn-radius-pkmv1-10, and have one small concern
    that I'd like to discuss before recommending approval of the document:
    
    Section 6: "this document does not define a method for doing so
    securely" sounds very strange, because the next sentence does define a
    recommended method for doing exactly that.
    
    That method is IMHO fine (while it's not perfect from security
    point-of-view, it's not totally insecure or useless either -- and the
    weaknesses are IMHO adequately described by the last sentence of the
    paragraph), but since it's a key part of the specification, the use of
    this attribute should be described in e.g. Section 3, and it should be
    listed in Section 4. 
        
  2. Pasi Eronen: Comment [2010-02-17]:
    Sections 3.1/3.2 say "It is possible that the size of the SS/CA
    certificate may exceed the maximum size of a RADIUS attribute".
    A certificate compliant with 802.16-2004 is always longer than 255
    bytes, so perhaps something like "the size usually exceeds" (or
    "the size exceeds") would be more accurate.
  3. Adrian Farrel: Discuss [2010-02-18]:
        I don't have any objection to the existence or content of this document, but I
    don't understand why it is Informational.
    
    It seems to define stuff for implementation, and it seems to do that defining
    within the IETF (i.e. it is not a report of work done elsewhere).
    
    I will be happy to clear this Discuss on the call if someone can give a good
    reason. 
        
  4. Adrian Farrel: Comment [2010-02-18]:
    
        
  5. Tim Polk: Discuss [2010-02-18]:
        This will probably be a trivial discuss to clear, but I have concerns about the
    hard size limits
    for two of the attributes.
    
    (1) In section 3.4, the PKM-Cryptosuite-List is defined with Len 2 + 3n < 39,
    where 'n'
    is the number of cryptosuite identifiers.  That gives us n < 12.333...
    which seems a bit
    odd.  Where does the n come from, and why is 12 the maximum
    number of cryptosuites?
    
    (2) In section 3.7, PKM-AUTH-KEY is sized to convey a 128 bit key.  While I
    suspect that
    PKMv1 may be limited to 128 bits, is there a reason to limit the
    attribute as well?  Support for
    256 bit keys can be be achieved without crossing
    the magic 255 octet boundary, and might
    help us avoid defining new attributes
    for PKMv2... 
        
  6. Tim Polk: Comment [2010-02-18]: