IESG Narrative Minutes

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

Narrative scribe: Barry Leiba and Susan Hares (The scribe was sometimes uncertain who was speaking.)

Corrections from:

1 Administrivia

  1. Roll Call 1133 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. Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute (Proposed Standard)
    draft-ietf-mpls-fastreroute-mib-15
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the document shepherd.
    Discusses/comments (from ballot 645):
    1. Stewart Bryant: Discuss [2010-12-16]:
      I understand that the reviewers and editors have agreed text. I will clear when the next version is posted.
      There is no way in the MIB to read or set a value for "SE Style preferred" as defined in RFC4090 Section 4.3. This means there is no way to tell from looking at an instance of the MIB whether the ingress node is allowed to reroute the protecting LSP without tearing it down. Equally there is no way to read or set a value for "Bandwidth protection desired" as defined in RFC4090.
      Section 4.2.2 explains how to identify a a detour LSP in the MIB, however the fields used for identification differ from those described in RFC4090 Section 6.1 so it is not clear to me how one could map between an RSVP-TE message and the corresponding MIB entry for that detour LSP. This should be described.
      Section 4.2.2. includes the following two paragraphs:
      "A detour LSP is also considered as an instance of a protected TE tunnel. Therefore, each detour LSP SHOULD have an entry in the mplsTunnelTable (defined in the MPLS-TE-STD-MIB[RFC3812])."
      "In the mplsTunnelTable, the higher 16 bits of the tunnel instance SHOULD be used as a detour instance. Note that for the protected TE tunnel instances, the higher 16 bits of the tunnel instance MUST all be set to zero."
      The first paragraph is fine and included here for context. The second paragraph is extremely difficult to parse, partly because it is not explicit as to when it is referring to a detour LSP Vs a protected LSP. Do you mean that for protected LSPs the high order 16 bits should be set to 0 and for protecting LSPs the high order 16 bits should be used as a detour instance. So in the case of a detour LSP, it has two mplsTunnelTable entries - one with the high order bits set to 0 and one with the high order bits set to the detour instance?
      Section 4.2.3. The example in this section places the mplsTunnelInstance for the protected LSP in the high order bits and the mplsTunnelInstance for the detour LSP in the low order bits. However section 4.2.2 specifics that they should be the other way round, i.e. protected LSP instance in the low order bits and detour LSP instance in the high order bits.
    2. Stewart Bryant: Comment [2010-12-13]:
      From the RtgArea review: "The document defines three MIB modules but it only provides an example of how it could be used for the MPLS-FRR-ONE2ONE-STD-MIB. Personally I find examples of how to use MIBs extremely helpful when I have had to make use of a MIB for configuration or diagnostics. I would suggest adding examples of usage for the other two MIBs specified in the document."
    3. David Harrington: Discuss [2010-12-13]:
      1) I think the following is invalid. Is it legal to have different max-access for different enumerations in the same object?
         mplsFrrGeneralProtectionMethod OBJECT-TYPE
             SYNTAX        INTEGER { 
                                     unknown(1),
                                     oneToOneBackup(2),
                                     facilityBackup(3)
                                   }
             MAX-ACCESS    read-write
             STATUS        current
             DESCRIPTION
               "Indicates which protection method is to be used for fast
                reroute on this device. Some devices may require a reboot 
                if this variable is to take affect after being modified.
                The value of unknown(1) is read-only and cannot be set.
                If the value of unknown(1) is set an inconsistentValue error
                MUST be returned. It is provided to correct any 
                misconfiguration."
             ::= { mplsFrrGeneralObjects 1 }
      

      2) This error processing would seem to be invalid. inconsistentValue is an SNMPv3 error code; this object could not be used with SNMPv1 or SNMPv2c. That would violate RFC1052 and RFC3410 architectural separation of the protocol from the MIB.
      3) mplsFrrGeneralConstraintsEntry talks about what agents must allow. SNMPv3 moved away from the agent/manager terminology to discussion of specific application functionality, such as Command Responders, because the SNMPv1 concept of agent was no longer valid after Informs were defined.
      4) I am not sure how agents know what the LSP signalling allows, especially in a master/subagent architecture implementation.
      5) mplsFrrGeneralConstraintsEntry : [citations] are not allowed in MIB modules because a MIB module is often distributed separately from the surrounding document. A REFERENCE clause, or textual mention of an RFC# is acceptable.
      6) The MIB does not discuss the persistence of tables and objects across reboots. That will have an effect in a number of places.
      7) mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the agent, but the rows are read-create; is the manager allowed to modify objects in the row? (and see previous note about agent/manager terminology)
      9) mplsFrrGeneralTunnelARHopProtectTypeInUse seems to only support IPv4. Why?
      11) what happens to mplsFrrOne2OnePlrEntry if the corresponding row in the mplsTunnelTable is deleted?
      12) what happens if mplsFrrGeneralConstraintsEntry is created, but the corresponding row in MplsTunnelIndex does not exist?
      13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in this table to protect the LSPs or tunnel instances determined earlier." What happens if the ifIndex values used in ifStackTable change upon device or management system reinitialization? What is the persistence of mplsFrrGeneralConstraintsTable?
      14) should mplsFrrOne2OnePlrSenderAddrType and mplsFrrOne2OnePlrSenderAddr be read-write rather than read-create? If read-create, shouldn't there be a rowstatus object? if read-create, what happens if one of these objects is deleted?
      16) what is the persistence of mplsFrrFacilityDBTable? what happens to mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of the system or the management system?
      18) There is a security template for MIB modules that was written to meet exact requirements. Authors often think they can improve upon the wording, but almost always get it wrong.
      The template has been modifed in this document, in a manner that is inappropriate. This text is inappropriate because a MIB should not require a specific version of SNMP be used, or specific SNMPv3 MIB modules be used:
      "The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements these MIB modules."
      The SNMPv3 standard (STD61) has VACM and USM as mandatory-to-implement, but not mandatory-to-use. The RFC3410 architecture was designed so different access control models and different security models and different SNMP message versions can be used within an SNMP system. The security provided by the SSH Transport Model (RFC5592) or (D)TLS (RFC 5953) with the Transport Security Model (RFC5591) is equally strong as USM, and reuses existing security infrastructure. There is no reason why USM MUST be **used** with any v3 agent that supports this MIB.
    4. David Harrington: Comment [2010-12-13]:
      8) I am not sure what "object availability" means in mplsFrrGeneralTunnelARHopEntry
      10) mplsFrrGeneralModuleFullCompliance supports the MPLS-FRR-GENERALSTD-MIB
      mplsFrrGeneralModuleReadOnlyCompliance supports MPLS FRR MIB
      Shouldn't these be consistent in naming the MIB they support?
      s/agents/Command Responders/ ??
      15) mplsFrrOne2OneModuleFullCompliance supports MPLS-FRR-ONE2ONE-STD-MIB
      mplsFrrOne2OneModuleReadOnlyCompliance supports MPLS FRR ONE2ONE MIB
      shoudn't these be consistent?
      17) RFC4181 says abbreviations should be consistent.
      mplsFrrFacilityBackupTunnelEgressLSRId and
      mplsFrrFacilityInitialBkupTunnelInvoked are inconsistent.
      This makes it harder for operators to remember whether an name contains "Backup" or "Bkup".
    5. Dan Romascanu: Discuss [2010-12-15]:
      Item #2 in the DISCUSS was modified following input from IANA.
      1. David Harrington made a number of comments in his DISCUSS and COMMENT which I support. Especially issues #2 (SNMPv3 specific error messages) and #18 (security considerations template) must absolutely be resolved before this document can be approved.
      2. The document used a process which is not recommended pre-assigning mib-2 OIDs for the roots of the three MIB modules in sections 8.1 to 8.3. We discourage this practice, as one MIB document designer does not necessarily know what other authors are doing in their documents. In this case the MIB authors request the allocation of OIDs already in use:
      mib-2 numbers 187-189 have already been assigned:
          187   forcesMIB          FORCES-MIB                  [RFC5813]
          188   pwTcStdMIB         PW-TC-STD-MIB               [RFC5542]
          189   sshtmMIB           Secure Shell Transport Model MIB  [RFC5592]
      
      The allocation request in this document must be changed and final allocation of OIDs left only to IANA.
      3. It is not clear to me the reason of defining DEFVAL values for read-only objects (mplsFrrIncomingDetourLSPs, mplsFrrOne2OneDetourOriginating, and other). Although bot explicitly forbidden by the SMI rules, read-only objects are filled in as soon as the agent can complute a meaningful value, so default values are in effect for a very short time at initialization and typically not used. If there is any special need in this case it should be described and explained.
    6. Dan Romascanu: Comment [2010-12-14]:
      1. It is not clear to me what the follwing text means in the DESCRIPTION clause of mplsFrrGeneralTunnelARHopTable
      "Note that object availability in this table is governed by the support of the Record Route Object in the RSVP-TE signaling of the implementation."
      Does this apply to all objects in the table? How does an operator know that the fact that this table is not populated is due to the lack of support of the Record Route Object?
      2. OBJECT mplsFrrGeneralConstraintsRowStatus
      MIN-ACCESS read-only
      DESCRIPTION "Write access is not required."
      Not requiring write access for a RowStatus object means that the respective table does not support dynamic row creation. How is it populated? I think that some explanation is needed for this case.
      3. Specifying just RFC4090 with no clause as REFERENCE like for mplsFrrOne2OnePlrAvoidNodeAddr seems very vague and not useful. Same for RFC3812 provided as REFERENCE for mplsFrrFacilityProtectingTunnelIndex.
    7. Sean Turner: Comment [2010-12-14]:
      #1 Spell out first use of LSR.
      #2) On page 7:
      a) Need "--" before mplsFrr...?
      -- The first value would be: mplsFrrOne2OneDetourActive.1.6553601
      b) Need comma after "= 0" in the following?
      mplsFrrOne2OneDetourMergedDetourInst = 0

    Telechat:

  2. Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (Proposed Standard)
    draft-ietf-sipcore-event-rate-control-05
    Token: Robert Sparks
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3444):
    1. Jari Arkko: Comment [2010-12-02]:
      I have reviewed this document and placed a no-objection vote, even if I do agree with most of the issues raised by Lars and David. I do think though that despite its problems and complexity, the document is understandable enough to be reviewed. I think the right path is to fix the specific issues in the document rather than to bring the document back to the working group. I do think that the document should stick to using either rate or frequency terminology, however.
      Also, here are some review comments from Ari Keränen who I asked to take another look at the document:
      The abstract should state that this document updates RFC 3265.
      5.1. Subscriber Behavior
      "The value of this parameter is an integral number of seconds in decimal."
      Should that be "decimal integer"? And probably negative values are not OK (should be stated), but how about zero? Same issue in sections 6.1. and 7.1.
      7.3. Calculating the Timeout
      "timeout = (average-interval ^ 2) * count / period"
      It's not really immediately clear how this formula results in correct timeouts. Say, if one uses average-interval of 10s and period of 100s, based on quick calculation, it seems that the timeouts would be 0,1,2,...,9 for the first 10 (batches of) messages (10*10*0/100, 10*10*1/100, ...) resulting in all 10 messages being sent during the first 45 seconds (as opposed to 100 seconds); or didn't I get the formula right?
      9.2. Grammar
      "min-interval-param = "min-interval" EQUAL delta-seconds"
      The "delta-seconds" token is not defined.
    2. Ralph Droms: Discuss [2010-12-02]:
      I fall somewhere between Jari and David regarding the use of "rate" "frequencey" and "interval" terminology. I agree with Jari that the document can be reviewed and fixed with editorial updates. However, this text from section 5.2 is an example of what I think needs to be fixed, not just improved:
      "A compliant notifier MUST NOT generate notifications more frequently than the maximum rate allows for [...]"
      The specific parameter is a minimum interval, not a maximum rate. To ensure accurate compliance with the specification, the requirement must be stated in terms of the parameter, not the inverse of the parameter (which, speaking pedantically, is not as precise):
      "A compliant notifier MUST NOT generate notifications with an interval between notifications less than the currently allowed minimum interval [...]"
      Text such as this excerpt from the next paragraph is OK, but could be improved:
      "When a local policy dictates a maximum rate for notifications, a notifier will not generate notifications more frequently than the local policy maximum rate"
      which mixes frequency and rate but is still understandable and has no normative requirements langauge. I think this text would be more accurate:
      "When a local policy dictates a minimum interval for notifications, a notifier will not generate notifications more frequently than the local policy minimum interval [...]"
    3. Lars Eggert: Discuss [2010-11-30]:
      Section 6., paragraph 0: Operation of the Minimum Rate Mechanism
      DISCUSS: Assuming that you disallow max_interval := 0, this mechanism can still be used to get the notifier to generate a notification once per second. This can put some stress on the network as well as on the notifier. It's also questionable from the example use cases that a notification rate that is that aggressive can be useful. Can we define a useful max_interval that is larger than 1 second? If not, can we add some strong language here to caution implementers to use the lowest possible useful rate here? (This also applies to the "adaptive" variant.)
    4. Lars Eggert: Comment [2010-11-30]:
      Section 3.4., paragraph 7:
      "paremeters are adjusted from the value given by the"
      Nit: s/paremeters/parameters/
      Section 7.1., paragraph 4:
      "The main consequence for the subscriber when applying the adative"
      Nit: s/adative/adaptive/
      Section 7.3., paragraph 5:
      "period: The rolling average period, in seconds. The value of the "period" parameter is chosen by the notifier, however the notifier MUST choose a value greater than the value of the "average- interval" parameter."
      Additionally, period should be several times larger than the average-interval, because otherwise, not much averaging will happen - the mechanism degrades to the non-adaptive variant.
    5. Adrian Farrel: Comment [2010-12-02]:
      Just a few nits in a document I found otherwise to be very readable.
    6. David Harrington: Discuss [2010-12-13]:
      1) The document continually refers to both rate and interval - two sides of the same coin. I find the current approach to handling this very distracting. I think the document would be clearer if you chose one perspective, explained in the terminology section how it relates to the other perspective, and then used the one perspective consistently. Maybe you should rename the parameters to reflect the rate perspective - e.g., change "min-interval" to "max-rate".
      section 1 defines min-interval, and equates it to maximum rate:
      "min-interval: specifies a minimum notification time period (maximum rate) between two notifications, in seconds."
      This is incorrect; min-interval does not specify the maximum rate between two notifications; min-interval refers only to the time period. Maximum rate refers to the ratio of the number of notifications per min-interval. - min-interval is only the denominator; maximum rate refers to the numerator/denominator ratio.
      section 3.1 says, "The maximum rate applies to the overall resource list, which means that there is a hard cap imposed by the maximum rate to the number of notifications the presence client can expect to receive."
      This sentence is inaccurate on at least two points -
      a) the sentence does not stipulate that the rate is a function of the time period; there is no time period specified here, so it could be interpreted as the number of notifications received for the lifetime of the client.
      b) maximum rate only indirectly imposes a cap on the number of notifications - i.e., the numerator is ALWAYS 1. The hard cap per period is imposed by the min-interval, i.e., the cap is 1/min-interval. The attribute that varies to establish the cap is the min-interval, never the number of notifications.
      The repeated mixing of the interval and rate leads to inaccuracies in the spec. The spec would be more accurate if the relation of rate to interval was defined in the termonology, and then the specification were written from the interval perspective (since this spec is about standardizing the settings for the interval parameters.)
      2) 3.1 talks about "notifications that do not comply with the maximum rate". I'm not sure quite what that means - I assume it means notifications are generated faster than they are allowed to be sent. Why not say that?
      3) 3.1 says the RLS will "batch all of the buffered state changes together in a single notification only when allowed by the maximum rate."
      - I don't understand "when allowed by the maximum rate". The maximum rate is a number. How does that number "allow" batching?
      In addition, section 1 says "it is strictly an implementation decision whether batching of notifications is supported, and by what means."
      So I don't understand what "allowed by the maximum rate" means relative to the implementation decision. My impression is that "maximum rate" is being used to refer to an abstraction of the whole process, and that does not lead to clear and unambiguous standards specification.
      4) 3.1 says "The presence client can also modify the "min-interval" parameter during the lifetime of the subscription. For example, if the User Interface (UI) of the application shows inactivity for a period of time, it can simply pause the notifications by setting the "min-interval" parameter to the subscription expiration time, while still keeping the subscription alive. When the user becomes active again, the presence client can resume the stream of notifications by re-subscribing with a "min-interval" parameter set to the earlier used value."
      This text conflates the application, the UI, the user, and the presence client. These are potentially different entities - an application's database of activity might be a totally different process than its UI. I assume the presence client is an abstract fucntionality supported by an application - possibly implemented in a totally different process. and the user obviously is neither the application, nor the UI, nor the presence client. Is the presence client supposed to have a mechanism to watch the UI to see whether there is UI activity? or does it detect inactivity by monitoring protocol acivity? How exactly does it detect this- which protocols should be watched?
      5) in 3.2, "In order to control the actual state, the location application sets a minimum rate ("max-interval" parameter), i.e. a maximum time interval between two notifications." Again, this approach of "here, let me say this three different ways" is distracting. More important, should this text say that it sends the parameter to the RLS? or does it just set an internal parameter paid attention to at the presence client?
      6) 3.3 says "The "average-interval" parameter value is used by the notifier to dynamically calculate the actual maximum time ("timeout" parameter) between two notifications." timeout is used before being defined - you might need a forward reference here.
      7) 4.1 says "If the subscriber did not include at least one of the "min-interval, "max-interval", or "average-interval" header field parameters in the most recent SUBSCRIBE request in a given dialog, it MUST NOT include an Event header field with any of those parameters in a 2xx response to a NOTIFY request in that dialog." The "it" in thsi sentence should be replaced by a named "actor". Is this the server that MUST NOT include things in the response?
      8) 4.2 says "A notifier that supports the different rate control mechanisms will comply with the value given in "min-interval", "max-interval" and "average-interval" parameters and adjust its rate of notification accordingly. However, if the notifier needs to lower the subscription expiration value or if a local policy or other implementation-determined constraint at the notifier can not satisfy the rate control request, then the notifier can adjust (i.e. increase or decrease) appropriately the subscriber requested rate control." How do I comply with a value? I know how to comply weith a standard, but not with a value. The "will comply" seems to call for a RFC2119 keyword. "will comply" seems to call for a MUST, but the next sentence discusses the exceptions, so I guess "will comply" needs to tbe replaced by a SHOULD.
      9) 5.1 says "Note that the witnessed time between two consecutive received notifications may not conform to the "min-interval" value for a number of reasons. For example, network jitter and retransmissions may result in the subscriber receiving the notifications with smaller intervals than the "min-interval" value recommends." Hmmm. Doesn't min-interval mean do not send notifications more fequently than every X seconds? Am I missing somethign in my interprwetation? Doesn't this text say that the receiver might receive the notifications at a rate faster than the rate they are sent?
      10) in 5.5.1, how does one determine the relative sizes of the partial and full state notifications? Is there a specification that defines the size of a full state notification? The partial state contains values that are differences between two full states. Can the size of the partial state be greater than the size of the full state, when the partial contains only the differences between two full states - the current full state and the last successfully communicated full state? And I note that section 5.6 says explicitly "However, even in the worst case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update." So why SHOULD implementations check whether the partial state notification is smaller than the full state notification?
      11) Is it true that the maximum size should never exceed the size of a full state notification? For example, could the size vary depending on the encoding language, or the compression algorithm?
      12) As with all SHOULDs, what is the acceptable exception to not checking this? What are the full implications if a notifier sends a partial notification instead of a full notification when the partial and full are the same size? (If the partial can never be bigger than the full, and the only time you would substitute a full for a partial is when the partial is not smaller than the full, then they must be the same size) I assume the subsequent baseline would be changed when the full was sent, and not when the partial was sent. Is there a significant operational impact from this happening, that doesn't occur using "accumulated" partials anyway? If there are implications, why is this not a MUST?
      13) Is there a specification that defines the datatypes supported for calculating differences? (Note that SMIv2 defines Counter64 datatypes, but failed to define an unsigned64 datatype, which would be necessary for representing the difference between two Counter64s.
      14) What is an accumulated partial state notification? where is this defined?
      15) With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. How large a buffer is required of compliant implementations? How many subscriptions must a compliant implementation support? What happens if an implementation runs out of buffer space? (note that this partial-notification requirement is not discussed in terms of operational considerations, or in terms of possible DoS under security considerations, including those of RFC 5263)
      16) in 6.2, "A compliant notifier MUST generate notifications when state changes occur or when the time since the most recent notification exceeds the value in the "max-interval" parameter. Depending on the event package and subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of a max-interval expiration MUST contain either the current full state or the partial state showing the difference between the current state and the last successfully communicated state.", Section 6.1 mentions sending an etag in the ntoification, presumably instead of a full or partial state. Wouldn't this violate the MUST in section 6.2?
      17) in section 9.3, it states "A subscriber that wishes to update the value for maximum, minimum or adaptive minimum rate of notifications can do so by including all desired values for the "min-interval", "max-interval" and "average- interval" parameters in an Event header field of the 2xx response to a NOTIFY request." Shouldn't "can do so by including all desired" be "MUST include all desired", since not including a value shuts off that specific feature?
    7. Alexey Melnikov: Discuss [2010-12-02]:
      In 9.2:
            event-param    =/  min-interval-param
            subexp-params  =/  min-interval-param
            min-interval-param =   "min-interval" EQUAL delta-seconds
      
            event-param    =/  max-interval-param
            subexp-params  =/  max-interval-param
            max-interval-param =   "max-interval" EQUAL delta-seconds
      
            event-param    =/  average-interval-param
            subexp-params  =/  average-interval-param
            average-interval-param =   "average-interval" EQUAL delta-seconds
      

      delta-seconds is not defined in the document. I think it is coming from RFC 3261, but this needs to be stated explicitly.
    8. Dan Romascanu: Comment [2010-12-16]:
      I support the issues raised by David and Alexey in their DISCUSSes
    9. Peter Saint-Andre: Comment [2010-11-30]:
      1. In Section 3.4, the parameter names do not belong in the requirement definitions because they are implementations of the requirements. Thus I suggest:
      REQ1: The subscriber must be able to set a maximum rate of notifications in a specific subscription.
      REQ2: The subscriber must be able to set a minimum rate of notifications in a specific subscription.
      REQ3: The subscriber must be able to set an adaptive minimum rate, which adjusts the minimum rate of notifications based on a moving average.
      REQ7: The notifier must be allowed to use a policy in which the maximum rate, minimum rate, and adaptive minimum rate are adjusted from the value given by the subscriber.
      2. In Sections 5.1, 6.1, and 7.1, what is "an integral number of seconds in decimal"? An integral number sounds like an integer, i.e., a whole number, i.e., not a decimal number. Please clarify.

    Telechat:

  3. IMAP LIST extension for special-use mailboxes (Proposed Standard)
    draft-ietf-morg-list-specialuse-06
    Token: Alexey Melnikov
    Note: Timo Sirainen <tss@iki.fi> is the document shepherd.

    Discusses/comments (from ballot 3480):
    1. Ralph Droms: Comment [2010-12-15]:
      From this example in section 5.4 and a brief e-mail exchange with Barry:
      ==> Set new use for SavedDrafts; MyDrafts changes automatically:
      C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts")
      S: * METADATA "MyDrafts" (/shared/specialuse NIL)
      S: t3 OK SETMETADATA complete
      I infer that, in this example, only one mailbox on the server can have the \Drafts attribute. This text from section 2 gives a hint that a server may have a restriction that only one mailbox at a time may be assigned a specific special use attribute:
      "All of the above attributes are OPTIONAL, and any given server or message store may support any combination of the attributes, or none at all. In some server or message store implementations it might be possible for multiple mailboxes to have the same special-use attribute."
      It would make the restriction explicit to add text here to the effect of "Some servers or message store implementations may restrict the use of special use attributes so that only one mailbox is assigned each special use attribute."
    2. Adrian Farrel: Comment [2010-12-13]:
      I don't think it is appropriate to use RFC2119 terminology in the Abstract.
      It is probably also not appropriate in the Introduction.
      It would be nice to capitalise the section headings.
      Section 7: "LIST response: There are no security issues with conveying special-use information to a client."
      Really. Doesn't the exchange of information imply that there is potential to intercept the information. Knowledge of the message store usage may be valuable to someone attempting to access messages.

    Telechat:

  4. The Trickle Algorithm (Proposed Standard)
    draft-ietf-roll-trickle-06
    Token: Adrian Farrel
    Note: JP Vasseur (jpv@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3545):
    1. Stewart Bryant: Discuss [2010-12-15]:
      "All that matters is that some nodes communicate with one another at some nonzero rate."
      This is not right. If every node received, nothing would get communicated. In addition I tend to think of communication as requiring some degree transmission.
      I think that you mean transmits at some nonzero rate.
      Considering that later text says that Trickle breaks if there is a parameter mismatch, I am concerned that this text is not strict enough:
      "It is RECOMMENDED that a protocol which uses Trickle includes mechanisms to inform nodes of configuration parameters at runtime. However, it is not always possible to do so."
      I am also concerned with the get out clause that allows the degradation of a MUST to a RECOMMENDATION. Surely for the cost of a few bytes the parameters can at least be announced so that other nodes can get some hint that the mismatch is occurring.
    2. Ralph Droms: Comment [2010-12-14]:
      Nit: 3rd para of section 3, s/their/its/
      Question: is the typical value of k in the range 1-5 independent of the density of the network nodes, where I'm thinking of "density" as the number of nodes that hear a given message?
    3. Adrian Farrel: Comment [2010-12-15]:
      Rtg Dir review from Alia Atlas says: I have reviewed draft-ietf-roll-trickle-06. It is one of the best drafts that I have read and I do not have any substantial or even editorial comments on it. I found the protocol as described to be clear, simple and pretty elegant.
    4. Tim Polk: Discuss [2010-12-15]:
      This is a very nice document, but I do have a couple of issues I would like the authors to consider before I move to No Objection:
      The introduction implies that a participating node will attempt to communicate with its neighbors if it notices an inconsistency in other nodes' broadcast messages between its internal state and the state of the other nodes. I expected to see that reflected in Section 4.2 (Trickle Algorithm), Step 5 when the node heard an inconsistent transmission. However, the text in step 5 does not state that the node transmits anything. As stated, the only reason that the Trickle node will transmit is if the timer t expires before the redundancy counter is met (in step 3).
      I also think that two bullets need to be added to Section 5, Using Trickle. Perhaps I am stating the obvious, but a protocol specification that uses Trickle needs to specify:
      (1) what information is transmitted if the node transmits because of timer expiration; and
      (2) what information is transmitted if the node hears information inconsistent with its internal state.
    5. Robert Sparks: Comment [2010-12-14]:
      In section 6.5 - The comment about "having the parameter describe k-1 instead of k being confusing" is confusing. I had to think for some time to convince myself that I understood what you were trying to say. I encourage you to further explain, or rewrite the comment.
      Why are you allowing different uses of trickle to give different meanings to k=0? It would seem to facilitate interoperability (and simplify implementation) if you just defined k=0 to mean turning off suppression in all cases. Individual uses of trickle can forbid setting k=0 if they don't want to allow turning off suppression.

    Telechat:

  5. Prohibiting SSL Version 2.0 (Proposed Standard)
    draft-ietf-tls-ssl2-must-not-03
    Token: Alexey Melnikov
    Note: Joe Salowey (jsalowey@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3547):
    1. Stewart Bryant: Comment [2010-12-13]:
      Adrian has an interesting point.
    2. Adrian Farrel: Comment [2010-12-13]:
      "however, this version does not provide the expected level of security."
      I think it provided exactly the "expected" level of security. Maybe you mean "does not provide a sufficiently high level of security."

    Telechat:

  6. RTP Payload Format for Scalable Video Coding (Proposed Standard)
    draft-ietf-avt-rtp-svc-24
    Token: Gonzalo Camarillo
    Note: Roni Even is the document shepherd (Even.roni@huawei.com)
    IPR: LMI's statement about IPR claimed in draft-ietf-avt-rtp-svc-01
    IPR: Nokia Corporation's statement about IPR claimed in draft-ietf-avt-rtp-svc-01.txt
    IPR: Nokia Corporation 's Statement about IPR related to draft-ietf-avt-rtp-svc-14
    IPR: Cisco System's Statement About IPR Claimed in draft-ietf-avt-rtp-svc-21.txt
    Discusses/comments (from ballot 3559):
    1. Stewart Bryant: Discuss [2010-12-16]:
      This is initially a Discuss Discuss
      I have two issues that I would like to understand before taking a position:
      1) The document discusses a MANE as a type of middlebox. I would like to understand whether the content server and user explicitly request the services of a MANE to modify the content, or whether it's services are imposed on the stream by a third party?
      If the server or the user request the services of the MANE, and the traffic is explicitly addressed there this fine. If one the other hand the MANE just sits in the path and does this, issues of compliance with the Internet Architecture and issues of net-neutrality apply.
      2) I would like to understand whether this draft proposes modification to the output of an ITU-T codec. If it does, has the draft been liaised to ITU-T to ensure that the stream is conferment to their specification.
    2. Alexey Melnikov: Discuss [2010-12-16]:
      Issue for the AD to address:
      The shepherding write-up doesn't list anything in response to the following question:
      "In the case of a Media Type review, on what date was the request posted?"
      The registration template was posted to ietf-types@iana.org for 2 weeks review: <http://www.ietf.org/mail-archive/web/ietf-types/current/msg00996.html>
      Please add this to the ballot write-up, as this is going to be sent out on approval.
      In Section 7.1: Encoding considerations: "This type is only defined for transfer via RTP (RFC 3550)."
      This text is not valid for this field in the registration template. It must be moved to the "Restrictions on usage:" field of the template (which is missing from this section).
      Please check the Section 4.8 of RFC 4288 for the list of valid values for this field.
      The registration template is also missing the following fields: "Interoperability considerations:, Applications that use this media type:"
      Please read RFC 4288 for possible values of these fields.
    3. Alexey Melnikov: Comment [2010-12-12]:
      In Section 7.1: "Public specification:" --> "Published specification:"
    4. Peter Saint-Andre: Comment [2010-12-15]:
      I concur with Alexey's DISCUSS regarding compliance with RFC 4288.
      Section 4.5.1 states: "When SST is in use, Section 5.4 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the following modifications."
      And Section 4.6 states: "Section 5.6 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the following modifications."
      Does this specification modify 3984[bis], or does it only extend 3984[bis]?
    5. Robert Sparks: Comment [2010-12-14]:
      It would help to more clearly call out the consequences rewriting RTCP has on the way SRTP can be used. Currently the document only mentions this (and not as directly as it could) in an "Informative Note". Pointing to the last paragraph in the Security Considerations section of 3894bis would help.
    6. Sean Turner: Discuss [2010-12-15]:
      #1) Section 3.1: It's probably worth pointing out where the normative definitions are. That is, add "Where there is a discrepancy, the definitions in [H.264] are normative."
      #2) Section 3.1 the bit about section 3.1.2: If you're copying the definitions and then changing them, then it would greatly aid the reader if you said which ones you're changing and how.
    7. Sean Turner: Comment [2010-12-15]:
      #1) The RFC editor will make you remove the reference in the abstract.
      #2) Abstract: r/in_Annex/in Annex
      #3) Expand HDTV and Mbps.
      #4) Section 4.4, last para: Wouldn't it be easier to say SST is the default?

    Telechat:

  7. Extensible Messaging and Presence Protocol (XMPP): Address Format (Proposed Standard)
    draft-ietf-xmpp-address-08
    Token: Gonzalo Camarillo
    Note: Ben Campbell (ben@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3580):
    1. Russ Housley: Discuss [2010-11-30]:
      In the Gen-ART Review by Elwyn Davies on 30 November 2010, one issue was discovered that is easily addressed. I think consistent terms will aid future readers and implementers.
      s4.3.1, last para: There should be a formal definition of 'Bare JID' as it is extensively used in draft-ietf-xmpp-3920bis. Note that almost all the cases where 'Bare JID' is used, both in this document and 3920bis add a expansion that this means <localpart@domainname>, except for one instance in s8.1.2.1 of 3920bis where it means just <domainname^gt; (also referred to as 'Mere Dominname' elsewhere in 3920bis!).
    2. Alexey Melnikov: Discuss [2010-12-10]:
      4). DISCUSS DISCUSS: Should domainpart be migrated to IDNA2008 now? Apps Area is pretty much requiring use of IDNA2008 in all documents.
    3. Alexey Melnikov: Comment [2010-12-10]:
      (blank)

    Telechat:

  8. Sieve Notification Using Presence Information (Proposed Standard)
    draft-ietf-sieve-notify-presence-04
    Token: Alexey Melnikov
    Note: Cyrus Daboo is the document shepherd.

    Discusses/comments (from ballot 3608):
    1. Gonzalo Camarillo: Comment [2010-12-16]:
      In Section 2, the first time XMPP is mentioned there is no reference to the XMPP spec. The reference only appears later. Adding a reference the first time XMPP appears in the text would be useful.
    2. Adrian Farrel: Comment [2010-12-13]:
      "dnd - Do Not Disturb; the user should not be disturbed now"
      s/should not/does not wish to/ ?
    3. Tim Polk: Discuss [2010-12-01]:
      The first and third paragraphs of the security considerations section seem to be in conflict. The first paragraph states that "implementations MUST ensure that users can not create scripts that access the presence information of others without the proper access controls." The third paragraph advocates "caching presence tests for periods of time, even across Sieve script instances." Is it reasonable to expect an implementation to ensure that the different script instances *all* satisfy the access controls?
    4. Dan Romascanu: Comment [2010-12-14]:
      1.The language in the Security Considerations section is inconsistent in the way it deals with the actions needed to be considered by implementations to mitigate the security threats described in this section. While the first paragraph ends with: > In addition, implementations MUST ensure that users can not create scripts that access the presence information of others without the proper access controls. the third one says: > Implementations might consider providing options for rate limiting, or for caching presence tests for periods of time, even across Sieve script instances. For consitency purposes it would be better to use 2119 language in both places or none. My preference would be for a MAY or SHOULD to be used in the later case.
      2. The OPS-DIR review by Peter Koch questioned the free format of the status information for:
      Description: A human-readable description of the user's availability status. This is similar to the presence element with the same name that's defined in Section 2.2.2.2 of RFC 3921.
      Syntax: There is no formal definition for the values this item may take. It is free-form and may be in any language, and is meant for human consumption.
      I think that it would be better to clarify that as per RFC 3921 this is a natural language description (which is more clear than 'any language') and that Sieve already specifies that strings are in UTF-8 (RFC 5228, section 2.1)
    5. Robert Sparks: Comment [2010-12-14]:
      As far as I can tell so far, nothing in this document would make it hard to later extend its ideas to cover other types of presence information, up to and including queries against current location (PIDF-LO) enabling rules like "only send me an SMS notification if I'm in the country" - so, I'm entering this as a comment instead of a discuss.
      Please consider further reinforcing that these notification capability parameter values are going to be derived from potentially several inputs, including calendars as well as presence servers. It would help to informatively reference PIDF (RFC3863), especially in the registration of the "status" element, pointing to PIDF's "note" element in section 4.1.6.
      Also please consider calling out considering RPID and PDIF-LO when choosing new capability parameter names in the discussion of adding new presence items.

    Telechat:

  9. Requirements for Label Edge Router Forwarding of IPv4 Option Packets (Proposed Standard)
    draft-ietf-mpls-ip-options-06
    Token: Adrian Farrel
    Note: George Swallow (swallow@cisco.com) is the Document Shepherd.
    Discusses/comments (from ballot 3617):
    1. Ron Bonica: Discuss [2010-12-14]:
      This document attempts to fill a very important gap in the the standards. I look forward to changing this DISCUSS to a YES when the following issues are addressed:
      - In order to implement a compliant version of MPLS, the authors must read this document. Therefore, this document UPDATES RFC 3031
      - Is the scope of this document correct, or should we address all IETF encapsulation types (IP-in-IP, MPLS, IPEC). It seems that they should all work the same way. RFC 2003 (IP-in-IP) includes some very fuzzy language about IP options "generally" not being copied to the outer header, but it doesn't seem to have addressed the issue.
      - Does encapsulation (of any type) scuttle the intent of some IP options. If so, we might want to drop some packets at the head end of the LSP rather than forwarding them without the intended per-hop processing.
    2. Ron Bonica: Comment [2010-12-14]:
      - In the introduction, you say "The IP packet header provides for various IP options as originally specified in [RFC791]."
      Not all options are defined in 791. Some are defined in RFCs 1191, 1385, 1393, 2213, and 4782.
      - In the introduction, you say
      "IP options extend the IP packet header length beyond the minimum of 20 octets. As a result, IP packets received with header options are typically handled as exceptions and in a less efficient manner due to their variable length and complex processing requirements. For example, many router implementations, punt such IP option packets from the hardware forwarding (fast) path into the software forwarding (slow) path causing high CPU utilization."
      Even when the forwarding plane can parse a variable length header, it still needs to punt to the control plane, because the forwarding plane may not have the clock cycles or intelligence required to process the option.
      - in the introduction, your use of the word "transparent" is imprecise. Transparent means that you can see one thing through another (e.g., glass is transparent). IP options are not transparent when encapsulated in MPLS. MPLS would be transparent if you could see the IP header through it.
      - In Section 4, you say: "When processing of signaling messages or data packets with more specific forwarding rules is enabled, this policy SHOULD NOT alter the specific processing rules."
      What are these more specific forwarding rules?
    3. Stewart Bryant: Comment [2010-12-13]:
      In Section 4. Ingress Label Edge Router Requirement: "Further, how an ingress LER processes the IP header options of packets before MPLS encapsulation is out of scope since the IP packets are received as they enter the MPLS domain."
      The IP packet is not actually received in the IP component of the LSR, it is forwarded.
      You could delete "since the IP packets are received as they enter the MPLS domain.", or perhaps say "since these are processed before they enter the MPLS domain."
    4. Lars Eggert: Discuss [2010-12-16]:
      Section 5.1., paragraph 3: "Further, IPv6 [RFC2460] makes use of extension headers not header options and is therefore outside the scope of this document."
      DISCUSS-DISCUSS: I want to discuss this on the call, after which I will clear the DISCUSS. In other words, no author action required at this time: Is there a separate document in the works for IPv6? Or do we already have the required mechanism specified?
    5. Lars Eggert: Comment [2010-12-16]:
      INTRODUCTION, paragraph 4: "Requirements for Label Edge Router Forwarding of IPv4 Option Packets"
      This document isn't really about requirements, it specifies a required behavior. Suggest to drop "Requirements for" from the title.
      INTRODUCTION, paragraph 7: "This document specifies how Label Edge Routers (LER) should behave when determining whether to MPLS encapsulate an IP packet with header options."
      Although it's clear from the the title that this document is for IPv4, it would be good to s/IP/IPv4/ throughout, for clarity.
    6. David Harrington: Discuss [2010-12-14]:
      1) Why does this document not Update 3031 and 3032?
      2) There is an assumption in this document that packets with IP options SHOULD be sent through MPLS. But somebody put those options in. What if the operator deliberately wanted to have the IP options take precedence over the MPLS encapsulation? The document does not discuss the security and operational considerations of over-riding the IP options and pushing the packets into an MPLS tunnel. For example,
      o Crafted IP strict and loose source route option packets that belong to a prefix-based FEC yet bypass MPLS encapsulation at a ingress LER may allow an authorized operator to specify explicit IP forwarding path(s) across an MPLS network and, thereby, achieve specific operational goals.
    7. David Harrington: Comment [2010-12-14]:
      Please consider addressing the issues rasied in the TSVDIR review by James Polk
    8. Tim Polk: Discuss [2010-12-15]:
      Shouldn't this update RFCs 3031 and 3032?
    9. Tim Polk: Comment [2010-12-15]:
      The conformance requirements could be stated more clearly. In the abstract "invoked" seems to be the wrong word. To me at least, it implies that the feature gets turned on as part of the protocol run. In light of the discuss issue, it also isn't clear if it is mandatory to implement in any MPLS LSR, LER, or only implementations of this document.
    10. Dan Romascanu: Comment [2010-12-16]:
      I support Ron's DISCUSS and item #1 in David's DISCUSS
    11. Sean Turner: Comment [2010-12-15]:
      I support Dave's first and Tim's discuss position.

    Telechat:

  10. IPv6 Address Assignment to End Sites (BCP)
    draft-ietf-v6ops-3177bis-end-sites-00
    Token: Ron Bonica
    Note: Fred Baker (fred@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3624):
    1. Jari Arkko: Comment [2010-12-16]:
      This document is spot-on, much needed, and its about time we publish it. I can warmly recommend it being approved as it is. I do have a few comments on other AD's comments, however.
      Regarding David's Discuss on IPv6-IPv6 address translation, I think the current text in the document is actually completely appropriate and should not be changed. It is indeed the case that we must avoid a situation where address translation becomes necessary from a mere tight address allocation policy reason.
      Regarding Robert's Discuss on IETF role, I think the text would probably read better and be more acceptable to you if it said ... the IETF's role ... *in this case*. That is what I think the authors meant. The IETF should not, IMO, dictate the exact allocation size but rather provide guidelines, for the reasons stated in the document.
      Regarding the possible need to ask for IAB's approval, I think this document is clearly within IETF's scope, the working group and the community is behind this proposal and I see no formal reason to ask previous authors (including the IAB) for a permission. From a basic politeness stance, maybe we should check with the IAB though. I propose that this be done as a "for information" query rather than as a formal review period, and the AD who holds the discuss can clear when we are satisfied that the IAB has had enough time to respond if they feel the need to.
    2. David Harrington: Discuss [2010-12-14]:
      In section 1, the text asserts that IPv6/IPv6 NATS must be avoided. I think should be avoided is more accurate, since we cannot predict the future needs of an applicant. We can certainly try to avoid assigning non-contiguous ranges, but we cannot guarantee it. Therefore "must" seems inapprorpiate.
    3. David Harrington: Comment [2010-12-14]:
      "The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document provides input into those discussions."
      I suggest this might be better worded as "This document provides input to the discussions of how much address space to assign end sites, as guidance to the operations community."
    4. Alexey Melnikov: Discuss [2010-12-12]:
      DISCUSS DISCUSS: The original document came from IAB+IESG. Does this document need to also be approved by IAB?
    5. Robert Sparks: Discuss [2010-12-14]:
      This text (which occurs twice in the document) is problematic:
      "The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations."
      The IETF's role, in general, is clearly much larger. It is not necessary for this document to attempt to define or limit what the IETF's role is or isn't. I suggest deleting the sentences.
    6. Robert Sparks: Comment [2010-12-14]:
      This appears to obsolete 3177, not update it.

    Telechat:

  11. IMAP4 Extension for Fuzzy Search (Proposed Standard)
    draft-ietf-morg-fuzzy-search-03
    Token: Alexey Melnikov
    Note: Barry Leiba (one of the MORG chairs) is the document shepherd.
    Discusses/comments (from ballot 3641):
    1. Stewart Bryant: Comment [2010-12-03]:
      In reading the text there are a number of cases where "a" or "the" is missing in conjunction with "server"...
      This text looks redundant:
      "A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org."
      From the security section:
      "Implementation of this extension might enable a denial-of-service attack if the implementation isn't careful to prevent them."
      I am not sure that the implementer can resist a DoS attack, they can only implement this feature to be resistant to one.
      "Implementations should test at least the behavior of large messages that contain very long words and/or unique random strings."
      I think that the implementers need to test the feature ON large messages
    2. Lars Eggert: Comment [2010-12-16]:
      INTRODUCTION, paragraph 5: "Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org."
      This section should be removed.
      Section 4., paragraph 1: "Servers SHOULD assign a search relevancy score for each matched message when the FUZZY search key is given. Relevancy scores are given in range 1-100, where 100 is the highest relevancy. The relevancy scores SHOULD use the full 1-100 range, so that clients can show them to users in a meaningful way, such as a percentage value."
      Any particular reason why the range isn't 0-100? At least in my mind, a relevance of "1" still means "a tiny bit relevant", which is not "not relevant."
    3. Adrian Farrel: Discuss [2010-12-15]:
      I found the PARTIAL return option important and was surprised to see it "hidden" in Section 6. Surely the nature of a fuzzy search (or indeed any search) is that it could return a large number of matches. Therefore the PARTIAL option is needed in all cases.
      The solution is to pull this out into its own section "Limiting the number of returned messages"
      Should Section 8 also suggest rate limiting (at the server) fuzzy search requests either globally or from specific clients/users? Should there be a consideration for the ability to limit (at a server) which clients/users can issue fuzzy searches?
    4. Russ Housley: Discuss [2010-12-15]:
      The Gen-ART Review by Brian Carpenter on 2010-12-14 points out that the title page header should indicate that this document updates RFC 3501. In particular, this document extends the formal syntax of search-key to add '"FUZZY" / '.
    5. Robert Sparks: Comment [2010-12-15]:
      I've cleared based on the RFC Editor note.

    Telechat:

  12. Reducing the TIME-WAIT state using TCP timestamps (BCP)
    draft-ietf-tcpm-tcp-timestamps-02
    Token: Lars Eggert
    Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
    Discusses/comments (from ballot 3647):
    1. Stewart Bryant: Comment [2010-12-13]:
      2*MSL: Term not defined in the document.
    2. Ralph Droms: Comment [2010-12-15]:
      Stylistic suggestion: in the bullets in section 2, either include the parenthetical "(creating a connection in the SYN-RECEIVED state)" in every sub-bullet or only the first.
      Where ISN comparisons are performed in the rules in section 2, is the comparison strictly "less than", or is the (rather unlikely event of) wraparound considered?
    3. Adrian Farrel: Comment [2010-12-13]:
      "The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments, that can be used to"
      s/TCP/TCP implementation/?
    4. David Harrington: Comment [2010-12-14]:
      section 3:
      s/are important for TCPs that/are important for TCP connections that/
      s/break prevent/prevent/
      appendix A: "the workaround in RFC 1337" - can you be more specific?
    5. Russ Housley: Comment [2010-12-15]:
      I expected a few (minor) changes following the Gen-ART Review by Francis Dupont on 2010-12-10. The changes have not appeared yet.
    6. Tim Polk: Discuss [2010-12-15]:
      I have some relatively minor issues with the Security Considerations section, plus a discuss-discuss issue.
      (1) The first paragraph doesn't really seem to describe a security issue. I wonder if the text should be focused on the (lack of) security implications when only one of the communicating peers implements the specification. (As I understand it, this algorithm never does any worse than the current state.)
      (2) It seems there is a very minor attack that is enabled by this enhancement - certainly nothing that would preclude using this technique, but still there: an attacker could spoof a SYN that met the requirements and prevent a host from releasing unneeded resources (after the normal TIME_WAIT passed).
      This attack could already be performed using the ISNs; this document just expands the range of messages that could be used.
      Now to the discuss-discuss: is this really a BCP? I personally would lean to standards track, but want to hear what others think.
    7. Tim Polk: Comment [2010-12-15]:
      (blank)
    8. Sean Turner: Comment [2010-12-15]:
      I support Tim's discuss.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. DNS-Based Service Discovery (Proposed Standard)
    draft-cheshire-dnsext-dns-sd-07
    Token: Ralph Droms
    IPR: Apple Inc.'s Statement about IPR related to draft-cheshire-dnsext-dns-sd-05
    Discusses/comments (from ballot 2293):
    1. Lars Eggert: Discuss [2010-11-30]:
      Section 18., paragraph 1: "IMPORTANT NOTE: Once draft-ietf-tsvwg-iana-ports is published, most of this IANA Considerations section can be deleted."
      DISCUSS: Would it make sense to replace this section with a normative reference to draft-ietf-tsvwg-iana-ports? (Currently, it's not even cited as a reference?)
    2. Lars Eggert: Comment [2010-11-30]:
      This document has quite a list of ID nits that should be fixed before publication (outdated references, not using example domains/prefixes, etc.)
    3. Adrian Farrel: Discuss [2010-12-15]:
      I see no reason to hold up the publication of this document especially in the light of existing deployments, but I do have two small issues I would like to discuss.
      The Introduction (fairly) says: "This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery."
      I don't understand what it is about this I-D that is on the standards track.
      I see from the proto-writeup that: "An earlier revision of this document was reviewed by the IETF and the IESG for publication as Informational. The current revision has been updated based on feedback from the earlier reviews."
      I went back to the history in the data tracker and I am puzzled. AFAICS, revision -04 was the version that received the publication request, and that showed: "Category: Standards Track"
      Indeed, draft-cheshire-dnsext-dns-sd-00.txt also shows that intention.
      So, I don't think there is historic reason for this disposition.
      There is a good deal of 2119 langauge, and I wonder what the consequence would be of not abiding by this language. Would it break interoperability or mean that the SD function could not be provided by a particular DNS server?
      Possibly it is the word "convention" used in several places that is inconsistnet with "standards track".
      A question for the sponsoring AD. Has this version of the document been reviewed by the DNSEXT working group? I can't find any informaiton on this in the write-up, but the DNSEXT charter says... "The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group."
    4. David Harrington: Discuss [2010-12-02]:
      Pasi Sarolahti did a TSVDIR review and raised a couple of points:
      1) In several places the document appears to assume that TCP and UDP are the only valid transport protocols to be used in service records. Then, Section 7 says:
      "the first label of the pair is an underscore character followed by the Application Protocol Name, and the second label is either "_tcp" or "_udp"."
      "For applications using other transport protocols, such as SCTP, DCCP, Adobe's RTMFP, etc., the second label of <Service> portion of its DNS-SD name should be "_udp"." "
      This is confusing. Why wouldn't other transport protocols use their own protocol labels, for example "_sctp" or "_dccp"? (There is ongoing work for defining UDP encapsulation for SCTP and DCCP. In such case the meaning of "_udp" would be even more complicated.)
      Generally, I think it would be good to keep a mindset that DNS-SD could be used with any transport protocol, not just TCP and UDP, even if they are the dominant protocols today.
      DBH: the use of _tcp has issues either way, and the TSVDIR debated this comment, with no clear resolution. I think the TSV community needs to have this debate and provide some guidance for future documents. In the meantime, I think the document might do well to mention that it could be used with other protocols, and to state that this specification might need to be updated in the future to accommodate a different naming scheme.
      DBH: I agree that using _udp for other protocols is confusing and should NOT be done. Is there a justification for not using _sctp, etc.?
      update: Mail with Lars crossed with my entering the DISCUSS: "The transport being included in the SRV RR was a historical mistake. But it can't be rolled back. So TCP services use _tcp and all others _udp. (Yes, even SCTP and DCCP.)"
      Can we add this justification to the document to answer the question before it gets asked?
      2) Section 6.3, on TXT records: "The intention of DNS-SD TXT records is to convey a small amount of useful additional information about a service. Ideally it SHOULD NOT be necessary for a client to retrieve this additional information before it can usefully establish a connection to the service"
      As a more minor note, I don't think the sentence should be written in normative language, instead of just using a non-capitalized "should not" as recommendation for the usual case with TCP. With some protocols connecting just based on the port number in the SRV record might not be possible. For example DCCP with its service codes could be one such case (in the spirit of thinking of possible future protocols that might use this service).
      DBH: Generally when SHOULD is used, I like a discussion of a known exception to justify why it is not MUST. I think the DCCP case is an exception that might be explained in the document to justify the SHOULD keyword.
    5. Alexey Melnikov: Discuss [2010-11-26]:
      I generally support publication of this document. I have a small list of comments I would like to discuss before recomending its final approval:
      4.1 Structured Instance Names: "In addition, because Service Instance Names are not constrained by the limitations of host names, this document recommends that they be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8, Unicode Normalization Form C [UAX15]. In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using "Punycode" [RFC 3492] encoding, beginning with"
      This reference is not defined and it needs to be a Normative one.
      5. Service Name Resolution: "In the event that more than one SRV is returned, clients SHOULD correctly interpret the priority and weight fields -- i.e. lower numbered priority servers should be used in preference to higher numbered priority servers, and servers with equal priority should be selected randomly in proportion to their relative weights."
      Why is this a SHOULD? I thought compliance with DNS SRV document makes this a MUST.
      18. IANA Considerations: "This document specifies the following IANA allocation policy for unique application protocol names:"
      I don't think it is very clear if this is asking IANA to establish a new registry, or use an existing registry.
      Allowable names:
      * Must be no more than fifteen characters long
      * Must consist only of:
      - lower-case letters 'a' - 'z'
      - digits '0' - '9'
      - the hyphen character '-'
      * Must begin and end with a lower-case letter or digit.
      * Must contain at least one lower-case letter 'a' - 'z'
      * Must not already be assigned to some other protocol in the existing IANA "list of assigned application protocol names and port numbers" [ports].
      This is missing one rule from draft-ietf-tsvwg-iana-ports-08.txt: "hyphens MUST NOT be adjacent to other hyphens"
    6. Alexey Melnikov: Comment [2010-11-26]:
      4.1 Structured Instance Names: "The <Instance> portion of the Service Instance Name is a single DNS label, containing arbitrary precomposed (Unicode Normalization Form C [UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name. It MUST NOT contain ASCII control characters (byte values 0x00 - 0x1F) but otherwise is allowed to contain any characters, without restriction, including spaces, upper case, lower case, punctuation -- including dots -- accented characters, non-roman text, and anything else that may be represented using UTF-8."
      How does this interact with draft-ietf-tsvwg-iana-ports? I think it would be worth pointing out here to sections that define more restricted formats.
      6.4 Rules for Keys in DNS-SD Key/Value Pairs: "The characters of "Key" MUST be printable US-ASCII values (0x20-0x7E), excluding '=' (0x3D)."
      This needs a reference to US-ASCII.
      [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
      While RFC Editor is likely to fix this automatically, it would be better to update this reference to point to RFC 5226.
    7. Tim Polk: Comment [2010-12-02]:
      I am not sure that the use of non-example domains in section 4.1 adds anything that "example.com" wouldn't provide: "a conventional unicast DNS domain name, such as "ietf.org.", "cs.stanford.edu.", or "eng.us.ibm.com." "
      Since section 14 is a worked example, I expect that no revisions are possible, but the authors should consider the ramifications of readers playing along at home...
    8. Peter Saint-Andre: Discuss [2010-12-01]:
      1. Section 6.4 states: "The "Key" MUST be at least one character. Strings beginning with an '=' character (i.e. the key is missing) SHOULD be silently ignored."
      Why is this SHOULD not a MUST? How would an application behave if it did not silently ignore zero-length keys?
      2. Section 7 states: "Application Protocol Names may be no more than fifteen characters (not counting the mandatory underscore), conforming to normal DNS host name rules: Only lower-case letters, digits, and hyphens; must begin and end with lower-case letter or digit. In addition, Application Protocol Names must contain at least one lower-case letter. This is to prevent service names such as "80" or "6000-6063" which could be misinterpreted as port numbers or port number ranges."
      I think we need conformance terms here (e.g., "MUST NOT be" instead of "may be no"), because later sections (e.g., 7.1, 18) assume that the fifteen-character rule is a hard limit.
      3. It seems that the IANA Considerations should simply normatively reference to draft-ietf-tsvwg-iana-ports, or provide only the minimal information that is not covered by that document.
    9. Peter Saint-Andre: Comment [2010-12-01]:
      1. The User Interface Considerations might be more appropriate as an appendix.
    10. Robert Sparks: Discuss [2010-12-15]:
      Does the special meta-query definition in section 9 (where PTR record's rdata is restricted to be a two-label name like _http._tcp.) update the definition of PTR? In particular, does the SHOULD in the last paragraph update the existing definition that the result is a pointer to a location in the domain name space (i.e. root->_tcp->_http)?
      Why is the SHOULD in the last paragraph of section 5 not a MUST? (In the event that more than one SRV is returned, clients SHOULD correctly interpret the priority and weight fields)
      What document contains the normative text that constrains SRV lookups for protocols like SCTP and DTLS to use the token _udp? This document should reference it. If there isn't such a document, I'm not sure we have community consensus that it's the correct standard use of SRV.
    11. Robert Sparks: Comment [2010-12-15]:
      This document contains several instances of opinion and observation that are not going to be useful for building interoperable implementations of the protocol. Earlier versions of draft-cheshire-dnsext-multicast had similar text that was polished out as it was completed, leaving a better document for implementers. Please consider a similar editorial pass for this document.

    Telechat:

  2. Multicast DNS (Proposed Standard)
    draft-cheshire-dnsext-multicastdns-12
    Token: Ralph Droms
    IPR: Apple Inc.'s Statement about IPR related to draft-cheshire-dnsext-multicastdns-08
    Discusses/comments (from ballot 2886):
    1. Jari Arkko: Comment [2009-12-17]:
      (blank)
    2. Lars Eggert: Comment [2010-11-30]:
      This document has quite a list of ID nits that should be fixed before publication (outdated references, not using example domains/prefixes, etc.)
    3. Adrian Farrel: Discuss [2010-12-15]:
      I found two small concerns that I hope will be really easy to adddress and will not hold the document up.
      I found the use of 2119 language a bit patchy. It would be really good if the authors took a pass on the document to check consistency. Some examples from Section 3: "If this happens, the computer (or its human user) SHOULD cease using the name, and may choose to attempt to allocate a new unique name for use on that link."
      Is that MAY?
      "This document recommends a single flat namespace for dot-local host names, (i.e. the names of DNS "A" and "AAAA" records, which map names to IPv4 and IPv6 addresses), but other DNS record types (such as those used by DNS Service Discovery [DNS-SD]) may contain as many labels as appropriate for the desired usage, up to a maximum of 255 bytes, plus a terminating zero byte at the end. Name length issues are discussed further in Appendix C."
      Is that RECOMMENDED and MAY?
      "In summary: It is required that the protocol have the ability to detect and handle name conflicts, but it is not required that this ability be used for every record."
      REQUIRED and NOT REQUIRED?
      The mDNS port (5353) is currently shown in the registry with Stuart's coordinates (Stuart Cheshire <cheshire&multicastdns.org>). Shouldn't we be asking IANA to replace or update with a reference to the RFC this document will become?
    4. Adrian Farrel: Comment [2010-12-15]:
      (blank)
    5. Russ Housley: Comment [2009-12-16]:
      (blank)
    6. Cullen Jennings: Discuss [2009-12-17]:
      This is NOT a discuss. I am simply using this flag in the tracker tool to make sure that I read the right version of the document. I am highly likely to be a YES on this doc. I have been educated about my earlier questions about is this should be PS or not and am happy with the current plan.
    7. Cullen Jennings: Comment [2009-12-17]:
      (blank)
    8. Tim Polk: Comment [2009-12-17]:
      (blank)
    9. Peter Saint-Andre: Comment [2010-12-15]:
      1. In Section 5.3 ("Continuous Multicast DNS Querying"), the third paragraph states in part: "... the interval between the first two queries SHOULD be at least one second, the intervals between successive queries SHOULD increase by at least a factor of two"
      Is there a good reason why an implementation would override these recommendations? If not, do they deserve to be required instead of recommended? Also, perhaps a reference to the "truncated binary exponential backoff" algorithm from the Ethernet spec (IEEE Standard 802.3) would be appropriate here.
      2. Section 10 ("Resource Record TTL Values and Cache Coherency") states: "Various techniques are available to minimize the impact of such stale data." Perhaps it would be appropriate to provide a description of, or pointer to, such techniques.
      3. Section 23 ("IANA Considerations") contains normative text about how implementations are to handle the the designated link-local domains. This normative text doesn't comprise instructions to IANA and thus belongs somewhere else. Section 12 ("Special Characteristics of Multicast DNS Domains") seems like an appropriate home for this text, i.e., the paragraph starting with "These domains" as well as the seven bullet points that follow.
    10. Sean Turner: Comment [2010-12-01]:
      For consistency with RFC 5395, all occurrences of "pseudo-RR" should be replace with "meta-RR" and it would not hurt to add a reference to RFC 5395 (or the rfc5395bis draft which is being fast tracked).

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. IPFIX Mediation: Framework (Informational)
    draft-ietf-ipfix-mediators-framework-09
    Token: Dan Romascanu
    Note: Juergen Quittek is the document shepherd
    Discusses/comments (from ballot 3325):
    1. Jari Arkko: Comment [2010-12-16]:
      Ari Keränen had these comments:
      IPFIX, PSAMP and quite a few other abbreviations are never expanded.
      Section 5.3: "[...] value of the "flowKeyIndicator" needs to be modified when modifying the data structure defined by an original Template."
      At least for someone not familiar with the protocol, it was not clear how the value needs to be modified in this case.
    2. Stewart Bryant: Comment [2010-12-11]:
      From a protocol conversion point of view, this intermediate entity may provide conversion into IPFIX, or conversion of IPFIX transport protocols (e.g., from UDP to SCTP) to improve the export reliability.
      I assume that you mean to improve export reliability over a sub-network (or a network segment) since you cannot improve the reliability of the UDP segment, or an SCTP segment using a low reliability mode.
      TLS & DTLS used without expansion
    3. Gonzalo Camarillo: Comment [2010-12-16]:
      Expand the IPFIX acronym in the title, Abstract, and Introduction. All acronyms need to be expanded on their first use.
      When referring to a particular section (e.g., Section 2), the word "Section" needs to be capitalized.
    4. Lars Eggert: Comment [2010-12-16]:
      Abstract: "This document describes a framework for IPFIX Mediation. This framework extends the IPFIX reference model by defining the IPFIX Mediator components."
      For the uninitiated, it would be good to add a sentence about what "IPFIX mediation" *is*.
    5. Adrian Farrel: Discuss [2010-12-15]:
      Are we sure this document does not update the IPFIX architecture making it an Update to RFC 5470?
      I think that RFC 5470 needs to be a Normative reference. Also RFC 5655 for its use in Section 9. Possibly some of the others (e.g., those referenced from Section 9), although I don't feel strongly
    6. Adrian Farrel: Comment [2010-12-15]:
      Section 8 says: "IPFIX Mediation reuses the general information models from [RFC5102] and [RFC5477]. However, several Intermediate Processes would potentially require additional Information Elements as follows:"
      Is "would potentially" code for "the Information Model is out of scope for this document"?

    Telechat:

  2. Protecting The Router Control Plane (Informational)
    draft-ietf-opsec-protect-control-plane-06
    Token: Ron Bonica
    Discusses/comments (from ballot 3564):
    1. Jari Arkko: Discuss [2010-12-16]:
      This is a good document, but I had trouble with one aspect. The document talks about filtering and rate limiting ICMP traffic and entirely dropping all fragmented packets. The document seemed to be unclear whether such drastic measures are to be applied to the traffic destined to the router itself or all traffic flowing through this. Dropping all fragmented traffic through the router would be a very unfortunate design, and would have severe impacts to the service that it provides to Internet users.
      Please clarify that you meant to filter only traffic destined to the device itself, i.e., with a destination address being one of the router's addresses.
    2. Jari Arkko: Comment [2010-12-16]:
      Ari Keränen had this comment:
      4. Security Considerations: "The filter above leaves the router susceptible to discovery from any host in the Internet. If network operators find this risk objectionable, they can reduce the exposure by restricting the sub-networks from which ICMP Echo requests or traceroute packets are accepted."
      In practice this does not help much, since, e.g., TCP scanning would be still possible.
    3. Stewart Bryant: Discuss [2010-12-15]:
      For network deployments where the protocols used rely on IP options, the filter is simpler to design in that it can drop all packets with any IP option set.
      That looks the wrong way round.
    4. Stewart Bryant: Comment [2010-12-15]:
      "Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software."
      Firstly I agree with the sentiment of this statement, however whilst this is true in all high end core routers, and in many mid range routers, it is not universally true. The crossover point between distributed designs and classic designs depends on the current ability of CPUs and is thus always in a state of flux
      It is also worth noting that the need to provide isolation and stability for the cp with work conservation and fast discard of rouge cp packets has been known and incorporated into designs for at least the past 30 years.
      o Drop all IP packets that are fragments
      There is some text on this later, but the reader would find it useful to have this explained up front. At least a forward reference would be useful.
    5. Ralph Droms: Comment [2010-12-15]:
      It might be useful to add DHCP to the example because of the DHCP relay function, rate limiting inbound DHCP traffic from clients and restricting traffic from servers to a list of known DHCP servers.
    6. Lars Eggert: Discuss [2010-12-16]:
      Appendix A., paragraph 0: Configuration Examples
      DISCUSS: I believe that the sequence of configuration commands in appendix A.1 and A.2 constitute "code" (components intended to be directly processed by a computer). This means that some boilerplate text needs to be inserted, see http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
    7. Lars Eggert: Comment [2010-12-16]:
      Section 3., paragraph 0: Method
      You should be MUCH more clear that Section 3.1 gives a particular EXAMPLE of how one might set up a filter to protect the control plane, and that any actual deployments SHOULD NOT blindly follow that example without considering the network setup at hand.
      Section 4., paragraph 1: "The filter above leaves the router susceptible to discovery from any host in the Internet. If network operators find this risk objectionable, they can reduce the exposure by restricting the sub-networks from which ICMP Echo requests or traceroute packets areaccepted."
      Several techniques for tracerouting exists, and "traceroute" packets are therefore not so easy to identify. What can be done is preventing "TTL expired" ICMP responses from being sent, but that can have drawbacks.
    8. Adrian Farrel: Comment [2010-12-15]:
      Section 1: "While software instructions run on both planes, the router control plane software is usually not optimized for high speed packet handling."
      Did you actually mean "router control plane *hardware* is usually not optimized"? It seems to me that the software *will* be optimized since who would not want their control plane to scale well?
    9. Tim Polk: Comment [2010-12-15]:
      +1 on Sean's discuss...
    10. Dan Romascanu: Comment [2010-12-15]:
      I support Sean's DISCUSS

    Telechat:

  3. An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (Informational)
    draft-ietf-v6ops-incremental-cgn-02
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com), v6ops co-chair is the document shepherd.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-v6ops-incremental-cgn-01
    Discusses/comments (from ballot 3606):
    1. Jari Arkko: Discuss [2010-12-16]:
      I think we need a document like this and it should be in the V6OPS scope to produce one. In particular, I would like to see a recommendation and operational considerations to use CGN + tunneled IPv6 service at an ISP. That seems a very likely configuration in many places.
      However, I'm somewhat unhappy with some parts of the document. In particular:
      - it portrays this as a new solution as opposed to recommended application of existing components
      - it brings in some IMHO unnecessary extensions and references
      - its treatment of IPv6-IPv4 translation aspects seems outdated (referring to NAT-PT)
      My suggestion is to go through the document once more and remove extra material and take the above focus comments into account, to see if you can cast the document in slightly different terms.
      More detailed comments:
      The document says: "ISPs facing only one pressure out of two could adopt either CGN (for shortage of IPv6 addresses) or 6rd (to provide IPv6 connectivity services)."
      I think you mean IPv4 addresses.
      The document says: "In order to enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement) can be integrated with the CGN."
      This is wrong. The replacement is already an RFC (or about to become one), and there is no reason to switch the reference to the right specification. Pointing to the old specification is harmful.
      Sections 2.3 and 2.4 would be better cast as "just use existing forwarding, NAT, and tunneling technology", than as something where you describe behaviour. I had to read the text multiple times to determine what was actually going on, and AFAICT there is no difference to the application of normal IP forwarding rules and tunnel termination logic. I think the usual rules are clearer than what the document describes, e.g.,
      "firstly checks whether the packet is a normal IPv4 packet or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN translates packet source address from a CGN-scope private IPv4 address into a public IPv4 address, and then send it to IPv4 Internet. The CGN records the v4-v4 address mapping information for inbound packets, just like normal NAT does. For a v6-over-v4 tunnel packet, the CGN needs to decapsulate it
      seems to be saying that we should particularly check tunnel packets, but I think the normal way is that the tunnel packet, being addressed to the CGN device will naturally enter different processing than packets routed/natted through it.
      Section 2.5 should mention MTU effects.
      The document says: "An ISP can provide its IPv6-only customers with a network-layer translation service to satisfy this need. Such a service is not fully defined at this time, so we refer to it non-specifically as "NAT64". Current work in the IETF is focused on one particular proposal [I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be provided as a common service located at the border between the ISP and the IPv4 Internet, beyond the dual stack CGN from the customer's viewpoint. It may be integrated into CGN devices too."
      This is quite outdated.
      The document says: "[I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a DS-lite solution with an additional feature to ease interconnection between IPv4 and IPv6 realms. Home users may encounter the problem of reaching legacy IPv4-only public services from IPv6-only clients. This problem already exists in early phases, but will become more serious over time.
      I'm concerned that we are unnecessarily listing all kinds of extensions that we don't even know are needed and which are definitely not in the current IETF agenda. Suggest deleting this paragraph. And delete this as well while you are at it:
      "If a different technology than v4-v4 NAT is chosen for IPv4 address sharing, for example [I-D.ymbk-aplusp], the present approach could be suitably modified, for example replacing the v4-v4 NAT function by the A+P gateway function."
      The document says: "For example, the appearance of IPv6 Route Advertisement messages or DHCPv6 messages can be used as a signal the availability of DS-Lite CGN. When an ISP decides to switch from incremental CGN to DS-Lite CGN, it may be that only a configuration change or a minor software update is needed on the CGNs. The home gateway can then detect this change and switch automatically to DS-Lite mode. The only impact on the home user will be to receive a different IPv6 prefix."
      I'm not sure I understand what I need to do here as an implementor, and whether all the necessary pieces in RAs are already defined.
    2. Jari Arkko: Comment [2010-12-16]:
      The document says nothing of prefix delegation. Maybe it should, or should at least point out that discussion about prefix delegation can be found in several of the references.
      The document says: "For dual-stack ISP networks, dual-stack home gateways can simply switch off the v6-over-v4 function and forward both IPv6 and IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4 NAT function. This approach is considered an unlikely choice, since we expect ISPs to choose the approach described as incremental CGN here because they want to avoid or are unable to complete dual-stack deployment completely."
      This text is somewhat confusing. I *think* you are saying that you can do all this in dual stack ISP network, but that if you were adopting this specification to begin with you did not have a dual stack network. Please clarify/rewrite, and make sure that the document does not seem to recommend against deploying dual stack ISP networks...
      Ari Keränen had these questions:
      1. Introduction: "A smooth transition mechanism is also described in this document. It introduces an integrated configurable CGN device and an adaptive HG device. Both CGN and HG are re-usable devices during different transition periods. It avoid potential multiple upgrade."
      What does the last sentence mean?
      2. An Incremental CGN Approach: "Most consumers remain primarily IPv4."
      Should that be, e.g., "Most consumers remain primarily in IPv4-only networks"?
      2.4. Behavior of Dual-stack CGN: "When a dual-stack CGN receives a data packet from a dual-stack home gateway, it firstly checks whether the packet is a normal IPv4 packet or a v6-over-v4 tunnel packet."
      How is this check performed? And what if the host (i.e., not the HG) is using some v6-over-v4 mechanism; would that cause problems with the check?
    3. Stewart Bryant: Comment [2010-12-16]:
      "ISPs facing only one pressure out of two could adopt either CGN (for shortage of IPv6 addresses)"
      Do you mean "shortage of IPv4 addresses"?
      "Modified GRE [RFC2784] with additional auto-configuration mechanism is also suitable to support v6-over-v4 tunneling."
      Do you mean "modified GRE" in which case how is it modified, or do you mean GRE supplemented by a signalling protocol to set up tunnels?
      The security text on tunnel security seems a little light. If the ISP is going to consider the tunnel as own infrastructure and not needing to be policed, the ISP needs to consider policing those tunnel endpoint addresses at the boundary of the network.
      "When an ISP decides to switch from incremental CGN to DS-Lite CGN, it may be that only a configuration change or a minor software update is needed on the CGNs. The home gateway can then detect this change and switch automatically to DS-Lite mode.
      This seems very speculative
    4. Adrian Farrel: Comment [2010-12-15]:
      Section 1: "Based on this fact, the Internet industry appears to have reached consensus that global IPv6 deployment is inevitable and has to be done expediently."
      Do you mean "it is expedient" or "it has to be done expeditiously"?
      "CPE" needs to be expanded on first use.
      It seems (to me, and from the usage made in the document) capriscious that 5969 should be a normative reference, but 5569 informational.
      Section 2.2: "Other tunneling mechanisms such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] or Virtual Enterprise Traversal (VET) [RFC5558] are also considered.
      The passive voice is to be avoided! By whom are these other tunneling mechanisms considered, to what end, and with what result?
      Section 2.4: "When a dual-stack CGN receives a data packet from a dual-stack home gateway, it firstly checks whether the packet is a normal IPv4 packet or a v6-over-v4 tunnel packet.
      You need to say how it checks.
    5. Tim Polk: Discuss [2010-12-16]:
      This is a reiteration of Sean Turner's discuss. I am entering as a discuss (rather than No Objection with a supporting comment) so I can be involved in any subsequent discussion.
      This seems like a perfect document for Experimental. Running an experiment while we work through the security issues seems like a nice lead-in to an informational or standards track specification. The current spec doesn't feel fully baked (esp with respect to security) imho.
    6. Sean Turner: Discuss [2010-12-15]:
      This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).
      The security considerations include the following two statements:
      "Further security analysis will be needed to understand double NAT security issues and tunnel security issues." and
      "[RFC4891] describes how to protect tunnels using IPSec, but it is not clear whether doing so would be an important requirement."
      Taken together I've got ask why this isn't experimental?
      This one is normal discuss:
      It's worth noting early that the proposal has not fully addressed the security considerations and that further analysis may show that the proposal might not be worth adopting based on what is found during the study of the security considerations.
    7. Sean Turner: Comment [2010-12-15]:
      Figure 1: Is it supposed to to be "6 to 4" as opposed to "6 o 4" in the tunnel? Or is the "o" just supposed to be over?

    Telechat:

  4. Device Reset Characterization (Informational)
    draft-ietf-bmwg-reset-04
    Token: Ron Bonica
    Note: Al Morton (acmorton@att.com) is the document shepherd.
    Discusses/comments (from ballot 3634):
    1. Jari Arkko: Comment [2010-12-16]:
      I have no issues with this document, but Ari Keränen found some small problems in his review:
      2.2. Recovery Time Measurement Methods: "There are two accepted methods to measure the 'recovery time':"
      Is the meaning of "accepted" as in "no other method SHOULD be used" or as in "currently widely used" (or something else)?
      4.2. Software Reset Test: "A software reset is initiated for example from the DUT's Command Line Interface (CLI)."
      The CLI abbreviation is used already in Section 4.1. Would make sense to move the expanded form there.
      The second part of the test "Procedure" (6 lines of text) seems to be identical for all the test cases. Perhaps this text could be in the draft just once and have that single instance referenced in the test case descriptions.
    2. Stewart Bryant: Discuss [2010-12-16]:
      "The tester / operator MAY use either method for recovery time measurement depending on the test tool capability. However, the Frame-loss method SHOULD be used if the test tool is capable of (a) counting the number of lost frames per stream, and (b) transmitting test frame despite the physical link status, whereas Time-stamp method SHOULD be used if the test tool is capable of (a) time-stamping each frame, (b) monitoring received frame's timestamp, and (c) transmitting frames only if the physical link status is UP."
      The document should explain
      1) Why is the phy link status is only applicable in the second case?
      2) Any guidance on choice of method if an equipment can do both?
      The scaling considerations consider the RIB not the FIB. To some extent this is reasonable in that the number of routes is a topology factor and the number of FIB entries is an implementation issue. However given that in many routers it is FIB update time that dominates the topic is worthy of greater discussion. One particular case where FIB entries come into play is when you get ECMPs (which increases FIB entries) another is BGP free core (which reduces them).
      When power cycle tests (and maybe some of the other tests) are conducted, I would expect that the outage would be dominated by the specifics of the routing protocols, which are not particularly well characterized by this test? In particular it's difficult to see how to fairly test this without some characteristic of the routing behavior the routing peers being reported in the test results.
    3. Adrian Farrel: Discuss [2010-12-15]:
      It looks to me as though a number of these tests might require that forwarding state is re-established from an external source (e.g., re-learned from neighbors). Are these situations explicitly excluded from the set of benchmarking methodologies described in this document, in which case it would be really nice to call this out in the Scope section.
      If control plane interactions with neighbors were needed, you would have a much wider field to describe in order to ensure "fair" reuslts for the DUT.
      Further to Russ's Discuss, I find the following paragraph in Section 4.1 confusing:
      "Reset procedures that do not require the physical removal and insertion of a hardware component are RECOMMENDED. These include using the CLI or a physical switch or button. If such procedures cannot be performed (e.g., for lack of platform support, or because the corresponding Test Case calls for them), human operation time SHOULD be minimized across different platforms and Test Cases as much as possible, and variation in human operator time SHOULD also be minimized across different vendors products as much as practical, by having the same person perform the operation, and by practicing the operation."
      Surely the variations in operator time will not matter. For example, the time that a card is out for will not change the test, which is measuring the time to recover from when the card is reinsterted. Thus, there is no fear of variation between vendors' products becuase the ease or insertion of a card is not relevant to the atomic event of the card being (finally) inserted.
      More of an issue would be how you synchronize the timing event with the reinsertion of the card.
      That means hat your Recommendation is sound, but the motivation is suspect.
    4. Adrian Farrel: Comment [2010-12-15]:
      "BMWG" is used without expansion.
      Section 3: "In order to provide consistent and fairness"
      s/constistent/consistence/
    5. Russ Housley: Discuss [2010-12-15]:
      The Gen-ART Review by Joel Halpern on 27-Nov-2010 included two questions. I think that the should be answered before the document is approved:
      Is there a reason that section 4.1.1.1 on reset of a single-RP device refers to simple removal and re-insertion, without explaining the caveats that section 4.1.2 (line card removal and re-insertion) provides about using a method to avoid having the human time for the removal and reinsertion have a significant effect on the operation?
      Also, should the same caveat not be applied to section 4.3.1 on Power Interruption? There seems to be an implicit assumption that the human operation will be sufficiently fast, and the recovery sufficiently slow, that the human element does not matter. At the very least, it would seem that this should be articulated.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Extending YANG with Language Abstractions (Experimental)
    draft-linowski-netmod-yang-abstract-05
    Token: Dan Romascanu
    Note: Mehmet Ersue is the document shepherd.
    Discusses/comments (from ballot 3544):
    1. Stewart Bryant: Comment [2010-12-15]:
      s/suggests to enhance/suggests enhancing/
    2. Alexey Melnikov: Comment [2010-12-16]:
      I like this extension to YANG, but I haven't reviewed it in enough details to vote Yes.
    3. Tim Polk: Comment [2010-12-15]:
      I would like to know why the authors chose not register the yang module in Appendix B.
    4. Peter Saint-Andre: Comment [2010-12-15]:
      This document defines what seems like a worthwhile experiment.
      Overall, the specification does not always clearly explain the relationship between this extension and YANG itself (e.g., by relating things like complex types to particular extension points in RFC 6020), the text is sometimes difficult to understand (e.g., the document does not provide very detailed justifications for various design decisions, and there are numerous grammatical errors), and the document is sometimes poorly organized (e.g., often there are no introductory paragraphs before lists and no explanations of the tables, which seem to be merely stuck in the middle of the text without any context). These problems could be fixed if and when the experiment is completed and a follow-up specification is proposed on the standards track, but I don't think it's worth spending a lot of time to fix them now.
      On the other hand, the document provides many examples, thus helping the reader to understand the proposed extensions.
      Here are several more concrete comments...
      1. The following text is a bit presumptuous:
      "After successful usage this experimental specification can be republished at IETF as a proposed standard possibly as part of a future version of YANG."
      I suggest the following:
      "If this experimental specification results in successful usage, it is possible that the protocol defined herein could be updated to incorporate implementation and deployment experience, then pursued on the standards track, perhaps as part of a future version of YANG."
      2. In Section 1.2, the text does not explain that the bullet points are examples and therefore not exhaustive.
      3. No reference is provided for the "TM Forum SID".
      4. In Section 4, please make sure that the registrations provide all information in one place (e.g., it's not appropriate to point to the "Authors' Addresses" block for the Registrant Contact).
      5. The namespaces are mostly of the form "http://example.com/*", but it appears that they might be intended for wider use (not merely as examples). If so, I suggest using URNs in the ietf tree, or more stable URLs.

    Telechat:

  2. Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment (Informational)
    draft-arkko-ipv6-transition-guidelines-10
    Token: Ron Bonica
    Note: Kurt Erik Lindqvist (kurtis@kurtis.pp.se) is the document shepherd.
    Discusses/comments (from ballot 3625):
    1. Ralph Droms: Discuss [2010-12-15]:
      It like the IETF last call on this doc "ends 2010-12-27". Should it be on this week's agenda?
    2. Adrian Farrel: Discuss [2010-12-16]:
      Holding a Discuss until the IETF LC completes
    3. Adrian Farrel: Comment [2010-12-16]:
      Nit: Section 4.2: "There are several types tunneling mechanisms"
      s/types/types of/
    4. Tim Polk: Discuss [2010-12-15]:
      This is a discuss-discus. To be clear, I am not asking for any changes in the document with respect to this issue at this time.
      Section 3, Principles, opens with the following statement: "The end goal is network-wide native IPv6 deployment, resulting in the obsolescence of transitional mechanisms based on encapsulation, tunnels, or translation, and also resulting in the obsolescence of IPv4."
      I do not think that these are the goals of someone deploying an IPv6 network on the Internet. Their motivations for deploying IPv6 are more likely focused on address availability and the availability of specific features. Even more than that, most IPv6 deployments are more focused on ensuring connectivity with the installed IPv4 base than IPv6 purity. Citing obsolescence of IPv4 as a goal makes the document less convincing to this reader.
      I don't think refining the goals would change the set of transition strategies to be discussed, but I think there is a tone issue that results from the anti-IPv4 goals.
      A more actionable discuss issue: while this document doesn't create new security issues, a discussion of the relevant issues probably should take place in this spec.
    5. Tim Polk: Comment [2010-12-15]:
      +1 on Ralph's discuss. In light of the Last Call closing 12-27, it seems premature to gauge IETF consensus.
    6. Dan Romascanu: Discuss [2010-12-15]:
      This is a DISCUSS-DISCUSS, as I am not sure that the issue I am raising needs to be reflected in this document, but I feel it is important enough to be raised with the IESG in the context of this document. I would expect that a discussion on the transition mechanisms to IPv6 includes a reference about the network management tools that need to be used during the transition, and what would be the requirements from the network management systems during the transition in the different scenarios. One aspect of the problem is touched by in section 4.3 (addressability of managed systems) but this is only one of the multiple aspects to be discussed. Is the place for such a discussion in this document?
    7. Sean Turner: Discuss [2010-12-15]:
      I hate to just list a bunch of documents as references, but we've just reviewed draft-ietf-opsec-ip-security and draft-ietf-v6ops-tunnel-security-concerns is coming down the pipe. Should these and maybe some others you think are important be listed in the security considerations?

    Telechat:

3.2.2 Returning Items

  1. Requirements for a Protocol to Replace AppleTalk NBP (Informational)
    draft-cheshire-dnsext-nbp-09
    Token: Ralph Droms
    Discusses/comments (from ballot 2887):
    1. Pasi Eronen: Discuss [2008-12-04]:
      I think the document should be clearer whether these requirements represent some kind of IETF consensus, or just opinions of the authors. I'm guessing it's the latter, but this guess is mostly based on the I-D file name (which won't be visible once this becomes an RFC).
      I agree with Chris that Section 6 should be more realistic about the security goals: things like determining the authenticity of received information, or authority to request some information, can't usually be done with zero configuration. Even with non-zero configuration, a security solution that's realistically deployable in e.g. enterprise environment probably has to be able to leverage existing authentication and authorization infrastructure (things like Active Directory, Kerberos, or internal PKIs come to mind). Besides, the problem solved by DNSSEC (authenticating a hierarchical delegation structure) is quite different from securing an AppleTalk NBP like protocol (even if the messages re-use DNS formats).
      Section 7 should probably be clearer what actions IANA is expected to take when this document is approved (I'm guessing it's "none", but then the text should say "This document has no IANA actions."). [Holding a discuss for IANA]
    2. Russ Housley: Comment [2010-04-03]:
      (blank)
    3. Cullen Jennings: Comment [2008-12-01]:
      This needs a ballot.
    4. Chris Newman: Comment [2008-12-02]:
      I found the security considerations weak, albeit tolerable for this sort of informational document.
      Some discussion of the usability/deployability/security tradeoffs between a zeroconf home network and a fully managed DNSSEC infrastructure would be informative. Further, I suspect it's a critical requirement to replace Appletalk NBP that "no security" be a protocol option since there's no way to get something with the same ease-of-use/ease-of-deployment profile in a home network.
      Right now there are two security options proposed: none or manually configured DNS unicast w/ DNSSEC. While I consider the "none" option very important since that's exactly the security I want to deploy on my home WLAN when it comes to this protocol (WPA2-AES is good enough for my home WLAN), there are scenarios where I might want some sort of middle ground without having to administer a DNS infrastructure. For example, "make sure I connect to the same file service as last time", or "make sure I use ipp/tls to the printer service and it's the same printer service I used last time". Has any sort of leap-of-faith SSH-style keying been considered within this framework? Indeed, in a large corporation with outsourced IT, getting competent DNSSEC management is probably not feasible so "grassroots" security might be more viable.
    5. Tim Polk: Comment [2008-12-02]:
      Section 3.15 (Immediate and Ongoing Information Presentation) describes user interface requirements rather than the underlying protocol requirements. I suggest revising this section in terms of the protocol requirements.
    6. Dan Romascanu: Comment [2008-12-04]:
      I find the name of the document and of the page headers completely misleading. IMO the name should be 'Requirements for Replacing AppleTalk Name Binding Protocol (NBP)'.
    7. Sean Turner: Comment [2010-12-02]:
      The rewritten security considerations include two points a) had the protocol been developed with security in mind then it would have been done differently b) when a new/modern version is designed the requirement is that it have security measures appropriate to the environment in which it will be used. Based on the changes, I'm changing to no objection.

    Telechat:

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Media Description for IKE in the Session Description Protocol (SDP) (Informational)
    draft-saito-mmusic-sdp-ike-08
    Token: Robert Sparks
    Note: See the Ballot Writeup for the working 5742 response
    Discusses/comments (from ballot 3520):
    1. Adrian Farrel: Discuss [2010-12-16]:
      I have no objection to the progress of this document, but I would like to check two things with my fellow ADs.
      I expect the RFC Editor would pick this up, but I wondered why this document refers to RFC 4306 and not to RFC 5996.
      I also wondered whether text (such as in the title and the Abstract) should refer explicitly to "IKE v2" rather than "IKE".

    Telechat:

  2. The Internet Routing Overlay Network (IRON) (Experimental)
    draft-templin-iron-13
    Token: Jari Arkko
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot 3638):
    1. Stewart Bryant: Comment [2010-12-15]:
      I am surprised that the document contains no reference to LISP which is operating broadly in this space.
      SRA is not a defined abbreviation.
      This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay:
      "After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages.
      "If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping."
      "quickly" is a non-specific metric
      [I-D.templin-intarea-seal] looks like it should be normative
      [I-D.templin-intarea-vet] looks like it should be normative
      Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.
    2. Ralph Droms: Comment [2010-12-16]:
      I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it?
      The remainder of my COMMENTs are editorial.
      In Section 6.1, I think I understand what this text is trying to explain, but I don't think it's correct:
      "It is therefore essential that the Client send the initial packets through its Server to avoid loss of SCMP messages that cannot traverse a NAT in the reverse direction."
      Does this mean to explain that the Client sends packets through its Server to establish NAT state so SCMP messages from the Server to the Client can traverse the NAT?
      In Section 6.2, this text uses "into the Internet" in a confusing way, assuming I'm understanding the meaning of the text correctly:
      "The Server then forwards the revised packet into the Internet via a default or more-specific route, where it will be directed to the closest Relay within the destination VPC overlay network."
      Everywhere else in this section "into the Internet" is used to describe the forwarding of a decapsulated datagram, after the outer header with locator addresses have been removed, into the (non-IRON) Internet. In the text quoted aboce, "into the Internet" seems to mean forwarding of an encapsulated datagram, which is described elsewhere in this section as simply "forwards" or "sends". I suggest rewriting, for consistency, as
      "The Server then forwards to the closest Relay within the destination VPC overlay network."
      In Figure 6, why would the anycast datagram from Server(A) be delivered to Relay(B) rather than Relay(A) (which presumably would be in the routing fabric for ISP A)? Does it matter?
      Once Server(B) receives the datagram to be forwarded to Client(B), is it possible for Server(B) to send a redirect to Client(A) so Client(A) can send traffic directly to Client(B)?
      Stylistic nit in section 6.4.1 (and elsewhere) - why start using the verb "releases" instead of the previously used "forwards" or "sends"? Seems like lots of unnecessary verbiage right after Figure 6; why not something like "..., host A sends packets to host B through its EUN. Client(A), as the defautl router for the EUN, receives the packets, encapsulates them in the IRON encapsulation and forwards them to Server(A). ..." (etc.) All the explanation of routing, etc., seems redundant at this point.
      Sorry, can't help myself; in section 6.6: "The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates."
      ... as opposed to the unethical business practices and unreasonably high rates from those evil, greedy ISPs.
      Seriously, has the renumbering problem simply been moved from the ISPs to the VPCs?
    3. Adrian Farrel: Comment [2010-12-16]:
      Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions.
      I feel that it would be helpful if the document contained a pointer to draft-irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.

    Telechat:

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Audio/Video Transport Payloads (payload)
    Token: Robert

    Telechat:

  2. Metric Blocks for use with RTCP's Extended Report Framework (xrblock)
    Token: Robert

    Telechat:

  3. Audio/Video Transport Core Maintenence (avtcore)
    Token: Robert

    Telechat:

  4. Audio/Video Transport Extensions (avtext)
    Token: Robert

    Telechat:

  5. ControLling mUltiple streams for TElepresence (clue)
    Token: Gonzalo

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Transparent Interconnection of Lots of Links (trill)
    Token: Ralph

    Telechat:

  2. Ad-Hoc Network Autoconfiguration (autoconf)
    Token: Jari

    Telechat:

