IESG Narrative Minutes

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

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

Corrections from: Barry, Richard, Russ

1 Administrivia

  1. Roll Call 1135 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Pseudowire Preferential Forwarding Status Bit (Proposed Standard)
    draft-ietf-pwe3-redundancy-bit-07
    Token: Stewart Bryant
    Note: Andy Malis (amalis@gmail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pwe3-redundancy-bit):
    1. Benoit Claise: Discuss [2012-05-23]:
      1. In the section 10, you wrote: "This document makes the following update to the PwOperStatusTC textual convention in RFC 5542 [9]:"
      You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context. A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title. Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated.
      Now, looking more closely at your proposed change.
      - dormant(4): The PW is not in a condition to pass packets but is in a 'pending' state, waiting for some external event. For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY".
      The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4).
      IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic. What I believe you should be doing is:
      - a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence
      - you remove "update: RFC 5542"
      2. - Section 5.1 "independent mode".
      What do you mean by "management indication" in:
      "In steady state with consistent configuration, a PE will always find an active PW. However, it is possible that such a PW is not found due to a mis-configuration. In the event that an active PW is not found, a management indication SHOULD be generated. If a management indication for failure to find an active PW was generated and an active PW is subsequently found, a management indication SHOULD be generated, so clearing the previous failure indication. Additionally, a PE MAY use the optional request switchover procedures described in Section 6.3. to have both PE nodes switch to a common PW."
      A syslog message, a SNMP notification, something else, or this is left completely open... in other words: "please do a little bit of management to please the OPS people ;-)"
      Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode"
      note: I never seen the term management "indication". Do you want to say "management notification"?
      3. Here is another point, reported by Dan Romascanu, which I cut/pasted here: I did not have the time for a full OPS-DIR review, but I had a look at draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow. Benoit entered a DISCUSS on a specific issue related to a proposed modification of the PwOperStatusTC from RFC 5542, which I support, but I think that the manageability problems with this I-D are broader. From an operator perspective I believe that there needs to be clear indication of the modes of operation (Independent, Master/Slave) besides the active / standby status of the PW, otherwise there will be no way to understand the status and configuration in different network situations. This may lead to changes to RFC 5542, but I think that mentioning just the MIB changes is not sufficient, as implementing the MIB modules is not mandatory for all PW devices, so the need to expose the modes and forwarding states needs to operators needs to be made in a protocol-independent manner.
    2. Benoit Claise: Comment [2012-05-22]:
      - Section 12 "Major Contributing Authors"
      Not sure if it's a good idea to have this new section title. Knowing how sensitive this authors/contributors topic is, I wouldn't like to see a precedent with this future RFC ,i.e. "I see a Major Contributing Authors, so can we have Minor Contributing Authors section now?" So I would prefer "contributors" and "authors" sections.
      - Section 5.1
      1. For FEC128 PW, the PW with the lowest pw-id value is selected.
      2. For FEC129 PW, each PW in a redundant set is uniquely identified
      No idea what FEC128 and FEC129 were. I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're spelled "FEC 128" and "FEC 129". So please add a reference.
    3. Adrian Farrel: Discuss [2012-05-23]:
      [Discuss updated 5/23 to cross-reference the requirements document for non-reversion and detection of misconfiguration, and to make observations about the failure of a Master in master/slave mode.]
      I have a long and rather rambling Discuss on this document. I think that it is important to address the requirements of management and control of end-to-end service protection as provided by PWs, so I am in no way rejecting the concept of this document. On the other hand, I found quite a number of issues that caused me concern. I have split these across this Discuss (where I hope changes to the text, or conversations in email, will resolve the issues) and Comments where I am less bothered by how or whether you address the issues.
      Section 1: "In order to support AC or spoke PW redundancy, at least one of the PEs on which a PW terminates MUST be different from that on which the primary PW terminates, as described in [6]."
      This is not true, is it? Well, it may be true that the reference says this, but in that case the reference is wrong.
      AC redundancy can be provided using a pair of parallel ACs between the same CE and PE pair (although this seems to be explicitly excluded by figure 4-1). What you are describing is PE protection.
      I think some of the confusion here is because of the terminology inconsistency. RFC 3985 is quite clear that the AC does not form part of the PW. So, this document is all about protecting the emulated service.
      This does appear to be noticed earlier in the section where it says: "Scenarios, such as those above, therefore rely on a set of two or more pseudowires to protect a given VPWS or VPLS."
      I believe that the document should be clear up front that two protection mechanisms are being described in this document. The first is end-to-end service protection (where AC and T-PE failure are protected) and end-to-end PW protection (where the working and protection PWs run between the same pair of T-PEs). The document also needs to note clearly that PW segment protection (i.e. working and protection [multi-] segment protection between a pair of S-PEs) is out of scope.
      >> Ah, I found this in the last paragraph of Section 2. A bit lost in the morass of other text.
      Note that an excellent way to handle this discuss will be the wholesale deletion of text and replacement with a simple reference to [6].
      Looks to me that [6] is used normatively.
      It is not clear to me why you don't support 1+1 protection. But section 2 clearly rules it out.
      "In the absence of faults, all PWs are UP both locally and remotely and a PE node needs to select a single PW to forward user packets to. This is referred to as the active PW. All other PWs will be in standby and MUST NOT be used to forward user packets."
      Perhaps this restriction should be stated. Or is there the possibility that a future protocol extension will be made to add 1+1 support?
      Section 2: "In order for both ends of the service to select the same PW for forwarding user packets, this document defines a new status bit, the 'Preferential Forwarding' status bit, to allow a PE node to indicate the preferential forwarding state of a PW to its peer PE node."
      I may have missed something here, but in 1:1 end-to-end *service* protection, the choice of which PW to use has to be made at the CE not the T-PE. But the signaling (LDP) is between PEs. How does the CE learn the settings of the status code bits?
      I think there is some confusion about when bits are set and cleared in the status code. Some of this is textual.
      Section 11.1 has...: "0x00000020 When the bit is set, it indicates "PW forwarding standby". When the bit is cleared, it indicates "PW forwarding active"."
      Which is good and means that the text should probably refer to this as the "PW forwarding standby bit" rather than "PW Preferential Forwarding" as currently in section 6. (Note that IANA will need a name for the bit in the registry - they seem to have dug the names out of section 6, but this should be explicit in the IANA section of the document).
      Then the bit used for requesting switchover gives me a problem. While I understand the issues (selection from a pool that may be larger than 1, need to synchronize, etc.), the explanation of the status code field in RFC 4447 is clear that setting a bit represents a "fault". Thus, it would be reasonable to handle a set bit as "cannot send traffic on this PW" whereas you are asking for it to mean "please send traffic on this PW". (Again, IANA will need a name for this bit in the registry.)
      I do wonder whether, given the existence of OAM and fault status bits, and the definition of precedence, you need this bit. It even seems to allow conflict with the precedence.
      What happens when a T-PE that supports this I-D sends a switchover request to a T-PE that foes not support this I-D? Presumably it will register the request as a fault (as above) and will not send traffic.
      In section 2: "a. A MANDATORY 1:1 PW protection with a single active PW and one standby PW. An active PW can forward data traffic and control plane traffic, such as Operations, Administration, and Maintenance (OAM) packets. A standby PW does not carry data traffic. "
      This does not say whether OAM packets and be carried on a standby PW. Later, in section 3, I find:
      "Standby PW: An UP PW that is not used for forwarding user traffic, but MAY forward OAM and specific control plane traffic."
      And so on (e.g. Section 6.1)
      "When a PW is in Standby state, the PEs MUST NOT forward user packets over the PW but MAY forward PW OAM packets and specific control plane packets."
      Perhaps, rather than listing types of message, you should note that all ACH packets are allowed.
      Section 2: "b. Multi-homing of a PE node to two or more PE nodes."
      What does this mean? A PE is multi-homed to multiple PEs? I suppose you are trying to talk about parallel PWs between two T-PEs, and a PE that is at the far end of a relationship with a CE that is multi-homed to more than one T-PE?
      Section 3: "The designation of Primary is performed by local configuration for the PW at the PE and is only required when revertive behavior is used."
      But all of the text (for example, in 5.1 and 5.2) uses MUST for reversion, so there appears to be no option.
      Which is odd because the second requiremen of Section 4.1 of draft-ietf-pwe3-redundancy says that non-revertive behavior MUST be supported.
      Section 5: I think that you need to clarify which mode of operation would be used in the case of figure 15-2. I think that master/slave mode cannot be used, and that independent mode only works with configuration. There is a degenerate case of this topology where there is absolutely no LDP communication between the PEs on the active PW and those on the standby PW.
      Section 5.1 first point 2: "we propose"
      please restate this protocol specification in terms of absolute statements of required behavior.
      Section 5.2.: "Note that the behavior described in this section assumes correct configuration of the Master and Slave endpoints. This document does not define a mechanism to detect errors in the configuration."
      I suggest this is broken. You should at least be able to detect the error (not necessary to be able to resolve it) and report it. Also to not get into an unresolvable protocol breakdown when there are two T-PEs that think they are Masters.
      Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3-redundancy seem to speak against this text.
      The timers need to have recommended defaults, and should be called out as configurable.
      Section 7
      [5] is used normatively.
      [8] is used normatively.
      Section 7: The procedures for determining and mapping PW and AC states MUST follow the rules in [8] with the following modifications."
      Does that mean this document updates [8]?
      Section 7.1: "When a PE enters the AC receive (or transmit) defect state for a PW, it MUST send a forward (reverse) defect indication to the remote peers over all PWs in the redundancy set when required by the PW type in [8]."
      I think this is subtly incorrect. It applies only to PWs in the redundancy set that terminate at the PE and that are connected to the AC.
      Section 8: "A PE implementation compliant to RFC 4447 [2], and which does not support the generation or processing of the 'Preferential Forwarding' status bit or of the 'request switchover' status bit, will ignore these status bits if they are received from a peer PE.
      I struggled to find this behavior defined in RFC 4447. While I believe that many implementations might take this approach, I also think many might view the text in 4447 that indicates that the bits represent "faults" to mean that even unknown status code bits should be interpreted as PW failures. (Hence my burbling earlier about flipping the sense of the bits.)
      If you can point me at the text in 4447, I will back off this issue.
      Section 9:I don't think this section should be so banal. You are introducing a feature that allows the compromise of signaling for one PW between one pair of PEs, to change the behavior (disruptively) on a PW between another pair of PEs. That seems to be a new and interesting attack vector.
      Therefore, you should at least flag this point and note that security on a redundant set is only as good as the weakest security on any member of that group.
      On re-reading Section 5.2 I cannot work out what happens if the Master node is the PE that fails. It looks like this is not covered and would provide a problem.
    4. Adrian Farrel: Comment [2012-05-22]:
      In case anyone is hunting, I can find just 4 out of the 12 authors confirming on the PWE3 list that they are not aware of any IPR disclosures that need to be made.
      I continue to be disappointed by the piecemeal invention of bolt-on signaling features for PW management. It really seems that the working group needs to work on a functional architecture for pseudowires to work out all of the bits and pieces that are needed for redundancy, bandwidth, multi-segment routing, etc., etc. I wish this would happen before we incrementally munge the protocol too much, but I understand that this is not directly actionable for the authors of this document.
      (19 other items)
    5. Stephen Farrell: Comment [2012-05-21]:
      The security considerations say that this is the same as for 4447, which is arguably correct, but 4447 really defers to 3036, which a) doesn't consider switching over to a "less good" PW as a potential DoS (is it?) and b) only has TCP-MD5 based security which even in 2001 attracted an IESG note, repeated in 3036 from rfc 2385 (from 1998!). Any chance of getting some 21st century security stuff done in PW-land? (Sorry, but that's hard to resist:-) This is probably not the place to fix that, but it'd be good to know if there's a plan. Is there?
      Nits: ...
    6. Russ Housley: Comment [2012-05-23]:
      Please consider the issues raised in the Gen-ART Review by Miguel Garcia on 23-May-2012. I tend to agree with his points on RFC 2119 language in Sections 5 and 15.
    7. Pete Resnick: Comment [2012-05-21]:
      Section 2: "MANDATORY" "OPTIONAL" "OPTIONALLY"
      Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized words in this section are a new magical usage of which I am unaware. Perhaps you might like to define terms?
      5.1: "The PW endpoints MAY also implement the following optional active PW selection mechanism.
      "1. If the PW endpoint is configured with the precedence parameter on each PW in the redundant set, it MUST select the PW with the lowest configured precedence value."
      So you MAY do something that you MUST do? I am confused.
      "a management indication SHOULD be generated"
      I may not understand what is meant by a "management indication" here, but it sounds like an implementation choice, not something that is required for interoperation. Did I get that wrong?
    8. Martin Stiemerling: Comment [2012-05-21]:
      Please check the idnits: ...
    9. Sean Turner: Comment [2012-05-22]:
      Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit.
      Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Can't you just point from on to the other?
      This uses the TCP MD5 "signature" option [RFC5036]. KARP's hopefully going to get this fixed sooner rather than later. So there's nothing for the authors to do about this otherwise recurring gripe.
      I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark:
      1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036?
      2nd - I think there's only one of them?
      3rd - I think you mean control plane not control protocol?
      How about the following tweaks to the security considerations section:
      "This document uses the TCP MD5 Signature option, as specified in [2], to protect pseudowires. This document has the same security considerations as in the PWE3 control-plane [2]."
      If you want to future proof the text more maybe:
      "LDP extensions/options that protect pseudowires must be implemented because the security considerations for the bits defined in this document have the same security considerations as the PWE3 control-plane [2]."

    Telechat:

  2. Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP (Proposed Standard)
    draft-ietf-pkix-cmp-transport-protocols-19
    Token: Sean Turner
    Note: Steve Kent (kent@bbn.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-pkix-cmp-transport-protocols):
    1. Wesley Eddy: Discuss [2012-05-21]:
      There is significant confusion in terminology in this document, with "transport" used in cases where we would normally use "transfer" to be more clear and consistent with the existing body of RFCs. HTTP is a transfer protocol; TCP is a transport protocol. If the document was scrubbed to fix this terminology, I would have no problem with it going forward.
    2. Stephen Farrell: Discuss [2012-05-21]:
      (1) Today, using HTTP/TLS is not hard. If CMP messages are visible over a public network, then there may be a number of high-level DoS-type attacks possible, e.g. bad-guy sees a certification request for example.com and knows that that will take ~1 day to process so bad-guy goes to another (not so careful) CA and get a cert for example.com denying service to the correct example.com and damaging the CA to whom the original certification request was directed. On this basis, I think this document really needs to make use of HTTP/TLS a MUST-use messages go over any untrusted network, and hence TLS would need to be mandatory-to-implement. I'd also say that IPsec isn't really very relevant here (but would work fine), so I'd suggest that the spec be changed along the lines of:
      OLD: "Therefore users of the HTTP transport for CMP might want to consider using HTTP over TLS according to [RFC2818] or virtual private networks created e.g. by utilizing Internet Protocol Security according to [RFC4301]."
      NEW: "HTTP over TLS [RFC2818] MUST be supported by all nodes implementing this protocol. TLS with strong confidentiality SHOULD be used in all cases, with the only exception being when CMP messages are sent over fully trusted networks, which doesn't happen very often."
      (2) How is RFC 1945 a MUST but not a normative reference and is that then a downref? Is http/1.0 *really* needed as a MUST these days? I'd say s/MUST support/might support/ for http/1.0 and leave 1945 as an informative reference and avoid the messing with new last calls etc.
    3. Stephen Farrell: Comment [2012-05-21]:
      3.3 - is the 200 vs 201/202 point here consistent, seems like not. 3.5 also seems to say what's needed and better, so I'd suggest deleting 3.3 entirely
      3.3 - what are the 3xx "security implications"? Either 4210 is ok or not, so I'm really not sure what's meant here.
    4. Brian Haberman: Comment [2012-05-18]:
      I have no issues with the publication of this document. I only have some non-blocking comments:
      1. Part of the Introduction sounds more like a history lesson and does not bolster the content of the document. I would suggest paring it down and focusing on introducing the functionality.
      2. Terms like "PKIMessage" and "DER-encoded" are not defined anywhere before they are used.
      3. The 2nd paragraph of section 3.3 seems incomplete. It would be useful if some example security implications were discussed.
      4. What purpose does section 4 serve? Are there interoperability functions that could be described? I would suggest providing guidance on how the potential interactions can be handled.
      5. While I appreciate the impact of having unresponsive authors, I don't think the explanatory text in section 7 (paragraph 1) is needed. Simply list those people as previously contributing authors.
    5. Barry Leiba: Comment [2012-05-19]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      I agree with Brian Haberman's comments #3 and #4. On #3: there is a short note in the Security Considerations about using 301 Moved Permanently, but, in general, this should say more about the security implications of using HTTP redirection. Otherwise, "careful consideration of possible security implications" isn't likely. On #4, I think you either need to remove the section or explain it quite a bit better.
      Other comments; no need to respond to these:
      A note to the doc shepherd: Thank you for being clear about the low level of WG interest in the document and the reasons for publishing it despite that. Too often, shepherd writeups try to give what they think are "the right answers", rather than the true and accurate ones.
      A note on Brian Haberman's comment #1: In contrast, I think the "history" in the introduction is useful. After reading Brian's comment I considered each paragraph for removal or abridgment, and found that each one was useful in explaining why the document is making the choices it's making and going in the direction it's going.
    6. Pete Resnick: Comment [2012-05-22]:
      In 3.8: "While implementations MAY make use of all defined features of the HTTP protocol, they SHOULD keep the protocol utilization as simple as possible."
      I find this potentially confusing. If the directive to implementers is that they are allowed to use (and therefore the other side needs to be aware of) all defined HTTP features, the MAY should be uppercased and the SHOULD should not. If the directive to implementers is that they SHOULD keep the protocol use simple, then the first part of the sentence is at best confusing. If the latter is the intent, try:
      "While all defined features of the HTTP protocol are available to implementations, they SHOULD keep the protocol utilization as simple as possible."
    7. Martin Stiemerling: Discuss [2012-05-21]:
      Section 1., paragraph 4: "Before this document was published as an RFC, the draft version underwent drastic changes during the long-lasting work process. The "TCP-Based Management Protocol" was enhanced and a TCP-Messages-over-HTTP transport specification appeared. As both proved to be needless and cumbersome, implementers preferred to use plain HTTP transport following [RFC1945] or [RFC2616]. This document now reflects that by exclusively describing HTTP as transport protocol for CMP."
      The sentence "TCP-Based Management Protocol" was enhanced and a TCP-Messages-over-HTTP transport specification appeared." hit my eye as Transport AD. Is there any meat to have this sentence in here? I would suggest to remove it, in order to not give a wrong impression that the IETF has worked at any time on a TCP over HTTP protocol. The "TCP-Based Management Protocol" is also sort of unknown to me.
      Section 3.7., paragraph 1: "A CMP server may create event-triggered announcements or generate them on a regular basis. It MAY utilize HTTP transport to convey them to a suitable recipient. As no request messages are specified for those announcements they can only be pushed to the recipient."
      How can a HTTP server push data to the client with HTTP? HTTP is a request/response protocol where the client is sending out the requests. I assume that the CMP server is located at the HTTP server. However, the draft isn't completely clear about whether the CMP server is necessarily located at the HTTP server.
      Section 3.7., paragraph 7: "CMP Announcement messages do not require any CMP response. However, the recipient MUST acknowledge receipt with a HTTP response having an appropriate status code and an empty body. When not receiving such response it MUST be assumed that the delivery was not successful and if applicable the sending side may retry sending the Announcement after waiting for an appropriate time span."
      What is this time span?
      Replace "may" with "MAY"?
      Section 3.7., paragraph 10: "A receiver MUST answer with a suitable 4xx or 5xx HTTP error code when a problem occurs."
      This MUST here contradicts this statement "All applicable "Client Error 4xx" or "Server Error 5xx" status codes may be used to inform the client about errors." out of Section 3.3, as 4xx/5xx codes may be support, but this requires that they are supported.
    8. Martin Stiemerling: Comment [2012-05-21]:
      Section 3.3., paragraph 2: "While "Redirection 3xx" status codes MAY be supported by implementations, clients should only be enabled to automatically follow them after careful consideration of possible security implications."
      It would be good to link to your security section about the discussion of this.
      Section 3.4., paragraph 0: "All applicable "Client Error 4xx" or "Server Error 5xx" status codes may be used to inform the client about errors."
      Replace "may" with "MAY"? But see also my DISUCSS about 4xx/5xx codes.
      Section 3.4., paragraph 1: "The Internet Media Type "application/pkixcmp" MUST be set in the HTTP header when conveying a PKIMessage."
      to be precise: MUST be set in the Content-Type header.
      - Section 4: In support of Brian's comment, i.e., what is the purpose of this section?

    Telechat:

  3. Access Network Identifier (ANI) Option for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netext-access-network-option-10
    Token: Brian Haberman
    Note: Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-netext-access-network-option):
    1. Benoit Claise: Discuss [2012-05-23]:
      -The term "vendor" is confusing
      "Vendor ID: The Vendor ID is the SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI]."
      The example in figure 1 speaks about: "Operator-Id: provider2.example.com" Vendor Id, in the network management world is the manufacturer id, while you're after the Operator-Id I see what you want to do, but this is confusing. Also, do we expect that all operators will have Private Enterprise Number?
      Maybe you want to redefine this with something such as (I trust you on the right wording)
      "Operator PEN ID: SMI Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI] for the operator running ... [actually running what, that's another required clarification in the draft] ... the respective interface on mobile access gateway?
      In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by "Operator PEN ID"
      And also add a few sentences about
      - whether all operators should or must now register new PENs for this spec.
      I checked for a couple of my local ISPs, and not all of them had a PEN.
      - if there is no PEN Operator ID, then ANI type= 3, Op-ID=2 MUST NOT/SHOULD NOT be used
      if "SHOULD NOT", what should be default?
      Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
      You want to discuss with the authors of draft-liang-iana-pen-00, be in synch with them.
    2. Benoit Claise: Comment [2012-05-23]:
      - I was wondering about the relationship between the Access Technology Type option and this new Access Network Identifier option. Both of the required at the same time? I finally discovered the answer in RFC5213: the Access Technology Type is mandatory. That would help to stress this in the document, just in case the readers are not that familiar with RFC5213 (like myself)
      -OLD: The Access Network Identifier mobility option MUST contains one or more Access Network Identifier Sub-options.
      NEW: The Access Network Identifier mobility option MUST contain one or more Access Network Identifier Sub-options.
      - Part of the OPS-DIR review, the following editorial comments were reported by Juergen Quittek:
      Section 3.1.1, description of Net-Name length: Following up on the technical issue above: It is not clear, if the Network Name may be of length zero. The description of the AP-Name Length explicitly states
      "If the access point name is not included, then this length MUST be set to a value of zero."
      There is no such statement for the Net-Name Length. Please add A statement, that the Network name MUST NOT be of length zero, Or add a statement like the cited one from AP-Name length.
      Section 3, description of field "Type" under Figure 2: "(IANA-1)" is highly ambiguous. Please replace
      OLD: Type: (IANA-1)
      NEW: It MUST be set to value of (to be defined by IANA), indicating that its a Network-Identifier option.
      Section 3.1.2, description of N and E flag:
      OLD: N: When the flag (N) is set to a value of (1), it means North, else its South
      NEW: N: When the flag (N) is set to a value of (1), it means North, else it means South
      The same applies accordingly to the E flag.
    3. Ralph Droms: Discuss [2012-05-22]:
      I have a concern about tying the interpretation of the "Network Name" field in the Network-Identifier Sub-option to the Access Technology type in the Access Technology Type option. Why not put a "Network Name Type" field - there's a handy set of Reserved bits available - that explicitly identifies the type of the Network Name?
      Without a "Network Name Type" field, the definition of a new Access Technology type will have to include the definition of the interpretation of the "Network Name" field.
    4. Adrian Farrel: Comment [2012-05-23]:
      This is a not-quite-Discuss Comment
      I think a number of references listed as Informative need to be moved to Normative. Specifically:
      SMI
      RFC 3629
      RFC 1035
      RFC 6275
      I am in two mindsabout RFC2460.
      Happy to discuss why/whether this would be appropriate, but it looks like the uses are explicit "do encode this thing you need to read this reference" type of statements.
    5. Stephen Farrell: Discuss [2012-05-21]:
      (1) Why doesn't this use geopriv?
      (2) Why is it ok to send the MN location (3.1.2) without asking the user?
      (3) Why is it ok to send SSID and AP name without asking the user? Many of those are pretty revealing as to MN location.
      (4) I looked at 6275 and 5213 and its not clear to me that these sensitive values, if sent, MUST be protected using IPsec with strong confidentiality and mutual authentication. The authentication part may be ok according to the documents, but I'm not sure if that's the deployed reality. Is it? But even if so, there's nothing much that I can see to ensure confidentiality for this information. Where's all that (clearly) specified?
    6. Barry Leiba: Comment [2012-05-16]:
      IANA Considerations rant:
      "o Action-1: This specification defines a new Mobility Header option, the Access Network Identifier. This mobility option is described in Section 3. The Type value for this option needs to be assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC6275]."
      I noticed the same problem that confused IANA, and was going to kick in a DISCUSS to get it fixed: the registry is called "Mobility Options", and referring to it as a "Mobility Header option" confused it with the "Mobility Header Types" registry. No need for the DISCUSS, though, because the author noticed the error in Pearl's proposed IANA actions, and sorted it out by email.
      So this comment will just serve to beat people up about this, and to rant a bit. You can otherwise ignore it: Folks, it's just not that hard to go to http://www.iana.org/protocols/ and actually *look up* the correct name of the registry you aim to use... and then to use the *exact* name. Please be specific and accurate; it's important.
    7. Pete Resnick: Discuss [2012-05-22]:
      3.1.1: "'E'-bit: 1-bit flag for representing the encoding of the following name field. MUST be set to zero (0) if the network name is encoded using 8-bit octets or to one (1) if the network name is encoded using UTF-8 [RFC3629]."
      So, I want to understand the semantics of the below network name field if the 'E'-bit is 0. What does it mean to be 8-bit octets that are not UTF-8? What is it then? And I'm not sure this is even correct, since further down in the definition of Network Name you say, "Encoding MUST be UTF-8." Something is funky here. Please explain.
      (BTW: RFC3629 is a normative reference, not informative. Please correct that in section 9. I think there are probably several things you've got in the wrong place.)
      "Net-Name Length: 8-bit field for representing the length of the network name to be followed."
      I think you want to specifically say "in octets", since if it's UTF-8, characters is probably *not* what you mean.
      3.1.3: "2 - Realm of the operator. Realm names are required to be unique, and are piggybacked on the administration of the DNS namespace. Realms are encoded using a domain name encoding defined in [RFC1035]."
      "Operator Identifier: Up to 253 octets of the operator identifier. The encoding of the identifier depends on the used Operator-ID Type. Numeric values are encoded in network byte order and strings are in UTF-8 representation and have no terminating '\0' mark."
      So the first part above says that the domain names are encoded to RFC 1035. Are you talking there about the letter-digit-hyphen rules of 2.3.1 of 1035? If so, you should say that. However, if that's what you mean, then clearly those are all US-ASCII. The second part says that "strings are in UTF-8 representation". Now I'm confused. Are you intending to allow things outside of US-ASCII, e.g. unencoded UTF-8 U-labels for IDNs? Something is not right about the above. I also have no idea why you have the note about the terminating '\0'. Please explain.
      Now, all that said, I'm a bit worried about the lack of information on how to compare these things that appears in section 4. Comparing network names you seem to leave to DHCP, but others you don't talk about. If you have to compare these things, are you going to (and do you have to) deal with comparing UTF-8 strings which have different normalizations? Perhaps the answer is "no" and these are not things that need to compare if one contains "latin small 'o' followed by combining diaeresis" and the other contains "latin small 'o' with diaeresis". But if these two *do* have to compare as identical, you're going to need to say more about how those comparisons (and normalizations) happen.
    8. Robert Sparks: Discuss [2012-05-23]:
      ( no change - just reformatting to make this easier to read in the tracker )
      Can the document provide more clarity on what kinds of things the LMA is expecting to use the information carried by this extension for? Specifically, how is geolocation going to be used? Is there normative text in some other document that constrains what the LMA can do with this information? Could it be used, for instance, for dispatching emergency services?
      The document is inconsistent in describing what the location represents. Some sections say it is the location of the MAG. Other sections say it is the location of the network (which is very unclear). The security considerations section says it is the location of the mobile node. What this location represents needs to be very clearly stated.
      If the security consideration text is correct, and this location is intended to represent (even as coarsely as which AP a user is attached to) the location of the MN, and thus the MN's user, then the considerations in RFC6280 do come into play, and the document needs to account for them.
      What is the expected relationship/trust model between the APs and the MAGs in Figure 1? Are they required to be part of the same administrative domain? What are the consequences if incorrect data is provided when the information is "dynamically obtained through some of out-of-band means".
      The geolocation format proposed in this document doesn't allow specifying details like the coordinate reference system. Was reusing an existing format (such as the geo-uri in RFC5870) considered? Is there a need to express precision or uncertainty?
    9. Sean Turner: Comment [2012-05-24]:
      I'm piling on with Stephen and Robert.

    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. The Atom "deleted-entry" Element (Proposed Standard)
    draft-snell-atompub-tombstones-15
    Token: Barry Leiba
    Note: This document switched from Informational to Standards Track,
    because of Robert's DISCUSS suggestion.  But that happened
    across the transition to new IESG members, so the document
    needs two more positions.  ADs with no positions, please add
    your ballot, and I'll put this back on the telechat for 24 May.
    Discusses/comments (from ballot draft-snell-atompub-tombstones):
    1. Benoit Claise: Discuss [2012-05-21]:
      I don't think I have seen a reply to the Chris' review below, part of the OPS-DIR review... [snip]
    2. Benoit Claise: Comment [2012-05-21]:
      I have the same comment as Adrian Farrel: the 3 lines introduction is very very light, and doesn't give much background and references.
    3. Adrian Farrel: Comment [2012-05-21]:
      My Comment raised on -14 persists in -15.
      I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.
    4. Stephen Farrell: Comment [2012-02-24]:
      1. I didn't really get what's meant by "When an at:deleted-entry element appears in a Feed document other than it's source Feed or when an at:deleted-entry element that has a source Feed document is used in the context of a Deleted Entry Document, it MUST contain an atom:source element."
      But I guess Atom developers probably do so that's ok.
      2. Last para of section 6: I guess that if someone did MAC and then symmetrically encrypt one of these (is that as unlikely as I think?) then it might be useful to tell them not to use the same key for both.
      3. Digital signatures by themselves do not provide non-repudiation. Please delete that term.
    5. Pete Resnick: Discuss [2012-05-20]:
      I intend to move to Yes, but I've got a couple of concerns with text in section 3:
      "An Atom feed MAY contain atom:entry elements and at:deleted-entry elements sharing the same atom:id value. Atom processors SHOULD ignore any at:deleted-entry elements sharing an atom:id value with an atom:entry whose atom:updated element specifies a date and time more recent than or equal to the at:deleted-entry element's when value."
      What exactly are the semantics associated with a feed that has both an atom-entry and at:deleted-entry for the same atom:id? Is it something like "marked for delete before purged"? How might this situation come up? I'm worried that there is not enough information in here (and the SHOULD is making me more worried) to be able to implement this in an interoperable fashion. Please explain.
      "Implementors should note that the at:deleted-entry element is informative in nature only and may be ignored by Atom processors."
      I'm not sure what the above means. What is it informative of? Do you really mean "advisory" instead of "informative"? Or do you mean "probabilistic" (which would concern me)? Are you saying that an Atom processor can't rely on an at:deleted-entry?
      "The presence of an at:deleted-entry element does not guarantee that the atom:entry to which it is referring will no longer be available."
      Again, I'm not sure what the above means in practice. If it doesn't guarantee it, does it probabilistically indicate it? Again, what are the semantics of the thing?
    6. Sean Turner: Comment [2012-05-19]:
      Most of s5 and s6 are copied from RFC 4287 can't you just point to RFC 4287 for the text? In both s5 and s6, it's the last 3 paragraphs. Was the last paragraph of s6 supposed to be titled signing and encrypting like it was in 4287?
      I guess this made sense to the atom folks but those blurbs only talk about the processors of the feed, but where is the requirement for the generator of the feed? It's great to require that only RSA be supported instead of DSA and that AES-128 CBC be the only choice for the processor, but if the generator uses one of the other allowed W3C allowed algs how do you get interop?
      Assuming you import the text from RFC 4287 this is probably moot but ... in the following:
      "Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of TripleDES, AES-128, and AES-256. Processors that decrypt Deleted Entry Documents MUST be able to decrypt with AES-128 in Cipher Block Chaining (CBC) mode."
      What does the second sentence add? Was it trying to say that processors only have to support AES 128 CBC because it's the only thing that's going to be used?
      Nothing to do on this one: I really hate MACs being characterized as signatures.

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Low Extra Delay Background Transport (LEDBAT) (Experimental)
    draft-ietf-ledbat-congestion-09
    Token: Wesley Eddy
    Note: Murari Sridharan (muraris@microsoft.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-ledbat-congestion):
    1. Stewart Bryant: Discuss [2012-05-23]:
      There are a lot of timing assumptions and many specific references to NTP. The draft should go to the TICTOC and NTP WGs with a request for their review of these aspects of the draft.
      Detailed comments below:
      "Applications. Thus the extra delay induced by LEDBAT must be below 150 ms to reduce impact on delay-sentive applications."
      I find this a suprising comment given that earlier in the document you state that LEDBAT is not aimed at this class of application. Please can the authors provide clarity.
      A.2. Clock skew: "The clock skew manifests in a linearly changing error in the time estimate. For a given pair of clocks, the difference in skews is the skew of the one-way delay estimate. Unlike the offset, this no longer cancels in the computation of the queuing delay estimate. On the other hand, while the offset could be huge, with some clocks off by minutes or even hours or more, the skew is typically small. For example, NTP is designed to work with most clocks, yet it gives up when the skew is more than 500 parts per million (PPM). Typical skews of clocks that have never been trained seem to often be around 100-200 PPM."
      This needs evidence and qualification
      "Previously trained clocks could have 10-20 PPM skew due to temperature changes."
      This also needs evidence and qualification
      "A 100-PPM skew means accumulating 6 milliseconds of error per minute. The base delay updates mostly takes care of clock skew unless the skew is unusually high or extreme values have been chosen for TARGET and BASE_HISTORY so that the clock skew in BASE_DELAY minutes is larger than the TARGET."
      This needs to be reviewed by some NTP experts.
    2. Stewart Bryant: Comment [2012-05-23]:
      "Given that the base delay is constant,"
      It's not completely constant in the face of routing changes
      "implementation as a reference:" o correction with faster virtual clock:"
      This is the first time you have introduced the reader to a virtual clock.
    3. Benoit Claise: Discuss [2012-05-24]:
      1. Since "LEDBAT is an experimental delay-based congestion control mechanism", I was wondering when the LEDBAT is not appropriate. And I was very surprised not to see a reference to RFC 6297. Specifically http://tools.ietf.org/html/rfc6297#section-2.2, "Potential Issues with Delay-Based Congestion Control for LBE Transport". A sentence such as the following, from RFC 6297, is particularly important to mention: "this makes such protocols highly sensitive to eventual changes in the end-to-end route during the lifetime of the flow [Mo99]."
      2. Then I was wondering: what about ECMPs with different delays? Is LEDBAT appropriate or not? I could not deduced from the document if you keep the list of delay per host, or per transport. If per transport, LEDBAT is appropriate. If per host IP address, LEDBAT might have some issues in case of significant different delays in the ECMPs. A new section about LEDBAT applicability would be welcome.
      3. how can I monitor that LEDBAT doesn't do any harm or does actually the job? I understand that LEDBAT is experimental, but also deployed, but how do we monitor the impact? What if LEDBAT misbehaves: how do we notice? And I don't see in the charter that you're going to address the manageability and operational aspect in a different document.
    4. Benoit Claise: Comment [2012-05-24]:
      OLD: The International Telecommunication Union's (ITU's) Recommendation G.114 defines a delay of 150 ms to be acceptable for most user voice applications.
      NEW: The International Telecommunication Union's (ITU's) Recommendation G.114 defines a one way delay of 150 ms to be acceptable for most user voice applications.
    5. Ralph Droms: Discuss [2012-05-23]:
      I would be somewhat more comfortable with a "warning label", perhaps as a new section 2.3, that explicitly describes safe deployment scenarios, identifies and specifies crucial parameters for safe operation, and explains what experimental results will be produced.
      Before requiring any new text, I have a few questions that do not require any immediate action on the part of the authors. These questions may result in an actionable Discuss position.
      1. As this document suggests an ongoing experiment that will be run on the Internet, I'd like to know if the WG chairs and the document authors see any situation in which deployment of this experimental protocol could be harmful to the operation of the Internet.
      2. Are there specific operational parameters that are crucial to the safe operation of this protocol?
      3. Is there a plan for explicit experimentation to gather results that will allow this protocol to be published on the Standards Track?
    6. Ralph Droms: Comment [2012-05-23]:
      Minor editorial issue: I don't understand this sentence at the end of section 4.2.1:
      "As closer the extra delay gets to the TARGET value, as slower LEDBAT will increase the window."
    7. Stephen Farrell: Comment [2012-05-21]:
      One security/2119 question and a bunch of nits on what's a good document.
      section 7 - you say a protocol using LEDBAD "should" authentiate timestamp and delay fields. Is that a 2119 SHOULD? If so, then someone who turns up with an I-D that uses LEDBAT but has no MTI authentication might get DISCUSS comments on that basis. Is that what you want? If not, then perhaps s/should/ought/ will reduce the scope for possible future confusion. You could also mean that if using (D)TLS then the timestamp and acks SHOULD be protected, but that its ok for a protocol that has no MTI security (heaven forbid:-) to use LEDBAT.
      (See also the recent endless discussion on case for 2119 keywords on ietf-discuss if you've time to spare:-)
      I don't mind how you choose to handle this, since its really an issue to be handled when LEDBAT is used, but think that this could usefully be clarified here.
      nits: ...
    8. Brian Haberman: Comment [2012-05-17]:
      I am happy to see this document being published. I only have a minor, non-blocking, comment.
      In several places within the document, it says that LEDBAT is "no more aggressive than TCP". Given the wide range of TCP congestion control algorithms, I think it would be good to indicate which ones are being compared to LEDBAT. I assume the document is referring to those congestion control algorithms that conform to RFC 5681.
    9. Barry Leiba: Comment [2012-05-21]:
      A nit:
      -- Section 2 -- The second sentence looks like it needs to be split in two after "however", perhaps with a colon.
      Mail to Stanislav Shalunov is bouncing. If you can't get a current address, you should probably remove him from the front-page authors list, and move him to a "Contributors" section to avoid delays during AUTH48.
      My original DISCUSS, now recorded as a comment for posterity: ... [snip]
    10. Sean Turner: Comment [2012-05-21]:
      Had the same security question Stephen had.

    Telechat:

  2. Pseudowire Redundancy (Informational)
    draft-ietf-pwe3-redundancy-08
    Token: Stewart Bryant
    Note: Andy Malis (amalis@gmail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-pwe3-redundancy):
    1. Benoit Claise: Discuss [2012-05-23]:
      Thanks for the section 4.2. Operational Requirements, but I believe that you miss the monitoring part. Only configuration is mentioned at "o (T-)PEs participating in PW redundancy MUST support the configuration of revertive or non-revertive protection switching modes if both modes are supported."
      Please add a bullet point about the monitoring of the protection switching mode, along with the configuration. Always imagine the situation of two NMS changing the configuration....
    2. Benoit Claise: Comment [2012-05-23]:
      I've been confused by the section 3.2.1 title "Single Multi-Homed CE". When I looked at the first sentence in that section, "The following figure illustrates an application of single segment pseudowire redundancy", I thought: ok, "single" in the title means SS-PW. The figure 2 was in line with that assumption. Following the same logic, "3.2.2. Multiple Multi-Homed CEs" was targeting MS-PW. However, the figure 3 was not representing MS-PW
      Ok, I got now, thanks to Stewart Bryant's explanation, but my point remains: please change the 3.2.* section titles to something more meaningful. For example: [Single-Homed | dual-Homed] CE With [ MS-PW SS-PW] Redundancy
      Note: I always start reading a document by analyzing the table of content!
      Along the same lines, section 3.2 is only for SS-PW, right? So be consistent with the sentence from 3.2.1 "The following figure illustrates an application of single segment pseudowire redundancy.": either copy it or remove it (if you have the title right)
      Part of the OPS-DIR review done by Nevil Brownlee, a few typos: ...
    3. Adrian Farrel: Discuss [2012-05-23]:
      Thanks for this document. It is quite readable and explains the scenarios well.
      Unfortunately, the document does not cover all possible scenarios and it is hard to tell whether some key ones are left out on purpose (because they are not needed), on purpose (because they are hard to solve), or by mistake (but are still important). Maybe section 3.2 can help by explaining whether the reference scenarios are examples or a closed set.
      I have a specific case in mind that can be captured by the following figure.
      [see link]
      In this figure, it is unclear to me whether coordination between the active and standby PWs is possible without a "vertical" control protocol. But I am also not sure whether this is needed given that the PWs could be permanently provisioned and the switching could be performed in the CEs based on service-level OAM.
      But the answer to this question begs a big question about the solutions proposed for a number of the other scenarios. The issue can be summed up by asking: what is the difference between service-level protection and PW protection?
      Note that the figure is a developed case of figure 2, or a degenerate case of figure 3.
      There seem to be some unstated assumptions about how CEs detect and act on failures. For example, in 3.2.1 it is not clear whether both ACs from CE1 are intended to be sending traffic all the time (so that the PEs make the switching choices) or whether CE1 is expected to detect failure and switch over to the other AC.
      For the reverse direction traffic, this is an interesting problem because unless the CE is running continuity OAM in the active emulated service, it may not know that it needs to start receiving on the other AC.
      But, if there is an assumption that ACs are live-live, or that the emulated service runs OAM, then the PW protection requirements are quite a bit simpler.
      I think your references to RFC 4447 should often be to RFC 4446. For example, in Section 2:
      "o Up PW: A PW which has been configured (label mapping exchanged between PEs) and is not in any of the PW defect states specified in [RFC4447]. Such a PW is is available for forwarding traffic."
      But, maybe you would also want this to be future-proof. When *any* PW fault is reported by the status code field, doesn't that make a Down PW?
      The exclusion of 1+1 is, I suppose, OK if it has WG support. But the presentation in Section 4.1 is a bit abrubpt: "you might be able to do 1+1 is you like, but it is out of scope."
      Can you do two things:
      - indicate that 1+1 is out of scope near the top of the document so that readers get the picture
      - give some reason why it is out of scope
    4. Adrian Farrel: Comment [2012-05-23]:
      (11 items)
    5. Barry Leiba: Comment [2012-05-05]:
      Matthew, thank you: the -08 version is clear, and a pleasure to read. It has fixed all my concerns about the language. Good work.
    6. Sean Turner: Comment [2012-05-22]:
      Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit.
      Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit. Can't you just point from on to the other?
      This uses the TCP MD5 "signature" option [RFC5036]. KARP's hopefully going to get this fixed sooner rather than later. So there's nothing for the authors to do about this otherwise recurring gripe.
      I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark:
      1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036?
      2nd - I think there's only one of them?
      3rd - I think you mean control plane not control protocol?
      How about the following tweaks to the security considerations section:
      "This document uses the TCP MD5 Signature option, as specified in [2], to protect pseudowires. This document has the same security considerations as in the PWE3 control-plane [2]."
      If you want to future proof the text more maybe:
      "LDP extensions/options that protect pseudowires must be implemented because the security considerations for the bits defined in this document have the same security considerations as the PWE3 control-plane [2]."

    Telechat:

  3. Usage of The RSVP Association Object (Informational)
    draft-ietf-ccamp-assoc-info-03
    Token: Adrian Farrel
    Note: Deborah Brungard (dbrungard@att.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-ccamp-assoc-info):
    1. Brian Haberman: Comment [2012-05-18]:
      I have no objection to the publication of this document. I do have a comment/suggestion though...
      1. I believe that the 2nd paragraph of the intro can be substantially re-worded or deleted altogether. The thrust of the draft is to provide additional detail on the use of association information. That does not require referencing Adrian's e-mail to the list.
      2. If the text in the intro that references Adrian's e-mail is removed, the Acknowledgments section can be re-worded to drop the reference as well.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. IPv4 Options for ILNPv4 (Experimental)
    draft-irtf-rrg-ilnp-v4opts-03
    Token: Ralph Droms
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-v4opts):
    1. Stewart Bryant: Discuss [2012-05-23]:
      I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work.
      The IETF is working to phase out IPv4, and yet the proposal here seems to be to extend the capabilities of IPv4, which is contra to that goal. If this draft is to be published it should surely go straight to historic status.
      I do not think that we should be authorizing the assignment of IPv4 options to this protocol. The purpose of the protocol is to run an experiment and as such it should preferably be run on one of the existing experimental options. If the existing experimental options are not of a suitable type, a new experimental option could be considered.
    2. Stewart Bryant: Comment [2012-05-23]:
      Re the para starting: "Currently deployed IPv4 routers from multiple router vendors use packet forwarding silicon that is able to parse past IPv4 options to examine the upper-layer protocol header at wire-speed on reasonably fast (e.g. 1 Gbps or better) network interfaces."
      I am not sure what routers designs the authors have evaluated, but I would have anticipated that a significant number of deployed routers will either drop or punt any packet that does not start with 45 in the first octet.
    3. Adrian Farrel: Comment [2012-05-23]:
      I agree with Stewart's Discuss stating that there is no need to allocate IPv4 options for this experiment since it can be run on existing experimental options.
      The authors give a reason why using the existing values would not meet their requirements. I dispute the reason as follows:
      "In order to experiment with a new protocol, an experimental value may be needed that won't collide with an existing or future usage."
      It is precisely the nature of experiments that they may colide if they are run in overlapping networks. There are sufficient code points available that this can be coordinated if there are multiple experiments. There are no existing experiments that immediately spring to mind. Future experiments will be less likely as IPv4 is sunsetted.
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      "This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.

    Telechat:

  2. IPv6 Nonce Destination Option for ILNPv6 (Experimental)
    draft-irtf-rrg-ilnp-noncev6-03
    Token: Brian Haberman
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-noncev6):
    1. Stewart Bryant: Discuss [2012-05-23]:
      I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced.

    Telechat:

  3. ICMP Locator Update message for ILNPv6 (Experimental)
    draft-irtf-rrg-ilnp-icmpv6-03
    Token: Brian Haberman
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-icmpv6):
    1. Stewart Bryant: Discuss [2012-05-23]:
      I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced.
      Additionally, when the author of draft-templin-aero wanted to do experimental work using ICMPv6 we directed them to using an experimental identifier. For consistency we should do the same in the case of the ILNP experiment. If a new experimental type is needed we should create that and make it available to all experiments.
    2. Adrian Farrel: Discuss [2012-05-23]:
      Agreeing with Stewart, I cannot see (from this document or from discussions in email threads) why ILNP cannot make use of Experimental code points to conduct this experiment.
      Indeed, the Abstract says: "This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP)."
      ...which seems to be in direct contradiction with the IANA considerations section.
      I propose that the IESG refuse this request for a code point and refer the authors and IRSG to the existing experimental code points.
      I think the 5742 review should note that this work is related to the work conducted in the LISP and HIP working groups. Presumably, if it is using ICMP, it is also related to work in 6man.
    3. Adrian Farrel: Comment [2012-05-23]:
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.

    Telechat:

  4. ICMP Locator Update message for ILNPv4 (Experimental)
    draft-irtf-rrg-ilnp-icmpv4-03
    Token: Ralph Droms
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-icmpv4):
    1. Stewart Bryant: Discuss [2012-05-23]:
      I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced.
      The IETF is working to phase out IPv4, and yet the proposal here seems to be to extend the capabilities of IPv4, which is contra to that goal. If this draft is to be published it should surely go straight to historic status.
      I do not think that we should be authorizing the assignment of ICMPv4 codepoints to this protocol. The purpose of the protocol is to run an experiment and as such it should preferably be run on one of the existing experimental codepoints. If the existing experimental codepoints are not of a suitable type, a new experimental option could be considered. This is consistent with the advice given to the author of draft-templin-aero wanted to do experimental work using ICMPv6 we directed them to using an experimental identifier.
    2. Adrian Farrel: Discuss [2012-05-23]:
      [Updated Discuss to reflect new discoveries in the IANA registries]
      I think that the IESG's 5742 response on this document should note that this is related to the work in LISP and HIP. I wonder whether it should also note that it is related to Sunset4.
      I am very uneasy about allocating a new code point for ILNP from the ICMP message type registry. This seems incompatible with reducing the work on extensions that keep IPv4 viable and detract from moving to IPv6. It seems that (as with LISP) the bulk of the research work should be focussed on IPv6, and the IPv4 work should be archival not experimental.
      Thus, I do not think the IESG should grant the request for a code point in this case.
      Two ICMP messages types (253 and 254) are provided for experimentationand could be used in this case.
      The authors also note in this document: "there is no architectural difference between using ICMP and using some different framing, for example UDP."
      therefore I believe that our refusal of a code point would not prevent experimentation from being done.
    3. Adrian Farrel: Comment [2012-05-23]:
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      "This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.

    Telechat:

  5. ILNP Engineering Considerations (Experimental)
    draft-irtf-rrg-ilnp-eng-03
    Token: Sean Turner
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-eng):
    1. Stewart Bryant: Discuss [2012-05-24]:
      This is a discuss discuss and is entered for IESG procedural reasons.
      This document needs an IESG response that is consistent with the responses for the other documents in this set.
    2. Stewart Bryant: Comment [2012-05-24]:
      Section 10.4 calls up problems that are better described as access router problems and not end-system changes. These are quite serious issues and probably need greater prominence.

    Telechat:

  6. DNS Resource Records for ILNP (Experimental)
    draft-irtf-rrg-ilnp-dns-03
    Token: Ralph Droms
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-dns):
    1. Stewart Bryant: Comment [2012-05-24]:
      I agree with the Discuss and Comments entered by Adrian
    2. Adrian Farrel: Discuss [2012-05-23]:
      I think the IESG 5742 review should mention that this work is related to work done in LISP and HIP. Presumably, the suggested additions to DNS make it related to DNSEXT as well.
    3. Adrian Farrel: Comment [2012-05-23]:
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      "This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.

    Telechat:

  7. ILNP Architectural Description (Experimental)
    draft-irtf-rrg-ilnp-arch-03
    Token: Adrian Farrel
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-arch):
    1. Stewart Bryant: Discuss [2012-05-23]:
      I think that we need to go with at least the statement concerning LISP and HIP as these are experimental protocols being run by IETF WGs.
      Additionally the document needs to include either a reference to to RFC 6115, or equivalent reservation text so that it is treated with parity WRT to the LISP documents. The document also needs to provide a reference to the LISP work.
      The IPv4 text in the draft implies that we are continuing to develop IPv4 functionality and should be changed to make it clear that IPv4 is entering the end of its life.
    2. Stewart Bryant: Comment [2012-05-23]:
      (about 16 items)
    3. Wesley Eddy: Comment [2012-05-21]:
      I found one typo: Section 3.3: "thought it" -> "though it"
      In section 5.2, MP-TCP is actually being defined by the MPTCP working group (not TCPM). You could cite RFC 6182 for the MPTCP architecture.
    4. Adrian Farrel: Comment [2012-05-23]:
      The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says:
      "This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation."
      "An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on."
      It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
      This is particularly important in this document as it is the cornerstone of the ILNP project.
      I believe it would also be really good to do more analysis in this document of what type of further experimentation is welcomed, and how it should be carried out. Without that, this document is little more than a hostoric record.
      A reference in the Introduction to RFC 6115 would be highly appropriate.
    5. Pete Resnick: Comment [2012-05-22]:
      I am fine with either 5742 IESG note, but if we go with the latter one about LISP and HIP, it should probably apply to all of the documents. I don't know what Lars would do differently based on the IESG note, so it is probably moot.

    Telechat:

  8. Optional Advanced Deployment Scenarios for ILNP (Experimental)
    draft-irtf-rrg-ilnp-adv-03
    Token: Stephen Farrell
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-rrg-ilnp-adv):
    1. Stewart Bryant: Discuss [2012-05-24]:
      This is a discuss discuss and is entered for IESG procedural reasons.
      This document needs an IESG response that is consistent with the responses for the other documents in this set.

    Telechat:

3.3.2 Returning Items

  1. (none)

1302 EDT break

1307 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Simple Cloud Identity Management (scim)
    Token: Barry

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Protocol to Access WS database (paws)
    Token: Pete

    Telechat:

4.2.2 Proposed for Approval

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

    Telechat:

  2. Network File System Version 4 (nfsv4)
    Token: Martin

    Telechat:

  3. Multipath TCP (mptcp)
    Token: Wes

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Approve ICMPv6 Type allocation for draft-irtf-rrg-ilnp-icmpv6 (Brian Haberman)

    Telechat:

  2. Approve IPv6 Destination Option allocation for draft-irtf-rrg-ilnp-noncev6 (Brian Haberman)

    Telechat:

  3. Replace designated expert for Well-Known URIs (Barry Leiba)

    Telechat:

  4. Approve IPv4 Option Type numbers (Ralph Droms)

    Telechat:

  5. Approve ICMPv4 Type number assignment (Ralph Droms)

    Telechat:

  6. IPR disclosures on individual and WG I-Ds (Ralph Droms)

    Telechat:

  7. NOTE WELL (Russ Housley)

    Telechat:

7. Agenda Working Group News

Amy: secretariat issue, CDNI scheduled Interim without message to us, thus announced only on CDNI list
Several: should cancel
Russ: one of them should do it
Amy: two three-hour virtual meetings, May 29 and 30, both virtual (no travel issues to consider)
Russ: we need to find out from WGCs what went wrong; bottom-line is there wasn't the announcement... I will send them a note, cc to Secretariat
Robert: Wes is on jabber; I'll have him get in touch with you