5. IAB News We can use

  1. [Hannes left the call.]

6. Management Issues

  1. Registration of image/svg+xml media type (updated) (Alexey Melnikov)

    Telechat:

  2. Expert for RFC 5727 Registries [IANA #306256] (Michelle Cotton)

    Telechat:

  3. Expert for RFC-draft-levine-rfb Registries [IANA #413122] (Michelle Cotton)

    Telechat:

  4. Registration of application/ttml+xml media type (Alexey Melnikov)

    Telechat:

  5. ITU flow-state sig draft (Jari)

    Telechat:

  6. Request for early RFC number assignment (Tim)

    The W3C has requested expedited processing for draft-mcgrew-fundamental-ecc. W3C XMLEnc and XMLDsig 1.1 are going to Candidate Recommendation in January, and they have a normative reference to this document, and early assignment of an RFC number would be much appreciated.

    Telechat:

  7. Summary of EC meeting (Sean)

    Telechat:

7. Agenda Working Group News

1450 EST Adjourned



Appendix: Snapshot of discusses/comments

(at 2010-12-16 07:31:51 PST)

draft-ietf-mpls-fastreroute-mib

  1. Stewart Bryant: Discuss [2010-12-16]:
        These issues are based on the RTG Area review. 
    
    I understand that the reviewers and editors have agreed text. I will clear when
    the next version is posted.
    
    There is no way in the MIB to read or set a value for "SE Style preferred" as
    defined in RFC4090 Section 4.3. This means there is no way to tell from looking
    at an instance of the MIB whether the ingress node is allowed to reroute the
    protecting LSP without tearing it down. Equally there is no way to read or set a
    value for "Bandwidth protection desired" as defined in RFC4090.
    
    Section 4.2.2 explains how to identify a a detour LSP in the MIB, however the
    fields used for identification differ from those described in RFC4090 Section
    6.1 so it is not clear to me how one could map between an RSVP-TE message and
    the corresponding MIB entry for that detour LSP. This should be described.
    
    Section 4.2.2. includes the following two paragraphs:
    
          A detour LSP is also considered as an instance of a protected
          TE tunnel. Therefore, each detour LSP SHOULD have an entry in
          the mplsTunnelTable (defined in the MPLS-TE-STD-MIB[RFC3812]).
    
          In the mplsTunnelTable, the higher 16 bits of the tunnel instance
          SHOULD be used as a detour instance. Note that for the protected
          TE tunnel instances, the higher 16 bits of the tunnel instance
          MUST all be set to zero.
    
    The first paragraph is fine and included here for context. The second paragraph
    is extremely difficult to parse, partly because it is not explicit as to when it
    is referring to a detour LSP Vs a protected LSP. Do you mean that for protected
    LSPs the high order 16 bits should be set to 0 and for protecting LSPs the high
    order 16 bits should be used as a detour instance. So in the case of a detour
    LSP, it has two mplsTunnelTable entries - one with the high order bits set to 0
    and one with the high order bits set to the detour instance?
    
    Section 4.2.3. The example in this section places the mplsTunnelInstance for the
    protected LSP in the high order bits and the mplsTunnelInstance for the detour
    LSP in the low order bits. However section 4.2.2 specifics that they should be
    the other way round, i.e. protected LSP instance in the low order bits and
    detour LSP instance in the high order bits. 
        
  2. Stewart Bryant: Comment [2010-12-13]:
    From the RtgArea review:
    
    "The document defines three MIB modules but it only provides an example of how
    it could be used for the MPLS-FRR-ONE2ONE-STD-MIB. Personally I find examples of
    how to use MIBs extremely helpful when I have had to make use of a MIB for
    configuration or diagnostics. I would suggest adding examples of usage for the
    other two MIBs specified in the document."
  3. David Harrington: Discuss [2010-12-13]:
        1) I think the following is invalid. Is it legal to have different max-access
    for different enumerations in the same object?
    
       mplsFrrGeneralProtectionMethod OBJECT-TYPE
           SYNTAX        INTEGER { 
                                   unknown(1),
                                   oneToOneBackup(2),
                                   facilityBackup(3)
                                 }
           MAX-ACCESS    read-write
           STATUS        current
           DESCRIPTION
             "Indicates which protection method is to be used for fast
              reroute on this device. Some devices may require a reboot 
              if this variable is to take affect after being modified.
              The value of unknown(1) is read-only and cannot be set.
              If the value of unknown(1) is set an inconsistentValue error
              MUST be returned. It is provided to correct any 
              misconfiguration."
           ::= { mplsFrrGeneralObjects 1 }
    
    2) This error processing would seem to be invalid. inconsistentValue is an
    SNMPv3 error code; this object could not be used with SNMPv1 or SNMPv2c. That
    would violate RFC1052 and RFC3410 architectural separation of the protocol from
    the MIB.
    
    3) mplsFrrGeneralConstraintsEntry talks about what agents must allow. SNMPv3
    moved away from the agent/manager terminology to discussion of specific
    application functionality, such as Command Responders, because the SNMPv1
    concept of agent was no longer valid after Informs were defined.
    
    4) I am not sure how agents know what the LSP signalling allows, especially in a
    master/subagent architecture implementation.
    
    5) mplsFrrGeneralConstraintsEntry : [citations] are not allowed in MIB modules
    because a MIB module is often distributed separately from the surrounding
    document. A REFERENCE clause, or textual mention of an RFC# is acceptable.
    
    6) The MIB does not discuss the persistence of tables and objects across
    reboots. That will have an effect in a number of places.
    
    7) mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the
    agent, but the rows are read-create; is the manager allowed to modify objects in
    the row? (and see previous note about agent/manager terminology)
    
    9) mplsFrrGeneralTunnelARHopProtectTypeInUse seems to only support IPv4. Why?
    
    11) what happens to mplsFrrOne2OnePlrEntry if the corresponding row in the
    mplsTunnelTable is deleted?
    
    12) what happens if mplsFrrGeneralConstraintsEntry is created, but the
    corresponding row in MplsTunnelIndex does not exist?
    
    13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying
    physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in
    this table to protect the LSPs or tunnel instances determined earlier."
    What
    happens if the ifIndex values used in ifStackTable change upon device or
    management system reinitialization? What is the persistence of
    mplsFrrGeneralConstraintsTable?
    
    14) should mplsFrrOne2OnePlrSenderAddrType and mplsFrrOne2OnePlrSenderAddr be
    read-write rather than read-create? If read-create, shouldn't there be a
    rowstatus object? if read-create, what happens if one of these objects is
    deleted?
    
    16) what is the persistence of mplsFrrFacilityDBTable?
    what happens to
    mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of
    the system or the management system?
    
    18) There is a security template for MIB modules that was written to meet exact
    requirements. Authors often think they can improve upon the wording, but almost
    always get it wrong.
    
    The template has been modifed in this document, in a manner that is
    inappropriate. This text is inappropriate because a MIB should not require a
    specific version of SNMP be used, or specific SNMPv3 MIB modules be used:
    The use of stronger 
            mechanisms such as SNMPv3 security should be
    considered where 
            possible.  Specifically, SNMPv3 VACM and USM MUST be
    used with 
            any v3 agent which implements these MIB modules.
    The SNMPv3
    standard (STD61) has VACM and USM as mandatory-to-implement, but not mandatory-
    to-use. The RFC3410 architecture was designed so different access control models
    and different security models and different SNMP message versions can be used
    within an SNMP system. The security provided by the SSH Transport Model
    (RFC5592) or (D)TLS (RFC 5953) with the Transport Security Model (RFC5591) is
    equally strong as USM, and reuses existing security infrastructure. There is no
    reason why USM MUST be **used** with any v3 agent that supports this MIB. 
        
  4. David Harrington: Comment [2010-12-13]:
    8) I am not sure what "object availability" means in
    mplsFrrGeneralTunnelARHopEntry
    
    10) mplsFrrGeneralModuleFullCompliance supports the MPLS-FRR-GENERALSTD-MIB
        mplsFrrGeneralModuleReadOnlyCompliance supports MPLS FRR MIB
    Shouldn't these be consistent in naming the MIB they support?
    
    s/agents/Command Responders/ ??
    
    15) mplsFrrOne2OneModuleFullCompliance supports MPLS-FRR-ONE2ONE-STD-MIB 
        mplsFrrOne2OneModuleReadOnlyCompliance supports MPLS FRR ONE2ONE MIB
    shoudn't these be consistent?
    
    17) RFC4181 says abbreviations should be consistent.
    mplsFrrFacilityBackupTunnelEgressLSRId  and
    mplsFrrFacilityInitialBkupTunnelInvoked  are inconsistent.
    This makes it harder
    for operators to remember whether an name contains "Backup" or "Bkup".
  5. Dan Romascanu: Discuss [2010-12-15]:
        Item #2 in the DISCUSS was modified following input from IANA. 
    
    1. David Harrington made a number of comments in his DISCUSS and COMMENT which I
    support. Especially issues #2 (SNMPv3 specific error messages) and #18 (security
    considerations template) must absolutely be resolved before this document can be
    approved.
    
    2. The document used a process which is not recommended pre-assigning mib-2 OIDs
    for the roots of the three MIB modules in sections 8.1 to 8.3. We discourage
    this practice, as one MIB document designer does not necessarily know what other
    authors are doing in their documents. In this case the MIB authors request the
    allocation of OIDs already in use:
    
    mib-2 numbers 187-189 have already been assigned:
    
        187   forcesMIB          FORCES-MIB                  [RFC5813]
        188   pwTcStdMIB         PW-TC-STD-MIB               [RFC5542]
        189   sshtmMIB           Secure Shell Transport Model MIB  [RFC5592]
    
    The allocation request in this document must be changed and final allocation of
    OIDs left only to IANA.
    
    3. It is not clear to me the reason of defining DEFVAL values for read-only
    objects (mplsFrrIncomingDetourLSPs, mplsFrrOne2OneDetourOriginating, and other).
    Although bot explicitly forbidden by the SMI rules, read-only objects are filled
    in as soon as the agent can complute a meaningful value, so default values are
    in effect for a very short time at initialization and typically not used. If
    there is any special need in this case it should be described and explained. 
        
  6. Dan Romascanu: Comment [2010-12-14]:
    1. It is not clear to me what the follwing text means in the DESCRIPTION clause
    of mplsFrrGeneralTunnelARHopTable
    
              Note that object 
              availability in this table is governed by the support of 
              the Record Route Object in the RSVP-TE signaling of the 
              implementation.
    
    Does this apply to all objects in the table? How does an operator know that the
    fact that this table is not populated is due to the lack of support of the
    Record Route Object?
    
    2. OBJECT        mplsFrrGeneralConstraintsRowStatus
           MIN-ACCESS    read-only
           DESCRIPTION
             "Write access is not required."
    
    Not requiring write access for a RowStatus object means that the respective
    table does not support dynamic row creation. How is it populated? I think that
    some explanation is needed for this case.
    
     3. Specifying just RFC4090 with no clause as REFERENCE  like for
    mplsFrrOne2OnePlrAvoidNodeAddr seems very vague and not useful. Same for RFC3812
    provided as REFERENCE for mplsFrrFacilityProtectingTunnelIndex.
  7. Sean Turner: Comment [2010-12-14]:
    #1 Spell out first use of LSR. 
    
    #2) On page 7:
    
    a) Need "--" before mplsFrr...?
    
            -- The first value would be: 
                               mplsFrrOne2OneDetourActive.1.6553601
    
    b) Need comma after "= 0" in the following?
    
        mplsFrrOne2OneDetourMergedDetourInst   = 0
          }

draft-ietf-sipcore-event-rate-control

  1. Jari Arkko: Comment [2010-12-02]:
    I have reviewed this document and placed a no-objection vote, even if I do agree
    with most of the issues raised by Lars and David. I do think though that despite
    its problems and complexity, the document is understandable enough to be
    reviewed. I think the right path is to fix the specific issues in the document
    rather than to bring the document back to the working group. I do think that the
    document should stick to using either rate or frequency terminology, however.
    
    Also, here are some review comments from Ari Keränen who I asked to take another
    look at the document:
    
    The abstract should state that this document updates RFC 3265.
    
    5.1.  Subscriber Behavior
    
        The value of
        this parameter is an integral number of seconds in decimal.
    
    Should that be "decimal integer"? And probably negative values are not 
    OK (should be stated), but how about zero? Same issue in sections 6.1. 
    and 7.1.
    
    7.3.  Calculating the Timeout
    
        timeout = (average-interval ^ 2) * count / period              (1)
    
    It's not really immediately clear how this formula results in correct 
    timeouts. Say, if one uses average-interval of 10s and period of 100s, 
    based on quick calculation, it seems that the timeouts would be 
    0,1,2,...,9 for the first 10 (batches of) messages (10*10*0/100, 
    10*10*1/100, ...) resulting in all 10 messages being sent during the 
    first 45 seconds (as opposed to 100 seconds); or didn't I get the 
    formula right?
    
    9.2.  Grammar
    
           min-interval-param =   "min-interval" EQUAL delta-seconds
    
    The "delta-seconds" token is not defined.
  2. Ralph Droms: Discuss [2010-12-02]:
        
    I fall somewhere between Jari and David regarding the use of "rate"
    "frequencey" and "interval" terminology.  I agree with Jari that the
    document can be reviewed and fixed with editorial updates.  However,
    this text from section 5.2 is an example of what I think needs to be
    fixed, not just improved:
    
       A compliant notifier MUST NOT generate notifications more frequently
       than the maximum rate allows for [...]
    
    The specific parameter is a minimum interval, not a maximum rate.
    To ensure accurate compliance with the specification, the requirement must
    be stated in terms of the parameter, not the inverse of the parameter
    (which, speaking pedantically, is not as precise):
    
       A compliant notifier MUST NOT generate notifications with an
       interval between notifications less than the currently allowed
       minimum interval [...]
    
    Text such as this excerpt from the next paragraph is OK, but could be
    improved:
    
       When a local policy dictates a maximum rate for notifications, a
       notifier will not generate notifications more frequently than the
       local policy maximum rate
    
    which mixes frequency and rate but is still understandable and has no
    normative requirements langauge.  I think this text would be more
    accurate:
    
       When a local policy dictates a minimum interval for notifications,
       a notifier will not generate notifications more frequently than the
       local policy minimum interval [...]
     
        
  3. Lars Eggert: Discuss [2010-11-30]:
        Section 6., paragraph 0:
    > 6.  Operation of the Minimum Rate Mechanism
    
      DISCUSS: Assuming that you disallow max_interval := 0, this mechanism
      can still be used to get the notifier to generate a notification once
      per second. This can put some stress on the network as well as on the
      notifier. It's also questionable from the example use cases that a
      notification rate that is that aggressive can be useful. Can we define
      a useful max_interval that is larger than 1 second? If not, can we add
      some strong language here to caution implementers to use the lowest
      possible useful rate here? (This also applies to the "adaptive"
      variant.)
     
        
  4. Lars Eggert: Comment [2010-11-30]:
    Section 3.4., paragraph 7:
    >            paremeters are adjusted from the value given by the
    
      Nit: s/paremeters/parameters/
    
    Section 7.1., paragraph 4:
    >    The main consequence for the subscriber when applying the adative
    
      Nit: s/adative/adaptive/
    
    Section 7.3., paragraph 5:
    >    period:  The rolling average period, in seconds.  The value of the
    >       "period" parameter is chosen by the notifier, however the notifier
    >       MUST choose a value greater than the value of the "average-
    >       interval" parameter.
    
      Additionally, period should be several times larger than the
      average-interval, because otherwise, not much averaging will happen -
      the mechanism degrades to the non-adaptive variant.
    
  5. Adrian Farrel: Comment [2010-12-02]:
    Just a few nits in a document I found otherwise to be very readable.
    
    idnits points out...
    
      -- The document has a disclaimer for pre-RFC5378 work, but was first
         submitted on or after 10 November 2008.  Does it really need the
         disclaimer?
    
    ---
    
    Section 1
    
       none of the event package specifications have defined such a
       mechanism.
                                                                                  
    s/have/has/
    
    ---
    
    Section 3.4 Req 7
                                                  
                  For example, due to congestion reasons, local policy at
    
    s/due/owing/
    
    ---
    
    Section 4.1                                                                     
    
       In general, the way in which a subscriber generates SUBSCRIBE
       requests and processes NOTIFY requests is according to RFC 3265
       [RFC3265].
    
    "In general"?
    
    Similarly in section 4.2
    
       In general, the way in which a notifier processes SUBSCRIBE requests
       and generates NOTIFY requests is according to RFC 3265 [RFC3265].
    
  6. David Harrington: Discuss [2010-12-13]:
        1) The document continually refers to both rate and interval - two sides of the
    same coin. I find the current approach to handling this very distracting. I
    think the document would be clearer if you chose one perspective, explained in
    the terminology section how it relates to the other perspective, and then used
    the one perspective consistently. Maybe you should rename the parameters to
    reflect the rate perspective - e.g., change "min-interval" to "max-rate".
    
    section 1 defines min-interval, and equates it to maximum rate:
    "min-interval:
    specifies a minimum notification time period (maximum rate) between two
    notifications, in seconds. "
    This is incorrect; min-interval does not specify
    the maximum rate between two notifications; min-interval refers only to the time
    period. Maximum rate refers to the ratio of the number of notifications per min-
    interval. - min-interval is only the denominator; maximum rate refers to the
    numerator/denominator ratio.
    section 3.1 says, "The maximum rate applies to the
    overall resource list, which means that there is a hard cap imposed by the
    maximum rate to the number of notifications the presence client can expect to
    receive." 
    This sentence is inaccurate on at least two points - 
    a) the sentence
    does not stipulate that the rate is a function of the time period; there is no
    time period specified here, so it could be interpreted as the number of
    notifications received for the lifetime of the client.
    b) maximum rate only
    indirectly imposes a cap on the number of notifications - i.e., the numerator is
    ALWAYS 1. The hard cap per period is imposed by the min-interval, i.e., the cap
    is 1/min-interval. The attribute that varies to establish the cap is the min-
    interval, never the number of notifications.
    The repeated mixing of the interval
    and rate leads to inaccuracies in the spec. The spec would be more accurate if
    the relation of rate to interval was defined in the termonology, and then the
    specification were written from the interval perspective (since this spec is
    about standardizing the settings for the interval parameters.)
    
    2) 3.1 talks about "notifications that do not comply with the maximum rate". I'm
    not sure quite what that means - I assume it means notifications are generated
    faster than they are allowed to be sent. Why not say that? 
    3) 3.1 says the RLS
    will "batch all    of the buffered state changes together in a single
    notification only
       when allowed by the maximum rate." - I don't uinderstand
    "when allowed by the maximum rate". The maximum rate is a number. How does that
    number "allow" batching?
    In addition, section 1 says "it is strictly an
    implementation decision whether batching of notifications is
       supported, and
    by what means." So I don't understand what "allowed by the maximum rate" means
    relative to the implementation decision. My impression is that "maximum rate" is
    being used to refer to an abstraction of the whole process, and that does not
    lead to clear and unambiguous standards specification.
    4) 3.1 says "The presence
    client can also modify the "min-interval" parameter during the lifetime of the
    subscription.  For example, if the User Interface (UI) of the application shows
    inactivity for a period of time, it can simply pause the notifications by
    setting the "min-interval" parameter to the subscription expiration time, while
    still keeping the subscription alive.  When the user becomes active again, the
    presence client can resume the stream of notifications by re-subscribing with a
    "min-interval" parameter set to the earlier used value." 
    This text conflates
    the application, the UI, the user, and the presence client. These are
    potentially different entities - an application's database of activity might be
    a totally different process than its UI. I assume the presence client is an
    abstract fucntionality supported by an application - possibly implemented in a
    totally different process. and the user obviously is neither the application,
    nor the UI, nor the presence client. Is the presence client supposed to have a
    mechanism to watch the UI to see whether there is UI activity? or does it detect
    inactivity by monitoring protocol acivity? How exactly does it detect this-
    which protocols should be watched? 
    5) in 3.2, "In order to control the actual
    state, the location application sets a minimum rate ("max-interval" parameter),
    i.e. a maximum time interval between two notifications." Again, this approach of
    "here, let me say this three different ways" is distracting. More important,
    should this text say that it sends the parameter to the RLS? or does it just set
    an internal parameter paid attention to at the presence client? 
    6) 3.3 says
    "The "average-interval" parameter value is used by the notifier to dynamically
    calculate the actual maximum time ("timeout" parameter) between two
    notifications."  timeout is used before being defined - you might need a forward
    reference here.
    7) 4.1 says "If the subscriber did not include at least one of
    the "min-interval, "max-interval", or "average-interval" header field parameters
    in the most recent SUBSCRIBE request in a given dialog, it MUST NOT include an
    Event header field with any of those parameters in a 2xx response to a NOTIFY
    request in that dialog." The "it" in thsi sentence should be replaced by a named
    "actor". Is this the server that MUST NOT include things in the response?
    8) 4.2
    says "A notifier that supports the different rate control mechanisms will comply
    with the value given in "min-interval", "max-interval" and "average-interval"
    parameters and adjust its rate of notification accordingly.  However, if the
    notifier needs to lower the subscription expiration value or if a local policy
    or other implementation-determined constraint at the notifier can not satisfy
    the rate control request, then the notifier can adjust (i.e. increase or
    decrease) appropriately the subscriber requested rate control." How do I comply
    with a value? I know how to comply weith a standard, but not with a value. The
    "will comply" seems to call for a RFC2119 keyword. "will comply" seems to call
    for a MUST, but the next sentence discusses the exceptions, so I guess "will
    comply" needs to tbe replaced by a SHOULD.
    9) 5.1 says "Note that the witnessed
    time between two consecutive received notifications may not conform to  the
    "min-interval" value for a number of reasons.  For example, network jitter and
    retransmissions may result in the subscriber receiving the notifications with
    smaller intervals than the "min-interval" value recommends." Hmmm. Doesn't min-
    interval mean do not send notifications more fequently than every X seconds?  Am
    I missing somethign in my interprwetation? Doesn't this text say that the
    receiver might receive the notifications at a rate faster than the rate they are
    sent?
    
    10) in 5.5.1, how does one determine the relative sizes of the partial and full
    state notifications? Is there a specification that defines the size of a full
    state notification? The partial state contains values that are differences
    between two full states. Can the size of the partial state be greater than the
    size of the full state, when the partial contains only the differences between
    two full states - the current full state and the last successfully communicated
    full state? And I note that section 5.6 says explicitly "However, even in the
    worst case scenario, where each partial update is to a different part of the
    full state, a rate controlled notification merging all of these n partial states
    together should at a maximum be the size of a full-state update." So why SHOULD
    implementations check whether the partial state notification is smaller than the
    full state notification? 
    11) Is it true that the maximum size should never
    exceed the size of a full state notification? For example, could the size vary
    depending on the encoding language, or the compression algorithm? 
    12) As with
    all SHOULDs, what is the acceptable exception to not checking this? What are the
    full implications if a notifier sends a partial notification instead of a full
    notification when the partial and full are the same size? (If the partial can
    never be bigger than the full, and the only time you would substitute a full for
    a partial is when the partial is not smaller than the full, then they must be
    the same size) I assume the subsequent baseline would be changed when the full
    was sent, and not when the partial was sent. Is there a significant operational
    impact from this happening, that doesn't occur using "accumulated" partials
    anyway? If there are implications, why is this not a MUST?
    13) Is there a
    specification that defines the datatypes supported for calculating differences?
    (Note that SMIv2 defines Counter64 datatypes, but failed to define an unsigned64
    datatype, which would be necessary for representing the difference between two
    Counter64s.
    14) What is an accumulated partial state notification? where is this
    defined?
    15) With partial notifications, the notifier needs to maintain a
    separate buffer for each subscriber since each subscriber may have a different
    value for the maximum rate of notifications. How large a buffer is required of
    compliant implementations? How many subscriptions must a compliant
    implementation support? What happens if an implementation runs out of buffer
    space? (note that this partial-notification requirement is not discussed in
    terms of operational considerations, or in terms of possible DoS under security
    considerations, including those of RFC 5263)
    16) in 6.2, "A compliant notifier
    MUST generate notifications when state changes occur or when the time since the
    most recent notification exceeds the value in the "max-interval" parameter.
    Depending on the event package and subscriber preferences indicated in the
    SUBSCRIBE request, the NOTIFY request sent as a result of a max-interval
    expiration MUST contain either the current full state or the partial state
    showing the difference between the current state and the last successfully
    communicated state.",  Section 6.1 mentions sending an etag in the ntoification,
    presumably instead of a full or partial state. Wouldn't this violate the MUST in
    section 6.2?
    17) in section 9.3, it states "A subscriber that wishes to update
    the value for maximum, minimum or adaptive minimum rate of notifications can do
    so by including all desired values for the "min-interval", "max-interval" and
    "average- interval" parameters in an Event header field of the 2xx response to a
    NOTIFY request." Shouldn't "can do so by including all desired" be "MUST include
    all desired", since not including a value shuts off that specific feature? 
        
  7. Alexey Melnikov: Discuss [2010-12-02]:
        In 9.2:
    
          event-param    =/  min-interval-param
          subexp-params  =/  min-interval-param
          min-interval-param =   "min-interval" EQUAL delta-seconds
    
          event-param    =/  max-interval-param
          subexp-params  =/  max-interval-param
          max-interval-param =   "max-interval" EQUAL delta-seconds
    
          event-param    =/  average-interval-param
          subexp-params  =/  average-interval-param
          average-interval-param =   "average-interval" EQUAL delta-seconds
    
    delta-seconds is not defined in the document. I think it is coming from RFC
    3261, but this needs to be stated explicitly. 
        
  8. Dan Romascanu: Comment [2010-12-16]:
    I support the issues raised by David and Alexey in their DISCUSSes
  9. Peter Saint-Andre: Comment [2010-11-30]:
    1. In Section 3.4, the parameter names do not belong in the requirement
    definitions because they are implementations of the requirements. Thus I
    suggest:
    
       REQ1:   The subscriber must be able to set a maximum rate 
               of notifications in a specific subscription.
    
       REQ2:   The subscriber must be able to set a minimum rate
               of notifications in a specific subscription.
    
       REQ3:   The subscriber must be able to set an adaptive 
               minimum rate, which adjusts the minimum rate of
               notifications based on a moving average.
    
       REQ7:   The notifier must be allowed to use a policy in which
               the maximum rate, minimum rate, and adaptive minimum 
               rate are adjusted from the value given by the subscriber.
    
    2. In Sections 5.1, 6.1, and 7.1, what is "an integral number of seconds in
    decimal"? An integral number sounds like an integer, i.e., a whole number, i.e.,
    not a decimal number. Please clarify.