1402 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-05-24 07:30:06 PDT)

draft-ietf-pwe3-redundancy-bit

  1. Benoit Claise: Discuss [2012-05-23]:
    1.
    In the section 10, you wrote:
       This document makes the following update to
    the PwOperStatusTC
       textual convention in RFC 5542 [9]:
    You can't simply
    update a Textual Convention (TC) like this, but putting a new TC, out of
    context.
    A TC belongs to a MIB module. You need a new revision of that MIB
    module: RFC5542bis.
    Note: you could cut/paste the new revision of the MIB module
    in this document, and obsolete RFC5542, but that would be misleading from the
    document title.
    Also, having a new RFC5542bis will cause some problems: there
    are many TCs in there, so surely, many references to RFC5542... which in turn
    will need to be updated.
    
    Now, looking more closely at your proposed change.
         - dormant(4):   The PW
    is not in a condition to pass
                           packets but is in a
    'pending' state,
                           waiting for some external event. For
    example, the
                           PW Preferential Forwarding status state
    machine as defined in [RFC
                           XXXX (this document)] is in
    state "STANDBY".
    
    The only change that you require is the addition of "For example, the PW
    Preferential Forwarding status state machine as defined in [RFC XXXX (this
    document)] is in state "STANDBY" in dormant(4).
    
    IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't
    require the extra work to produce RFC5542bis. Indeed, you don't change the TC
    semantic.
    What I believe you should be doing is:
    - a sentence such as (I trust
    you on the exact wording): this document illustrates how the dormant value of
    the PwOperStatusTC TC can be used to ..." and you include the meaning of your
    initial extra sentence
    - you remove "update: RFC 5542"
    
    2.
    - Section 5.1 "independent mode". 
    What do you mean by "management indication" in:
    
       In steady state with consistent configuration, a PE will always find
       an active PW. However, it is possible that such a PW is not found due
       to a mis-configuration. In the event that an active PW is not found,
       a management indication SHOULD be generated. If a management
       indication for failure to find an active PW was generated and an
       active PW is subsequently found, a management indication SHOULD be
       generated, so clearing the previous failure indication. Additionally,
       a PE MAY use the optional request switchover procedures described in
       Section 6.3. to have both PE nodes switch to a common PW.
    
    A syslog message, a SNMP notification, something else, or this is left
    completely open... in other words:
    "please do a little bit of management to
    please the OPS people ;-)"
    
    Can you justify why you don't even mention "management indication" in the second
    mode, i.e. section 5.2 "master/slave mode"
    note: I never seen the term
    management "indication". Do you want to say "management notification"?
    
    3. 
    Here is another point, reported by Dan Romascanu, which I cut/pasted here:
    I did not have the time for a full OPS-DIR review, but I had a look at
    draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow.
    Benoit entered a DISCUSS on a specific issue related to a proposed
    modification of the PwOperStatusTC from RFC 5542, which I support, but I
    think that the manageability problems with this I-D are broader. From an
    operator perspective I believe that there needs to be clear indication
    of the modes of operation (Independent, Master/Slave) besides the active
    / standby status of the PW, otherwise there will be no way to understand
    the status and configuration in different network situations. This may
    lead to changes to RFC 5542, but I think that mentioning just the MIB
    changes is not sufficient, as implementing the MIB modules is not
    mandatory for all PW devices, so the need to expose the modes and
    forwarding states needs to operators needs to be made in a
    protocol-independent manner.
    
  2. Benoit Claise: Comment [2012-05-22]:
    - Section 12 "Major Contributing Authors"
    Not sure if it's a good idea to have
    this new section title.
    Knowing how sensitive this authors/contributors topic
    is, I wouldn't like to see a precedent with this future RFC ,i.e.  "I see a
    Major Contributing Authors, so can we have Minor Contributing Authors section
    now?" So I would prefer "contributors" and "authors" sections.
    
    - Section 5.1
    
       1. For FEC128 PW, the PW with the lowest pw-id value is selected.
    
       2. For FEC129 PW, each PW in a redundant set is uniquely identified
    
    No idea what FEC128 and FEC129 were.
    I had to search and found
    http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're
    spelled "FEC 128" and "FEC 129".
    So please add a reference.
  3. Adrian Farrel: Discuss [2012-05-23]:
    [Discuss updated 5/23 to cross-reference the requirements document for non-
    reversion and detection of misconfiguration, and to make observations about the
    failure of a Master in master/slave mode.]
    
    I have a long and rather rambling Discuss on this document. I think 
    that it is important to address the requirements of management and
    control of end-to-end service protection as provided by PWs, so I am
    in no way rejecting the concept of this document. On the other hand, I
    found quite a number of issues that caused me concern. I have split 
    these across this Discuss (where I hope changes to the text, or 
    conversations in email, will resolve the issues) and Comments where I
    am less bothered by how or whether you address the issues.
    
    ---
    
    Section 1
    
       In order to support AC or spoke PW redundancy, at least one of the 
       PEs on which a PW terminates MUST be different from that on which the 
       primary PW terminates, as described in [6].
    
    This is not true, is it? Well, it may be true that the reference says 
    this, but in that case the reference is wrong.
    
    AC redundancy can be provided using a pair of parallel ACs between the
    same CE and PE pair (although this seems to be explicitly excluded by 
    figure 4-1). What you are describing is PE protection. 
    
    I think some of the confusion here is because of the terminology
    inconsistency. RFC 3985 is quite clear that the AC does not form part 
    of the PW. So, this document is all about protecting the emulated
    service.
    
    This does appear to be noticed earlier in the section where it says:
            
       Scenarios, such as those above, therefore rely on a set of two or 
       more pseudowires to protect a given VPWS or VPLS.
    
    I believe that the document should be clear up front that two protection
    mechanisms are being described in this document. The first is end-to-end
    service protection (where AC and T-PE failure are protected) and end-to-
    end PW protection (where the working and protection PWs run between the
    same pair of T-PEs). The document also needs to note clearly that PW
    segment protection (i.e. working and protection [multi-] segment 
    protection between a pair of S-PEs) is out of scope.
    
    >> Ah, I found this in the last paragraph of Section 2. A bit lost in
       the morass of other text.
    
    Note that an excellent way to handle this discuss will be the wholesale
    deletion of text and replacement with a simple reference to [6].
    
    ---
    
    Looks to me that [6] is used normatively.
    
    ---
    
    It is not clear to me why you don't support 1+1 protection. But section
    2 clearly rules it out.
    
       In the absence of faults, all PWs are UP both locally and remotely 
       and a PE node needs to select a single PW to forward user packets to. 
       This is referred to as the active PW. All other PWs will be in 
       standby and MUST NOT be used to forward user packets.  
    
    Perhaps this restriction should be stated. Or is there the possibility
    that a future protocol extension will be made to add 1+1 support?
    
    ---
    
    Section 2
    
       In order for both ends of the service to select the same PW for 
       forwarding user packets, this document defines a new status bit, the 
       'Preferential Forwarding' status bit, to allow a PE node to indicate 
       the preferential forwarding state of a PW to its peer PE node.  
    
    I may have missed something here, but in 1:1 end-to-end *service*
    protection, the choice of which PW to use has to be made at the CE not
    the T-PE. But the signaling (LDP) is between PEs. How does the CE learn
    the settings of the status code bits?
    
    ---
    
    I think there is some confusion about when bits are set and cleared in
    the status code. Some of this is textual.
    
    Section 11.1 has...                                                            
    
       0x00000020 When the bit is set, it indicates "PW forwarding  
                  standby".  
    
                  When the bit is cleared, it indicates "PW forwarding  
                  active". 
    
    Which is good and means that the text should probably refer to this as
    the "PW forwarding standby bit" rather than "PW Preferential Forwarding"
    as currently in section 6. (Note that IANA will need a name for the bit
    in the registry - they seem to have dug the names out of section 6, but
    this should be explicit in the IANA section of the document).
    
    Then the bit used for requesting switchover gives me a problem. While I
    understand the issues (selection from a pool that may be larger than 1,
    need to synchronize, etc.), the explanation of the status code field in
    RFC 4447 is clear that setting a bit represents a "fault". Thus, it 
    would be reasonable to handle a set bit as "cannot send traffic on this
    PW" whereas you are asking for it to mean "please send traffic on this
    PW". (Again, IANA will need a name for this bit in the registry.)
    
    I do wonder whether, given the existence of OAM and fault status bits, 
    and the definition of precedence, you need this bit. It even seems to 
    allow conflict with the precedence.
    
    ---
    
    What happens when a T-PE that supports this I-D sends a switchover
    request to a T-PE that foes not support this I-D? Presumably it will
    register the request as a fault (as above) and will not send traffic.
    
    ---
    
    In section 2
    
          a. A MANDATORY 1:1 PW protection with a single active PW and one 
             standby PW. An active PW can forward data traffic and control 
             plane traffic, such as Operations, Administration, and 
             Maintenance (OAM) packets. A standby PW does not carry data 
             traffic. 
    
    This does not say whether OAM packets and be carried on a standby PW.
    Later, in section 3, I find:
    
       Standby PW: An UP PW that is not used for forwarding user traffic, 
               but MAY forward OAM and specific control plane traffic. 
    
    And so on (e.g. Section 6.1)
    
       When a PW is in Standby state, the PEs MUST NOT forward user packets 
       over the PW but MAY forward PW OAM packets and specific control plane 
       packets. 
    
    Perhaps, rather than listing types of message, you should note that all
    ACH packets are allowed.
    
    ---
    
    Section 2
    
              b. Multi-homing of a PE node to two or more PE nodes.  
    
    What does this mean? A PE is multi-homed to multiple PEs? I suppose you 
    are trying to talk about parallel PWs between two T-PEs, and a PE that 
    is at the far end of a relationship with a CE that is multi-homed to
    more than one T-PE?
    
    ---
    
    Section 3
    
               The designation of Primary is performed by local 
               configuration for the PW at the PE and is only required when 
               revertive behavior is used.  
    
    But all of the text (for example, in 5.1 and 5.2) uses MUST for
    reversion, so there appears to be no option.
    
    Which is odd because the second requiremen of Section 4.1 of draft-ietf-
    pwe3-redundancy says that non-revertive behavior MUST be supported.
    
    ---
    
    Section 5
    
    I think that you need to clarify which mode of operation would be used
    in the case of figure 15-2. I think that master/slave mode cannot be 
    used, and that independent mode only works with configuration. There is
    a degenerate case of this topology where there is absolutely no LDP 
    communication between the PEs on the active PW and those on the standby
    PW. 
    
    ---
    
    Section 5.1 first point 2
    
    "we propose"
    
    please restate this protocol specification in terms of absolute
    statements of required behavior.
    
    ---
    
    Section 5.2.
    
       Note that the behavior 
       described in this section assumes correct configuration of the Master 
       and Slave endpoints. This document does not define a mechanism to 
       detect errors in the configuration. 
    
    I suggest this is broken. You should at least be able to detect the 
    error (not necessary to be able to resolve it) and report it. Also to
    not get into an unresolvable protocol breakdown when there are two T-PEs
    that think they are Masters.
    
    Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3-redundancy seem
    to speak against this text.
    
    ---
    
    The timers need to have recommended defaults, and should be called out
    as configurable.
    
    ---
    
    Section 7
    
    [5] is used normatively.
    
    [8] is used normatively.
    
    ---
    
    Section 7
    
       The procedures for determining and mapping PW and AC states MUST 
       follow the rules in [8] with the following modifications.  
    
    Does that mean this document updates [8]?
    
    ---
    
    Section 7.1
    
       When a PE enters the AC receive (or transmit) defect state for a PW, 
       it MUST send a forward (reverse) defect indication to the remote 
       peers over all PWs in the redundancy set when required by the PW type 
       in [8] . 
    
    I think this is subtly incorrect. It applies only to PWs in the 
    redundancy set that terminate at the PE and that are connected to the 
    AC.
    
    ---
    
    Section 8
    
       A PE implementation compliant to RFC 4447 [2], and which does not 
       support the generation or processing of the 'Preferential Forwarding' 
       status bit or of the 'request switchover' status bit, will ignore 
       these status bits if they are received from a peer PE. 
    
    I struggled to find this behavior defined in RFC 4447. While I believe 
    that many implementations might take this approach, I also think many
    might view the text in 4447 that indicates that the bits represent
    "faults" to mean that even unknown status code bits should be
    interpreted as PW failures. (Hence my burbling earlier about flipping 
    the sense of the bits.)
    
    If you can point me at the text in 4447, I will back off this issue.
    
    ---
    
    Section 9
    
    I don't think this section should be so banal.
    You are introducing a feature that allows the compromise of signaling
    for one PW between one pair of PEs, to change the behavior (disruptively)
    on a PW between another pair of PEs. That seems to be a new and 
    interesting attack vector.
    
    Therefore, you should at least flag this point and note that security on
    a redundant set is only as good as the weakest security on any member
    of that group.
    
    ---
    
    On re-reading Section 5.2 I cannot work out what happens if the Master
    node is the PE that fails. It looks like this is not covered and would
    provide a problem.
    
  4. Adrian Farrel: Comment [2012-05-22]:
    In case anyone is hunting, I can find just 4 out of the 12 authors 
    confirming on the PWE3 list that they are not aware of any IPR 
    disclosures that need to be made.
    
    ---
    
    I continue to be disappointed by the piecemeal invention of bolt-on 
    signaling features for PW management. It really seems that the working
    group needs to work on a functional architecture for pseudowires to
    work out all of the bits and pieces that are needed for redundancy,
    bandwidth, multi-segment routing, etc., etc. I wish this would happen
    before we incrementally munge the protocol too much, but I 
    understand that this is not directly actionable for the authors of this
    document.
                                           
    ---
    
    You need to remove the citation from the Abstract.
    
    ---
    
    The document was pretty hard to review because there are repetitions
    and overlap between sections. Do you need all the text?
    
    ---
    
    Please clean up "redundant set" or "redundancy set"
    
    ---
    
    There's a lot of terminology in the Introduction that need clarifying.
    I found...
    
    SS-PW
    PW
    MS-PW
    T-PE
    PE-rs
    PE
    PWE3
    
    ---
    
    Section 1
       Only one of these 
       pseudowires is used by the PEs to forward user traffic on at any 
       given time.
    
    delete "on"
    
    ---
    
    Figure 1-1
    s/Pseudowire/Pseudowires/
    
    ---
    
    Please decide "pseudowire" or "pseudo wire".
    Cf. RFC 3985 figure 2 and draft-ietf-pwe3-redundancy figure 2
    
    ---
    
    Section 1
    
       In 
       this case, multiple MS-PWs are configured between a pair of T-PE 
       nodes, as described in Figure 2 of [6].
    
    Figure 2 of [6] would appear to be identical to figure 1-1. Why do 
    you reference it?
    
    ---
    
    Section 1
    
       This document specifies a new PW status bit to indicate the 
       preferential forwarding status of the PW for the purpose of notifying 
       the remote PE of the preferential forwarding state of each PW in the 
       redundancy set i.e. Active or Standby.
    
    Please say "remote T-PE".
    
    ---
    
    Section 2
    
       The PWE3 control protocol [2] defines the following status codes in 
       the PW status TLV to indicate the state for an AC and a PW: 
    
       0x00000000 - Pseudowire forwarding (clear all failures) 
    
       0x00000001 - Pseudowire Not Forwarding 
    
       0x00000002 - Local Attachment Circuit (ingress) Receive Fault 
    
       0x00000004 - Local Attachment Circuit (egress) Transmit Fault 
    
       0x00000008 - Local PSN-facing PW (ingress) Receive Fault 
    
       0x00000010 - Local PSN-facing PW (egress) Transmit Fault 
    
    Firstly, I think these values are defined in RFC 4446 not RFC 4447.
    Then, I think there is actually no need to list the values here.
    You could, if you like, point to the registry.
    
    But reading this section, I am not sure that this quoted text is
    pertinent.
    
    ---
    
    Section 2                    
    
    You have put some terms in upper case that are not from RFC 2119.
    Anyway, I am not convinced that RFC 2119 usage is helpful in this
    early and descriptive section. Lowercase would be just fine.
    
    ---
    
    Figure 4-1 caption
    s/Architecure/Architecture/
    
    ---
    
    Section 2 point d.
    
    s/qualify/qualifies/
    
    ---
    
    Section 3
    
    I think you could prune this section quite heavily. For example, it is 
    probably not necessary to define a pseudowire or a PE.
    
    ---
    
    Section 5.1 
    
          The PW which corresponds to the 
          minimum of the compared values across all PWs in the redundant is 
          selected.
    
    s/redundant/redundant set/  ?
    
    ---
    
    Section 5.2
    
       One endpoint node of the redundant set of PWs is designated the 
       Master and is responsible for selecting which PW both endpoints MUST 
       use to forward user traffic. 
    
    I think...
    s/MUST//
    
    ---
    
    Section 7.2
    
       A PE enters the PW receive (or transmit) defect state for a PW 
       service when one or more of the conditions specified in Section 8.2.1 
       (Section 8.2.2) in [8] are met for all PWs in the redundancy set. 
    
    For the avoidance of doubt, I think you should
       s/for all/for each of the/
    
    (It is not necessary that the same defect state should exist on each PW)
    
    ---
    
    Section 10
    
    I completely support Benoit's Discuss on this section. You cannot revise
    a MIB module like this.
    
    However, it really looks like you don't want to make a revision at all.
    Changing one Description clause by adding "for example" is really not
    worth the effort.
    
    Why don't you just write an applicability note saying how the TC is used
    to support the function described in this I-D?
    
    ---
    
    Author's Addresses
    
    s/Author's/Authors'/
  5. Stephen Farrell: Comment [2012-05-21]:
    The security considerations say that this is the same as for
    4447, which is arguably correct, but 4447 really defers to
    3036, which a) doesn't consider switching over to a "less good"
    PW as a potential DoS (is it?) and b) only has TCP-MD5 based
    security which even in 2001 attracted an IESG note, repeated in
    3036 from rfc 2385 (from 1998!).  Any chance of getting some
    21st century security stuff done in PW-land? (Sorry, but that's
    hard to resist:-) This is probably not the place to fix that,
    but it'd be good to know if there's a plan. Is there?
    
    Nits:
    
    - PE-rs is used without expansion (on p2)
    
    - FEC128 and FEC129 are used without definition on p11
    (As as AGI::SAII:TAII)
    
    - What is the "system IP address"? (on p11) Could be fairly
    obvious, but then again if a node has many addresses, 
    maybe not.
  6. Russ Housley: Comment [2012-05-23]:
      Please consider the issues raised in the Gen-ART Review by
      Miguel Garcia on 23-May-2012.  I tend to agree with his points on
      RFC 2119 language in Sections 5 and 15.  Please find the review at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07447.html.
  7. Pete Resnick: Comment [2012-05-21]:
    Section 2:
    
    MANDATORY
    OPTIONAL
    OPTIONALLY
    
    Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized
    words in this section are a new magical usage of which I am unaware. Perhaps you
    might like to define terms?
    
    5.1
    
       The PW endpoints MAY also implement the following optional active PW 
       selection mechanism.  
    
       1. If the PW endpoint is configured with the precedence parameter on 
          each PW in the redundant set, it MUST select the PW with the 
          lowest configured precedence value.  
    
    So you MAY do something that you MUST do? I am confused.
    
       a management indication SHOULD be generated
    
    I may not understand what is meant by a "management indication" here, but it
    sounds like an implementation choice, not something that is required for
    interoperation. Did I get that wrong?
  8. Martin Stiemerling: Comment [2012-05-21]:
    Please check the idnits:
    
      Checking nits according to http://www.ietf.org/id-info/checklist :
      ----------------------------------------------------------------------------
    
      ** There are 19 instances of too long lines in the document, the longest
         one being 4 characters in excess of 72.
    
      == The 'Updates: ' line in the draft header should list only the _numbers_
         of the RFCs which will be updated by this document (if approved); it
         should not include the word 'RFC' in the list.
    
      -- The draft header indicates that this document updates RFC5542, but the
         abstract doesn't seem to directly say this.  It does mention RFC5542
         though, so this could be OK.
    
     Miscellaneous warnings:
      ----------------------------------------------------------------------------
    
      == The copyright year in the IETF Trust and authors Copyright Line does not
         match the current year
    
      == The document seems to lack a disclaimer for pre-RFC5378 work, but was
         first submitted before 10 November 2008.  Should you add the disclaimer?
         (See the Legal Provisions document at
         http://trustee.ietf.org/license-info for more information.) -- however,
         there's a paragraph with a matching beginning. Boilerplate error?
    
         IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
         "This document may contain material from IETF Documents or IETF
          Contributions published or made publicly available before November
          10, 2008.  The person(s) controlling the copyright in some of this
          material may not have granted the IETF Trust the right to allow
          modifications of such material outside the IETF Standards Process.
          Without obtaining an adequate license from the person(s)
          controlling the copyright in such materials, this document may not
          be modified outside the IETF Standards Process, and derivative
          works of it may not be created outside the IETF Standards Process,
          except to format it for publication as an RFC or to translate it
          into languages other than English."
    
         ... text found in draft:
         "Code Components extracted from this document must include Simplified BSD
    ......^
          License text as described in Section 4.e of the Trust Legal
          Provisions and are provided without warranty as described in the
          Simplified BSD License."
    
      -- The document date (May 1, 2012) is 20 days in the past.  Is this
         intentional?
    
      Checking references for intended status: Proposed Standard
      ----------------------------------------------------------------------------
    
         (See RFCs 3967 and 4897 for information about using normative references
         to lower-maturity documents in RFCs)
    
      == Outdated reference: A later version (-08) exists of
         draft-ietf-pwe3-redundancy-07
  9. Sean Turner: Comment [2012-05-22]:
    Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-
    ietf-pwe3-redundancy-bit.
    
    Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-
    ietf-pwe3-redundancy-bit.  Can't you just point from on to the other?
    
    This uses the TCP MD5 "signature" option [RFC5036].  KARP's hopefully going to
    get this fixed sooner rather than later.  So there's nothing for the authors to
    do about this otherwise recurring gripe.
    
    I'd like to suggest some tweaks to the security considerations section, assuming
    of course that I've not totally missed the mark:
    
    1st - I think the "LDP extensions" are referred to as options in both RFC 4447
    and 5036?
    2nd - I think there's only one of them?
    3rd - I think you mean control
    plane not control protocol?
    
    How about the following tweaks to the security considerations section:
    
       This document uses the TCP MD5 Signature option, as specified
       in [2],  to protect pseudowires.  This document has the same
       security considerations as in the PWE3 control-plane [2].
    
    If you want to future proof the text more maybe:
    
       LDP extensions/options that protect pseudowires must be
       implemented because the security considerations for the
       bits defined in this document have the same security
       considerations as the PWE3 control-plane [2].

draft-ietf-pkix-cmp-transport-protocols

  1. Wesley Eddy: Discuss [2012-05-21]:
    There is significant confusion in terminology in this document, with "transport"
    used in cases where we would normally use "transfer" to be more clear and
    consistent with the existing body of RFCs.  HTTP is a transfer protocol; TCP is
    a transport protocol.  If the document was scrubbed to fix this terminology, I
    would have no problem with it going forward.
    
  2. Stephen Farrell: Discuss [2012-05-21]:
    (1) Today, using HTTP/TLS is not hard. If CMP messages are
    visible over a public network, then there may be a number of
    high-level DoS-type attacks possible, e.g. bad-guy sees a
    certification request for example.com and knows that that will
    take ~1 day to process so bad-guy goes to another (not so
    careful) CA and get a cert for example.com denying service to
    the correct example.com and damaging the CA to whom the
    original certification request was directed. On this basis, I
    think this document really needs to make use of HTTP/TLS a
    MUST-use messages go over any untrusted network, and hence TLS
    would need to be mandatory-to-implement. I'd also say that
    IPsec isn't really very relevant here (but would work fine), so
    I'd suggest that the spec be changed along the lines of:
    
    OLD:
    
      "Therefore users of the HTTP transport for CMP might want to
       consider using HTTP over TLS according to [RFC2818] or
       virtual private networks created e.g. by utilizing Internet
       Protocol Security according to [RFC4301]."
    
    NEW:
    
      "HTTP over TLS [RFC2818] MUST be supported by all nodes
       implementing this protocol.  TLS with strong confidentiality
       SHOULD be used in all cases, with the only exception being
       when CMP messages are sent over fully trusted networks,
       which doesn't happen very often."
    
    (2) How is RFC 1945 a MUST but not a normative reference and is
    that then a downref? Is http/1.0 *really* needed as a MUST
    these days? I'd say s/MUST support/might support/ for http/1.0
    and leave 1945 as an informative reference and avoid the
    messing with new last calls etc.
    
  3. Stephen Farrell: Comment [2012-05-21]:
    3.3 - is the 200 vs 201/202 point here consistent, seems like
    not. 3.5 also seems to say what's needed and better, so I'd
    suggest deleting 3.3 entirely
    
    3.3 - what are the 3xx "security implications"? Either 4210 is
    ok or not, so I'm really not sure what's meant here.
  4. Brian Haberman: Comment [2012-05-18]:
    I have no issues with the publication of this document.  I only have some non-
    blocking comments:
    
    1. Part of the Introduction sounds more like a history lesson and does not
    bolster the content of the document.  I would suggest paring it down and
    focusing on introducing the functionality.
    
    2. Terms like "PKIMessage" and "DER-encoded" are not defined anywhere before
    they are used.
    
    3. The 2nd paragraph of section 3.3 seems incomplete.  It would be useful if
    some example security implications were discussed.
    
    4. What purpose does section 4 serve?  Are there interoperability functions that
    could be described?  I would suggest providing guidance on how the potential
    interactions can be handled.
    
    5. While I appreciate the impact of having unresponsive authors, I don't think
    the explanatory text in section 7 (paragraph 1) is needed.  Simply list those
    people as previously contributing authors.
  5. Barry Leiba: Comment [2012-05-19]:
    Substantive comments; these are non-blocking, but please consider them
    seriously, and feel free to chat with me about them:
    
    I agree with Brian Haberman's comments #3 and #4.  On #3: there is a short note
    in the Security Considerations about using 301 Moved Permanently, but, in
    general, this should say more about the security implications of using HTTP
    redirection.  Otherwise, "careful consideration of possible security
    implications" isn't likely.  On #4, I think you either need to remove the
    section or explain it quite a bit better.
    
    ========
    Other comments; no need to respond to these:
    
    A note to the doc shepherd: Thank you for being clear about the low level of WG
    interest in the document and the reasons for publishing it despite that.  Too
    often, shepherd writeups try to give what they think are "the right answers",
    rather than the true and accurate ones.
    
    A note on Brian Haberman's comment #1: In contrast, I think the "history" in the
    introduction is useful.  After reading Brian's comment I considered each
    paragraph for removal or abridgment, and found that each one was useful in
    explaining why the document is making the choices it's making and going in the
    direction it's going.
  6. Pete Resnick: Comment [2012-05-22]:
    In 3.8:
    
       While implementations MAY make use of all defined features of the
       HTTP protocol, they SHOULD keep the protocol utilization as simple as
       possible.
    
    I find this potentially confusing. If the directive to implementers is that they
    are allowed to use (and therefore the other side needs to be aware of) all
    defined HTTP features, the MAY should be uppercased and the SHOULD should not.
    If the directive to implementers is that they SHOULD keep the protocol use
    simple, then the first part of the sentence is at best confusing. If the latter
    is the intent, try:
    
       While all defined features of the HTTP protocol are available to
       implementations, they SHOULD keep the protocol utilization
       as simple as possible.
  7. Martin Stiemerling: Discuss [2012-05-21]:
    Section 1., paragraph 4:
    
    >    Before this document was published as an RFC, the draft version
    >    underwent drastic changes during the long-lasting work process.  The
    >    "TCP-Based Management Protocol" was enhanced and a TCP-Messages-over-
    >    HTTP transport specification appeared.  As both proved to be needless
    >    and cumbersome, implementers preferred to use plain HTTP transport
    >    following [RFC1945] or [RFC2616].  This document now reflects that by
    >    exclusively describing HTTP as transport protocol for CMP.
    
    The sentence "TCP-Based Management Protocol" was enhanced and a
    TCP-Messages-
    over-HTTP transport specification appeared." hit my eye as Transport AD. 
    Is
    there any meat to have this sentence in here? I would suggest to remove it, in
    order to not
    give a wrong impression that the IETF has worked at any time on a
    TCP over HTTP protocol.
    The "TCP-Based Management Protocol"  is also sort of
    unknown to me.
    
    Section 3.7., paragraph 1:
    
    >    A CMP server may create event-triggered announcements or generate
    >    them on a regular basis.  It MAY utilize HTTP transport to convey
    >    them to a suitable recipient.  As no request messages are specified
    >    for those announcements they can only be pushed to the recipient.
    
     How can a HTTP server push data to the client with HTTP?
     HTTP is a request/response protocol where the client is sending out
     the requests.
    I assume that the CMP server is located at the HTTP server.
     However, the draft isn't completely clear about whether the CMP server
     is necessarily located at the HTTP server.
    
    Section 3.7., paragraph 7:
    
    >    CMP Announcement messages do not require any CMP response.  However,
    >    the recipient MUST acknowledge receipt with a HTTP response having an
    >    appropriate status code and an empty body.  When not receiving such
    >    response it MUST be assumed that the delivery was not successful and
    >    if applicable the sending side may retry sending the Announcement
    >    after waiting for an appropriate time span.
    
      What is this time span?
      Replace "may" with "MAY"?
    
    Section 3.7., paragraph 10:
    
    >    A receiver MUST answer with a suitable 4xx or 5xx HTTP error code
    >    when a problem occurs.
    
      This MUST here contradicts this statement "All applicable
     "Client Error 4xx" or "Server Error 5xx" status codes
     may be used to inform the client about errors."  out of Section 3.3,
     as 4xx/5xx codes may be support, but this requires that they are supported.
    
  8. Martin Stiemerling: Comment [2012-05-21]:
    Section 3.3., paragraph 2:
    
    >    While "Redirection 3xx" status codes MAY be supported by
    >    implementations, clients should only be enabled to automatically
    >    follow them after careful consideration of possible security
    >    implications.
    
      It would be good to link to your security section about the
     the discussion of this.
    
    Section 3.4., paragraph 0:
    
    >    All applicable "Client Error 4xx" or "Server Error 5xx" status codes
    >    may be used to inform the client about errors.
    
      Replace "may" with "MAY"? But see also my DISUCSS about 4xx/5xx codes.
    
    Section 3.4., paragraph 1:
    
    >    The Internet Media Type "application/pkixcmp" MUST be set in the HTTP
    >    header when conveying a PKIMessage.
    
      to be precise: MUST be set in the Content-Type header.
    
    - Section 4: In support of Brian's comment, i.e., what is the purpose of this
    section?

draft-ietf-netext-access-network-option

  1. Benoit Claise: Discuss [2012-05-23]:
    -The term "vendor" is confusing
    
       Vendor ID
    
          The Vendor ID is the SMI Network Management Private Enterprise
          Code of the IANA-maintained Private Enterprise Numbers registry
          [SMI].
    
    The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
    Vendor Id, in the network management world is the manufacturer id, while you're
    after the Operator-Id
    I see what you want to do, but this is confusing. Also, do
    we expect that all operators will have Private Enterprise Number?
    
    Maybe you want to redefine this with something such as (I trust you on the right
    wording)
    
       Operator PEN ID
    
          SMI Network Management Private Enterprise
          Code of the IANA-
    maintained Private Enterprise Numbers registry
          [SMI] for the operator
    running ... [actually running what, that's another 
          required clarification
    in the draft] ... the respective interface on mobile access gateway?
    
    In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by
    "Operator PEN ID"
    
    And also add a few sentences about
    - whether all operators should or must now
    register new PENs for this spec.
      I checked for a couple of my local ISPs, and
    not all of them had a PEN.
    - if there is no PEN Operator ID, then ANI type= 3,
    Op-ID=2 MUST NOT/SHOULD NOT be used
        if "SHOULD NOT", what should be default?
    Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
    You want to discuss with the authors of draft-liang-iana-pen-00, be in synch
    with them.
    
    - Part of the OPS-DIR review, this one was reported by Juergen Quittek:
    Section 3.1.1, description of ANI Length:
    ANI Length: The description states
       "The value can be in the range of 2 to 32 octets."
    I think this is wrong. A value of 2 would only include
    the E-bit, the reserved field and a (zero valued) Net-Name-Len
    field.  The description implies that a (zero-valued) AP-Name Length
    Field is also mandatory. Then you need at least 3 octets, not just 2.
    
  2. Benoit Claise: Comment [2012-05-23]:
    - I was wondering about the relationship between the Access Technology Type
    option and this new Access Network Identifier option. Both of the required at
    the same time? I finally discovered the answer in RFC5213: the Access Technology
    Type is mandatory. That would help to stress this in the document, just in case
    the readers are not that familiar with RFC5213 (like myself)
    
    -OLD:
       The
       Access Network Identifier mobility option MUST contains one or more
       Access Network Identifier Sub-options.
    
    NEW: 
       The
       Access Network Identifier mobility option MUST contain one or more
       Access Network Identifier Sub-options.
    
    - Part of the OPS-DIR review, the following editorial comments were reported by
    Juergen Quittek:
    
    Section 3.1.1, description of Net-Name length:
    Following up on the technical issue above: It is not clear,
    if the Network Name may be of length zero.  The description
    of the AP-Name Length explicitly states
       "If the access point name is not included, then this length
       MUST be set to a value of zero."
    There is no such statement for the Net-Name Length. Please add
    A statement, that the Network name MUST NOT be of length zero,
    Or add a statement like the cited one from AP-Name length.
    
    Section 3, description of field "Type" under Figure 2:
    "(IANA-1)" is highly ambiguous.  Please replace
    OLD
       Type:   (IANA-1)
    NEW
       It MUST be set to value of (to be defined by IANA),
       indicating that its a Network-Identifier option.
    
    Section 3.1.2, description of N and E flag:
    OLD
       N: When the flag (N) is set to a value of (1), it means North, else
          its South
    NEW
       N: When the flag (N) is set to a value of (1), it means North, else
          it means South
    
    The same applies accordingly to the E flag.
  3. Ralph Droms: Discuss [2012-05-22]:
    I have a concern about tying the interpretation of the "Network Name"
    field in the Network-Identifier Sub-option to the Access Technology
    type in the Access Technology Type option.  Why not put a "Network
    Name Type" field - there's a handy set of Reserved bits available -
    that explicitly identifies the type of the Network Name?
    
    Without a "Network Name Type" field, the definition of a new Access
    Technology type will have to include the definition of the
    interpretation of the "Network Name" field.
    
  4. Adrian Farrel: Comment [2012-05-23]:
    This is a not-quite-Discuss Comment
    
    I think a number of references listed as Informative need to be moved
    to Normative. Specifically:
    
    SMI
    RFC 3629
    RFC 1035
    RFC 6275
    
    I am in two mindsabout RFC2460.
    
    Happy to discuss why/whether this would be appropriate, but it looks 
    like the uses are explicit "do encode this thing you need to read this 
    reference" type of statements.
  5. Stephen Farrell: Discuss [2012-05-21]:
    
    (1) Why doesn't this use geopriv? 
    
    (2) Why is it ok to send the MN location (3.1.2) without asking
    the user?
    
    (3) Why is it ok to send SSID and AP name  without asking the
    user?  Many of those are pretty revealing as to MN location.
    
    (4) I looked at 6275 and 5213 and its not clear to me that
    these sensitive values, if sent, MUST be protected using IPsec
    with strong confidentiality and mutual authentication. The
    authentication part may be ok according to the documents, but
    I'm not sure if that's the deployed reality. Is it? But even if
    so, there's nothing much that I can see to ensure
    confidentiality for this information. Where's all that
    (clearly) specified?
    
  6. Barry Leiba: Comment [2012-05-16]:
    IANA Considerations rant:
    
       o  Action-1: This specification defines a new Mobility Header option,
          the Access Network Identifier.  This mobility option is described
          in Section 3.  The Type value for this option needs to be assigned
          from the same numbering space as allocated for the other mobility
          options, as defined in [RFC6275].
    
    I noticed the same problem that confused IANA, and was going to kick in a
    DISCUSS to get it fixed: the registry is called "Mobility Options", and
    referring to it as a "Mobility Header option" confused it with the "Mobility
    Header Types" registry.  No need for the DISCUSS, though, because the author
    noticed the error in Pearl's proposed IANA actions, and sorted it out by email.
    
    So this comment will just serve to beat people up about this, and to rant a bit.
    You can otherwise ignore it:
    Folks, it's just not that hard to go to
    http://www.iana.org/protocols/ and actually *look up* the correct name of the
    registry you aim to use... and then to use the *exact* name.  Please be specific
    and accurate; it's important.
  7. Pete Resnick: Discuss [2012-05-22]:
    3.1.1
    
       'E'-bit:  1-bit flag for representing the encoding of the following
          name field.  MUST be set to zero (0) if the network name is
          encoded using 8-bit octets or to one (1) if the network name is
          encoded using UTF-8 [RFC3629].
    
    So, I want to understand the semantics of the below network name field if the
    'E'-bit is 0. What does it mean to be 8-bit octets that are not UTF-8? What is
    it then? And I'm not sure this is even correct, since further down in the
    definition of Network Name you say, "Encoding MUST be UTF-8." Something is funky
    here. Please explain.
    
    (BTW: RFC3629 is a normative reference, not informative. Please correct that in
    section 9. I think there are probably several things you've got in the wrong
    place.)
    
       Net-Name Length:  8-bit field for representing the length of the
          network name to be followed.
    
    I think you want to specifically say "in octets", since if it's UTF-8,
    characters is probably *not* what you mean.
    
    3.1.3
    
          2 -  Realm of the operator.  Realm names are required to be
             unique, and are piggybacked on the administration of the DNS
             namespace.  Realms are encoded using a domain name encoding
             defined in [RFC1035].
    
       Operator Identifier:  Up to 253 octets of the operator identifier.
          The encoding of the identifier depends on the used Operator-ID
          Type.  Numeric values are encoded in network byte order and
          strings are in UTF-8 representation and have no terminating '\0'
          mark.
    
    So the first part above says that the domain names are encoded to RFC 1035. Are
    you talking there about the letter-digit-hyphen rules of 2.3.1 of 1035? If so,
    you should say that. However, if that's what you mean, then clearly those are
    all US-ASCII. The second part says that "strings are in UTF-8 representation".
    Now I'm confused. Are you intending to allow things outside of US-ASCII, e.g.
    unencoded UTF-8 U-labels for IDNs? Something is not right about the above. I
    also have no idea why you have the note about the terminating '\0'. Please
    explain.
    
    Now, all that said, I'm a bit worried about the lack of information on how to
    compare these things that appears in section 4. Comparing network names you seem
    to leave to DHCP, but others you don't talk about. If you have to compare these
    things, are you going to (and do you have to) deal with comparing UTF-8 strings
    which have different normalizations? Perhaps the answer is "no" and these are
    not things that need to compare if one contains "latin small 'o' followed by
    combining diaeresis" and the other contains "latin small 'o' with diaeresis".
    But if these two *do* have to compare as identical, you're going to need to say
    more about how those comparisons (and normalizations) happen.
    
  8. Robert Sparks: Discuss [2012-05-23]:
    ( no change - just reformatting to make this easier to read in the tracker )
    
    Can the document provide more clarity on what kinds of things the LMA is
    expecting to use the information carried by this extension for? Specifically,
    how is geolocation going to be used? Is there normative text in some other
    document that constrains what the LMA can do with this information? Could it be
    used, for instance, for dispatching emergency services?
    
    The document is inconsistent in describing what the location represents. Some
    sections say it is the location of the MAG. Other sections say it is the
    location of the network (which is very unclear). The security considerations
    section says it is the location of the mobile node. What this location
    represents needs to be very clearly stated.
    
    If the security consideration text is correct, and this location is intended to
    represent (even as coarsely as which AP a user is attached to) the location of
    the MN, and thus the MN's user,  then the considerations in RFC6280 do come into
    play, and the document needs to account for them.
    
    What is the expected relationship/trust model between the APs and the MAGs in
    Figure 1? Are they required to be part of the same administrative domain? What
    are the consequences if incorrect data is provided when the information is
    "dynamically obtained through some of out-of-band means".
    
    The geolocation format proposed in this document doesn't allow specifying
    details like the coordinate reference system. Was reusing an existing format
    (such as the geo-uri in RFC5870) considered? Is there a need to express
    precision or uncertainty?
    
  9. Sean Turner: Comment [2012-05-24]:
    I'm piling on with Stephen and Robert.

draft-snell-atompub-tombstones

  1. Benoit Claise: Discuss [2012-05-21]:
    I don't think I have seen a reply to the Chris' review below, part of the OPS-
    DIR review.
    
    -------- Original Message --------
    Subject:        Re: [OPS-DIR] Ops directorate
    review of draft-snell-atompub-tombstones-14.txt
    Date:   Tue, 7 Feb 2012 05:21:14
    -0800
    From:   Christopher LILJENSTOLPE <ietf@cdl.asgaard.org>
    To:     ops-
    dir@ietf.org
    CC:     draft-snell-atompub-tombstones@tools.ietf.org
    
    > Greetings,
    > 
    > I have performed an Operations Directorate review of draft-
    snell-atompub-tombstones-14.txt
    > 
    > Operations directorate reviews are
    solicited primarily to help
    > the area directors improve their efficiency,
    particularly when
    > preparing for IESG telechats, and allowing them to focus on
    > documents requiring their attention and spend less time on the
    > trouble-free
    ones. Improving the documents is important, but
    > clearly a secondary purpose. A
    third purpose is to broaden the
    > OpsDir reviewers' exposure to work going on in
    other parts of
    > the IETF.
    > 
    > Reviews from OpsDir members do not in and of
    themselves cause
    > the IESG to raise issue with a document. The reviews may,
    >
    however, convince individual IESG members to raise concern over
    > a particular
    document requiring further discussion. The reviews,
    > particularly those
    conducted in last call and earlier, may also
    > help the document editors improve
    their documents.
    > 
    > ----
    > 
    > Review result:
    > 
    > I believe there is an
    operational impact in this document, or, at lest a technical issue that may
    result in operational confusion.
    > 
    > Section 5 discusses digital signatures of
    a atom removal message.  Specifically, the paragraph:
    > 
    > Section 4.4.2 of [W3C
    .REC-xmldsig-core-20020212] requires support for
    >   DSA signatures and
    recommends support for RSA signatures.  However,
    >   because of the much greater
    popularity in the market of RSA versus
    >   DSA, Atom Processors that verify
    signed Atom Documents MUST be able
    >   to verify RSA signatures, but do not need
    be able to verify DSA
    >   signatures.  Due to security issues that can arise if
    the keying
    >   material for message authentication code (MAC) authentication is
    not
    >   handled properly, Atom Documents SHOULD NOT use MACs for signatures.
    >
    > Is where I have my issue.  By reading this document, it seems as if we are
    suggesting an exactly opposite selection of mandatory digital signature
    algorithms as the W3C does for XML.  W3C MUST's DSA, and SHOULD's RSA, and this
    draft is suggesting a MUST for RSA and a MAY for DSA.  I would suggest that the
    authors either consider harmonizing with W3C, or requiring both RSA and DSA.  If
    not, toolchains created to validate XML signatures may not work in this
    application.
    > 
    > I also believe that the authors should outline the expected
    behavior if a processor can validate an XML message signature, and that
    validation proves that the message is invalid.  There is NO mention that that
    should be a MUST NOT or SHOULD NOT for further processing of the message.
    > 
    >
    These could lead to operational behavior issues and should, in my opinion, be
    addressed before the document is published.
    > 
    > Regards,
    >       Chris
    > 
    >
    
  2. Benoit Claise: Comment [2012-05-21]:
    I have the same comment as Adrian Farrel: the 3 lines introduction is very very
    light, and doesn't give much background and references.
  3. Adrian Farrel: Comment [2012-05-21]:
    My Comment raised on -14 persists in -15.
    
    I have no objection to the publicaiton of this document. I think that the
    Introduction could have been more extensive - a good place for citations and
    explanations.
  4. Stephen Farrell: Comment [2012-02-24]:
    1. I didn't really get what's meant by 
    
    "  When an at:deleted-entry element appears in a Feed document other
    than it's source Feed or when an at:deleted-entry element that has a
    source Feed document is used in the context of a Deleted Entry
    Document, it MUST contain an atom:source element."
    
    But I guess Atom developers probably do so that's ok.
    
    2. Last para of section 6: I guess that if someone did MAC and then
    symmetrically encrypt one of these (is that as unlikely as I think?)
    then it might be useful to tell them not to use the same key for
    both.
    
    3. Digital signatures by themselves do not provide non-repudiation.
    Please delete that term.
    
  5. Pete Resnick: Discuss [2012-05-20]:
    I intend to move to Yes, but I've got a couple of concerns with text in section
    3:
    
       An Atom feed MAY contain atom:entry elements and at:deleted-entry
       elements sharing the same atom:id value.  Atom processors SHOULD
       ignore any at:deleted-entry elements sharing an atom:id value with an
       atom:entry whose atom:updated element specifies a date and time more
       recent than or equal to the at:deleted-entry element's when value.
    
    What exactly are the semantics associated with a feed that has both an atom-
    entry and at:deleted-entry for the same atom:id? Is it something like "marked
    for delete before purged"? How might this situation come up? I'm worried that
    there is not enough information in here (and the SHOULD is making me more
    worried) to be able to implement this in an interoperable fashion. Please
    explain.
    
       Implementors should note that the at:deleted-entry element is
       informative in nature only and may be ignored by Atom processors.
    
    I'm not sure what the above means. What is it informative of? Do you really mean
    "advisory" instead of "informative"? Or do you mean "probabilistic" (which would
    concern me)? Are you saying that an Atom processor can't rely on an at:deleted-
    entry?
    
       The presence of an at:deleted-entry element does not guarantee that
       the atom:entry to which it is referring will no longer be available.
    
    Again, I'm not sure what the above means in practice. If it doesn't guarantee
    it, does it probabilistically indicate it? Again, what are the semantics of the
    thing?
    
  6. Sean Turner: Comment [2012-05-19]:
    Most of s5 and s6 are copied from RFC 4287 can't you just point to RFC 4287 for
    the text?  In both s5 and s6, it's the last 3 paragraphs.  Was the last
    paragraph of s6 supposed to be titled signing and encrypting like it was in
    4287?
    
    I guess this made sense to the atom folks but those blurbs only talk about the
    processors of the feed, but where is the requirement for the generator of the
    feed?  It's great to require that only RSA be supported instead of DSA and that
    AES-128 CBC be the only choice for the processor, but if the generator uses one
    of the other allowed W3C allowed algs how do you get interop?
    
    Assuming you import the text from RFC 4287 this is probably moot but ... in the
    following:
    
       Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
       TripleDES, AES-128, and AES-256.  Processors that decrypt Deleted
       Entry Documents MUST be able to decrypt with AES-128 in Cipher Block
       Chaining (CBC) mode.
    
    What does the second sentence add?  Was it trying to say that processors only
    have to support AES 128 CBC because it's the only thing that's going to be used?
    
    Nothing to do on this one: I really hate MACs being characterized as signatures.

draft-ietf-ledbat-congestion

  1. Stewart Bryant: Discuss [2012-05-23]:
    
    There are a lot of timing assumptions and many specific references to NTP.
    The draft should go to the TICTOC and NTP WGs with a request for their
    review of these aspects of the draft.
    
    Detailed comments below:
    
       Applications.  Thus the extra delay induced by LEDBAT must be below
       150 ms to reduce impact on delay-sentive applications. 
    SB> I find this a suprising comment given that earlier in the document
    SB> you state that LEDBAT is not aimed at this class of application.
    SB> Please can the authors provide clarity.
    
    =====
    
    A.2.  Clock skew
    
       The clock skew manifests in a linearly changing error in the time
       estimate.  For a given pair of clocks, the difference in skews is the
       skew of the one-way delay estimate.  Unlike the offset, this no
       longer cancels in the computation of the queuing delay estimate.  On
       the other hand, while the offset could be huge, with some clocks off
       by minutes or even hours or more, the skew is typically small.  For
       example, NTP is designed to work with most clocks, yet it gives up
       when the skew is more than 500 parts per million (PPM).  Typical
       skews of clocks that have never been trained seem to often be around
       100-200 PPM.  
    
    SB> This needs evidence and qualification
    
    Previously trained clocks could have 10-20 PPM skew due
       to temperature changes. 
    
    SB> This also needs evidence and qualification
    
     A 100-PPM skew means accumulating 6
       milliseconds of error per minute.  The base delay updates mostly
       takes care of clock skew unless the skew is unusually high or extreme
       values have been chosen for TARGET and BASE_HISTORY so that the clock
       skew in BASE_DELAY minutes is larger than the TARGET.
    
    SB> This needs to be reviewed by some NTP experts.
    
  2. Stewart Bryant: Comment [2012-05-23]:
    Given that the base delay is constant, 
    
    SB> It's not completely constant in the face of routing changes
    
    ======
    
       implementation as a reference:
       o  Skew correction with faster virtual clock:
    SB> This is the first time you have introduced the reader to a virtual
    SB> clock.
  3. Benoit Claise: Discuss [2012-05-24]:
    1. Since "LEDBAT is an experimental delay-based congestion control mechanism", I
    was wondering when the LEDBAT is not appropriate.
    And I was very surprised not
    to see a reference to RFC 6297.  Specifically
    http://tools.ietf.org/html/rfc6297#section-2.2, "Potential Issues with Delay-
    Based Congestion Control for LBE Transport".
    A sentence such as the following,
    from RFC 6297, is particularly important to mention: "this makes such protocols
    highly sensitive to eventual changes in the end-to-end route during the lifetime
    of the flow [Mo99]."
    
    2. Then I was wondering: what about ECMPs with different delays?
    Is LEDBAT
    appropriate or not? I could not deduced from the document if you keep the list
    of delay per host, or per transport.
    If per transport, LEDBAT is appropriate
    If
    per host IP address, LEDBAT might have some issues in case of significant
    different delays in the ECMPs
    A new section about LEDBAT applicability would be
    welcome
    
    3. how can I monitor that LEDBAT doesn't do any harm or does actually the job?
    I
    understand that LEDBAT is experimental, but also deployed, but how do we monitor
    the impact? What if LEDBAT misbehaves: how do we notice?
    And I don't see in the
    charter that you're going to address the manageability and operational aspect in
    a different document.
    
  4. Benoit Claise: Comment [2012-05-24]:
    OLD:
       The
       International Telecommunication Union's (ITU's) Recommendation G.114
       defines a delay of 150 ms to be acceptable for most user voice
       applications.
    
    NEW:
       The
       International Telecommunication Union's (ITU's) Recommendation G.114
       defines a one way delay of 150 ms to be acceptable for most user voice
       applications.
  5. Ralph Droms: Discuss [2012-05-23]:
    I would be somewhat more comfortable with a "warning label", perhaps
    as a new section 2.3, that explicitly describes safe deployment
    scenarios, identifies and specifies crucial parameters for safe
    operation, and explains what experimental results will be produced.
    
    Before requiring any new text, I have a few questions that do not
    require any immediate action on the part of the authors.  These
    questions may result in an actionable Discuss position.
    
    1. As this document suggests an ongoing experiment that will be run on
    the Internet, I'd like to know if the WG chairs and the document
    authors see any situation in which deployment of this experimental
    protocol could be harmful to the operation of the Internet.
    
    2. Are there specific operational parameters that are crucial to the
    safe operation of this protocol?
    
    3. Is there a plan for explicit experimentation to gather results that
    will allow this protocol to be published on the Standards Track?
    
  6. Ralph Droms: Comment [2012-05-23]:
    Minor editorial issue: I don't understand this sentence at the end of
    section 4.2.1:
    
       As closer the extra delay gets to the TARGET value, as slower
       LEDBAT will increase the window.
  7. Stephen Farrell: Comment [2012-05-21]:
    One security/2119 question and a bunch of nits on what's a good
    document.
    
    section 7 - you say a protocol using LEDBAD "should"
    authentiate timestamp and delay fields. Is that a 2119 SHOULD?
    If so, then someone who turns up with an I-D that uses LEDBAT
    but has no MTI authentication might get DISCUSS comments on
    that basis. Is that what you want? If not, then perhaps
    s/should/ought/ will reduce the scope for possible future
    confusion. You could also mean that if using (D)TLS then
    the timestamp and acks SHOULD be protected, but that
    its ok for a protocol that has no MTI security (heaven
    forbid:-) to use LEDBAT.
    
    (See also the recent endless discussion on case for
    2119 keywords on ietf-discuss if you've time to spare:-) 
    
    I don't mind how you choose to handle this, since its
    really an issue to be handled when LEDBAT is used,
    but think that this could usefully be clarified here.
    
    nits:
    
    - list in 2.1 ends with a comma - just checking that a
    point 4 wasn't dropped off the end of the list
    
    - 2.2 uses "tail-drop" and "non-drop-tail" - would
    "non-tail-drop" be better there?
    
    - p8, there's no mandatory-to-implement FILTER() - is that
    ok? You give a bunch of options, but don't say that one of
    them MUST be implemented.
    
    - p9, says a maximum value MAY be placed on CTO, then gives a
    MUST about that value. Just checking that its intended to be
    ok to implement with no maximum CTO at all.
    
    - 4.2.2, a reference to the limited experimented with BT nodes
    would be nice (I've a few such comments, the added references
    would be good I think if someone's reading this in 10 years
    time, which they may do.)
    
    - 4.3 a reference to the G.114 doc would be nice (incl. the
    version since that can change and the 150ms recommendation
    might also)
    
    - 4.3, references to the DNA and uTorrent implementations 
    would be nice
    
    - 5.3, typo s/worse case/worst case/
    
    - p16, a reference for NTP would be nice in Appendix A
    
    - p17, typo "condersiderations"
    
    - A.3, earlier you mentioned two BT implementations but
    here you talk about *the* BT implementation - which do
    you mean? And a reference would be nice.
  8. Brian Haberman: Comment [2012-05-17]:
    I am happy to see this document being published.  I only have a minor, non-
    blocking, comment.
    
    In several places within the document, it says that LEDBAT is "no more
    aggressive than TCP".  Given the wide range of TCP congestion control
    algorithms, I think it would be good to indicate which ones are being compared
    to LEDBAT.  I assume the document is referring to those congestion control
    algorithms that conform to RFC 5681.
  9. Barry Leiba: Comment [2012-05-21]:
    A nit:
    -- Section 2 --
    The second sentence looks like it needs to be split in
    two after "however", perhaps with a colon.
    
    Mail to Stanislav Shalunov is bouncing.  If you can't get a current address,
    you should probably remove him from the front-page authors list, and move him to
    a "Contributors" section to avoid delays during AUTH48.
    
    ====================================================
    My original DISCUSS, now recorded as a comment for posterity:
    
    I understand that the shepherd says that the algorithm "requires further
    experimentation and targeted deployments before it is ready for standards
    track."  But the shepherd also says that there are "several independent
    implementations" that include a product deployment, that there's been a lot of
    experimentation and that "parameterization and associated tradeoffs are well
    understood and documented," that "we got enough (independent) experimental data
    that guided the design decisions," and that it's been reviewed by experts from
    TCPM and ICCRG (who I presume are happy with it).  All this over a development
    period of a year and a half.
    
    It makes me wonder what experimentation is still needed, such that this can't be
    sent out a Proposed Standard.  In general, have we really gotten to where
    "Proposed Standard" means "final and perfect"?  For this specific document, is
    there really not enough data at this point to recommend greatly expanded
    deployment?  Does this really still have to be carefully rolled out here and
    there in controlled experiments?  Is it intended that this will eventually
    become a Proposed Standard?  What data will you collect from limited
    experimentation at this point, that you haven't already gotten?  How will we
    know when the experiment is ready to be turned into a Proposed Standard (or
    declared a failure), how far from that point are we now, and how will be make
    sure the experiment progresses?
    
    --------
    Response from Rolf Winter:
    
    We have seen a large deployment by a single company. While this means that there
    indeed is massive deployment, it doesn't mean we have (enough) independent data
    to say it is always safe, efficient, reliable etc. The company in question says
    they have deployed it with "good results" (no other indicators or data really).
    I personally feel that this is not enough and (as far as I am concerned) not
    enough independent experimental results. In particular, the WG made decisions
    that changed the initial design that was brought to the IETF which is what has
    been run in the wild I believe.
    
    Generally, I know what you mean when you say that this smells like Proposed
    Standard rather than Experimental. We should aim to bring good proposals faster
    to standards track, however this is congestion control and the IETF was always
    cautious when it came to congestion control (you could argue this as being
    positive or negative of course). So I think experimental here is the right way
    to go for now. We have just seen implementations from other people and I would
    like them to experiment as well (hopefully sharing more real data with the
    community).
    
    Once we decide to go standards track we would also need to define a framing
    format. I'd say we should do these two things at the same time. The experiment I
    believe is over, once people that have implemented the congestion control part
    are actually asking for a framing format. This hasn't happened as of now.
    
    --------
    Further response from Wes Eddy:
    
    One of the open questions that I think would warrant further understanding
    before going Standards Track is discussed in the Applicability Section 2.2, and
    summarized at the end:
    
      Further study is required to fully understand the behaviour of LEDBAT
      with non-drop-tail, non-FIFO queues.
    
    In my opinion, that's one of the important unknowns.  It's related to the
    question of what happens when queues are very small.
    
    Another question that has received a lot of discussion lately is whether the
    LEDBAT target delay is really low enough that the people doing competing real-
    time media flows are totally happy with it, how to know whether we've got this
    balance right, and how low it can really go without suffering from other issues.
    
    I think Rolf explained well that we tend to be pretty conservative about
    advancing CC specifications, traditionally.  Look at the progression of 2001
    (PS) in 1997 to 5681 (DS) in 2009 as an example! (and of course SS and CA
    predate RFC 2001 by quite a bit as well).
  10. Sean Turner: Comment [2012-05-21]:
    Had the same security question Stephen had.

draft-ietf-pwe3-redundancy

  1. Benoit Claise: Discuss [2012-05-23]:
    Thanks for the section 4.2.  Operational Requirements, but I believe that you
    miss the monitoring part.
    Only configuration is mentioned at 
       o  (T-)PEs
    participating in PW redundancy MUST support the
          configuration of revertive
    or non-revertive protection switching
          modes if both modes are supported.
    
    Please add a bullet point about the monitoring of the protection switching mode,
    along with the configuration.
    Always imagine the situation of two NMS changing
    the configuration....
    
  2. Benoit Claise: Comment [2012-05-23]:
    I've been confused by the section 3.2.1 title "Single Multi-Homed CE". 
    When I
    looked at the first sentence in that section, "The following figure illustrates
    an application of single segment pseudowire redundancy", I thought: ok, "single"
    in the title means SS-PW. The figure 2 was in line with that assumption.
    Following the same logic, "3.2.2. Multiple Multi-Homed CEs" was targeting MS-PW.
    However, the figure 3 was not representing MS-PW
    
    Ok, I got now, thanks to Stewart Bryant's explanation, but my point remains:
    please change the 3.2.* section titles to something more meaningful.
    For
    example:
        [Single-Homed | dual-Homed]  CE With [ MS-PW   SS-PW] Redundancy
    
    Note: I always start reading a document by analyzing the table of content!
    
    Along the same lines, section 3.2 is only for SS-PW, right? So be consistent
    with the sentence from 3.2.1 "The following figure illustrates an application of
    single segment pseudowire redundancy.": either copy it or remove it (if you have
    the title right)
    
    Part of the OPS-DIR review done by Nevil Brownlee, a few typos:
    
    1. Intro:  "ensuring that only one active path ..." needs to end in
        something like "is active at any one time."
    
    2. Terminology:  You need to be consistent in capitalising UP.
       You define "Up PW," but mostly refer to it as "UP PW."
    
    s 1:     s/describes framework/describes a framework/
    
    s 3.2.1  s/are not be propagated/are not propagated/
    
    s.3.2.4  "one of the PE to forward the traffic and the
             other to standby status." seems odd.  How about
             "one of the PE to forward the traffic, while the
             other remains in standby status" ?
    
    s 4.1    s/MUST besupported./MUST be supported./
    
    s 4.2    empty bullet at end of list
  3. Adrian Farrel: Discuss [2012-05-23]:
    Thanks for this document. It is quite readable and explains the
    scenarios well.
    
    Unfortunately, the document does not cover all possible scenarios and
    it is hard to tell whether some key ones are left out on purpose (because
    they are not needed), on purpose (because they are hard to solve), or by
    mistake (but are still important). Maybe section 3.2 can help by
    explaining whether the reference scenarios are examples or a closed set.
    
    I have a specific case in mind that can be captured by the following
    figure.
    
                |<-------------- Emulated Service ---------------->|
                |                                                  |
                |          |<------- Pseudo Wire ------>|          |
                |          |                            |          |
                |          |    |<-- PSN Tunnels-->|    |          |
                |          V    V                  V    V          |
                V    AC    +----+                  +----+     AC   V
          +-----+    |     | PE1|==================|PE2 |     |    +-----+
          |     |----------|....|...PW1.(active)...|....|----------|     |
          |     |          |    |==================|    |          |     |
          | CE1 |          +----+                  +----+          | CE2 |
          |     |          +----+                  +----+          |     |
          |     |          |    |==================|    |          |     |
          |     |----------|....|...PW2.(standby)..|....|----------|     |
          +-----+    |     | PE3|==================|PE4 |     |    +-----+
                     AC    +----+                  +----+     AC
    
    In this figure, it is unclear to me whether coordination between the
    active and standby PWs is possible without a "vertical" control
    protocol. But I am also not sure whether this is needed given that the
    PWs could be permanently provisioned and the switching could be
    performed in the CEs based on service-level OAM.
    
    But the answer to this question begs a big question about the solutions
    proposed for a number of the other scenarios. The issue can be summed
    up by asking: what is the difference between service-level protection
    and PW protection?
    
    Note that the figure is a developed case of figure 2, or a degenerate
    case of figure 3.
    
    ---
    
    There seem to be some unstated assumptions about how CEs detect and
    act on failures. For example, in 3.2.1 it is not clear whether
    both ACs from CE1 are intended to be sending traffic all the time
    (so that the PEs make the switching choices) or whether CE1 is
    expected to detect failure and switch over to the other AC.
    
    For the reverse direction traffic, this is an interesting problem
    because unless the CE is running continuity OAM in the active
    emulated service, it may not know that it needs to start receiving
    on the other AC.
    
    But, if there is an assumption that ACs are live-live, or that the
    emulated service runs OAM, then the PW protection requirements are
    quite a bit simpler.
    
    ---
    
    I think your references to RFC 4447 should often be to RFC 4446. For
    example, in Section 2:
    
       o  Up PW: A PW which has been configured (label mapping exchanged
          between PEs) and is not in any of the PW defect states specified
          in [RFC4447].  Such a PW is is available for forwarding traffic.
    
    But, maybe you would also want this to be future-proof. When *any* PW
    fault is reported by the status code field, doesn't that make a Down PW?
    
    ---
    
    The exclusion of 1+1 is, I suppose, OK if it has WG support. But the 
    presentation in Section 4.1 is a bit abrubpt: "you might be able to do
    1+1 is you like, but it is out of scope."
    
    Can you do two things:
    - indicate that 1+1 is out of scope near the top of the document so 
      that readers get the picture
    - give some reason why it is out of scope
    
  4. Adrian Farrel: Comment [2012-05-23]:
    There is quite a slection of unexplained acronyms that you should sort
    out.
    
    ---
    
    I don't think you should make such a big thing of the difference between
    SS-PW and MS-PW protection. You are doing end-to-end PW protection and if
    you call it that, you don't have to go through any hoops.
    
    As a counterpoint to this, I don't think that you can claim that
    protection mechanisms in the PSN necessarily provide everything that is
    needed for SS-PW protection. Consider a PE that is homed to two
    networks. It is likely that when switching from one network to another
    we will switch to a separate PW in its own tunnel, rather than switch
    the PW to a new tunnel. (Note also that the figure in my Discuss could
    easliy apply to SS-PWs, and AC/PE protection would be wanted and not
    available from the PSN.)
    
    But the bottom line is to have a lighter touch wrt PSN protection
    techniques. What you are defining here supplements those techniques. It
    may be run instead of or as well as PSN techniques and (obviously) is
    very useful when those techniques are not available.
    
    You certainly should not be worried about creating multiple layers of
    protection. This is normal, and an important part of network operation
    is to decise which layers to enable, and how to prioritise between the
    layers.
    
    ---
    
    I do think it is a shame that you do not consider segment protection as
    part of this work.
    
    ---
    
    It is disappointing that this document describes the solution. Surely
    you could make this document more abstract and leave the description of
    the solution to draft-ietf-pwe3-redundancy-bit.
    
    ---
    
    The terminology here seems to be very subtly different from that in
    draft-ietf-pwe3-redundancy-bit. For example "Up PW" or "UP PW". It would
    make sense to have just one terminology section between the two docs
    (probably here), and avoid any ambiguity.
    
    (Actually, there is some internal inconsistency in this I-D, as well.)
    
    ---
    
    In Section 2
    
       o  Revertive protection switching: Traffic will be carried by the
          primary PW if it is UP and a wait-to-restore timer expires and the
          primary PW is made the active PW.
    
    I think there is something missing. At least punctuation, but probably
    words.
    
    ---
    
    In section 2 there is a contradiction between the definition of Primary
    PW:
    
          When the primary PW comes back up
          after a failure and qualifies for the active state, the PW
          endpoint always reverts to it.
    
    And the existence of a definition for non-revertive switching.
    
    ---
    
    By the way, did you look at RFC 4427?               
    I find some of the terminology here a little loose and not in step with
    normal usage for protection switching.
    
    ---
    
    In Section 4.1 you have:
    
       o  Protection switchover can be initiated from a PE e.g. using a
          manual lockout/force switchover, or it may be triggered by a
          signal failure i.e. a defect in the PW or PSN.  Manual switchover
          may be necessary if it is required to disable one PW in a
          redundant set.  Both methods MUST be supported and signal failure
          triggers MUST be treated with a higher priority than any local or
          far-end manual trigger.
    
    This is very unusual and I am surprised that the operators in the WG
    have bought in to it. What it says is that if an operator takes a PW
    out of service (using a lockout) or forces the traffic onto a particular
    PW, then a network failure may override what the operator said. This
    would be pretty bad news in an optical network (because you might blind
    an engineer), but in a packet network it is only a problem because it 
    would be a surprise to the operator and might reuslt in a traffic hit.
    
    ---
    
    In section 4.1 it seems you have a somewhat underspecified requirement.
    
       o  Note that a PE MAY be able to forward packets received from a PW
          with a standby status in order to avoid black holing of in-flight
          packets during switchover.  However, in the case of use of VPLS,
          all VPLS application packets received from standby PWs MUST be
          dropped, except for OAM packets.
    
    Probably...
    s/Note that a PE MAY be able to forward/A PE MAY forward/
    
    But also, how long does it go on doing this for? 
    And in the VPLS case, what about control plane packets? Do you really
    mean s/OAM/ACH/ ?
    
    ---
    
    Please sort out "redundant set" vs. "redundancy set"
  5. Barry Leiba: Comment [2012-05-05]:
    Matthew, thank you: the -08 version is clear, and a pleasure to read.  It has
    fixed all my concerns about the language.  Good work.
  6. Sean Turner: Comment [2012-05-22]:
    Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-
    ietf-pwe3-redundancy-bit.
    
    Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-
    ietf-pwe3-redundancy-bit.  Can't you just point from on to the other?
    
    This uses the TCP MD5 "signature" option [RFC5036].  KARP's hopefully going to
    get this fixed sooner rather than later.  So there's nothing for the authors to
    do about this otherwise recurring gripe.
    
    I'd like to suggest some tweaks to the security considerations section, assuming
    of course that I've not totally missed the mark:
    
    1st - I think the "LDP extensions" are referred to as options in both RFC 4447
    and 5036?
    2nd - I think there's only one of them?
    3rd - I think you mean control
    plane not control protocol?
    
    How about the following tweaks to the security considerations section:
    
       This document uses the TCP MD5 Signature option, as specified
       in [2],  to protect pseudowires.  This document has the same
       security considerations as in the PWE3 control-plane [2].
    
    If you want to future proof the text more maybe:
    
       LDP extensions/options that protect pseudowires must be
       implemented because the security considerations for the
       bits defined in this document have the same security
       considerations as the PWE3 control-plane [2].