draft-ietf-morg-list-specialuse

  1. Ralph Droms: Comment [2010-12-15]:
    From this example in section 5.4 and a brief e-mail exchange with Barry:
    
         ==> Set new use for SavedDrafts; MyDrafts changes automatically:
         C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts")
         S: * METADATA "MyDrafts" (/shared/specialuse NIL)
         S: t3 OK SETMETADATA complete
    
    I infer that, in this example, only one mailbox on the server can have
    the \Drafts attribute.  This text from section 2 gives a hint that a
    server may have a restriction that only one mailbox at a time may be
    assigned a specific special use attribute:
    
       All of the above attributes are OPTIONAL, and any given server or
       message store may support any combination of the attributes, or none
       at all.  In some server or message store implementations it might be
       possible for multiple mailboxes to have the same special-use
       attribute.
    
    It would make the restriction explicit to add text here to the effect of "Some
    servers or message store implementations may restrict the use of
    special use attributes so that only one mailbox is assigned each
    special use attribute."
  2. Adrian Farrel: Comment [2010-12-13]:
    I don't think it is appropriate to use RFC2119 terminology in the
    Abstract.
    
    It is probably also not appropriate in the Introduction.
    
    ---
    
    It would be nice to capitalise the section headings.
    
    ---
    
    Section 7
    
       LIST response: There are no security issues with conveying special-
       use information to a client.
    
    Really. Doesn't the exchange of information imply that there is 
    potential to intercept the information. Knowledge of the message store
    usage may be valuable to someone attempting to access messages.

draft-ietf-tls-ssl2-must-not

  1. Stewart Bryant: Comment [2010-12-13]:
    Adrian has an interesting point.
    
  2. Adrian Farrel: Comment [2010-12-13]:
       however, this 
       version does not provide the expected level of security.
    
    I think it provided exactly the "expected" level of security.
    Maybe you mean "does not provide a sufficiently high level of
    security."

draft-ietf-avt-rtp-svc

  1. Stewart Bryant: Discuss [2010-12-16]:
        This is initially a Discuss Discuss
    
    I have two issues that I would like to understand before taking a position:
    
    1) The document discusses a MANE as a type of middlebox. I would like to
    understand whether the content server and user explicitly request the services
    of a MANE to modify the content, or whether it's services are imposed on the
    stream by a third party?
    
    If the server or the user request the services of the MANE, and the traffic is
    explicitly addressed there this fine. If one the other hand the MANE just sits
    in the path and does this, issues of compliance with the Internet Architecture
    and  issues of net-neutrality apply.
    
    2) I would like to understand whether this draft proposes modification to the
    output of an ITU-T codec. If it does, has the draft been liaised to ITU-T to
    ensure that the stream is conferment to their specification. 
        
  2. Alexey Melnikov: Discuss [2010-12-16]:
        [Updated. One issue added at the beginning.]
    
    Issue for the AD to address:
    
    The shepherding write-up doesn't list anything in response to the following
    question:
       In the case of a Media Type review, on what date was the request
    posted?
    
    The registration template was posted to ietf-types@iana.org for 2 weeks review:
     <http://www.ietf.org/mail-archive/web/ietf-types/current/msg00996.html>
    
    Please add this to the ballot write-up, as this is going to be sent out on
    approval.
    
    --------------------
    
    In Section 7.1:
    
    Encoding considerations:
             This type is only defined for transfer via RTP (RFC 3550).
    
    This text is not valid for this field in the registration template. It must be
    moved to the "Restrictions on usage:" field of the template (which is missing
    from this section).
    
    Please check the Section 4.8 of RFC 4288 for the list of valid values for this
    field.
    
    The registration template is also missing the following fields:
    
       Interoperability considerations:
    
       Applications that use this media type:
    
    Please read RFC 4288 for possible values of these fields.
     
        
  3. Alexey Melnikov: Comment [2010-12-12]:
    In Section 7.1:
    
    "Public specification:" --> "Published specification:"
    
  4. Peter Saint-Andre: Comment [2010-12-15]:
    I concur with Alexey's DISCUSS regarding compliance with RFC 4288.
    
    Section 4.5.1 states:
    
       When SST is in use, Section 5.4 of [I-D.ietf-avt-rtp-rfc3984bis]
       applies with the following modifications.
    
    And Section 4.6 states:
    
       Section 5.6 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the
       following modifications.
    
    Does this specification modify 3984[bis], or does it only extend 3984[bis]?
  5. Robert Sparks: Comment [2010-12-14]:
    It would help to more clearly call out the consequences rewriting RTCP has on
    the way SRTP can be used. Currently the document only mentions this (and not as
    directly as it could) in an "Informative Note". Pointing to the last paragraph
    in the Security Considerations section of 3894bis would help.
  6. Sean Turner: Discuss [2010-12-15]:
        #1) Section 3.1: It's probably worth pointing out where the normative
    definitions are.  That is, add "Where there is a discrepancy, the definitions in
    [H.264] are normative."
    
    #2) Section 3.1 the bit about section 3.1.2: If you're copying the definitions
    and then changing them, then it would greatly aid the reader if you said which
    ones you're changing and how.
    
        
  7. Sean Turner: Comment [2010-12-15]:
    #1) The RFC editor will make you remove the reference in the abstract.
    
    #2) Abstract: r/in_Annex/in Annex
    
    #3) Expand HDTV and Mbps.
    
    #4) Section 4.4, last para: Wouldn't it be easier to say SST is the default?