draft-ietf-ccamp-assoc-info

  1. Brian Haberman: Comment [2012-05-18]:
    I have no objection to the publication of this document.  I do have a
    comment/suggestion though...
    
    1. I believe that the 2nd paragraph of the intro can be substantially re-worded
    or deleted altogether.  The thrust of the draft is to provide additional detail
    on the use of association information.  That does not require referencing
    Adrian's e-mail to the list.
    
    2. If the text in the intro that references Adrian's e-mail is removed, the
    Acknowledgments section can be re-worded to drop the reference as well.

draft-irtf-rrg-ilnp-v4opts

  1. Stewart Bryant: Discuss [2012-05-23]:
    I respectfully disagree with the evaluation of the IESG shepherd WRT this
    document not being in conflict with existing IETF work.
    
    The IETF is working to phase out IPv4, and yet the proposal here seems to be to
    extend the capabilities of IPv4, which is contra to that goal. If this draft is
    to be published it should surely go straight to historic status.
    
    I do not think that we should be authorizing the assignment of IPv4 options to
    this protocol. The purpose of the protocol is to run an experiment and as such
    it should preferably be run on one of the existing experimental options. If the
    existing experimental options are not of a suitable type, a new experimental
    option could be considered.
    
  2. Stewart Bryant: Comment [2012-05-23]:
    Re the para starting:
    
    Currently deployed IPv4 routers from multiple router vendors use
    packet forwarding silicon that is able to parse past IPv4 options
    to examine the upper-layer protocol header at wire-speed on
    reasonably fast (e.g. 1 Gbps or better) network interfaces. 
    
    I am not sure what routers designs the authors have evaluated, but I would have
    anticipated that a significant number of deployed routers will either drop or
    punt any packet that does not start with 45 in the first octet.
  3. Adrian Farrel: Comment [2012-05-23]:
    I agree with Stewart's Discuss stating that there is no need to allocate
    IPv4 options for this experiment since it can be run on existing 
    experimental options.
    
    The authors give a reason why using the existing values would
    not meet their requirements. I dispute the reason as follows:
    
    >  In order to experiment with a new protocol, an experimental value may
    >  be needed that won't collide with an existing or future usage.
    
    It is precisely the nature of experiments that they may colide if they are 
    run in overlapping networks. There are sufficient code points available 
    that this can be coordinated if there are multiple experiments. There are
    no existing experiments that immediately spring to mind. Future
    experiments will be less likely as IPv4 is sunsetted.
    
    ---
    
    The LISP documents (currently in the RFC Editor Queue for publication
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    text to caution the user about the unknown side-effects of conducting
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
       This experimental specification has areas that require additional
    experience and measurement.  It is NOT RECOMMENDED for deployment
       beyond
    experimental situations.  Results of experimentation may lead
       to
    modifications and enhancements of protocol mechanisms defined in
       this
    document.  See Section 15 for specific, known issues that are in
    need of further work during development, implementation, and
       experimentation.
    
       An examination of the implications of LISP on Internet traffic,
       applications, routers, and security is for future study.  This
       analysis will explain what role LISP can play in scalable routing and
       will also look at scalability and levels of state required for
       encapsulation, decapsulation, liveness, and so on.
    
    It seems to me highly desirable that similar caveats be applied to this
    work and added to the front of all ILNP documents. I strongly urge the
    authors and IRSG to apply such text.

draft-irtf-rrg-ilnp-noncev6

  1. Stewart Bryant: Discuss [2012-05-23]:
    I respectfully disagree with the evaluation of the IESG shepherd WRT this
    document not being in conflict with existing IETF work. The IETF is conducting
    experimental work in this area (LISP & HIP) and this needs to be referenced.
    

draft-irtf-rrg-ilnp-icmpv6

  1. Stewart Bryant: Discuss [2012-05-23]:
    I respectfully disagree with the evaluation of the IESG shepherd WRT this
    document not being in conflict with existing IETF work. The IETF is conducting
    experimental work in this area (LISP & HIP) and this needs to be referenced.
    
    Additionally, when the author of draft-templin-aero wanted to do experimental
    work using ICMPv6 we directed them to using an experimental identifier. For
    consistency we should do the same in the case of the ILNP experiment. If a new
    experimental type is needed we should create that and make it available to all
    experiments.
    
  2. Adrian Farrel: Discuss [2012-05-23]:
    Agreeing with Stewart, I cannot see (from this document or from discussions in
    email threads) why ILNP cannot make use of Experimental code points to conduct
    this experiment.
    
    Indeed, the Abstract says:
    
       This note specifies an experimental ICMPv6 message type used with
       the Identifier-Locator Network Protocol (ILNP).
    
    ...which seems to be in direct contradiction with the IANA considerations
    section.
    
    I propose that the IESG refuse this request for a code point and refer the
    authors and IRSG to the existing experimental code points.
    
    ---
    
    I think the 5742 review should note that this work is related to the work
    conducted in the LISP and HIP working groups. Presumably, if it is using ICMP,
    it is also related to work in 6man.
    
  3. Adrian Farrel: Comment [2012-05-23]:
    The LISP documents (currently in the RFC Editor Queue for publication
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    text to caution the user about the unknown side-effects of conducting
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
       This experimental specification has areas that require additional
    experience and measurement.  It is NOT RECOMMENDED for deployment
       beyond
    experimental situations.  Results of experimentation may lead
       to
    modifications and enhancements of protocol mechanisms defined in
       this
    document.  See Section 15 for specific, known issues that are in
    need of further work during development, implementation, and
       experimentation.
    
       An examination of the implications of LISP on Internet traffic,
       applications, routers, and security is for future study.  This
       analysis will explain what role LISP can play in scalable routing and
       will also look at scalability and levels of state required for
       encapsulation, decapsulation, liveness, and so on.
    
    It seems to me highly desirable that similar caveats be applied to this
    work and added to the front of all ILNP documents. I strongly urge the
    authors and IRSG to apply such text.

draft-irtf-rrg-ilnp-icmpv4

  1. Stewart Bryant: Discuss [2012-05-23]:
    I respectfully disagree with the evaluation of the IESG shepherd WRT this
    document not being in conflict with existing IETF work. The IETF is conducting
    experimental work in this area (LISP & HIP) and this needs to be referenced.
    
    The IETF is working to phase out IPv4, and yet the proposal here seems to be to
    extend the capabilities of IPv4, which is contra to that goal. If this draft is
    to be published it should surely go straight to historic status.
    
    I do not think that we should be authorizing the assignment of ICMPv4
    codepoints  to this protocol. The purpose of the protocol is to run an 
    experiment and as such it should preferably be run on one of the existing 
    experimental codepoints. If the existing experimental codepoints are not 
    of a suitable type, a new experimental option could be considered.
    This is consistent with the advice given to the author of draft-templin-aero 
    wanted to do experimental work using  ICMPv6 we directed them to using 
    an experimental identifier.
    
  2. Adrian Farrel: Discuss [2012-05-23]:
    [Updated Discuss to reflect new discoveries in the IANA registries]
    
    I think that the IESG's 5742 response on this document should note that
    this is related to the work in LISP and HIP. I wonder whether it should 
    also note that it is related to Sunset4.
    
    ---
    
    I am very uneasy about allocating a new code point for ILNP from the 
    ICMP message type registry. This seems incompatible with reducing the
    work on extensions that keep IPv4 viable and detract from moving to 
    IPv6. It seems that (as with LISP) the bulk of the research work should 
    be focussed on IPv6, and the IPv4 work should be archival not
    experimental.
    
    Thus, I do not think the IESG should grant the request for a code point
    in this case.
    
    Two ICMP messages types (253 and 254) are provided for 
    experimentationand could be used in this case.
    
    The authors also note in this document:
    
       there is no
       architectural difference between using ICMP and using some
       different framing, for example UDP.
    
    therefore I believe that our refusal of a code point would not prevent
    experimentation from being done.
    
  3. Adrian Farrel: Comment [2012-05-23]:
    The LISP documents (currently in the RFC Editor Queue for publication
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    text to caution the user about the unknown side-effects of conducting
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
       This experimental specification has areas that require additional
    experience and measurement.  It is NOT RECOMMENDED for deployment
       beyond
    experimental situations.  Results of experimentation may lead
       to
    modifications and enhancements of protocol mechanisms defined in
       this
    document.  See Section 15 for specific, known issues that are in
    need of further work during development, implementation, and
       experimentation.
    
       An examination of the implications of LISP on Internet traffic,
       applications, routers, and security is for future study.  This
       analysis will explain what role LISP can play in scalable routing and
       will also look at scalability and levels of state required for
       encapsulation, decapsulation, liveness, and so on.
    
    It seems to me highly desirable that similar caveats be applied to this
    work and added to the front of all ILNP documents. I strongly urge the
    authors and IRSG to apply such text.

draft-irtf-rrg-ilnp-eng

  1. Stewart Bryant: Discuss [2012-05-24]:
    This is a discuss discuss and is entered for IESG procedural reasons.
    
    This document needs an IESG response that is consistent with the responses for
    the other documents in this set.
    
  2. Stewart Bryant: Comment [2012-05-24]:
    Section 10.4 calls up problems that are better described as access router
    problems and not end-system changes. These are  quite serious issues and
    probably need greater prominence.

draft-irtf-rrg-ilnp-dns

  1. Stewart Bryant: Comment [2012-05-24]:
    I agree with the Discuss and Comments entered by Adrian
  2. Adrian Farrel: Discuss [2012-05-23]:
    I think the IESG 5742 review should mention that this work is related to work
    done in LISP and HIP. Presumably, the suggested additions to DNS make it related
    to DNSEXT as well.
    
  3. Adrian Farrel: Comment [2012-05-23]:
    The LISP documents (currently in the RFC Editor Queue for publication
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    text to caution the user about the unknown side-effects of conducting
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
       This experimental specification has areas that require additional
    experience and measurement.  It is NOT RECOMMENDED for deployment
       beyond
    experimental situations.  Results of experimentation may lead
       to
    modifications and enhancements of protocol mechanisms defined in
       this
    document.  See Section 15 for specific, known issues that are in
    need of further work during development, implementation, and
       experimentation.
    
       An examination of the implications of LISP on Internet traffic,
       applications, routers, and security is for future study.  This
       analysis will explain what role LISP can play in scalable routing and
       will also look at scalability and levels of state required for
       encapsulation, decapsulation, liveness, and so on.
    
    It seems to me highly desirable that similar caveats be applied to this
    work and added to the front of all ILNP documents. I strongly urge the
    authors and IRSG to apply such text.

draft-irtf-rrg-ilnp-arch

  1. Stewart Bryant: Discuss [2012-05-23]:
    I think that we need to go with at least the statement concerning LISP and HIP
    as these are experimental protocols being run by IETF WGs.
    
    Additionally the document needs to include either a reference to to RFC 6115, or
    equivalent reservation text so that it is treated with parity WRT to the LISP
    documents. The document also needs to provide a reference to the LISP work.
    
    The IPv4 text in the draft implies that we are continuing to develop IPv4
    functionality and should be changed to make it clear that IPv4 is entering the
    end of its life.
    
  2. Stewart Bryant: Comment [2012-05-23]:
       be mapped and then tunnelled through the inter-domain core of the
       Internet. Another class being considered is sometimes known as
       "Identifier/Locator Split". This document relates to a proposal
       that is in the latter class of evolutionary approaches.
    
    SB> Given that LISP is an IETF WG which seems to be operating in
    SB> this area, why is there no reference to this work?
    
       when designing the TCP/IP protocol suite.  Unfortunately, that
       separation did not occur, so the deployed IPv4 and IPv6 Internet
       entangles upper-layer protocols (e.g. TCP, UDP) with
       network-layer routing and topology information (e.g. IP
       addresses) [IEN1] [RFC768] [RFC793].
    
    SB> You can have ID/Loc splitting below the transport layer and there are many
    ways to design it.
    
       The key idea proposed for ILNP is to directly and specifically
       change the overloaded semantics of the IP address. The Internet
       community has indicated explicitly, several times, that this use
       of overloaded semantics is a significant problem with the use of
       the Internet protocol today [RFC1498] [RFC2101] [RFC2956]
       [RFC4984].
    
    SB> Please be aware that there are a number of competing proposal to encode
    information in an IPv6 address.
    
                Layer     |          IP          |     ILNP
           ---------------+----------------------+---------------
             Application  |  FQDN or IP address  |  FQDN
             Transport    |  IP address          |  Identifier
             Network      |  IP address          |  Locator
             Physical i/f |  IP address          |  MAC address
           ---------------+----------------------+---------------
    
    SB> What if the physical interface is not a LAN?
    SB> Surely IP resolves an IP
    address to a physical interface or indeed a virtual interface. This is
    particularly
    SB> necessary with an unnumbered interface.
    SB>
    SB> You might
    consider borrowing the notation used by the  Transport Network(sic) engineers
    and use a client
    SB> server model when you go below IP.
    SB> 
    SB> Hopefully you
    later consider recursive newtwork designs.
    
       Where, today, IP packets have:
    
        - source IP address, destination IP address
    
       instead ILNP packets have:
    
        - source I-LV, destination I-LV
    
       However, it must be emphasised that the I-LV and the IP address
       are *not* equivalent.
    
       With these naming enhancements, we will improve the Internet
       architecture by adding explicit harmonised support for many
       functions, such as multi-homing, mobility and IP Security.
    
    SB> This is a view of the network based on the concept of a 
    SB> classic global IP layer.
    SB> There are many new applications emerging that don't think that
    SB> way and want multiple instances. In other words they have
    SB> addresses that exist outside the network - sort of Godel addresses.
    
       Specifically in response to [RFC4984], ILNP improves routing
       scalability by helping multi-homed sites operate effectively with
       provider-aggregatable (PA) address prefixes. Many multi-homed
       sites today request provider-independent (PI) address prefixes so
       they can provide session survivability despite the failure of one
       or more access links or Internet Service Providers (ISPs). ILNP
       provides this session survivability by having a
       provider-independent node Identifier value that is free of any
       topological semantics. This I value can be bound dynamically to a
       provider-aggregatable L value, the latter being a topological
     
    SB> I may have missed it, but I do not see a definition or "I" or "L"
    
    3. ARCHITECTURAL CHANGES INTRODUCED BY ILNP
    
    3.1 Identifiers
    
       In normal operation, a node will not change its set of valid
       Identifier values frequently. However, a node MAY change its set
    
    SB>You do not define frequently.
    
       of valid Identifier values over time, for example in an effort to
       provide identity obfuscation, while remaining subject to the
       architectural rule of the preceding paragraph.
    
    SB> Surely there are less arcane reasons to change identity besides
    SB> security by obscurity, for example there are business reasons
    SB> such as restructuring the business or re-purposing of the 
    SB> equipment.
    
    3.1.2  Syntax
    
       ILNP Identifiers have the same syntax as IPv6 Interface
       Identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI],
       which helps with backwards compatibility. 
    
    SB> IFF the requirement is to solve the problem with a single
    SB> layer of encapsulation.
    
       There is no semantic
       equivalent to an ILNP Identifier in IPv4 or IPv6 today.
    
    SB> Is this true? You could regard the problem as solved
    SB> by updating DNS, thus the issue is not semantics
    SB> but performance in today's networks.
    
       The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6
       Interface Identifiers contains a bit indicating whether the value
       has global-scope or local-scope [IEEE-EUI] [RFC4219].  ILNP
       Identifiers have either global-scope or local-scope. If they have
       global scope, they SHOULD be globally unique.
    
    SB> Why are global (and you need to define global) identifiers
    SB> not REQUIRED to be unique?
    
       Regardless of whether an Identifier is global-scope or
       local-scope, an Identifier MUST be unique within the scope of a
       given Locator value to which it is bound for a given session or
       packet flow. 
    SB> For that network instance.
    
    As an example, with ILNPv6, the ordinary IPv6
       Neighbour Discovery (ND) processes ensure that this is true, just
       as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork
       have the same IPv6 address at the same time.
    SB> Is that true, or do mean that no more than two are concurrently
    SB> operational in that network instance?
    
    3.4 Notation
    
    3.5  Transport-layer state and transport pseudo-headers
    
       In ILNP, protocols above the network-layer do not use the Locator
       values. Thus, the transport-layer uses only the I values for the
       transport-layer state (e.g. TCP checksum, UDP checksum), as is
       shown, for example, in expression (6) above.
    
    SB> I have not seen you note to the reader that the code to calculate the 
    SB> transport checksums needs to change.
    SB>
    SB> Also surely NATs need to change as a result of this?
    
    3.7 ILNP Multicasting
    
       Multicast forwarding and routing are unchanged, in order to avoid
       requiring changes in deployed IP routers and routing protocols.
       ILNPv4 multicasting is the same as IETF standards-track IPv4
       multicasting. 
    
    SB> What does this mean?
    SB> You used the IPv4 address as a locator, so either ILNP does
    SB> not support IPv4 m/c or you only support m/c to the loc.
    
    5.1 Host Multi-Homing (H-MH)
    
       At present, host multi-homing is not common in the deployed
       Internet.  
    
    SB> Ah, what about all of the laptops that are connected
    SB> to both Ethernet and WiFi? A number of these have
    SB> one or more virtual network connections in addition.
     
    8. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT
    
       ILNPv4 is backwards compatible with existing IPv4. As the IPv4
       address fields are used as 32-bit Locators, using only the
       address prefix bits of the the 32-bit space, IPv4 routers also
       would not require changes.  An IPv4 router would be unaware
       whether the packet being forwarded were classic IPv4 or the
       proposed enhancement in ILNPv4 [ILNP-V4OPTS]. 
    
    SB> Most IPv4 routers are aware that they are being presented
    SB> with IPv4  packets carrying options
  3. Wesley Eddy: Comment [2012-05-21]:
    I found one typo:
    Section 3.3: "thought it" -> "though it"
    
    In section 5.2, MP-TCP is actually being defined by the MPTCP working group (not
    TCPM).  You could cite RFC 6182 for the MPTCP architecture.
  4. Adrian Farrel: Comment [2012-05-23]:
    The LISP documents (currently in the RFC Editor Queue for publication
    as Experimental RFCs in the IETF Stream) have clear and unambiguous
    text to caution the user about the unknown side-effects of conducting
    the experiment on the Internet. For example, draft-ietf-lisp-23 says:
    
       This experimental specification has areas that require additional
    experience and measurement.  It is NOT RECOMMENDED for deployment
       beyond
    experimental situations.  Results of experimentation may lead
       to
    modifications and enhancements of protocol mechanisms defined in
       this
    document.  See Section 15 for specific, known issues that are in
    need of further work during development, implementation, and
       experimentation.
    
       An examination of the implications of LISP on Internet traffic,
       applications, routers, and security is for future study.  This
       analysis will explain what role LISP can play in scalable routing and
       will also look at scalability and levels of state required for
       encapsulation, decapsulation, liveness, and so on.
    
    It seems to me highly desirable that similar caveats be applied to this
    work and added to the front of all ILNP documents. I strongly urge the
    authors and IRSG to apply such text.
    
    This is particularly important in this document as it is the cornerstone
    of the ILNP project.
    
    I believe it would also be really good to do more analysis in this
    document of what type of further experimentation is welcomed, and
    how it should be carried out. Without that, this document is little
    more than a hostoric record.
    
    ---
    
    A reference in the Introduction to RFC 6115 would be highly appropriate.
  5. Pete Resnick: Comment [2012-05-22]:
    I am fine with either 5742 IESG note, but if we go with the latter one about
    LISP and HIP, it should probably apply to all of the documents. I don't know
    what Lars would do differently based on the IESG note, so it is probably moot.

draft-irtf-rrg-ilnp-adv

  1. Stewart Bryant: Discuss [2012-05-24]:
    This is a discuss discuss and is entered for IESG procedural reasons. 
    
    This document needs an IESG response that is consistent with the responses for
    the other documents in this set.