draft-ietf-xmpp-address

  1. Russ Housley: Discuss [2010-11-30]:
        
      In the Gen-ART Review by Elwyn Davies on 30 November 2010, one issue
      was discovered that is easily addressed.  I think consistent terms
      will aid future readers and implementers.
    
        s4.3.1, last para: There should be a formal definition of 'Bare JID'
        as it is extensively used in draft-ietf-xmpp-3920bis.  Note that
        almost all the cases where 'Bare JID' is used, both in this document
        and 3920bis add a expansion that this means <localpart@domainname>,
        except for one instance in s8.1.2.1 of 3920bis where it means just
        <domainname> (also referred to as 'Mere Dominname' elsewhere in
        3920bis!). 
        
  2. Alexey Melnikov: Discuss [2010-12-10]:
        I just can't possibly resist not having a DISCUSS on this document ;-). Below
    are my review comments:
    
    4). DISCUSS DISCUSS:
    Should domainpart be migrated to IDNA2008 now? Apps Area
    is pretty much requiring use of IDNA2008 in all documents. 
        
  3. Alexey Melnikov: Comment [2010-12-10]:
    
      

draft-ietf-sieve-notify-presence

  1. Gonzalo Camarillo: Comment [2010-12-16]:
    In Section 2, the first time XMPP is mentioned there is no reference to the XMPP
    spec. The reference only appears later. Adding a reference the first time XMPP
    appears in the text would be useful.
  2. Adrian Farrel: Comment [2010-12-13]:
    dnd  - Do Not Disturb; the user should not be disturbed now
    
    s/should not/does not wish to/ ?
    
  3. Tim Polk: Discuss [2010-12-01]:
        [This is a preliminary discuss.  I may have additional issues before the
    telechat, but wanted to raise this issue now
    in hopes of resolving it
    beforehand.]
    
    The first and third paragraphs of the security considerations section seem to be
    in conflict.  The first paragraph states 
    that "implementations MUST ensure that
    users can not create scripts that access the presence information of others
    without the proper access controls."  The third paragraph advocates "caching
    presence tests for periods of time, even
    across Sieve script instances."  Is it
    reasonable to expect an implementation to ensure that the different script
    instances *all* satisfy the access controls? 
        
  4. Dan Romascanu: Comment [2010-12-14]:
    1.The language in the Security Considerations section is inconsistent in the way
    it deals with the actions needed to be considered by implementations to mitigate
    the security threats described in this section.
    
    While the first paragraph ends with: 
    
    > In addition, implementations MUST
       ensure that users can not create scripts that access the presence
       information of others without the proper access controls.
    
    the third one says: 
    
    >  Implementations might consider providing options for rate limiting,
       or for caching presence tests for periods of time, even across Sieve
       script instances.
    
    For consitency purposes it would be better to use 2119 language in both places
    or none. My preference would be for a MAY or SHOULD to be used in the later
    case.
    
    2. The OPS-DIR review by Peter Koch questioned the free format of the status
    information for:
    
    > Description:  A human-readable description of the user's availability
            status.  This is similar to the presence element with the same
            name that's defined in Section 2.2.2.2 of RFC 3921.
       Syntax:  There is no formal definition for the values this item may
            take.  It is free-form and may be in any language, and is meant
            for human consumption.
    
    I think that it would be better to clarify that as per RFC 3921 this is a
    natural language description  (which is more clear than 'any language') and that
    Sieve already specifies that strings are in UTF-8 (RFC 5228, section 2.1)
  5. Robert Sparks: Comment [2010-12-14]:
    As far as I can tell so far, nothing in this document would make it hard to
    later
    extend its ideas to cover other types of presence information, up to and
    including
    queries against current location (PIDF-LO) enabling rules like "only
    send me an
    SMS notification if I'm in the country" - so, I'm entering this as a
    comment instead
    of a discuss.
    
    Please consider further reinforcing that these notification capability parameter
    values
    are going to be derived from potentially several inputs, including
    calendars as well
    as presence servers. It would help to informatively reference
    PIDF (RFC3863),
    especially in the registration of the "status" element, pointing
    to PIDF's "note" element 
    in section 4.1.6.
    
    Also please consider calling out considering RPID and PDIF-LO when choosing 
    new capability parameter names in the discussion of  adding new presence items.

draft-ietf-mpls-ip-options

  1. Ron Bonica: Discuss [2010-12-14]:
        This document attempts to fill a very important gap in the the standards. I look
    forward to changing this DISCUSS to a YES when the following issues are
    addressed:
    
    - In order to implement a compliant version of MPLS, the authors must read this
    document. Therefore, this document UPDATES RFC 3031
    
    - Is the scope of this document correct, or should we address all IETF
    encapsulation types (IP-in-IP, MPLS, IPEC). It seems that they should all work
    the same way. RFC 2003 (IP-in-IP) includes some very fuzzy language about IP
    options "generally" not being copied to the outer header, but it doesn't seem to
    have addressed the issue.
    
    - Does encapsulation (of any type) scuttle the intent of some IP options. If so,
    we might want to drop some packets at the head end of the LSP rather than
    forwarding them without the intended per-hop processing. 
        
  2. Ron Bonica: Comment [2010-12-14]:
    - In the introduction, you say
    
    "The IP packet header provides for various IP options as originally specified in
    [RFC791]."
    
    Not all options are defined in 791. Some are defined in RFCs 1191, 1385, 1393,
    2213, and 4782.
    
    - In the introduction, you say
    
    "IP options extend the IP packet header length beyond the minimum of 20 octets.
    As a result, IP  packets received with header options are typically handled as
    exceptions and in a less efficient manner due to their variable length and
    complex processing requirements.  For example, many router implementations, punt
    such IP option packets from the hardware forwarding (fast) path into the
    software forwarding (slow) path causing high CPU utilization."
    
    Even when the forwarding plane can parse a variable length header, it still
    needs to punt to the control plane, because the forwarding plane may not have
    the clock cycles or intelligence required to process the option.
    
    - in the introduction, your use of the word "transparent" is imprecise.
    Transparent means that you can see one thing through another (e.g., glass is
    transparent). IP options are not transparent when encapsulated in MPLS. MPLS
    would be transparent if you could see the IP header through it.
    
    - In Section 4, you say:
    
    When processing of signaling messages or data packets with more specific
    forwarding rules is enabled, this policy  SHOULD NOT alter the specific
    processing rules.
    
    What are these more specific forwarding rules?
  3. Stewart Bryant: Comment [2010-12-13]:
    In Section 4. Ingress Label Edge Router Requirement
    
    "Further, how an ingress LER processes the IP header options of packets before
    MPLS encapsulation is out of scope since the IP packets are received as they
    enter the MPLS domain."
    
    The IP packet is not actually received in the IP component of the LSR, it is
    forwarded.
    
    You could delete "since the IP packets are received as they enter the MPLS
    domain.", or perhaps say "since these are processed before they enter the MPLS
    domain."
  4. Lars Eggert: Discuss [2010-12-16]:
        Section 5.1., paragraph 3:
    >    Further, IPv6 [RFC2460] makes use of extension headers not header
    >    options and is therefore outside the scope of this document.
    
      DISCUSS-DISCUSS: I want to discuss this on the call, after which I
      will clear the DISCUSS. In other words, no author action required at
      this time: Is there a separate document in the works for IPv6? Or do
      we already have the required mechanism specified?
     
        
  5. Lars Eggert: Comment [2010-12-16]:
    INTRODUCTION, paragraph 4:
    >   Requirements for Label Edge Router Forwarding of IPv4 Option Packets
    
      This document isn't really about requirements, it specifies a required
      behavior. Suggest to drop "Requirements for" from the title.
    
    INTRODUCTION, paragraph 7:
    >    This document specifies how Label Edge Routers (LER) should behave
    >    when determining whether to MPLS encapsulate an IP packet with header
    >    options.
    
      Although it's clear from the the title that this document is for IPv4,
      it would be good to s/IP/IPv4/ throughout, for clarity.
    
  6. David Harrington: Discuss [2010-12-14]:
        1) Why does this document not Update 3031 and 3032?
    
    2) There is an assumption in this document that packets with IP options SHOULD
    be sent through MPLS. 
    But somebody put those options in. What if the operator
    deliberately wanted to have the IP options take 
    precedence over the MPLS
    encapsulation? The document does not discuss the security and operational
    considerations of over-riding the IP options and pushing the packets into an
    MPLS tunnel.  For example,
       o Crafted IP strict and loose source route option
    packets that
           belong to a prefix-based FEC yet bypass MPLS encapsulation
    at a
           ingress LER may allow an authorized operator to specify explicit IP
    forwarding path(s) across an MPLS network and, thereby, achieve
           specific
    operational goals. 
        
  7. David Harrington: Comment [2010-12-14]:
    Please consider addressing the issues rasied in the TSVDIR review by James Polk:
    
    I've reviewed this document as part of the transport area 
    directorate's ongoing effort to review key IETF documents. These 
    comments were written primarily for the transport area directors, but 
    are copied to the document's authors for their information and to 
    allow them to address any issues raised. The authors should consider 
    this review together with any other last-call comments they receive. 
    Please always CC <mailto:tsv-dir@ietf.org>tsv-dir@ietf.org if you 
    reply to or forward this review.
    
    Summary:
    This is a well written, concise and needed modification to MPLS.
    
    That said, I don't understand why the 1st minor issue below is 
    present. Recommend (fairly strongly) adding the
    
         "Document Updates: RFC 3031, RFC 3032"
    
    as mentioned below on this first page of this RFC to be.
    
    Transport Issues:
    There are no issues
    
    minor issues:
    - S2 "Motivation", last sentence is
    
       "We believe that this document adds
       details that have not been fully addressed in [RFC3031] and [RFC3032]
       as well as complements [RFC3270], [RFC3443] and [RFC4950]. "
    
    I find it surprising that this document does not formally update 3031 
    and 3032, given that it is mandatory to implement, optional to 
    invoke. ISTM, as an outsider to MPLS, this would in fact be the case 
    given the impact of/to IP stacks not adhering to this proposed standard.
    
    - Section 5.2 is about Router Alert Options, and states "At the time 
    of this writing ...". I wonder if this subsection is valid, or needs 
    another review against this IntArea ID
    http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02
    to still be valid in a month or two once the IntArea ID (currently in 
    WGLC) is processed by the IESG and RFC-Editor?
    
    IMO - these two docs are progressing near enough to each other to 
    each consider what the other says - with or without a normative or 
    informative reference in either or both docs to the other.
    
    [dbh: the draft-ietf-intarea-router-alert-considerations draft does reference
    the mpls-ip-options draft as an example of tunneling to avoid RAO. The two
    drafts are closely linked, and authors should watch closely to make sure they
    stay in sync through the approval/publication process.]
    
    nits:
    - I'm surprised to see the Abstract on page 2. I thought we 
    collectively fixed the case in which the Abstract can be on any page 
    other than page 1.
    
    - at the page Footer, in the middle of the line, there isn't a "short 
    document name" - which has been there on all previous well formed IDs 
    and RFCs that I have seen (which of course is not all of them). It is 
    recommended the authors pick a short form name for the subject of 
    this doc for this location, such as
    
          LER Header Option Behaviors
    
    - S3, 4th para, second to last sentence is:
    
       "First a downstream LSR may
       have not have sufficient IP routing information to forward the packet
       resulting in packet loss. "
    
    recommend removing the first instance of "have". The sentence reads 
    better without it.
    
    - S3, 4th para, last two sentences
    list a "First" and a "Second" reason correctly, but are missing 
    required commas after each word (i.e., "First, ...", and "Second, ..." )
    
    - S3, 5th para, 1st sentence is lacking commas here:
    
       "...FEC, yet are forwarded
       into an IP/MPLS network without being MPLS-encapsulated,
        present..."
    
    - S5.1, last bullet has this:
    
       "...MPLS encapsulation at a ingress LER ..."
                               ^^^^^
    s/a/an
    
    James  
    
  8. Tim Polk: Discuss [2010-12-15]:
        Nice document in general. Thanks!
    
    One simple but discuss-worthy issue:
    
    Shouldn't this update RFCs 3031 and 3032?
     
        
  9. Tim Polk: Comment [2010-12-15]:
    The conformance requirements could be stated more clearly. 
    In the abstract
    "invoked" seems to be the wrong word.  To me at least, it implies that the
    feature gets turned on as part of the protocol run. In light of the discuss
    issue, it also isn't
    clear if it is mandatory to implement in any MPLS LSR, LER,
    or only implementations of 
    this document.
  10. Dan Romascanu: Comment [2010-12-16]:
    I support Ron's DISCUSS and item #1 in David's DISCUSS
  11. Sean Turner: Comment [2010-12-15]:
    I support Dave's first and Tim's discuss position.

draft-ietf-v6ops-3177bis-end-sites

  1. Jari Arkko: Comment [2010-12-16]:
    This document is spot-on, much needed, and its about time we publish it.
    I can warmly recommend it being approved as it is.
    
    I do have a few comments on other AD's comments, however.
    
    Regarding David's Discuss on IPv6-IPv6 address translation, I think
    the current text in the document is actually completely appropriate
    and should not be changed. It is indeed the case that we must avoid
    a situation where address translation becomes necessary from a mere
    tight address allocation policy reason.
    
    Regarding Robert's Discuss on IETF role, I think the text would
    probably read better and be more acceptable to you if it said ...
    the IETF's role ... *in this case*. That is what I think the authors
    meant. The IETF should not, IMO, dictate the exact allocation
    size but rather provide guidelines, for the reasons stated in the
    document.
    
    Regarding the possible need to ask for IAB's approval, I think
    this document is clearly within IETF's scope, the working group
    and the community is behind this proposal and I see no formal reason
    to ask previous authors (including the IAB) for a permission. From
    a basic politeness stance, maybe we should check with the IAB though.
    I propose that this be done as a "for information" query rather than
    as a formal review period, and the AD who holds the discuss can clear
    when we are satisfied that the IAB has had enough time to respond if
    they feel the need to.
  2. David Harrington: Discuss [2010-12-14]:
        In section 1, the text asserts that IPv6/IPv6 NATS must be avoided. I think
    should be avoided is more accurate, since we cannot predict the future needs of
    an applicant. We can certainly try to avoid assigning non-contiguous ranges, but
    we cannot guarantee it. Therefore "must" seems inapprorpiate.
    
        
  3. David Harrington: Comment [2010-12-14]:
     
    "The exact choice of how much address
       space to assign end sites is an issue for the operational community.
       The role of the IETF is limited to providing guidance on IPv6
       architectural and operational considerations. This document provides
       input into those discussions."
    I suggest this might be better worded as
    "This document provides input to the discussions of how much address
       space to assign end sites, as guidance to the operations community."
    
  4. Alexey Melnikov: Discuss [2010-12-12]:
        DISCUSS DISCUSS: The original document came from IAB+IESG. Does this document
    need to also be approved by IAB? 
        
  5. Robert Sparks: Discuss [2010-12-14]:
        This text (which occurs twice in the document) is problematic:
    "The role of the
    IETF is limited to providing guidance on IPv6 architectural and operational
    considerations."
    
    The IETF's role, in general, is clearly much larger. It is not necessary for
    this document to attempt to define
    or limit what the IETF's role is or isn't. I
    suggest deleting the sentences. 
        
  6. Robert Sparks: Comment [2010-12-14]:
    This appears to obsolete 3177, not update it.

draft-ietf-morg-fuzzy-search

  1. Stewart Bryant: Comment [2010-12-03]:
    In reading the text there are a number of cases where "a" or "the" is missing in
    conjunction with "server"
    
    For example:
    Old
    IMAP protocol extension enabling server to
    New
    IMAP protocol extension enabling a server to
    
    ======
    
    This text looks redundant:
    
    Note
    
       A revised version of this draft document will be submitted to the RFC
       editor as a Proposed Standard for the Internet Community.  Discussion
       and suggestions for improvement are requested, and should be sent to
       morg@ietf.org.
    
    =======
    From the security section:
    
       Implementation of this extension might enable a denial-of-service
       attack if the implementation isn't careful to prevent them. 
    
    I am not sure that the implementer can resist a DoS attack, they can only
    implement this feature to be resistant to one.
    
       Implementations should test at least the
       behavior of large messages that contain very long words and/or unique
       random strings. 
    
    I think that the implementers need to test the feature ON large messages
  2. Lars Eggert: Comment [2010-12-16]:
    INTRODUCTION, paragraph 5:
    > Note
    >    A revised version of this draft document will be submitted to the RFC
    >    editor as a Proposed Standard for the Internet Community.  Discussion
    >    and suggestions for improvement are requested, and should be sent to
    >    morg@ietf.org.
    
      This section should be removed.
    
    Section 4., paragraph 1:
    >    Servers SHOULD assign a search relevancy score for each matched
    >    message when the FUZZY search key is given.  Relevancy scores are
    >    given in range 1-100, where 100 is the highest relevancy.  The
    >    relevancy scores SHOULD use the full 1-100 range, so that clients can
    >    show them to users in a meaningful way, such as a percentage value.
    
      Any particular reason why the range isn't 0-100? At least in my mind,
      a relevance of "1" still means "a tiny bit relevant", which is not
      "not relevant."
    
  3. Adrian Farrel: Discuss [2010-12-15]:
        Thanks for this document which carefully skirts around defining "fuzzy" in an
    admirable way.
    
    I found a couple of small points which I think need a little attention.
    
    ---
    
    I found the PARTIAL return option important and was surprised to see it
    "hidden" in Section 6. Surely the nature of a fuzzy search (or indeed 
    any search) is that it could return a large number of matches. Therefore
    the PARTIAL option is needed in all cases.
    
    The solution is to pull this out into its own section "Limiting the
    number of returned messages"
    
    ---
    
    Should Section 8 also suggest rate limiting (at the server) fuzzy search
    requests either globally or from specific clients/users? Should there be
    a consideration for the ability to limit (at a server) which
    clients/users can issue fuzzy searches?  
        
  4. Russ Housley: Discuss [2010-12-15]:
        
      The Gen-ART Review by Brian Carpenter on 2010-12-14 points out that
      the title page header shoulf indicate that this document updates
      RFC 3501. In particular, this document extends the formal syntax of
      search-key to add '"FUZZY" / '.
     
        
  5. Robert Sparks: Comment [2010-12-15]:
    I've cleared based on the RFC Editor note.
    
    There is no new discuss or comment text below.
    
    Previous Discuss text:
    -----
    The draft should be a little more clear that
    different servers implementations are very likely to return a different set of
    results for the same search. A user should net expect the results of a search to
    be consistent over time, even when using the same service (since the service
    provider may choose a new implementation, or upgrade their existing
    implementation, resulting in a completely different "fuzzy" algorithm being
    applied). Also, service load might be distributed over several
    server instances
    (using multiple SRV records perhaps) - if the different instances are not
    running identical algorithms,
    search results will be different.
    
    Should the document constrain a given instance of a server to produce the same
    results when given the same search?
    I suggest not, given the observations above.
    ----
    Previous Comment Text
    ----
    Consider also pointing out that a user may end
    up with different search results when using a dedicated imap client on their
    user device than when using a web interface into the same email store.
    
    Has the group considered adding way for the client to influence the level of
    fuzziness? Does the current mechanism make it hard to add that later if the
    group decided it was useful?

draft-ietf-tcpm-tcp-timestamps

  1. Stewart Bryant: Comment [2010-12-13]:
    2*MSL
    
    Term not defined in the document.
  2. Ralph Droms: Comment [2010-12-15]:
       Stylistic suggestion: in the bullets in section 2, either include
       the parenthetical "(creating a connection in the SYN-RECEIVED
       state)" in every sub-bullet or only the first.
    
       Where ISN comparisons are performed in the rules in section 2, is
       the comparison strictly "less than", or is the (rather unlikely
       event of) wraparound considered?
    
  3. Adrian Farrel: Comment [2010-12-13]:
       The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
       to include a timestamp value in its segments, that can be used to
    
    s/TCP/TCP implementation/?
    
  4. David Harrington: Comment [2010-12-14]:
    section 3:
    s/are important for TCPs that/are important for TCP connections that/
    
    s/break prevent/prevent/
    
    appendix A: "the workaround in RFC 1337" - can you be more specific?
    
    
  5. Russ Housley: Comment [2010-12-15]:
      I expected a few (minor) changes following the Gen-ART Review by
      Francis Dupont on 2010-12-10.  The changes have not appeared yet.
  6. Tim Polk: Discuss [2010-12-15]:
        Nice document, very clear presentation.
    
    I have some relatively minor issues with the Security Considerations section,
    plus a discuss-discuss issue.
    
    (1)
    The first paragraph doesn't really seem to describe a security issue.  I
    wonder if the
    the text should be focused on the (lack of) security implications
    when only one of the
    communicating peers implements the specification.  (As I
    understand it, this algorithm
    never does any worse than the current state.)
    
    (2)
    It seems there is a very minor attack that is enabled by this enhancement -
    certainly nothing that would preclude using this technique, but still there:
    an attacker could spoof a SYN that met the requirements and prevent a
    host from releasing unneeded resources (after the normal TIME_WAIT passed).
    
    This attack could already be performed using the ISNs; this document
    just expands the range of messages that could be used.
    
    Now to the discuss-discuss:  is this really a BCP?  I personally would lean
    to standards track, but want to hear what others think. 
        
  7. Tim Polk: Comment [2010-12-15]:
    
        
  8. Sean Turner: Comment [2010-12-15]:
    I support Tim's discuss.

draft-cheshire-dnsext-dns-sd

  1. Lars Eggert: Discuss [2010-11-30]:
        Section 18., paragraph 1:
    >    IMPORTANT NOTE: Once draft-ietf-tsvwg-iana-ports is published, most
    >    of this IANA Considerations section can be deleted.
    
      DISCUSS: Would it make sense to replace this section with a normative
      reference to draft-ietf-tsvwg-iana-ports? (Currently, it's not even
      cited as a reference?)
     
        
  2. Lars Eggert: Comment [2010-11-30]:
      This document has quite a list of ID nits that should be fixed before
      publication (outdated references, not using example domains/prefixes,
      etc.)
    
  3. Adrian Farrel: Discuss [2010-12-15]:
        I see no reason to hold up the publication of this document especially
    in the light of existing deployments, but I do have two small issues
    I would like to discuss.
    
    ---
    
    The Introduction (fairly) says:
    
       This document simply specifies
       a convention for how existing resource record types can be named and
       structured to facilitate service discovery.
    
    I don't understand what it is about this I-D that is on the standards
    track.
    
    I see from the proto-writeup that:
    
       An earlier revision of this document was reviewed by the IETF and
       the IESG for publication as Informational.  The current revision
       has been updated based on feedback from the earlier reviews.
    
    I went back to the history in the data tracker and I am puzzled.
    AFAICS, revision -04 was the version that received the publication
    request, and that showed:
      Category: Standards Track
    Indeed, draft-cheshire-dnsext-dns-sd-00.txt also shows that intention.
    
    So, I don't think there is historic reason for this disposition.
    
    There is a good deal of 2119 langauge, and I wonder what the consequence
    would be of not abiding by this language. Would it break
    interoperability or mean that the SD function could not be provided by a
    particular DNS server?
    
    Possibly it is the word "convention" used in several places that is 
    inconsistnet with "standards track".
    
    ---
    
    A question for the sponsoring AD.
    
    Has this version of the document been reviewed by the DNSEXT working
    group? I can't find any informaiton on this in the write-up, but the
    DNSEXT charter says...
    
      The WG will review DNS protocol related work which may originate
      elsewhere in the IETF, including AD-sponsored submissions or drafts
      in other working group. 
        
  4. David Harrington: Discuss [2010-12-02]:
        Pasi Sarolahti did a TSVDIR review and raised a couple of points:
    
    1) In several places the document appears to assume that TCP and UDP are
    the only valid transport protocols to be used in service
    records. Then, Section 7 says:
       "the first label of the pair is an
       underscore character followed by the Application Protocol Name, and
       the second label is either "_tcp" or "_udp".
    
       For applications using other transport protocols, such as SCTP, DCCP,
       Adobe's RTMFP, etc., the second label of <Service> portion of its
       DNS-SD name should be "_udp"."
    
    This is confusing. Why wouldn't other transport protocols use
    their own protocol labels, for example "_sctp" or "_dccp"?
    (There is ongoing work for defining UDP encapsulation for SCTP and
    DCCP. In such case the meaning of "_udp" would be even more complicated.)
    
    Generally, I think it would be good to keep a mindset that DNS-SD could be
    used with any transport protocol, not just TCP and UDP, even if they
    are the dominant protocols today.
    
    DBH: the use of _tcp has issues either way, and the TSVDIR debated this comment,
    with no clear resolution. I think the TSV community needs to have this debate
    and provide some guidance for future documents. In the meantime, I think the
    document might do well to mention that it could be used with other protocols,
    and to state that this specification might need to be updated in the future to
    accommodate a different naming scheme.
    
    DBH: I agree that using _udp for other protocols is confusing and should NOT be
    done. Is there a justification for not using _sctp, etc.? 
    update: Mail with
    Lars crossed with my entering the DISCUSS: 
    "The transport being included in the
    SRV RR was a historical mistake. But it can't be rolled back. So TCP services
    use _tcp and all others _udp. (Yes, even SCTP and DCCP.)" 
    Can we add this
    justification to the document to answer the question before it gets asked?
    
    2) Section 6.3, on TXT records:
       "The intention of DNS-SD TXT records is to convey a small amount of
       useful additional information about a service. Ideally it SHOULD NOT
       be necessary for a client to retrieve this additional information
       before it can usefully establish a connection to the service"
    
    As a more minor note, I don't think the sentence should be written in
    normative language, instead of just using a non-capitalized "should
    not" as recommendation for the usual case with TCP. With some
    protocols connecting just based on the port number in the SRV record
    might not be possible. For example DCCP with its service codes could
    be one such case (in the spirit of thinking of possible future
    protocols that might use this service).
    
    DBH: Gnereally when SHOULD is used, I like a discussion of a known exception to
    justify why it is not MUST. I think the DCCP case is an exception that might be
    explained in the document to justify the SHOULD keyword. 
        
  5. Alexey Melnikov: Discuss [2010-11-26]:
        I generally support publication of this document. I have a small list of
    comments I would like to discuss before recomending its final approval:
    
    4.1 Structured Instance Names
    
       In addition, because Service Instance Names are not constrained by
       the limitations of host names, this document recommends that they
       be stored in the DNS, and communicated over the wire, encoded as
       straightforward canonical precomposed UTF-8, Unicode Normalization
       Form C [UAX15]. In cases where the DNS server returns a negative
       response for the name in question, client software MAY choose to
       retry the query using "Punycode" [RFC 3492] encoding, beginning with
    
    This reference is not defined and it needs to be a Normative one.
    
    5. Service Name Resolution
    
       In the event that more than one SRV is returned, clients SHOULD
       correctly interpret the priority and weight fields -- i.e. lower
       numbered priority servers should be used in preference to higher
       numbered priority servers, and servers with equal priority should be
       selected randomly in proportion to their relative weights.
    
    Why is this a SHOULD? I thought compliance with DNS SRV document makes this a
    MUST.
    
    18. IANA Considerations
    
       This document specifies the following IANA allocation policy for
       unique application protocol names:
    
    I don't think it is very clear if this is asking IANA to establish
    a new registry, or use an existing registry.
    
       Allowable names:
         * Must be no more than fifteen characters long
         * Must consist only of:
           - lower-case letters 'a' - 'z'
           - digits '0' - '9'
           - the hyphen character '-'
         * Must begin and end with a lower-case letter or digit.
         * Must contain at least one lower-case letter 'a' - 'z'
         * Must not already be assigned to some other protocol in the
           existing IANA "list of assigned application protocol names
           and port numbers" [ports].
    
    This is missing one rule from draft-ietf-tsvwg-iana-ports-08.txt:
    
      hyphens MUST NOT be adjacent to other hyphens
     
        
  6. Alexey Melnikov: Comment [2010-11-26]:
    4.1 Structured Instance Names
    
       The <Instance> portion of the Service Instance Name is a single DNS
       label, containing arbitrary precomposed (Unicode Normalization Form C
       [UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name.
       It MUST NOT contain ASCII control characters (byte values 0x00 -
       0x1F) but otherwise is allowed to contain any characters, without
       restriction, including spaces, upper case, lower case, punctuation --
       including dots -- accented characters, non-roman text, and anything
       else that may be represented using UTF-8.
    
    How does this interact with draft-ietf-tsvwg-iana-ports? I think it would be
    worth pointing out here to sections that define more restricted formats.
    
    6.4 Rules for Keys in DNS-SD Key/Value Pairs
    
       The characters of "Key" MUST be printable US-ASCII values
       (0x20-0x7E), excluding '=' (0x3D).
    
    This needs a reference to US-ASCII.
    
       [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
                  an IANA Considerations Section in RFCs", RFC 2434,
                  October 1998.
    
    While RFC Editor is likely to fix this automatically, it would be better to
    update this reference to point to RFC 5226.
  7. Tim Polk: Comment [2010-12-02]:
    I do not want to hold up publication of this document, so I am entering this as
    a comment, but hope the authors
    will take the time to review the use of non-
    example domain names in sections 4.1 and the various subsections of 14.
    
    I am not sure that the use of non-example domains in section 4.1 adds anything
    that "example.com" wouldn't provide:
    
      a conventional unicast DNS domain name, such as "ietf.org.",
       "cs.stanford.edu.", or "eng.us.ibm.com."
    
    Since section 14 is a worked example, I expect that no revisions are possible,
    but the authors should consider the
    ramifications of readers playing along at
    home...
  8. Peter Saint-Andre: Discuss [2010-12-01]:
        I strongly support publication of this document. However, I have a few comments.
    
    1. Section 6.4 states:
    
       The "Key" MUST be at least one character. Strings beginning with an
       '=' character (i.e. the key is missing) SHOULD be silently ignored.
    
    Why is this SHOULD not a MUST? How would an application behave if it did not
    silently ignore zero-length keys?
    
    2. Section 7 states:
    
       Application Protocol Names may be no more than fifteen characters
       (not counting the mandatory underscore), conforming to normal DNS
       host name rules: Only lower-case letters, digits, and hyphens; must
       begin and end with lower-case letter or digit. In addition,
       Application Protocol Names must contain at least one lower-case
       letter. This is to prevent service names such as "80" or "6000-6063"
       which could be misinterpreted as port numbers or port number ranges.
    
    I think we need conformance terms here (e.g., "MUST NOT be" instead of "may be
    no"), because later sections (e.g., 7.1, 18) assume that the fifteen-character
    rule is a hard limit.
    
    3. It seems that the IANA Considerations should simply normatively reference to
    draft-ietf-tsvwg-iana-ports, or provide only the minimal information that is not
    covered by that document. 
        
  9. Peter Saint-Andre: Comment [2010-12-01]:
    1. The User Interface Considerations might be more appropriate as an appendix.
  10. Robert Sparks: Discuss [2010-12-15]:
        (Apologies in advance for the pedantic nature of this question)
    Does the special meta-query definition in section 9 (where PTR record's rdata
    is restricted to be a two-label name like _http._tcp.) update the definition of
    PTR?  In particular, does the SHOULD in the last paragraph update the existing 
    definition that the result is a pointer to a location in the domain name space 
    (i.e. root->_tcp->_http)?
    
    Why is the SHOULD in the last paragraph of section 5 not a MUST?  (In the event
    that more than one SRV is returned, clients SHOULD correctly interpret the
    priority and weight fields)
    
    What document contains the normative text that constrains SRV lookups for
    protocols like SCTP and DTLS to use the token _udp? This document should
    reference it. If there isn't such a document, I'm not sure we have community
    consensus that it's the correct standard use of SRV. 
        
  11. Robert Sparks: Comment [2010-12-15]:
    This document contains several instances of opinion and observation that are not
    going to be useful for building interoperable implementations of the protocol.
    Earlier versions of draft-cheshire-dnsext-multicast had similar text that was
    polished out as it was completed, leaving a better document for implementers.
    Please consider a similar editorial pass for this document.

draft-cheshire-dnsext-multicastdns

  1. Jari Arkko: Comment [2009-12-17]:
    
        
  2. Lars Eggert: Comment [2010-11-30]:
      This document has quite a list of ID nits that should be fixed before
      publication (outdated references, not using example domains/prefixes,
      etc.)
  3. Adrian Farrel: Discuss [2010-12-15]:
        Thank you for providing a new revision that addresses the previous IETF
    last call issues.
    
    I found two small concerns that I hope will be really easy to
    adddress and will not hold the document up.
    
    I found the use of 2119 language a bit patchy. It would be really good
    if the authors took a pass on the document to check consistency. Some
    examples from Section 3:
    
       If this happens, the computer
       (or its human user) SHOULD cease using the name, and may choose to
       attempt to allocate a new unique name for use on that link.
    
    Is that MAY?
    
       This document recommends a single flat namespace for dot-local host
    names, (i.e. the names of DNS "A" and "AAAA" records, which map names
       to IPv4
    and IPv6 addresses), but other DNS record types (such as
       those used by DNS
    Service Discovery [DNS-SD]) may contain as many
       labels as appropriate for the
    desired usage, up to a maximum of 255
       bytes, plus a terminating zero byte at
    the end. Name length issues
       are discussed further in Appendix C.
    
    Is that RECOMMENDED and MAY?
    
       In summary: It is
       required that the protocol have the ability to detect and handle name
       conflicts, but it is not required that this ability be used for every
       record.
    
    REQUIRED and NOT REQUIRED?
    
    ---
    
    The mDNS port (5353) is currently shown in the registry with Stuart's
    coordinates (Stuart Cheshire <cheshire&multicastdns.org>). Shouldn't
    we be asking IANA to replace or update with a reference to the RFC this
    document will become?
     
        
  4. Adrian Farrel: Comment [2010-12-15]:
    
        
  5. Russ Housley: Comment [2009-12-16]:
    
        
  6. Cullen Jennings: Discuss [2009-12-17]:
        This is NOT a discuss. I am simply using this flag in the tracker tool to make
    sure that I read the right version of the document. I am highly likely to be a
    YES on this doc. I have been educated about my earlier questions about is this
    should be PS or not and am happy with the current plan. 
        
  7. Cullen Jennings: Comment [2009-12-17]:
    
        
  8. Tim Polk: Comment [2009-12-17]:
    
        
  9. Peter Saint-Andre: Comment [2010-12-15]:
    I strongly support publication of this document. However, I have several
    comments:
    
    1. In Section 5.3 ("Continuous Multicast DNS Querying"), the third paragraph
    states in part:
    
       ... the interval between the first two queries
       SHOULD be at least one second, the intervals between successive
       queries SHOULD increase by at least a factor of two
    
    Is there a good reason why an implementation would override these
    recommendations? If not, do they deserve to be required instead of recommended?
    Also, perhaps a reference to the "truncated binary exponential backoff"
    algorithm from the Ethernet spec (IEEE Standard 802.3) would be appropriate
    here.
    
    2. Section 10 ("Resource Record TTL Values and Cache Coherency") states:
    "Various techniques are available to minimize the impact of such stale data."
    Perhaps it would be appropriate to provide a description of, or pointer to, such
    techniques.
    
    3. Section 23 ("IANA Considerations") contains normative text about how
    implementations are to handle the the designated link-local domains. This
    normative text doesn't comprise instructions to IANA and thus belongs somewhere
    else. Section 12 ("Special Characteristics of Multicast DNS Domains") seems like
    an appropriate home for this text, i.e., the paragraph starting with "These
    domains" as well as the seven bullet points that follow.
  10. Sean Turner: Comment [2010-12-01]:
    For consistency with RFC 5395, all occurrences of "pseudo-RR" should be replace
    with "meta-RR" and it would not hurt to add a reference to RFC 5395 (or the
    rfc5395bis draft which is being fast tracked).

draft-ietf-ipfix-mediators-framework

  1. Jari Arkko: Comment [2010-12-16]:
    Ari Keränen had these comments:
    
    IPFIX, PSAMP and quite a few other abbreviations are never expanded.
    
    Section 5.3:
    
           [...]
           value of the "flowKeyIndicator" needs to be modified when
           modifying the data structure defined by an original Template.
    
    At least for someone not familiar with the protocol, it was not clear 
    how the value needs to be modified in this case.
  2. Stewart Bryant: Comment [2010-12-11]:
    From a protocol conversion point of view, this intermediate entity may provide
    conversion into IPFIX, or conversion of IPFIX transport protocols (e.g., from
    UDP to SCTP) to improve the export reliability.
    
    I assume that you mean to improve export reliability over a sub-network (or a
    network segment) since you cannot improve the  reliability of the UDP segment,
    or an SCTP segment using a low reliability mode.
    
    =======
    
    TLS & DTLS  used without expansion
  3. Gonzalo Camarillo: Comment [2010-12-16]:
    Expand the IPFIX acronym in the title, Abstract, and
    Introduction. All acronyms need to be expanded on their first use.
    
    When referring to a particular section (e.g., Section 2), the
    word "Section" needs to be capitalized.
    
  4. Lars Eggert: Comment [2010-12-16]:
    Abstract:
    >    This document describes a framework for IPFIX Mediation.  This
    >    framework extends the IPFIX reference model by defining the IPFIX
    >    Mediator components.
    
      For the uninitiated, it would be good to add a sentence about what
      "IPFIX mediation" *is*.
    
  5. Adrian Farrel: Discuss [2010-12-15]:
        Just a couple of very small points that could be fixed with an RFC
    Editor's note.
    
    ---
    
    Are we sure this document does not update the IPFIX architecture making
    it an Update to RFC 5470?
    
    ---
    
    I think that RFC 5470 needs to be a Normative reference.
    Also RFC 5655 for its use in Section 9.
    Possibly some of the others (e.g., those referenced from Section 9),
    although I don't feel strongly 
        
  6. Adrian Farrel: Comment [2010-12-15]:
    Section 8 says:
    
       IPFIX Mediation reuses the general information models from [RFC5102]
       and [RFC5477].  However, several Intermediate Processes would
       potentially require additional Information Elements as follows:    
                                                                         
    Is "would potentially" code for "the Information Model is out of scope
    for this document"?

draft-ietf-opsec-protect-control-plane

  1. Jari Arkko: Discuss [2010-12-16]:
        This is a good document, but I had trouble with one aspect. The document
    talks about filtering and rate limiting ICMP traffic and entirely dropping
    all fragmented packets. The document seemed to be unclear whether such
    drastic measures are to be applied to the traffic destined to the router
    itself or all traffic flowing through this. Dropping all fragmented
    traffic through the router would be a very unfortunate design, and would
    have severe impacts to the service that it provides to Internet users.
    
    Please clarify that you meant to filter only traffic destined to the
    device itself, i.e., with a destination address being one of the
    router's addresses. 
        
  2. Jari Arkko: Comment [2010-12-16]:
    Ari Keränen had this comment:
    
    4.  Security Considerations
    
        The filter above leaves the router susceptible to discovery from any
        host in the Internet.  If network operators find this risk
        objectionable, they can reduce the exposure by restricting the sub-
        networks from which ICMP Echo requests or traceroute packets are
        accepted.
    
    In practice this does not help much, since, e.g., TCP scanning would be 
    still possible.
  3. Stewart Bryant: Discuss [2010-12-15]:
        For network deployments where the protocols used rely on IP options, the filter
    is simpler to design in that it can drop all packets with any IP option set.
    
    That looks the wrong way round.
     
        
  4. Stewart Bryant: Comment [2010-12-15]:
    "Modern router architecture design maintains a strict separation of forwarding
    and router control plane hardware and software."
    
    Firstly I agree with the sentiment of this statement, however whilst this is
    true in all high end core routers, and in many mid range routers, it is not
    universally true. The crossover point between distributed designs and classic
    designs depends on the current ability of CPUs and is thus always in a state of
    flux
    
    It is also worth noting that the need to provide isolation and stability for the
    cp with work conservation and fast discard of rouge cp packets has been known
    and incorporated into designs for at least the past 30 years.
    
    ======
    
       o  Drop all IP packets that are fragments
    
    There is some text on this later, but the reader would find it useful to have
    this explained up front. At least a forward reference would be useful.
  5. Ralph Droms: Comment [2010-12-15]:
    It might be useful to add DHCP to the example because of the DHCP
    relay function, rate limiting inbound DHCP traffic from clients and
    restricting traffic from servers to a list of known DHCP servers.
    
  6. Lars Eggert: Discuss [2010-12-16]:
        Appendix A., paragraph 0:
    > Appendix A.  Configuration Examples
    
      DISCUSS: I believe that the sequence of configuration commands in
      appendix A.1 and A.2 constitute "code" (components intended to be
      directly processed by a computer). This means that some boilerplate
      text needs to be inserted, see
      http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
     
        
  7. Lars Eggert: Comment [2010-12-16]:
    Section 3., paragraph 0:
    > 3.  Method
    
      You should be MUCH more clear that Section 3.1 gives a particular
      EXAMPLE of how one might set up a filter to protect the control plane,
      and that any actual deployments SHOULD NOT blindly follow that example
      without considering the network setup at hand.
    
    Section 4., paragraph 1:
    >    The filter above leaves the router susceptible to discovery from any
    >    host in the Internet.  If network operators find this risk
    >    objectionable, they can reduce the exposure by restricting the sub-
    >    networks from which ICMP Echo requests or traceroute packets are
    >    accepted.
    
      Several techniques for tracerouting exists, and "traceroute" packets
      are therefore not so easy to identify. What can be done is preventing
      "TTL expired" ICMP responses from being sent, but that can have
      drawbacks.
    
  8. Adrian Farrel: Comment [2010-12-15]:
    Section 1
    
       While software instructions run on both planes, the
       router control plane software is usually not optimized for high speed
       packet handling.
    
    Did you actually mean "router control plane *hardware* is usually not
    optimized"? It seems to me that the software *will* be optimized since
    who would not want their control plane to scale well?
    
  9. Tim Polk: Comment [2010-12-15]:
    Nice document.  Clear presentation, much appreciated.
    
    +1 on Sean's discuss...
  10. Dan Romascanu: Comment [2010-12-15]:
    I support Sean's DISCUSS

draft-ietf-v6ops-incremental-cgn

  1. Jari Arkko: Discuss [2010-12-16]:
        I think we need a document like this and it should be in the V6OPS
    scope to produce one. In particular, I would like to see a recommendation
    and operational considerations to use CGN + tunneled IPv6 service at
    an ISP. That seems a very likely configuration in many places.
    
    However, I'm somewhat unhappy with some parts of the document. In
    particular:
    
    - it portrays this as a new solution as opposed to recommended
      application of existing components
    - it brings in some IMHO unnecessary extensions and references
    - its treatment of IPv6-IPv4 translation aspects seems outdated
      (referring to NAT-PT)
    
    My suggestion is to go through the document once more and remove
    extra material and take the above focus comments into account, to
    see if you can cast the document in slightly different terms.
    
    More detailed comments:
    
    The document says:
    
       ISPs facing only one pressure out of
       two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
       (to provide IPv6 connectivity services). 
    
    I think you mean IPv4 addresses.
    
    The document says:
    
       In order to
       enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
       access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement)
       can be integrated with the CGN. 
    
    This is wrong. The replacement is already an RFC (or about to become
    one), and there is no reason to switch the reference to the right
    specification. Pointing to the old specification is harmful.
    
    Sections 2.3 and 2.4 would be better cast as "just use existing
    forwarding, NAT, and tunneling technology", than as something where
    you describe behaviour. I had to read the text multiple times to
    determine what was actually going on, and AFAICT there is no
    difference to the application of normal IP forwarding rules and
    tunnel termination logic. I think the usual rules are clearer
    than what the document describes, e.g.,
    
       firstly checks whether the packet is a normal IPv4 packet
       or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN
       translates packet source address from a CGN-scope private IPv4
       address into a public IPv4 address, and then send it to IPv4
       Internet. The CGN records the v4-v4 address mapping information for
       inbound packets, just like normal NAT does. For a v6-over-v4 tunnel
       packet, the CGN needs to decapsulate it 
    
    seems to be saying that we should particularly check tunnel packets,
    but I think the normal way is that the tunnel packet, being addressed
    to the CGN device will naturally enter different processing than
    packets routed/natted through it.
    
    Section 2.5 should mention MTU effects.
    
    The document says:
    
       An ISP can provide its IPv6-only customers with a network-layer
       translation service to satisfy this need. Such a service is not fully
       defined at this time, so we refer to it non-specifically as "NAT64".
       Current work in the IETF is focused on one particular proposal
       [I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be
       provided as a common service located at the border between the ISP
       and the IPv4 Internet, beyond the dual stack CGN from the customer's
       viewpoint. It may be integrated into CGN devices too.
    
    This is quite outdated.
    
    The document says:
    
       [I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a
       DS-lite solution with an additional feature to ease interconnection
       between IPv4 and IPv6 realms. Home users may encounter the problem of
       reaching legacy IPv4-only public services from IPv6-only clients.
       This problem already exists in early phases, but will become more
       serious over time.
    
    I'm concerned that we are unnecessarily listing all kinds of extensions
    that we don't even know are needed and which are definitely not in
    the current IETF agenda. Suggest deleting this paragraph. And delete
    this as well while you are at it:
    
       If a different technology than v4-v4 NAT is chosen for IPv4 address
       sharing, for example [I-D.ymbk-aplusp], the present approach could be
       suitably modified, for example replacing the v4-v4 NAT function by
       the A+P gateway function.
    
    The document says:
    
       For example, the appearance of IPv6 Route Advertisement messages or
       DHCPv6 messages can be used as a signal the availability of DS-Lite
       CGN. When an ISP decides to switch from incremental CGN to DS-Lite
       CGN, it may be that only a configuration change or a minor software
       update is needed on the CGNs. The home gateway can then detect this
       change and switch automatically to DS-Lite mode. The only impact on
       the home user will be to receive a different IPv6 prefix.
    
    I'm not sure I understand what I need to do here as an implementor,
    and whether all the necessary pieces in RAs are already defined. 
        
  2. Jari Arkko: Comment [2010-12-16]:
    The document says nothing of prefix delegation. Maybe it should, or
    should at least point out that discussion about prefix delegation
    can be found in several of the references.
    
    The document says:
    
       For dual-stack ISP networks, dual-stack home gateways can
       simply switch off the v6-over-v4 function and forward both IPv6 and
       IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4
       NAT function. This approach is considered an unlikely choice, since
       we expect ISPs to choose the approach described as incremental CGN
       here because they want to avoid or are unable to complete dual-stack
       deployment completely.
    
    This text is somewhat confusing. I *think* you are saying that you can
    do all this in dual stack ISP network, but that if you were adopting
    this specification to begin with you did not have a dual stack network.
    Please clarify/rewrite, and make sure that the document does not seem
    to recommend against deploying dual stack ISP networks...
    
    Ari Keränen had these questions:
    
    1. Introduction
    
        A smooth transition mechanism is also described in this document. It
        introduces an integrated configurable CGN device and an adaptive HG
        device. Both CGN and HG are re-usable devices during different
        transition periods. It avoid potential multiple upgrade.
    
    What does the last sentence mean?
    
    2. An Incremental CGN Approach
    
        Most consumers remain primarily IPv4.
    
    Should that be, e.g., "Most consumers remain primarily in IPv4-only 
    networks"?
    
    2.4. Behavior of Dual-stack CGN
    
        When a dual-stack CGN receives a data packet from a dual-stack home
        gateway, it firstly checks whether the packet is a normal IPv4 packet
        or a v6-over-v4 tunnel packet.
    
    How is this check performed? And what if the host (i.e., not the HG) is 
    using some v6-over-v4 mechanism; would that cause problems with the check?
  3. Stewart Bryant: Comment [2010-12-16]:
    ISPs facing only one pressure out of 
       two could adopt either CGN (for shortage of IPv6 addresses) 
    
    Do you mean "shortage of IPv4 addresses"? 
    
    =======
    
    Modified GRE 
       [RFC2784] with additional auto-configuration mechanism is also 
       suitable to support v6-over-v4 tunneling.
    
    Do you mean "modified GRE" in which case how is it modified, or do you mean GRE
    supplemented by a signalling protocol to set up tunnels?
    
    ========
    
    The security text on tunnel security seems a little light. If the ISP is going
    to consider the tunnel as own infrastructure and not needing to be policed, the
    ISP needs to consider policing those tunnel endpoint addresses at the boundary
    of the network.
    When an ISP decides to switch from incremental CGN to DS-Lite
    CGN, it may be that only a configuration change or a minor software 
       update
    is needed on the CGNs. The home gateway can then detect this 
       change and
    switch automatically to DS-Lite mode.
    
    This seems very speculative
    
  4. Adrian Farrel: Comment [2010-12-15]:
    An important document; thank you.
    
    I found a few nits you might want to try to fix along the way.
    
    ---
    
    Section 1
    
       Based on this fact, the Internet industry appears to 
       have reached consensus that global IPv6 deployment is inevitable and 
       has to be done expediently.
    
    Do you mean "it is expedient" or "it has to be done expeditiously"?
    
    ---
            
    "CPE" needs to be expanded on first use.
    
    ---
    
    It seems (to me, and from the usage made in the document) capriscious
    that 5969 should be a normative reference, but 5569 informational.
    
    ---
    
    Section 2.2
    
       Other tunneling mechanisms
    such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic 
       Tunnel
    Addressing Protocol (ISATAP) [RFC5214] or Virtual Enterprise 
       Traversal (VET)
    [RFC5558] are also considered.
    
    The passive voice is to be avoided!
    By whom are these other tunneling mechanisms considered, to what end,
    and with
    what result?
    
    ---
    
    Section 2.4
    
       When a dual-stack CGN receives a data packet from a dual-stack home 
       gateway, it firstly checks whether the packet is a normal IPv4 packet 
       or a v6-over-v4 tunnel packet.
    
    You need to say how it checks.
  5. Tim Polk: Discuss [2010-12-16]:
        This is a reiteration of Sean Turner's discuss.  I am entering as a discuss
    (rather than No Objection with
    a supporting comment) so I can be involved in any
    subsequent discussion.
    
    This seems like a perfect document for Experimental.  Running an experiment
    while we work through the
    security issues seems like a nice lead-in to an
    informational or standards track specification.  The current
    spec doesn't feel
    fully baked (esp with respect to security) imho. 
        
  6. Sean Turner: Discuss [2010-12-15]:
        This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).
    
    The security considerations include the following two statements:
    
    Further security analysis will be needed to understand double NAT security
    issues and tunnel security issues.
    
    and
    
    [RFC4891] describes how to protect tunnels using IPSec, but it is not clear
    whether doing so would be an important requirement.
    
    Taken together I've got ask why this isn't experimental?
    
    This one is normal discuss:
    
    It's worth noting early that the proposal has not fully addressed the security
    considerations and that further analysis may show that the proposal might not be
    worth adopting based on what is found during the study of the security
    considerations. 
        
  7. Sean Turner: Comment [2010-12-15]:
    Figure 1: Is it supposed to to be "6 to 4" as opposed to "6 o 4" in the tunnel?
    Or is the "o" just supposed to be over?

draft-ietf-bmwg-reset

  1. Jari Arkko: Comment [2010-12-16]:
    I have no issues with this document, but Ari Keränen found some small
    problems in his review:
    
    2.2. Recovery Time Measurement Methods
    
        There are two accepted methods to measure the 'recovery time':
    
    Is the meaning of "accepted" as in "no other method SHOULD be used" or 
    as in "currently widely used" (or something else)?
    
    4.2. Software Reset Test
    
        A software reset is initiated for example from the DUT's Command
        Line Interface (CLI).
    
    The CLI abbreviation is used already in Section 4.1. Would make sense to 
    move the expanded form there.
    
    The second part of the test "Procedure" (6 lines of text) seems to be 
    identical for all the test cases. Perhaps this text could be in the 
    draft just once and have that single instance referenced in the test 
    case descriptions.
  2. Stewart Bryant: Discuss [2010-12-16]:
         "The tester / operator MAY use either method for recovery time
       measurement depending on the test tool capability. However, the
       Frame-loss method SHOULD be used if the test tool is capable of (a)
       counting the number of lost frames per stream, and (b) transmitting
       test frame despite the physical link status, whereas Time-stamp
       method SHOULD be used if the test tool is capable of (a) time-
       stamping each frame, (b) monitoring received frame's timestamp, and
       (c) transmitting frames only if the physical link status is UP."
    
    The document should explain
    
    1) Why is the phy link status is only applicable in the second case?
    2) Any guidance on choice of method if an equipment can do both?
    
    ====
    
    The scaling considerations consider the RIB not the FIB. To some extent this is
    reasonable in that the number of routes is a topology factor and the number of
    FIB entries is an implementation issue. However given that in many routers it is
    FIB update time that dominates the topic is worthy of greater discussion. One
    particular case where FIB entries come into play is when you get ECMPs (which
    increases FIB entries) another is BGP free core (which reduces them).
    
    ====
    
    When power cycle tests (and maybe some of the other tests) are conducted, I
    would expect that  the outage would be dominated by the specifics of the routing
    protocols, which are not particularly well characterized by this test? In
    particular it's difficult to see how to fairly test this without some
    characteristic of the routing behavior the routing peers being reported in the
    test results. 
        
  3. Adrian Farrel: Discuss [2010-12-15]:
        It looks to me as though a number of these tests might require that
    forwarding state is re-established from an external source (e.g.,
    re-learned from neighbors). Are these situations explicitly excluded
    from the set of benchmarking methodologies described in this document,
    in which case it would be really nice to call this out in the Scope
    section.
    
    If control plane interactions with neighbors were needed, you would
    have a much wider field to describe in order to ensure "fair" reuslts
    for the DUT.
    
    ---
    
    Further to Russ's Discuss, I find the following paragraph in Section 
    4.1 confusing:
    
       Reset procedures that do not require the physical removal and
       insertion of a hardware component are RECOMMENDED. These include
       using the CLI or a physical switch or button. If such procedures
       cannot be performed (e.g., for lack of platform support, or because
       the corresponding Test Case calls for them), human operation time
       SHOULD be minimized across different platforms and Test Cases as
       much as possible, and variation in human operator time SHOULD also
       be minimized across different vendors products as much as practical,
       by having the same person perform the operation, and by practicing
       the operation.
    
    Surely the variations in operator time will not matter. For example,
    the time that a card is out for will not change the test, which is
    measuring the time to recover from when the card is reinsterted. Thus,
    there is no fear of variation between vendors' products becuase the
    ease or insertion of a card is not relevant to the atomic event of
    the card being (finally) inserted.
    
    More of an issue would be how you synchronize the timing event with
    the reinsertion of the card. 
    
    That means hat your Recommendation is sound, but the motivation is
    suspect. 
        
  4. Adrian Farrel: Comment [2010-12-15]:
    "BMWG" is used without expansion.
    
    ---                                                                         
    
    Section 3
    
       In order to provide consistent and fairness                                
    
    s/constistent/consistence/
  5. Russ Housley: Discuss [2010-12-15]:
        
      The Gen-ART Review by Joel Halpern on 27-Nov-2010 included two
      questions.  I think that the should be answered before the
      document is approved:
    
      Is there a reason that section 4.1.1.1 on reset of a single-RP device
      refers to simple removal and re-insertion, without explaining the
      caveats that section 4.1.2 (line card removal and re-insertion)
      provides about using a method to avoid having the human time for
      the removal and reinsertion have a significant effect on the
      operation?
    
      Also, should the same caveat not be applied to section 4.3.1 on
      Power Interruption?  There seems to be an implicit assumption that
      the human operation will be sufficiently fast, and the recovery
      sufficiently slow, that the human element does not matter.  At the
      very least, it would seem that this should be articulated.
     
        

draft-linowski-netmod-yang-abstract

  1. Stewart Bryant: Comment [2010-12-15]:
    s/suggests to enhance/suggests enhancing/
    
  2. Alexey Melnikov: Comment [2010-12-16]:
    I like this extension to YANG, but I haven't reviewed it in enough details to
    vote Yes.
  3. Tim Polk: Comment [2010-12-15]:
    I would like to know why the authors chose not register the yang module in
    Appendix B.
  4. Peter Saint-Andre: Comment [2010-12-15]:
    This document defines what seems like a worthwhile experiment. 
    
    Overall, the specification does not always clearly explain the relationship
    between this extension and YANG itself (e.g., by relating things like complex
    types to particular extension points in RFC 6020), the text is sometimes
    difficult to understand (e.g., the document does not provide very detailed
    justifications for various design decisions, and there are numerous grammatical
    errors), and the document is sometimes poorly organized (e.g., often there are
    no introductory paragraphs before lists and no explanations of the tables, which
    seem to be merely stuck in the middle of the text without any context). These
    problems could be fixed if and when the experiment is completed and a follow-up
    specification is proposed on the standards track, but I don't think it's worth
    spending a lot of time to fix them now.
    
    On the other hand, the document provides many examples, thus helping the reader
    to understand the proposed extensions.
    
    Here are several more concrete comments...
    
    1. The following text is a bit presumptuous:
    
       After successful usage this
       experimental specification can be republished at IETF as a proposed
       standard possibly as part of a future version of YANG.
    
    I suggest the following:
    
       If this experimental specification results in successful usage,
       it is possible that the protocol defined herein could be updated
       to incorporate implementation and deployment experience, then 
       pursued on the standards track, perhaps as part of a future version 
       of YANG.
    
    2. In Section 1.2, the text does not explain that the bullet points are examples
    and therefore not exhaustive.
    
    3. No reference is provided for the "TM Forum SID".
    
    4. In Section 4, please make sure that the registrations provide all information
    in one place (e.g., it's not appropriate to point to the "Authors' Addresses"
    block for the Registrant Contact).
    
    5. The namespaces are mostly of the form "http://example.com/*", but it appears
    that they might be intended for wider use (not merely as examples). If so, I
    suggest using URNs in the ietf tree, or more stable URLs.

draft-arkko-ipv6-transition-guidelines

  1. Ralph Droms: Discuss [2010-12-15]:
        It like the IETF last call on this doc "ends 2010-12-27".  Should it
    be on this week's agenda?
     
        
  2. Adrian Farrel: Discuss [2010-12-16]:
        Excellent document: thanks.
    
    Holding a Discuss until the IETF LC completes 
        
  3. Adrian Farrel: Comment [2010-12-16]:
    Nit
    
    Section 4.2
      There are several types tunneling mechanisms
    s/types/types of/
  4. Tim Polk: Discuss [2010-12-15]:
        This is a discuss-discus.  To be clear, I am not asking for any changes in the
    document with respect to this issue at this time.
    
    Section 3, Principles, opens with the following statement:
    
       The end goal is network-wide native IPv6 deployment, resulting in the
       obsolescence of transitional mechanisms based on encapsulation,
       tunnels, or translation, and also resulting in the obsolescence of
       IPv4.
    
    I do not think that these are the goals of someone deploying an IPv6 network on
    the Internet.  Their motivations
    for deploying IPv6 are more likely focused on
    address availability and the availability of specific features.  Even
    more than
    that, most IPv6 deployments are more focused on ensuring connectivity with the
    installed IPv4 base
    than IPv6 purity.  Citing obsolescence of IPv4 as a goal
    makes the document less convincing to this reader.
    
    I don't think refining the goals would change the set of transition strategies
    to be discussed, but I think there is
    a tone issue that results from the anti-
    IPv4 goals.
    
    A more actionable discuss issue: while this document doesn't create new security
    issues, a discussion of the
    relevant issues probably should take place in this
    spec. 
        
  5. Tim Polk: Comment [2010-12-15]:
    +1 on Ralph's discuss.  In light of the Last Call closing 12-27, it seems
    premature to gauge IETF consensus.
  6. Dan Romascanu: Discuss [2010-12-15]:
        This is a DISCUSS-DISCUSS, as I am not sure that the issue I am raising needs to
    be reflected in this document, but I feel it is important enough to be raised
    with the IESG in the context of this document. I would expect that a discussion
    on the transition mechanisms to IPv6 includes a reference about the network
    management tools that need to be used during the transition, and what would be
    the requirements from the network management systems during the transition in
    the different scenarios. One aspect of the problem is touched by in section 4.3
    (addressability of managed systems) but this is only one of the multiple aspects
    to be discussed. Is the place for such a discussion in this document? 
        
  7. Sean Turner: Discuss [2010-12-15]:
        I hate to just list a bunch of documents as references, but we've just reviewed
    draft-ietf-opsec-ip-security and draft-ietf-v6ops-tunnel-security-concerns is
    coming down the pipe.  Should these and maybe some others you think are
    important be listed in the security considerations? 
        

draft-cheshire-dnsext-nbp

  1. Pasi Eronen: Discuss [2008-12-04]:
        I think the document should be clearer whether these requirements
    represent some kind of IETF consensus, or just opinions of the
    authors.  I'm guessing it's the latter, but this guess is mostly based
    on the I-D file name (which won't be visible once this becomes an RFC).
    
    I agree with Chris that Section 6 should be more realistic about the
    security goals: things like determining the authenticity of received
    information, or authority to request some information, can't usually
    be done with zero configuration.  Even with non-zero configuration, a
    security solution that's realistically deployable in e.g. enterprise
    environment probably has to be able to leverage existing
    authentication and authorization infrastructure (things like Active
    Directory, Kerberos, or internal PKIs come to mind). Besides, the
    problem solved by DNSSEC (authenticating a hierarchical delegation
    structure) is quite different from securing an AppleTalk NBP like
    protocol (even if the messages re-use DNS formats).
    
    Section 7 should probably be clearer what actions IANA is expected
    to take when this document is approved (I'm guessing it's "none", but
    then the text should say "This document has no IANA actions.").
    [Holding a discuss for IANA] 
        
  2. Russ Housley: Comment [2010-04-03]:
    
        
  3. Cullen Jennings: Comment [2008-12-01]:
    This needs a ballot.
  4. Chris Newman: Comment [2008-12-02]:
    I found the security considerations weak, albeit tolerable for this sort
    of informational document.
    
    Some discussion of the usability/deployability/security tradeoffs
    between a
    zeroconf home network and a fully managed DNSSEC
    infrastructure would be
    informative.  Further, I suspect it's a critical
    requirement to replace
    Appletalk NBP that "no security" be a protocol option since there's no way to
    get something with the same
    ease-of-use/ease-of-deployment profile in a home
    network.
    
    Right now there are two security options proposed: none or manually
    configured DNS unicast w/ DNSSEC.  While I consider the "none" option
    very important since that's exactly the security I want to deploy on
    my home WLAN when it comes to this protocol (WPA2-AES is good
    enough for my home WLAN), there are scenarios where I might want
    some sort of middle ground without having to administer a
    DNS infrastructure.  For example, "make sure I connect
    to the same file service as last time", or "make sure I use ipp/tls
    to the printer service and it's the same printer service I used last
    time".  Has any sort of leap-of-faith SSH-style keying been
    considered within this framework?  Indeed, in a large corporation with
    outsourced IT, getting competent DNSSEC management is probably not
    feasible so "grassroots" security might be more viable.
  5. Tim Polk: Comment [2008-12-02]:
    Section 3.15 (Immediate and Ongoing Information Presentation) describes user
    interface requirements rather than the underlying protocol requirements.  I
    suggest revising this
    section in terms of the protocol requirements.
  6. Dan Romascanu: Comment [2008-12-04]:
    I find the name of the document and of the page headers completely misleading.
    IMO the name should be 'Requirements for Replacing AppleTalk Name Binding
    Protocol (NBP)'.
  7. Sean Turner: Comment [2010-12-02]:
    The rewritten security considerations include two points a) had the protocol
    been developed with security in mind then it would have been done differently b)
    when a new/modern version is designed the requirement is that it have security
    measures appropriate to the environment in which it will be used.  Based on the
    changes, I'm changing to no objection.

draft-saito-mmusic-sdp-ike

  1. Adrian Farrel: Discuss [2010-12-16]:
        I have no objection to the progress of this document, but I would like to check
    two things with my fellow ADs.
    
    I expect the RFC Editor would pick this up, but I wondered why this
    document refers to RFC 4306 and not to RFC 5996.
    
    I also wondered whether text (such as in the title and the Abstract) 
    should refer explicitly to "IKE v2" rather than "IKE". 
        

draft-templin-iron

  1. Stewart Bryant: Comment [2010-12-15]:
    I am surprise that the document contains no reference to LISP which is
    operating broadly in this space.
    
    =======
    
    SRA is not a defined abbreviation.
    
    =======
    
    This needs a few words of clarification - presumably the "locator addresses" are
    the addresses learned from the relay.
    
      After the Client receives an SRA message from the nearby Relay
       listing the locator addresses of nearby Servers, it sends SRS test
       messages to one or more of the locator addresses to elicit SRA
       messages.
    
    =======
    				   
    If this Server fails, the Client will quickly select a new
       one which will automatically update the VPC overlay network mapping
       system with a new EP-to-Server mapping.
    
    "quickly" is a non-specific metric
    
    =======
    
    [I-D.templin-intarea-seal] looks like it should be normative
    [I-D.templin-intarea-vet]  looks like it should be normative
    
    Although the RFCeditor may wish to overlook this if there is a concern that
    these drafts will not be taken to completion.
    
    
  2. Ralph Droms: Comment [2010-12-16]:
    I have one suggestion about the content of the document.  I'd like to
    see an analysis of how IRON actually "provide[s] scalable PI
    addressing without changing the current BGP [RFC4271] routing system"
    along with costs incurred by IRON.  How does hiding the EPA addresses
    inside the IRON locator prefixes reduce the routes in the real
    Internet core?  What is the cost in the routing tables maintained by
    the relays?  How expensive is the anycast routing?  How does inter-VPC
    routing work and how expensive is it?
    
    The remainder of my COMMENTs are editorial.
    
    In Section 6.1, I think I understand what this text is trying to
    explain, but I don't think it's correct:
    
       It
       is therefore essential that the Client send the initial packets
       through its Server to avoid loss of SCMP messages that cannot
       traverse a NAT in the reverse direction.
    
    Does this mean to explain that the Client sends packets through its
    Server to establish NAT state so SCMP messages from the Server to the
    Client can traverse the NAT?
    
    In Section 6.2, this text uses "into the Internet" in a confusing way,
    assuming I'm understanding the meaning of the text correctly:
    
       The Server then
       forwards the revised packet into the Internet via a default or more-
       specific route, where it will be directed to the closest Relay within
       the destination VPC overlay network.
    
    Everywhere else in this section "into the Internet" is used to
    describe the forwarding of a decapsulated datagram, after the outer
    header with locator addresses have been removed, into the (non-IRON)
    Internet.  In the text quoted aboce, "into the Internet" seems to mean
    forwarding of an encapsulated datagram, which is described elsewhere
    in this section as simply "forwards" or "sends".  I suggest rewriting,
    for consistency, as
    
       The Server then
       forwards to the closest Relay within
       the destination VPC overlay network.
    
    In Figure 6, why would the anycast datagram from Server(A) be
    delivered to Relay(B) rather than Relay(A) (which presumably would be
    in the routing fabric for ISP A)?  Does it matter? 
    
    Once Server(B) receives the datagram to be forwarded to Client(B), is
    it possible for Server(B) to send a redirect to Client(A) so Client(A)
    can send traffic directly to Client(B)?
    
    Stylistic nit in section 6.4.1 (and elsewhere) - why start using the
    verb "releases" instead of the previously used "forwards" or "sends"?
    Seems like lots of unnecessary verbiage right after Figure 6; why not
    something like "..., host A sends packets to host B through its EUN.
    Client(A), as the defautl router for the EUN, receives the packets,
    encapsulates them in the IRON encapsulation and forwards them to
    Server(A). ..."  (etc.)  All the explanation of routing, etc., seems
    redundant at this point.
    
    Sorry, can't help myself; in section 6.6:
    
       The IRON approach to
       renumbering avoidance therefore depends on VPCs conducting ethical
       business practices and offering reasonable rates.
    
    ... as opposed to the unethical business practices and unreasonably
    high rates from those evil, greedy ISPs.
    
    Seriously, has the renumbering problem simply been moved from the ISPs
    to the VPCs?
    
  3. Adrian Farrel: Comment [2010-12-16]:
    Thank you for bringing this work forward as Experimental and so increasing the
    documentation and discussion of potential solutions.
    
    I feel that it would be helpful if the document contained a pointer to draft-
    irtf-rrg-recommendation so that the other ideas in the field can be easily found
    and compared.