IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-10-06. These are not an official record of the meeting.

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

Corrections from:

1 Administrivia

  1. Roll Call 1136 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. Sieve Notification Mechanism: SIP MESSAGE (Proposed Standard)
    draft-ietf-sieve-notify-sip-message-06
    Token: Pete Resnick
    Discusses/comments (from ballot 3523):
    1. Adrian Farrel: Comment [2011-10-04]:
      I have a bunch of Comments on this document. I don't think any is serious enough to merit a Discuss, but I do hope the authors will have a look at addressing them before the document is advanced for publication.
      (7 items)
    2. Stephen Farrell: Comment [2011-10-04]:
      - I don't get the use-case for this - why would I want a SIP MESSAGE for each of the emails I get? I think a motivating use-case (or reference thereto) would be useful.
      - (Related to discuss point 1) How can a program "take care" to "ensure that confidential information is not sent" when any inbound mail might be forwarded? If you mean that deployments SHOULD use sips URIs then just saying that seems better.
      - If someone set this up and that could be detected from the Internet, and if each SIP MESSAGE cost someone some money, then a botnet could easily ramp up a whole lot of charges. Is that something that warrants a mention? (I'm not sure.)
    3. Dan Romascanu: Comment [2011-10-05]:
      I have a similar comment as Stephen (in his first comment). The use case is not clear, and some text or reference about why and where notifications are sent over SIP would be useful.

    Telechat:

  2. Enhanced RDMA Connection Establishment (Proposed Standard)
    draft-ietf-storm-mpa-peer-connect-07
    Token: David Harrington
    Note: David Black (david.black@emc.com) is the document shepherd.
    Discusses/comments (from ballot 3791):
    1. Adrian Farrel: Comment [2011-10-05]:
      Readable document, thank you.
      RDMA is not a "well known" acronym at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
      You should expand it in the Abstract and Introduction.
      (You might also want to lobby the RFC Editor to get it made "well known"
      MPA will also need expansion in the Abstract.
      FULPDU: Framed Upper Layer Protocol PDU
      How many letter Ps?
    2. Stephen Farrell: Comment [2011-10-04]:
      - The abstract uses the asconyms MPA and RDMA without expansion, it'd be better not to do that and generally many acronyms are used before being expanded - a pass to fix that would be useful
      - The security considerations section says that this changes nothing compared to RFC 5044, however, I guess that a peer could try a DoS against another peer by setting large xRD values, but I don't know if that's significant enough to warrant a mention or not. Is it? If it were, then I guess just a warning that implementations ought to have some kind of sanity checking on those inputs would suffice.
      - Just out of curiosity - RFCs 5043 and 5044 seem to say: "if you want security, do IPsec" - is that how things are actually deployed?
    3. Russ Housley: Discuss [2011-09-30]:
      The Gen-ART Review by Elwyn Davies on 26-Sept-2011 raises some concerns that deserve a response.

    Telechat:

  3. Dual Stack Hosts Using "Bump-in-the-Host" (BIH) (Proposed Standard)
    draft-ietf-behave-v4v6-bih-06
    Token: David Harrington
    Note: Dave Thaler (dthaler@microsoft.com) is the document shepherd.
    Discusses/comments (from ballot 3896):
    1. Ralph Droms: Comment [2011-10-05]:
      Thanks to the authors for a well-written, easily understandable document.
      Assuming that this recommendation in section 2.3 (which I think appears elsewhere; e.g., in section 2.3.2) is a general recommendation:
      "Hence the socket API layer option is RECOMMENDED."
      it might be helpful to emphasize the recommendation by repeating it somewhere up front in the Introduction.
      In section 2.3.4, why would availability of an IPv4 interface case BIH to shut down?
    2. Adrian Farrel: Comment [2011-10-05]:
      Clearing my Discuss having seen an email from the WG Chair to the original IPR holder.
    3. Stephen Farrell: Discuss [2011-10-04]:
      - 2.3 says "If there is a real IPv4 address available..." but doesn't say what is meant by "real" nor "available"- is it that an A record was returned with a non-1918 address that is contactable or what? Note - I'm not asking for any particular definition, just that these terms be well-defined here.
      - 2.3.2 says the "main resolver of a host running BIH SHOULD NOT perform validation of A records" - I think you don't mean that that resolver should never validate A records (e.g. while BIH is not running) so clarifying that might be good e.g. by saying "While running BIH, the main resolver of the host SHOULD NOT perform validation of A records. While not running BIH, that resolver can use DNSSEC in the same way that any other resolver can." or something like that.
      - 2.4 refers to section 4.3 for private addresses to use - shouldn't that be referring to section 4.4?
    4. Stephen Farrell: Comment [2011-10-04]:
      - The term "DNS synthesis" is used but not defined here. It might be worth explaining.
      - 2.2, end of 1st para has a lowercase "should" - is that meant to be a 2119 SHOULD or not?
      - 7.3 refers to "port translation" but I didn't see any discussion of ports here - is the text there correct?
    5. Russ Housley: Comment [2011-10-04]:
      The Gen-ART Review by Wassim Haddad on 3-October-2011 raised this concern, and it needs to be resolved.
      Please clarify the connection to the two obsoleted (RFCs 2767 & 3338).
      - The document states that it "obsoletes" them in the title page header and the abstract.
      - The document states that it "updates" them in the Introduction.
      - The document says that it is a "direct update to and directly derivative" from them in section 1.1.
      - The document says that it "combines and obsoletes" them in section 8.
      Please be clear that this document draws from the material in these RFCs, and that it obsoletes them.
    6. Pete Resnick: Comment [2011-10-05]:
      2.3 - I agree with Stephen's DISCUSS: MUST the ENR wait for an explicit negative response on the A record lookup, or can it synthesize from the AAAA in other circumstances? Probably best to explicitly say so. I guess I'd like to hear specifically what "only IPv6 addresses are available" means.
    7. Dan Romascanu: Comment [2011-10-06]:
      1. Section 1 uses the term 'DNS synthesis' without defining it.
      2. Section 5 deals with ALG considerations but ALG is never expanded
    8. Peter Saint-Andre: Comment [2011-10-03]:
      The abstract states that this document obsoletes RFC 2767 and RFC 3338. The introduction states that this document updates those RFCs. I think the introduction might need to be changed.
      Given that RFC 2767 was informational and RFC 3338 was experimental, it might be helpful to summarize the results of the experiment (e.g., implementation and deployment experience).

    Telechat:

  4. OTP Pre-authentication (Proposed Standard)
    draft-ietf-krb-wg-otp-preauth-19
    Token: Stephen Farrell
    Note: Sam Hartman (hartmans-ietf@mit.edu) is the document shepherd.
    Discusses/comments (from ballot 3902):
    1. Adrian Farrel: Comment [2011-10-04]:
      I am ballotting "No Objection" on the basis of a light read and reliance on the Security COmmunity to have done adequate review.
      Note that idnits shows an unused reference, RFC 5280. Please clean this up.
    2. Pete Resnick: Discuss [2011-10-05]:
      I agree with Peter's analysis in the end regarding otp-service and otp-vendor: These items are not used in any comparison, and therefore there should not be any mention of their case-sensitivity (or lack thereof) or their comparison.
      On the PIN however, you have a real problem. This appears to be a UTF-8 string taken from user input and then used in the security token. Unicode strings taken from user input have all sorts of interesting issues depending on the kinds of normalization used by the input method. In the best circumstances, this means a bunch of false negatives when comparing. In the worst circumstances, there could be some interesting false positives. I don't know if it's the place of this document to discuss all of this, but there at *least* needs to be some comment in the security considerations section if this is going to be a UTF-8 string.
    3. Peter Saint-Andre: Discuss [2011-10-05]:
      This document appears to nicely extend RFC 6113 and RFC 4120.
      There is one point I would like to chat about.
      I think we need to say a bit more about string comparison of elements that are of type UTF8String. Section 3.3 says:
      "Any string comparison operations carried out against the values of otp-service and otp-vendor MUST be case sentive."
      First, see draft-iab-identifier-comparison-00 for an extensive discussion of security issues related to comparison of identifiers.
      Second, it is not clear if the otp-service and otp-vendor elements are in fact subject to automated string comparison in the client. For example, Section 3.2 states:
      "The KDC MAY use the otp-service field to assist the client in locating the OTP token to be used by identifying the purpose of the authentication. For example, the otp-service field could assist a user in identifying the token to be used when a user has multiple OTP tokens that are used for different purposes."
      and:
      "The KDC MAY include the otp-vendor field in an otp-tokenInfo to identify the vendor of the token that can be used in the authentication request in order to assist the client in locating that token."
      Furthermore, Section 3.3 states:
      "The otp-service, otp-vendor, otp-tokenID, otp-length and otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to assist the client in locating the correct token to use but the use of the above fields will depend on the type of token. If connected tokens are used then these values SHOULD be used by the client to locate the correct token if connected and otp-vendor and otp-service MAY also be displayed to prompt the user if the correct token is not found. If the token is not a connected token, then the values of otp-service and otp-vendor MAY be displayed to the user in order to help the user select the correct token and the values of otp-algID, otp-tokenID and otp-length MAY be ignored. Any string comparison operations carried out against the values of otp-service and otp-vendor MUST be case sentive."
      And Appendix B.1 states:
      "6. The client displays the value of otp-service and prompts the user to connect the token."
      So it seems that the otp-service and otp-vendor elements are shown to the user for visual comparison, not compared within the client in an automated fashion.
      If that is so, then we might be able to remove the sentence about string comparison, but we will want to add some stern warnings about the hazards of visual comparison, such as the following text from draft-iab-identifier-comparison...
      "Some strings are visually confusable with others, and hence if a security decision is made by a user based on visual inspection, many opportunities for false positives exist. As such, highly secure systems should not rely on visual inspection."
      If that is not so and the otp-service and otp-vendor elements are indeed compared in an automated way within the client, we will need to say more than merely "compare in a case-sensitive manner" (see RFC 5895 for some related considerations) and Pete Resnick and I will probably want to confer about recommended text.
      Finally, given that the PIN element is also of type UTF8String, it would be good to clarify whether it, too, is compared in an automated fashion (within the server) or whether it even needs to be a UTF8String.
    4. Peter Saint-Andre: Comment [2011-10-05]:
      It would be helpful to cite RFC 4120 regarding the definition of the "nonce" production as a 32-bit integer (so as to avoid confusion about comparison of nonces when authenticating the user) and to clarify the exact nature of the nonce (e.g., Section 4.1 states "This nonce string MUST contain a randomly chosen component at least as long as the armor key length" whereas Section 4.2 states "This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports and MUST be chosen randomly" -- the use of "string" here might be taken to imply that the nonce is not an integer, and the difference between "at least as long" in 4.1 and "as long" in 4.2 might cause confusion about the allowable length).
    5. Sean Turner: Discuss [2011-10-05]:
      #1) s4.1: Is there something that needs to be said about otp-length if the otp-format is different? That is if it's binary is it the minimum # of bytes but if it's one of the other three then it's the number of characters? Characters can be encoded in a variety of ways. This reminds me of the text from RFC 6030 (Encoding there is Format here):
      "If the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or 'ALPHANUMERIC', this value indicates the minimum number of digits/characters. If the 'Encoding' attribute is set to 'BASE64' or 'BINARY', this value indicates the minimum number of bytes of the unencoded value."
      #2) s4.2: Is the otp-vendor is this the same as the <Manufacturer> element from RFC 6030? RFC 6030 came through the IESG and we had a (some might say lengthy) discussion about the <Manufacturer> field. There were concerns about where the values would come from. Originally, the authors of RFC 6030 wanted to take it from the OATH Manufacturer Prefix registry (http://ww.openauthentication.org/oath-id/prefixes), but to get in that registry you have to pay, if I remember correctly, like $500. Obviously, a free registry would have been better - and there is one: IANA's Enterprise Numbers. So what ended up in the RFC was this:
      "This element indicates the manufacturer of the device. Values for the <Manufacturer> element MUST be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN], "oath." MUST be prepended to the value (e.g., "oath.<prefix value from [OATHMAN]>"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.<Organization value from [IANAPENREG]>")."
      If the otp-vendor supposed to convey the same kind of info (or exactly the same kind of info) then I think it needs to use some similar language.
      #3) RFC 6030 includes a CheckDigit field:
      "This attribute indicates whether a device needs to check the appended Luhn check digit, as defined in [ISOIEC7812], contained in a challenge. This is only valid if the 'Encoding' attribute is set to 'DECIMAL'. A value of TRUE indicates that the device will check the appended Luhn check digit in a provided challenge. A value of FALSE indicates that the device will not check the appended Luhn check digit in the challenge."
      Is such a field needed when the OTPFormat is Decimal?
      #4) s5: I might be wrong here, but how is [LHA10] not a normative reference? You're using values from a registry that is later created in [LHA10]?
    6. Sean Turner: Comment [2011-10-05]:
      (17 items)

    Telechat:

  5. Using DNS SRV to Specify a Global File Name Space with NFS version 4 (Proposed Standard)
    draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08
    Token: David Harrington
    Discusses/comments (from ballot 3931):
    1. Adrian Farrel: Comment [2011-10-04]:
      "The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space."
      I love "natural." Is that just using herbal essence, or do you also use crystals?
      Section 3 might be a bit more definitive. No need to "propose" things in a published RFC.
    2. Russ Housley: Discuss [2011-09-30]:
      The Gen-ART Review by David Black on 26-Sept-2011 raises some concerns that deserve a response.
    3. Pete Resnick: Comment [2011-10-05]:
      I agree with the concerns regarding the SRV record and the mount points.
    4. Peter Saint-Andre: Discuss [2011-10-03]:
      I concur with the DISCUSS raised by Russ Housley in reference to the Gen-ART review: as far as I can see, a Service name of "_nfs4._domainroot" is not consistent with RFC 2782. If indeed the WG has formulated a solution to that problem ("in the form of a unitary single-level service name"), and if the WG has consensus on that proposed solution, then the I-D should be revised to incorporate that solution. Until that is done (or some other solution is found), I do not think it is appropriate to advance this specification to Proposed Standard.
    5. Robert Sparks: Discuss [2011-10-04]:
      I expect to clear or revise this discuss quickly based on discussion:
      It's unusual to standardize a directory name in a host's filesystem namespace (see section 4.1). Has the IETF done this before? Is it the right organization to establish this kind of convention?
    6. Robert Sparks: Comment [2011-10-04]:
      I support Peter's discuss.
    7. Sean Turner: Discuss [2011-10-04]:
      This ought be easy enough to fix (it might be that I'm reading it wrong):
      s5: The second paragraph includes: "NFS clients compliant to this standard MUST implement this functionality."
      What's the "this" referring to? The previous paragraph describes two alternatives. Maybe just reword to say which of the two must be supported?
    8. Sean Turner: Comment [2011-10-04]:
      s4.2: r/recommended/RECOMMENDED in the following:
      "As for the other attributes in fs_locations_info, the recommended approach is for a client to make its first possible contact with any ..."

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Definitions of Managed Objects for VRRPv3 (Proposed Standard)
    draft-ietf-vrrp-unified-mib-10
    Token: Adrian Farrel
    Note: Radia Perlman (radiaperlman@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 1844):
    1. Ralph Droms: Comment [2011-10-05]:
      I would like to see an expansion of the text in section 7 to answer Robert's comment.
    2. Stephen Farrell: Comment [2011-10-04]:
      I agree with Dan's discuss point #2
    3. Pete Resnick: Comment [2011-10-05]:
      Is it normal for 2119 language to appear in the MIB description sections? Seems like an odd thing to put in there, given that it occurs nowhere else in the document.
    4. Dan Romascanu: Discuss [2011-10-04]:
      DISCUSS and COMMENT modified following the RFC Editor Note.
      This document went a long way and is now in a pretty good shape. A couple of issues are worth being fixed before I can cast a Yes ballot:
      1. closed
      2. I find the description of the vulnerabilities of the writeable objects in the Security Considerations section as insufficient. Please describe what are the effects settings of the vrrpv3OperationsPriority, vrrpv3OperationsPrimaryIpAddr, vrrpv3OperationsAdvInterval, vrrpv3OperationsPreemptMode, vrrpv3OperationsAcceptMode objects at the wrong values, or of creating or deleting rows using vrrpv3AssociatedIpAddrRowStatus.
    5. Dan Romascanu: Comment [2011-10-04]:
      1. closed
      2. It would be useful to add UNITS clauses for the counter objects.
      3. closed
    6. Robert Sparks: Comment [2011-10-03]:
      Section 7 (Interpretation of RFC5798) as written does not provide enough information to let readers who were not involved in the conversation know what the disagreement actually was - they can only guess. As written, it's hard to know whether or not this is updating/profiling RFC5798.
      Is it the case that this assumption was chosen because it is the "safest" (in the sense of providing a useful MIB in as many circumstances as possible)? If so, characterizing the choice that way would be clearer. Either way, could the document capture why this work won't have to be revisited if the disagreement is ultimately resolved with a different interpretation?
    7. Sean Turner: Comment [2011-10-04]:
      I support Dan's #2 discuss.

    Telechat:

  2. IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) (Proposed Standard)
    draft-salgueiro-mmusic-image-iana-registration-08
    Token: Gonzalo Camarillo
    Discusses/comments (from ballot 3914):
    1. Dan Romascanu: Discuss [2011-10-06]:
      I would like to clarify the statement made about the document that it 'simplifies the usage of previously registered MIME media sub-types like 'image/t38' [RFC3362] that are used as SDP media descriptors for T.38 [T38].' In what way it 'simplifies'? Should this document update RFC 3362?
    2. Peter Saint-Andre: Discuss [2011-10-03]:
      Overall this is a fine document. There are two issues I'd like to chat about.
      Section 3 appears to limit the 'image' media type to still images. Would that exclude media such as animated GIFs or .mov files? If so, why?
      Section 4 claims that there are no security considerations beyond those described in RFC 4566. Yet it is known that images can contain malicious code or trigger attacks such as buffer overflows and code injection. As far as I can see, such attacks are not covered by RFC 4566. Perhaps such attacks are not possible with T.38 media, but the 'image' media type could be used to communicate other kinds of image data. Does this specification need to take such attacks into consideration?

    Telechat:

  3. Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses (Proposed Standard)
    draft-jesske-dispatch-update3326-reason-responses-05
    Token: Gonzalo Camarillo
    Discusses/comments (from ballot 3919):
    1. Adrian Farrel: Comment [2011-10-04]:
      I have cleared my Discuss after the editor convinced me that my concern had been the subject of discussion. I am still not convinced that this document is formally needed, but it certainly will not do any harm.
      The Abstract could usefully mention SIP at the start, not at the end.
      Ditto the introduction.
    2. Peter Saint-Andre: Comment [2011-10-03]:
      Some examples would be welcome (in fact, there is one example already in RFC 3326).

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Sockets API Extensions for Stream Control Transmission Protocol (SCTP) (Informational)
    draft-ietf-tsvwg-sctpsocket-31
    Token: Wesley Eddy
    Note: James Polk <jmpolk@cisco.com> is the Document Shepherd.
    Discusses/comments (from ballot 2141):
    1. Adrian Farrel: Discuss [2011-10-04]:
      I would like to see some generic discussion of the definition within this document of "deprecated" data structures, options, and functions.
      As it currently reads, you are defining sockets for SCTP as a new concept, and part of this definition includes things that you should no longer do! That looks a bit weird, especially in Section 9 which has the heading "New Functions" (they are so new, they are old :-)
      I'd suggest a new section 1.1 called "Deprecated Features"
      You need to say:
      - why they are marked deprecated
      - why you are still documenting them
      - what a new implementation is supposed to implement
      Hopefully, you can do this as a simple paragraph that can be inserted with an RFC Editor note.
    2. Adrian Farrel: Comment [2011-10-04]:
      idnits notes that RFC 1644 has been obsoleted by RFC 6247
      This is also noted in the Shepherd write-up. Please enter an RFC Editor note so the RFC Editor knows how to resolve this.
    3. Stephen Farrell: Comment [2011-10-05]:
      - In section 2, it'd be good to provide a (normative?) reference for the Posix API. Also, you're specifying the 1997 version - is that deliberate? (There seems to be a later version, but I'm not sure what today's systems follow.)
      - The security considerations might benefit from adding a generic sentence about implementation security, e.g. warning about buffer overruns, or maybe telling developers to go check out the CVE databases.
      - I was surprised not to see a mention of RFC 6083 (DTLS over SCTP). I'm not sure how DTLS would be implemented with this API. If its analogous to TLS/TCP then it'd be above this API I guess, but that'd be worth a mention, e.g. saying "If you want transport security, then DTLS [RFC 6083] can be used, but is expected to be implemented above, and not inside, this API." or something like that.
    4. Russ Housley: Discuss [2011-10-04]:
      The Gen-ART Review by Joel Halpern on 15-Sept-2011 raised a question:
      "For the shepherd's consideration: Is it sufficiently clear how the source address will be selected when sending a message, if bindx or wildcarding has been used to bind multiple source addresses? My guess is that this lack of description matches other specs in how that is handled, but I wanted to check."
      The authors suggested some text for the document, but a new version has not been posted and no RFC Editor note has been entered.
    5. Peter Saint-Andre: Comment [2011-10-05]:
      I agree that a normative reference to the POSIX specification (IEEE 1003.1) would be appropriate.
    6. Robert Sparks: Comment [2011-10-04]:
      While addressing Adrian's discuss, please look for a way to capture that this _has been_ the api definition for some time (the document's been around for a decade) and that you are deprecating parts of the API previously documented here. Please make it clear that there is no other formal definition of the API elsewhere that this is obsoleting.
    7. Sean Turner: Discuss [2011-10-05]:
      <process weenie>
      I think based on the IETF's TLP you need to put
      <CODE BEGINS>
      /*
      Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved.
      Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
      */
      code goes here
      <CODE ENDS>
      in appendix A and B.
      </process weenie>

    Telechat:

  2. Requirements for a Working Group Milestones Tool (Informational)
    draft-ietf-genarea-milestones-tool-05
    Token: Russ Housley
    Discusses/comments (from ballot 3820):
    1. Stewart Bryant: Comment [2011-10-03]:
      One minor comment:
      "The IETF Secretariat needs to be able to perform the same tasks as the WG chairs and ADs in order to fix problems or to make emergency changes."
      Surely it is simpler to say that the Secretariat should be able to perform the same tasks as the ADs (since WGC privs are a subset of AD privs).
    2. Adrian Farrel: Discuss [2011-09-30]:
      Thanks for the work. I have a number of points that I hope are relatively easy to handle.
      This document also updates RFC 6293 (see Section 7)
      Section 2: Sorry if I missed this in the discussion before: did we make an active decision that working group secretaries will not allowed to use the tool?
      Section 3: "The chair also needs to be able to delete existing milestones."
      This has worried me for a while. By "deleting" a milestone we might infer that all record is lost. I should not like that. Maybe "abort" would be a better word so that the milestone no longer remains something that the WG is trying to achieve, but the record remains in the database.
      (obvious ripples into the rest of the document)
      Did I miss it? I don't see any discussion of how the AD approves changes that need AD approval. Obviously, a mechanism must be supplied.
      Section 6: "The Datatracker needs to have a method for ADs and the Secretariat to see all the milestones that are pending approval."
      Although this list is probably short, it would be nice to be able to filter the list by AD and by Area.
      BTW This paragraph belongs in Section 4, not Section 6.
    3. Adrian Farrel: Comment [2011-09-30]:
      Section 1 second paragrpah read oddly:
      "Today, the tasks associated with creating and updating WG milestones are performed manually. Normally, WG chairs send email to their AD requesting that milestones be created or updated, or saying that one or more milestone has been met. These messages used to come as part of charter creation or updating, but will be a separate tool after the requirements in this document and in [RFC6292] are met. WG chairs sometimes send mail directly to the IETF Secretariat to make a change to the database of milestones, such as to change the dates for milestones or to say that they are completed. When a WG chair sends email to the Secretariat, the Secretariat must obtain the approval of the AD before taking the requested action."
      I'm also not sure that "milestone met" has involved the AD approval for a long time. The chairs have simply communicated to the Secretariat direct.
      How about:
      Today, the tasks associated with creating and updating WG milestones are performed manually by the Secretariat. Normally, WG chairs send email to their AD requesting that milestones be created or updated, or direct to the Secretariat saying that one or more milestone has been met. Apart from during WG creation, these updates will be made through a separate tool after the requirements in this document and in [RFC6292] are met."
      Section 1: "This document is intended to bring that discussion to a general consensus among WG chairs and ADs for the requirements for the eventual tool."
      Since this went to IETF last call, I think you could add "and the wider IETF community"
      Section 3: There seems to be some duplication between the paragraphs.
      Section 4: "Once a day, the Datatracker will look for changes to the milestones for a WG. If changes to milestones have been made in the past 24 hours, the Datatracker will send one message to the WG listing all the changes from that period."
      I don't really care, but this seems more work than just sending an email when the change is made. The purpose is to avoid swamping the WG when multipe changes are made?
    4. Pete Resnick: Comment [2011-10-05]:
      Like Adrian, I would like WG secretaries to be able to also perform the same tasks as chairs, but I think the document is fine if it does not contain this feature.
    5. Robert Sparks: Discuss [2011-10-03]:
      Apologies for catching this so late, but a point came up during testing of the charter tracking tool that probably should be clarified in this set of requirements. Paul - please wait for some discussion before updating the document to reflect any of this.
      We often want to see the milestones associated with the charter for a new group, and a recharter that's a significant rewrite for consideration as part of the approval process.
      When a group is active, and a recharter is being considered, the set of milestones the group is currently operating against (those associated with the currently approved charter) need to be editable separately from any milestones associated with a proposed recharter.
      The majority of the requirements in this document apply to maintaining milestones associated with a currently approved charter. I suggest stating explicitly that's the only data the tool being considered maintains.
      I propose that the set of milestones associated with a new unapproved charter for consideration or for a recharter be kept separately - we do not need the approval/reminder mechanics in the document for these. We could extend the (re)chartering tracking tool to carry the proposed milestones as a separate field, and can discuss (outside the context of this document) how we make sure they get applied to a newly approved charter at approval time.

    Telechat:

  3. Keying and Authentication for Routing Protocols (KARP) Design Guidelines (Informational)
    draft-ietf-karp-design-guide-05
    Token: Stewart Bryant
    Note: Joel Halpern (jmh@joelhalpern.com) is the document shepherd.
    Discusses/comments (from ballot 3864):
    1. Adrian Farrel: Comment [2011-09-21]:
      Thank you for your work on this important document. I am balloting "Yes", but I have a small raft of comments that you should look through.
      (13 items)
    2. Stephen Farrell: Comment [2011-10-04]:
      --- 04 and -05 cleared up my discuss points
      ---- original comments on -03 below
      (19 items)
    3. Russ Housley: Discuss [2011-10-06]:
      This is a long DISCUSS write-up. That is because I find that this document is not providing the design guidance that I expected based on the title of the document.
      Please consider these four points, each of them is significant I believe. Addressing them all together will, I fear, require a significant revision to the document.
      1. The KARP WG charter says: "A goal of the working group is to add incremental security to existing mechanisms rather than replacing them. Better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution."
      This is a very important bit of design guidance. The document does say that incremental deployment is needed, but I cannot find this important tradeoff described in this document.
      2. The KARP WG charter says: "This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection."
      This document talks about authentication and integrity, but it says noting about DoS protection.
      3. The KARP WG charter says: "Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols."
      This document covers much of this material. It talks about "transport mechanisms" and "communications relationships". It covers part of the material I would expect in a discussion of "security relevant characteristics of routings protocols". It covers the difference in "group" and "pairwise" communications. It does not come up with "common frameworks". I suggest that this document is a very good start at this charter deliverable.
      4. Please update [I-D.ietf-saag-crypto-key-table] to point to the KARP WG document: draft-ietf-karp-crypto-key-table.
    4. Russ Housley: Comment [2011-10-06]:
      The document tries to define "on the wire". I do not find the definition helpful. I think it is sufficient to say that "on the wire" protection can be achieved by the addition of authentication and integrity mechanisms to the routing protocol or by running the routing protocol over a security protocol the provides them.
      Why define the KMP acronym? It is not used many places.
      Please remove the URL to the MSEC charter.
    5. Peter Saint-Andre: Comment [2011-09-21]:
      Various paragraphs mention "modern, strong security algorithms", but that term is never defined. Given that the only algorithm mentioned in the text is SHA-1, the reader is left to wonder what is meant by "modern" and "strong".
      I don't see a need for the use of RFC 2119 keywords in this document.
    6. Sean Turner: Discuss [2011-10-05]:
      I had great difficulty getting through this document because I found it really hard to understand. I know I should learn to let go more, but since I think this is important I decided not to. I apologize for not spending more time with this document earlier. I have a lengthy set of comments, but none came to the level of discuss until I got to the last section and I couldn't get "it".
      #1) s7.4: Contains the following: "The desired end goal for KARP WG is to develop a strong peer-to-peer KMP; an Out-of-and external Key Management protocol is out of scope."
      s4.1 said there there were several goals for the end state of KARP. The second goal is a KMP. Maybe it's better to say something like:
      "One of the desired end goals for KARP is to develop a KMP. We further refine that goal by specifying a peer-to-peer KMP and declaring an out-of-band KMP out-of-scope."
      After reading the bullets that follow, I'm confused. In the bullets that follow, you're saying an out-of-band KMP is out-of-scope but the first option in the constraint is to use a out-of-band key management protocol?
    7. Sean Turner: Comment [2011-10-05]:
      I do not mean for any of these comments to change the intent of what was there before.
      (41 items)

    Telechat:

  4. LISP Map Server (Experimental)
    draft-ietf-lisp-ms-11
    Token: Jari Arkko
    Note: Joel Halpern (jmh@joelhalpern.com) is the document shepherd.
    Discusses/comments (from ballot 3909):
    1. Ron Bonica: Discuss [2011-10-05]:
      (Discuss has been updated yet again, based on information gleaned from the versioning draft)
      General: This document cannot be reviewed meaningfully before the LISP base document, LISP ALT and LISP SEC have been reviewed.
      General: Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.
      How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?
      General: Given the considerations raised in Section 5 and in this review, the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.
      Section 1: In the second paragraph of Section 1, you say:
      "There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database. A single device may implement one or both types of operation."
      In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.
      Section 3: The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.
      Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.
      Section 4.2: In paragraph 6 you say:
      "When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."
      What should the Map-Register message include when it does not request the proxy reply service? Are all RLOCs required? Must they include the same attributes and version numbers.
      This document is silent in that regard, however, the versioning document says:
      "Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping, including the same Map-Version number. In principle this is orthogonal to whether or not map-versioning is used. The synchronization problem is out of the scope of this document."
      This leads us to the following questions:
      - How are all ETRs servicing an EID kept in sync?
      - What are the consequence of becoming out of sync?
      Section 8.1 of the Versioning document says:
      "So far, LISP does not provide any specific synchronization mechanism, but assumes that synchronization is provided by configuring the different xTRs consistently."
      Section 8.1 of the Versioning document also demonstrates that loss of synchronization can cause network failure, whether or not version checking is enabled.
      I doubt if a manual ETR synchronization process will be sufficient. What happens during the period between the configuration of one ETR and another? What happens in case of operator error? What happens when one ETR goes offline, another is reconfigured, and the first comes back on line?
      Section 4.3: What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?
      Section 4.4: In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?
      Section 4.4: How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.
      Section 4.4: Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.
      Section 4.4: Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly? If so, what are those rules? What mechanisms enforce them.
    2. Ron Bonica: Comment [2011-10-04]:
      Section 4.2: You say: "In addition to the set of EID-prefixes defined for each ETR that may register, a Map Server is typically also be configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it."
      Grammar.
      Section 4.3: You say: "If any of the registered ETRs for the EID-prefix have requested proxy reply service, then the Map Server answered the request instead of forwarding it."
      Grammar
    3. Wesley Eddy: Comment [2011-10-05]:
      I support the first 2 parts of Stephen's DISCUSS
    4. Adrian Farrel: Discuss [2011-10-06]:
      The LISP Charter says (of the WG)... Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic.
      I do not find such disclaimers in this document. Section 5 is a good collection of issues for future analysis, but is not the same thing.
      Section 2: "Map Server: a network infrastructure component which learns EID-to-RLOC mapping entries from an authoritative source (typically, an ETR, via the registration mechanism described below)."
      I couldn't find a description of other authoritative sources.
      Section 4.1: "o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map Server answering on behalf of the ETR. Note that the stateless nature of non-caching Map Resolver forwarding means that the Map-Reply may not be from the Map Resolver to which the Encapsulated Map-Request was sent unless the target Map Resolver offers caching. See (Section 4.4) for more details on Map Resolver message processing."
      This is the first mention of the "stateless nature" of MR forwarding. The forward reference to 4.4 is helpful, but that indicates that one of the modes of operation is stateful frowarding (using the nonce).
      This is also the first indication (or rather the forward reference to 4.4 provides the first indication) that an MR might forward the request to another MR rather than direct to the ETR. I think that all the text up to this point has given the impression that the longest query flow is ITR-MR-ETR. It would be really helpful to bring out this fact earlier in the document.
      I think this might be aided by some clear description of the architecture in use and the roles of the components. A figure might even help.
      Section 4.2: "Map-Register messages are sent periodically from an ETR to a Map Server with a suggested interval between messages of one minute. A Map Server should time-out and remove an ETR's registration if it has not received a valid Map-Register message within the past three minutes. When first contacting a Map Server after restart or changes to its EID-to-RLOC database mappings, an ETR may initially send Map-Register messages at an increased frequency, up to one every 20 seconds. This "quick registration" period is limited to five minutes in duration."
      I understand why this is a good idea when an ETR starts, but it seems a big risk when a MS starts. In that case, there may be a large number of ETRs making contact and all sending Map-Reegister messages. The more rapid transmission means that the MS's queue (which might in any case be getting quite full) will get very full, yet many of the messages will be unnecessary duplicates.
      Section 4.2: "Note that a one-minute minimum registration interval during maintenance of an ETR-MS association does set a lower-bound on how quickly and how frequently a mapping database entry can be updated. This may have implications for what sorts of mobility can supported directly by the mapping system."
      A peculiar paragraph given that we have just been told that the period for sending the messages is only suggested at one minute.
      "Map-Register messages are sent periodically from an ETR to a Map Server with a suggested interval between messages of one minute."
      Surely the choice of words here implies that an ETR can send a Map-Register whenever it considers it appropriate.
      Section 4.3: "If none are found, then the Map-Server returns a negative Map-Reply with action code "forward-native" and a 1-minute TTL."
      Does this mean that the convergence time experienced by a device in a site is 1-minute because the ITR will cache a failed resolution for this amount of time. Is this a design decision of the pull nature of the ITR in a LISP system? I couldn't find any discussion of this on a quick scan of the base spec.
      I do note that you list convergence as an open issue in Section 5 (which is good).
      Section 4.4.1 is rather sparse.
      I wonder if you should punt this "for future study" rather than open the gates here but not address the issues. For example, when you use any-cast MRs I assume that the ITR will receive multiple responses. That would mean that this document should discuss the case and explain how the ITR selects between (potentially different) non-authoratative responses.
    5. Adrian Farrel: Comment [2011-10-06]:
      I find it very regrettable that this document was brough forward for IESG review before the architecture and protocol on which it depends.
      The very first word of the bdy of the document is a normative reference to the base specification which is currently in AD Review with a new revision required and a good dolop of questions from the AD for the authors to resolve.
      This means that any review of this document is necessarily moot. I am very sorry, but I may have to come back and extend my Discuss after we have reviewed the base spec.
      I recognise that this issue is not actionable by the authors, and simply supply it as a comment for the record. However, I strongly encourage the authors to keep a tight track of this document since it contains statements of protocol behavior that are lifted from the base LISP spec and which may be subject to change. Actually, I am not clear why it is helpful to restate protocol details (such as use of port numbers) in this document.
      Please expand acronyms in the Introduction on first use.
      For clarity, it is not helpful that a LISP Map Server contains two components called Map Resolver and Map Server. This means that the term "Map Server" can be confusing. For example, in Section 1: "There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database. A single device may implement one or both types of operation."
      ...yet in Section 4.3... "In response to a Map-Request (received over the ALT if LISP+ALT is in use), the Map Server first checks to see if the destination EID matches a configured EID-prefix. If there is no match, the Map Server returns a negative Map-Reply with action code "forward-native" and a 15-minute TTL. This may occur if a Map Request is received for a configured aggreate EID-prefix for which no more-specific EID-prefix exists; it indicates the presence of a non-LISP "hole" in the agregate EID-prefix."
      The latter implies that the "Map Server" operation processes a Map-Request message, where the former implies that this is processed by the "Map Resolver" operation.
      Section 4.2: "a Map Server is typically also be configured"
      d/be/
      I didn't feel that the use of LISP+ALT as an example in the text actually helped the document. In fact, in order to get a clear view of what the MS does, I found it helpful to skip those paragraphs. Additionally, it felt to me that the inclusion of discussion of this one DB scheme was prejudicing the working group's discussion of DBs.
      Section 4.3: s/Map-Server/Map Server/
      I really like section 5 and thank you for your frankness. The LISP experiment might be enhanced by the addition of more details to this section to help guide the experimenters and more quickly gather the necessary information.
      I confess that I found the repeated use of the same letters for flags in different messages and different components of messages very tricky to process. I appreciate that this would become easier with deeper experience with the protocol, and I also understand that *this* document can only use the assignments from the base spec. It might be wise to go through this document making sure that all things like "S bit" are given full context such as "the S bit of the foo message".
      I *think* the same issue arrises with "nonce".
    6. Stephen Farrell: Discuss [2011-10-06]:
      (added a few more points following further reading)
      - Section 2, definition of Map Server (and elsewhere) refers to *the* distributed mapping database. But you've previously said there are multiple schemes LISP+ALT etc so how can you talk about *the* distributed database? I think database needs to be used in the plural with possible consequences elsewhere (e.g. security guarantees might be DB dependant, implying that DB naming needs to be present in other messages). If, however, it is one DB, then you'll need to explain how LISP+ALT and others are really different schemes but yet use the same DB with the same guarantees.
      - In this case, the packet definitions are in the base document, so its not really possible to review sections 4 & 5 of this properly without first doing base. (When I got to the last sentence of section 3, my thought was: "Ah, FFS...";-)
      - 4.2: provision a shared secret - it seems odd to preclude signatures for authenticating map register messages at this level. Why do that? If you don't need to then I'd suggest s/secret shared-key/shared secret or other relevant authentication information/
      - I may need to come back about the security considerations of this document after I've reviewed [LISP] and [LISP-SEC].
    7. Stephen Farrell: Comment [2011-10-06]:
      - Section 1, 2nd para says that a "Map Server" can be a "Map Resolver" or a "Map Server" - huh? Terminology a bit messed up there really it seems. I'd suggest inventing a new term for one of the uses of "Map Server."
      - Definition of Map Resolver says "quickly" and "immediately" which are being used as marketing terms it seems. Better not to do that.
      - Map Request defn: Be good to point out somewhere (IANA considerations I guess) that port 4342 is already registered.
      - Map register defn: is "its" associated EID-prefixes correct? That implies there's no way for some other node to register EIDs on behalf of a bunch of ETRs for example.
      - typo: s/outdate, cached/outdated, cached/
      - Text in 4.1 is inconsistent about whether an ITR has one or can have more than one map resolver configured. I assume that "one or more" is the right rule, if not, you should probably say.
      - 4.1 - I've no clue why a negative map reply has to have a 15 minute ttl - why is that? (Same for other fixed TTL values.)
      - On the topic of an ETR registering bogus aggregates. It might be that a system like LISP could often detect that and react to it by dropping that ETR? Say if there were an error alerting system built into the LISP mapping store - when an ITR sees above-threshold errors for a given ETR it tells its resolver, when the resolver sees above threshold errors it passes that back etc. Not suggesting that you add that now, just a thought.
      - typo: s/outdate, cached/outdated, cached/
    8. Sean Turner: Discuss [2011-10-06]:
      s1 introduces the idea of multiple databases (NERD, CONS, LISP+ALT), but the rest of the document only discusses LISP+ALT. Does the rest of the document need to be made generic or have the authors slanted the deck for LISP+ALT? Is this because CONS is expired, NERD looks like an ISE submission, and LISP+ALT is a WG draft?
    9. Sean Turner: Comment [2011-10-06]:
      #1) I support Stephen's discusses.
      #2) s1: I support Ron's discuss about the term "Map Server" is overloaded.
      #3) Half-tongue-in-cheek: what no ping message to see if the peer is alive? ;)
      #4) s2: Maybe add to the last paragraph: "the port number assignments". I figured oh this protocol does have some assignments - they do they're just not in this draft ;)

    Telechat:

  5. LISP for Multicast Environments (Experimental)
    draft-ietf-lisp-multicast-08
    Token: Jari Arkko
    Note: Wassim Haddad <wassim.haddad@ericsson.com> is the document shepherd.
    Discusses/comments (from ballot 3910):
    1. Ron Bonica: Discuss [2011-10-05]:
      I concur with Ralph's evaluation, but will hold a separate discuss so that the termination of his evaluation does not unintentionally terminate mine.
    2. Ralph Droms: Discuss [2011-10-05]:
      I've reviewed this document keeping in mind the DISCUSS positions on other LISP documents. I found I could review the document, based on my background knowledge of LISP, but there are several details I will need to research in the LISP base spec to convince myself that this document is correct.
      That situation raises a slightly different problem than was raised in the DISCUSS positions on the other LISP documents: in my opinion, to complete my due diligence on this document, I will need to review it again after the LISP base spec has been reviewed and approved, to confirm that the approved version of the LISP base spec is still in sync with this document.
      I understand that we face a similar situation every time we review a document that contains normative references to documents that have not been approved for publication. In the case of this document set, the dependencies are sufficiently important and numerous that, again in my opinion, an additional review of this document will be required once the LISP base spec is approved.
      Therefore, I will maintain a DISCUSS position on this document until the LISP base spec is approved. I also note that I will have to do extra work in reviewing the document twice because of the order in which the documents have been brought to the IESG.
    3. Ralph Droms: Comment [2011-10-05]:
      In the numbered list of scenarios in section 9.1, there are a couple of occurrences of the term "LISP sites." Should "LISP sites" be replaced by "LISP-Multicast sites"?
      Is it assumed that a uLISP site uses non-LISP transport for multicast? If so, it would be helpful for the document to state that situation explicitly.
      In the Security Considerations section, if this document introduces no additional security concerns beyond those in LISP base spec, that assertion should be made explicitly.
    4. Wesley Eddy: Comment [2011-10-05]:
      I support Peter's DISCUSS
    5. Stephen Farrell: Discuss [2011-10-05]:
      (I bet this was a 100% predictable discuss, sorry for that. I'm even kind of wondering if its deliberate:-)
      It's really hard to believe that there are *no* new security considerations here compared to [LISP]. I suspect you might need to say that security in this environment is basically an unknown, or is that the case?
      You might also refer to some generic multi-cast security RFCs as well.
    6. Stephen Farrell: Comment [2011-10-05]:
      - It'd be good to know if this use of LISP claims some benefit over "ordinary" multicast, or if you're just making multicast work ok in a LISP environment. It doesn't matter much, but it'd be nice to say so the reader knows whether or not to get excited:-)
      - The intro leaves me wondering if a multicast group address is regarded as an EID or RLOC, or if it varies or if it matters. Just wondering. That is described at the start of section 5, but earlier would be good too.
      - You may want to expand the RPF acronym.
      - p5, 1st para after bullets - the 1st sentence talks about "protocols" but the 2nd talks about "the protocol" - seems wrong.
      - p17, oif_list is not explained here. Probably worth adding that, or a reference.
      - Section 10, 1st para, last sentence is missing something, maybe s/need to/and need to/?
    7. Russ Housley: Comment [2011-10-04]:
      Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 3-October-2011.
    8. Peter Saint-Andre: Comment [2011-10-05]:
      draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations", which provides a good start toward understanding the parameters of the experiment we're engaging in here, and perhaps some dimensions for measuring success. It would be helpful for this document to contain a similar section.
      The terminology section repeats definitions from the base LISP spec. This seems like a bad idea. It would be better to reference those definitions and here simply provide the extended information that applies only to multicast environments.
      The Security Considerations section seems rather sparse. Does the use of LISP in a multicast environment truly have no security implications whatsoever?

    Telechat:

  6. LISP Map-Versioning (Experimental)
    draft-ietf-lisp-map-versioning-04
    Token: Jari Arkko
    Note: Terry Manderson (terry.manderson@icann.org) is the document shepherd.
    Discusses/comments (from ballot 3911):
    1. Ron Bonica: Discuss [2011-10-05]:
      General: This document cannot be reviewed in a meaningful way before:
      - the LISP base document is reviewed
      - my DISCUSS against section 4.2 of the LISP Map Server document is resolved
      Section 5.1: In Bullet 2, you say:
      "2. The packet arrives with a Destination Map-Version number greater (i.e., newer) than the one stored in the EID-to-RLOC Database. Since the ETR is authoritative on the mapping, meaning that the Map-Version number of its mapping is the correct one, this implies that someone is not behaving correctly with respect to the specifications. In this case the packet carries a version number that is not valid, otherwise the ETR would have the same, and SHOULD be silently dropped."
      This reaction might be too strong, especially in a case where ETRs are temporarily out of sync (e.g., during a configuration change).
      In Section 5.2 you say: "3. The packet arrives with a Source Map-Version number smaller (i.e., older) than the one stored in the local EID-to-RLOC Cache. Such a case is not valid with respect to the specifications. Indeed, if the mapping is already present in the EID-to-RLOC Cache, this means that an explicit Map-Request has been sent and a Map-Reply has been received from an authoritative source. Assuming that the mapping system is not corrupted anyhow, the Map-Version in the EID-to-RLOC Cache is the correct one, while the one carried by the packet is stale. In this situation the packet MAY be silently dropped."
      Why would you want to drop a packet if your return route to the source is potentially corrupt?
    2. Wesley Eddy: Comment [2011-10-05]:
      I support Ron and Robert's DISCUSSes
    3. Stephen Farrell: Comment [2011-09-20]:
      If there's conflict in normative text between this and base, which takes precedence? I think you need to say, even if you believe there is no such conflict, just in case it turns out that there's some hidden conflict or the base draft changes after this one is done.
    4. Russ Housley: Discuss [2011-10-06]:
      I hope I am missing something, but I spent a fair amount of time trying to figure this out. So, if I missed something, I am sure other readers will miss it too.
      The document uses a fixed-length version number. When a received number is smaller than the stored one, the conclusion is that the sender has an older version. See for example the the 3rd numbered paragraph in Section 5.2. However, Section 4 defines a more complex algorithm that I believe is intended to recognize that a version number of 0x001 might be newer than a version number of 0xFFE.
      I found the use of "smaller" confusing in the face of wrap around.
      Further, I think the formula in Section 4 is incorrect. In my example above, 0x001 is newer than 0xFFE, so if I understand the document correctly, 0x001 should be "greater than" 0xFFE, and 0xFFE should be "less than" 0x001. The formula says:
      V1 < V2 : True if and only if V1 < V2 < (V1 + 2**(N-1)).
      This translates to: 0xFFE < 0x001 < (0xFFE + 2**11), which fails.
    5. Robert Sparks: Discuss [2011-10-04]:
      Related to the questions Richard Barnes asked in his 2Sep GenArt review (which afaict has not seen a response) - what keeps an ETR that has restarted from discarding traffic from ITRs that still have a map version cached from before the ETRs restart that happened fall in the half of the buffer the ETR would now consider "too new"?
    6. Robert Sparks: Comment [2011-10-04]:
      The comparison operator on the circular range of version numbers currently is not well defined when comparing against the value that's exactly half-way around the buffer (for example, if N were 3, it is not defined whether 1 is less than or greater than 5 (1<5<5 isn't true, nor is 5>1>1)).

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Multisegment Pseudowires in Passive Optical Networks (Informational)
    draft-li-pwe3-ms-pw-pon-06
    Token: Stewart Bryant
    Note: Daniel King (daniel@olddog.co.uk) is the Document Shepherd.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-li-pwe3-ms-pw-pon-02
    Discusses/comments (from ballot 3838):
    1. Stephen Farrell: Comment [2011-10-04]:
      The IPR declaration refers to "the standard" a couple of times so, since this is targetted at informational, its not possible for me to know if the stated terms apply or not. (Yet again;-)
    2. Pete Resnick: Discuss [2011-10-05]:
      I'd like to push Stephen's point to a DISCUSS at least until the telechat, though I am unwilling to continue this discussion past the telechat unless other ADs are really on board:
      I don't understand why this document is being put forward for IESG endorsement. It appears to be deployment instructions for a particular L2 network configuration, which doesn't seem terribly relevant to the IETF. Further, there is a patent disclosed (by the company of two out of the three authors) where that disclosure does not say how it would apply to a non-standard. It's not clear to my why this is relevant to the IETF community in the first place (the obvious WG for it had no interest in the document), and given the disclosure, I don't see clear benefit to the community to publish it.
    3. Dan Romascanu: Discuss [2011-10-06]:
      The document describes (also) the usage of OMCI for configuring end-to-end MPLS PWs over G-PON or XG-PON. However the Security Considerations section talks only about the security mechanisms of G-PON and XG-PON ('as good as those provided in a well secured MPLS PSN') and says nothing about the security mechanisms of OMCI. Are these also 'as good' as the ones used to manage MPLS networks?

    Telechat:

  2. Testing Eyeball Happiness (Informational)
    draft-baker-bmwg-testing-eyeball-happiness-05
    Token: Ron Bonica
    Note: Al Morton (acmorton@att.com) is the document shepherd.
    Discusses/comments (from ballot 3938):
    1. Wesley Eddy: Comment [2011-09-21]:
      In the timing requirements for each metric, it's confusing whether the requirement is 0.1 ms error over 60 seconds, or 1ppm, since both are mentioned.
    2. Stephen Farrell: Comment [2011-09-13]:
      (1) 2.2 says to do "at least N" runs when Bob has N addresses, but isn't that a bit misleading when alice has M addresses as well given that you're interested in the min and max over (I guess) all combinations of the (M,N) pairs that can ever work, blocking all but one each time? Maybe characterising the number of iterations like that would be better?
      (2) I wasn't clear if these metrics are also intended to be used e.g. for a config with a middlebox between router1 and router2 that enables one of Alice's IPv6 addresses setup a TCP session with one Bob's IPv4 addresses. I'm not asking for anything in particular, I just wondered and didn't get an answer from the text.
      Editorial nit-like stuff:
      (six items)
    3. Dan Romascanu: Comment [2011-09-18]:
      The Security Considerations section should mention the potential threat of overloading production networks if the conditions described in the last paragraph in Section 1 are not respected and advise care in using the test procedures in operational networks.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1239 EDT break

1244 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Binary Floor Control Protocol Bis (bfcpbis)
    Token: Gonzalo

    Telechat:

  2. Managed Incident Lightweight Exchange (mile)
    Token: Sean

    Telechat:

4.1.2 Proposed for Approval

  1. Reputation Services (repute)
    Token: Pete

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. BOF request instructions (Jari Arkko)

    Telechat:

Side question

7. Agenda Working Group News

1333 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-10-06 07:28:10 PDT)

draft-ietf-sieve-notify-sip-message

  1. Adrian Farrel: Comment [2011-10-04]:
    I have a bunch of Comments on this document. I don't think any is serious enough
    to merit a Discuss, but I do hope the authors will have a look at addressing
    them before the document is advanced for publication.
    
    ---
    
    Section 2.1
    
    Passive voice is to be avoided...
    
       The
       URI parameter "method" MUST be included and MUST contain the value
       "MESSAGE". 
    
    Must be included where and by whom?
    
    ---
    
    Section 2.1
    
    Is the "note" present twice?
    
    ---
    
    Section 2.2
    
    You have a couple of instances of :from without quote marks.
    
    ---
    
    Section 2.5
    
       The default message body
       SHOULD contain the values of the "From" and "Subject" header fields
       of the triggering email message
    
    One is bound to ask: under what circumstances can the From and Subject
    header fields be left out, and what would the result be?
    
    ---
    
    Section 2.6
    
       Implementations SHOULD NOT use the hname "body" parameter
       value as the message-body of the SIP MESSAGE request.
    
    Since this is "SHOULD NOT" they presumably can do so if they have good
    reasons. Can you state that reason or change this to "MUST NOT"?
    
    ---
    
    Section 2.6
    
       If the notification request fails, there will be a SIP error code
       describing the failure.
    
    Elegant prose, but unsure exactly what it means. It could mean that
    there is no failure other than one for which a SIP error code has been
    defined. Or it could mean that an error code will be found in a majick
    place.
    
    ---
    
    Section 2.7
    
       Because, absent use of SIP extensions such as [RFC3856], it is
       impossible to tell in advance whether the notification recipient is
       online and able to receive a SIP MESSAGE, the
       notify_method_capability test for "online" will always return "maybe"
       for this notification method.
    
    But surely, if RFC 3856 extensions are in use, the test for "online"
    could return more details.
    
    Maybe you intend to say that the test needs to have uniform behavior
    regardless of whether 3856 extensions are in use, and so...
    
  2. Stephen Farrell: Comment [2011-10-04]:
    - I don't get the use-case for this - why would I want a SIP MESSAGE
    for each of the emails I get? I think a motivating use-case (or
    reference thereto) would be useful.
    
    - (Related to discuss point 1) How can a program "take care" to
    "ensure that confidential information is not sent" when any inbound
    mail might be forwarded?  If you mean that deployments SHOULD use
    sips URIs then just saying that seems better.
    
    - If someone set this up and that could be detected from the
    Internet, and if each SIP MESSAGE cost someone some money, then 
    a botnet could easily ramp up a whole lot of charges. Is that
    something that warrants a mention? (I'm not sure.)
    
  3. Dan Romascanu: Comment [2011-10-05]:
    I have a similar comment as Stephen (in his first comment). The use case is not
    clear, and some text or reference about why and where notifications are sent
    over SIP would be useful.

draft-ietf-storm-mpa-peer-connect

  1. Adrian Farrel: Comment [2011-10-05]:
    Readable document, thank you.
    
    RDMA is not a "well known" acronym at
    http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
    
    You should expand it in the Abstract and Introduction.
    
    (You might also want to lobby the RFC Editor to get it made "well known"
    
    MPA will also need expansion in the Abstract.
    
    ---
    
    FULPDU:  Framed Upper Layer Protocol PDU
    
    How many letter Ps?
    
  2. Stephen Farrell: Comment [2011-10-04]:
    - The abstract uses the asconyms MPA and RDMA without expansion,
    it'd be better not to do that and generally many acronyms are
    used before being expanded - a pass to fix that would be useful
    
    - The security considerations section says that this changes
    nothing compared to RFC 5044, however, I guess that a peer 
    could try a DoS against another peer by setting large xRD
    values, but I don't know if that's significant enough to
    warrant a mention or not. Is it? If it were, then I guess
    just a warning that implementations ought to have some kind of
    sanity checking on those inputs would suffice.
    
    - Just out of curiosity - RFCs 5043 and 5044 seem to say: "if
    you want security, do IPsec" - is that how things are actually
    deployed?
    
  3. Russ Housley: Discuss [2011-09-30]:
        
      The Gen-ART Review by Elwyn Davies on 26-Sept-2011 raises some
      concerns that deserve a response.  Please find the review at
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06754.html. 
        

draft-ietf-behave-v4v6-bih

  1. Ralph Droms: Comment [2011-10-05]:
    Thanks to the authors for a well-written, easily understandable document.
    
    Assuming that this recommendation in section 2.3 (which I think appears
    elsewhere; e.g., in section 2.3.2) is a general recommendation:
    
      Hence the socket API layer option is RECOMMENDED.
    
    it might be helpful to emphasize the recommendation by repeating it somewhere up
    front in the Introduction.
    
    In section 2.3.4, why would availability of an IPv4 interface case BIH to shut
    down?
  2. Adrian Farrel: Comment [2011-10-05]:
    Clearing my Discuss having seen an email from the WG Chair to the original IPR
    holder.
  3. Stephen Farrell: Discuss [2011-10-04]:
        
    - 2.3 says "If there is a real IPv4 address available..." but doesn't
    say what is meant by "real" nor "available"- is it that an A record
    was returned with a non-1918 address that is contactable or what?
    Note - I'm not asking for any particular definition, just that
    these terms be well-defined here.
    
    - 2.3.2 says the "main resolver of a host running BIH SHOULD NOT 
    perform validation of A records" - I think you don't mean that 
    that resolver should never validate A records (e.g. while BIH is
    not running) so clarifying that might be good e.g. by saying
    "While running BIH, the main resolver of the host SHOULD NOT 
    perform validation of A records. While not running BIH, that
    resolver can use DNSSEC in the same way that any other resolver
    can." or something like that.
    
    - 2.4 refers to section 4.3 for private addresses to use - shouldn't
    that be referring to section 4.4?
     
        
  4. Stephen Farrell: Comment [2011-10-04]:
    - The term "DNS synthesis" is used but not defined here. It
    might be worth explaining.
    
    - 2.2, end of 1st para has a lowercase "should" - is that meant
    to be a 2119 SHOULD or not?
    
    - 7.3 refers to "port translation" but I didn't see any discussion
    of ports here - is the text there correct?
  5. Russ Housley: Comment [2011-10-04]:
      The Gen-ART Review by  Wassim Haddad on 3-October-2011 raised this
      concern, and it needs to be resolved.
    
      Please clarify the connection to the two obsoleted (RFCs 2767 & 3338).
       - The document states that it "obsoletes" them in the title page
         header and the abstract.
       - The document states that it "updates" them in the Introduction.
       - The document says that it is a "direct update to and directly
         derivative" from them in section 1.1.
       - The document says that it "combines and obsoletes" them in
         section 8.
      Please be clear that this document draws from the material in these
      RFCs, and that it obsoletes them.
  6. Pete Resnick: Comment [2011-10-05]:
    2.3 - I agree with Stephen's DISCUSS: MUST the ENR wait for an explicit negative
    response on the A record lookup, or can it synthesize from the AAAA in other
    circumstances? Probably best to explicitly say so. I guess I'd like to hear
    specifically what "only IPv6 addresses are available" means.
  7. Dan Romascanu: Comment [2011-10-06]:
    1. Section 1 uses the term 'DNS synthesis' without defining it. 
    
    2. Section 5 deals with ALG considerations but ALG is never expanded
  8. Peter Saint-Andre: Comment [2011-10-03]:
    The abstract states that this document obsoletes RFC 2767 and RFC 3338. The
    introduction states that this document updates those RFCs. I think the
    introduction might need to be changed.
    
    Given that RFC 2767 was informational and RFC 3338 was experimental, it might be
    helpful to summarize the results of the experiment (e.g., implementation and
    deployment experience).

draft-ietf-krb-wg-otp-preauth

  1. Adrian Farrel: Comment [2011-10-04]:
    I am ballotting "No Objection" on the basis of a light read and reliance on the
    Security COmmunity to have done adequate review.
    
    Note that idnits shows an unused reference, RFC 5280. Please clean this up.
  2. Pete Resnick: Discuss [2011-10-05]:
        I agree with Peter's analysis in the end regarding otp-service and otp-vendor:
    These items are not used in any comparison, and therefore there should not be
    any mention of their case-sensitivity (or lack thereof) or their comparison.
    
    On the PIN however, you have a real problem. This appears to be a UTF-8 string
    taken from user input and then used in the security token. Unicode strings taken
    from user input have all sorts of interesting issues depending on the kinds of
    normalization used by the input method. In the best circumstances, this means a
    bunch of false negatives when comparing. In the worst circumstances, there could
    be some interesting false positives. I don't know if it's the place of this
    document to discuss all of this, but there at *least* needs to be some comment
    in the security considerations section if this is going to be a UTF-8 string. 
        
  3. Peter Saint-Andre: Discuss [2011-10-05]:
        This document appears to nicely extend RFC 6113 and RFC 4120.
    
    There is one point I would like to chat about.
    
    I think we need to say a bit more about string comparison of elements
    that are of type UTF8String. Section 3.3 says:
    
       Any string comparison operations carried
       out against the values of otp-service and otp-vendor MUST be case
       sentive.
    
    First, see draft-iab-identifier-comparison-00 for an extensive
    discussion of security issues related to comparison of identifiers.
    
    Second, it is not clear if the otp-service and otp-vendor elements are
    in fact subject to automated string comparison in the client.  For
    example, Section 3.2 states:
    
       The KDC MAY use the otp-service field to assist the client in
       locating the OTP token to be used by identifying the purpose of the
       authentication.  For example, the otp-service field could assist a
       user in identifying the token to be used when a user has multiple OTP
       tokens that are used for different purposes.
    
    and:
    
       The KDC MAY include the otp-vendor field in an otp-tokenInfo to
       identify the vendor of the token that can be used in the
       authentication request in order to assist the client in locating that
       token.
    
    Furthermore, Section 3.3 states:
    
       The otp-service, otp-vendor, otp-tokenID, otp-length and otp-algID
       elements of the PA-OTP-CHALLENGE are provided by the KDC to assist
       the client in locating the correct token to use but the use of the
       above fields will depend on the type of token.  If connected tokens
       are used then these values SHOULD be used by the client to locate the
       correct token if connected and otp-vendor and otp-service MAY also be
       displayed to prompt the user if the correct token is not found.  If
       the token is not a connected token, then the values of otp-service
       and otp-vendor MAY be displayed to the user in order to help the user
       select the correct token and the values of otp-algID, otp-tokenID and
       otp-length MAY be ignored.  Any string comparison operations carried
       out against the values of otp-service and otp-vendor MUST be case
       sentive.
    
    And Appendix B.1 states:
    
       6.   The client displays the value of otp-service and prompts the
               user to connect the token.
    
    So it seems that the otp-service and otp-vendor elements are shown to
    the user for visual comparison, not compared within the client in an
    automated fashion.
    
    If that is so, then we might be able to remove the sentence about string
    comparison, but we will want to add some stern warnings about the
    hazards of visual comparison, such as the following text from
    draft-iab-identifier-comparison...
    
       Some strings are visually confusable with others, and hence if a
       security decision is made by a user based on visual inspection, many
       opportunities for false positives exist.  As such, highly secure
       systems should not rely on visual inspection.
    
    If that is not so and the otp-service and otp-vendor elements are indeed
    compared in an automated way within the client, we will need to say more
    than merely "compare in a case-sensitive manner" (see RFC 5895 for some
    related considerations) and Pete Resnick and I will probably want to
    confer about recommended text.
    
    Finally, given that the PIN element is also of type UTF8String, it would
    be good to clarify whether it, too, is compared in an automated fashion
    (within the server) or whether it even needs to be a UTF8String.
     
        
  4. Peter Saint-Andre: Comment [2011-10-05]:
    It would be helpful to cite RFC 4120 regarding the definition of the
    "nonce" production as a 32-bit integer (so as to avoid confusion about
    comparison of nonces when authenticating the user) and to clarify the
    exact nature of the nonce (e.g., Section 4.1 states "This nonce string 
    MUST contain a randomly chosen component at least as long as the 
    armor key length" whereas Section 4.2 states "This nonce string MUST 
    be as long as the longest key length of the symmetric key types that the 
    client supports and MUST be chosen randomly" -- the use of "string" here 
    might be taken to imply that the nonce is not an integer, and the 
    difference between "at least as long" in 4.1 and "as long" in 4.2 might 
    cause confusion about the allowable length).
    
  5. Sean Turner: Discuss [2011-10-05]:
        #1) s4.1: Is there something that needs to be said about otp-length if the otp-
    format is different?  That is if it's binary is it the minimum # of bytes but if
    it's one of the other three then it's the number of characters?  Characters can
    be encoded in a variety of ways.  This reminds me of the text from RFC 6030
    (Encoding there is Format here):
    
       If
       the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
       'ALPHANUMERIC', this value indicates the minimum number of
       digits/characters.  If the 'Encoding' attribute is set to
       'BASE64' or 'BINARY', this value indicates the minimum number
       of bytes of the unencoded value.
    
    #2) s4.2: Is the otp-vendor is this the same as the <Manufacturer> element from
    RFC 6030?  RFC 6030 came through the IESG and we had a (some might say lengthy)
    discussion about the <Manufacturer> field.  There were concerns about where the
    values would come from.  Originally, the authors of RFC 6030 wanted to take it
    from the OATH Manufacturer Prefix registry (http://www.openauthentication.org
    /oath-id/prefixes), but to get in that registry you have to pay, if I remember
    correctly, like $500.  Obviously, a free registry would have been better - and
    there is one: IANA's Enterprise Numbers.  So what ended up in the RFC was this:
    
          This element indicates the manufacturer of the
          device.  Values for the <Manufacturer> element MUST be taken from
          either [OATHMAN] prefixes (i.e., the left column) or from the IANA
          Private Enterprise Number Registry [IANAPENREG], using the
          Organization value.  When the value is taken from [OATHMAN],
          "oath."  MUST be prepended to the value (e.g., "oath.<prefix value
          from [OATHMAN]>").  When the value is taken from [IANAPENREG],
          "iana."  MUST be prepended to the value (e.g., "iana.<Organization
          value from [IANAPENREG]>").
    
    If the otp-vendor supposed to convey the same kind of info (or exactly the same
    kind of info) then I think it needs to use some similar language.
    
    #3) RFC 6030 includes a CheckDigit field:
    
       This attribute indicates whether a device needs to
       check the appended Luhn check digit, as defined in
       [ISOIEC7812], contained in a challenge.  This is only valid if
       the 'Encoding' attribute is set to 'DECIMAL'.  A value of TRUE
       indicates that the device will check the appended Luhn check
       digit in a provided challenge.  A value of FALSE indicates that
       the device will not check the appended Luhn check digit in the
       challenge.
    
    Is such a field needed when the OTPFormat is Decimal?
    
    #4) s5: I might be wrong here, but how is [LHA10] not a normative reference?
    You're using values from a registry that is later created in [LHA10]? 
        
  6. Sean Turner: Comment [2011-10-05]:
    #1) s2.2: contains the following:
    
       The PA-OTP-CHALLENGE will contain a KDC generated nonce, an optional
       list of hash algorithm identifiers, an optional iteration count and
       optional information on how the OTP should be generated by the
       client.
    
    Shouldn't "optional" be OPTIONAL x3.  I know it says it later, but it might not
    hurt to put it up here too.
    
    #2) s2.2: It would also be good to say why this data is optional.  It says it
    later but putting it in the paragraph makes sense to me.  Something along the
    lines of:
    
       The optional information indicates how the OTP was generated.
    
    #3) s3.2: Contains the following:
    
       This nonce string MUST
       contain a randomly chosen component at least as long as the armor key
       length.
    
    You need to add the obligatory reference to RFC 4086 for randomness
    requirements.  There's also something like this in s3.3.  Maybe put a catch all
    in the security considerations.
    
    #4) s3.3: Contains the following:
    
       In order to generate its response, the client must generate an OTP
       value.
    
    r/must/MUST ?
    
    #5) s4.1: contains the following:
    
       otp-tokenInfo
          This element SHALL include a sequence of one or more OTP-TOKENINFO
          objects containing information on the token or tokens that the
          user can use for the authentication and how the OTP value is to be
          generated using those tokens.
    
    I think what you're tying to say is that this field MUST always be present and
    it is ... i.e.,:
    
          This element MUST be included and it is a sequence of one or
          more OTP-TOKENINFO ....
    
    I don't know maybe that's just the way I'd write it.
    
    #6) s4.1: Contains the following:
    
          The challenge is an optional
          octet string that SHOULD be uniquely generated for each request
          in which it is present.
    
    r/optional/OPTIONAL to match the other fields.
    
    #7) s4.1: I have to ask ay chance of using SHA-256?
    
    #8) s4.1: Contains the following:
    
           This value MUST be present
           if and only if supportedHashAlg is present.
    
    Maybe indicate that the iterationCount is OPTIONAL otherwise?
    
    #9) s4.2: Missing a "," in the ASN.1:
    
            otp-pin        [6]  OCTET STRING                OPTIONAL
    
    it's in the ASN.1 module.
    
    #10) s4.2: Need to say that the field MUST always be included.
    
    #11) s4.2: Should you indicate that the other flags aren't applicable? Or are
    they?
    
    #12) s4.2: Maybe indicate that the nonce is OPTIONAL otherwise.
    
    #13) s4.2: Indicate encData MUST always be included.
    
    #14) s4.2: RFC 6030 includes the following choices for otp-format:
    
         DECIMAL:  Only numerical digits
    
         HEXADECIMAL:  Hexadecimal response
    
         ALPHANUMERIC:  All letters and numbers (case sensitive)
    
         BASE64:  Base-64 encoded, as defined in Section 4 of [RFC4648]
    
         BINARY:  Binary data
    
    should Base64 be added to the list in this draft?
    
    #15) s4.3: Should you indicate that the other flags aren't applicable? Or are
    they?
    
    #16) s4.3: Indicate pin, minLength, maxLength, and last-req are OPTIONAL or MAY
    be included.  Mostly for consistency with other sections, but also because the
    text should match the ASN.1.
    
    #17) s5: Just to make sure I'm following along: there are no otp-algs being
    registered right?  If there aren't then I think you can delete the 1st
    paragraph.
    
    

draft-ietf-vrrp-unified-mib

  1. Ralph Droms: Comment [2011-10-05]:
    I would like to see an expansion of the text in section 7 to answer Robert's
    comment.
  2. Stephen Farrell: Comment [2011-10-04]:
    I agree with Dan's discuss point #2
    
  3. Pete Resnick: Comment [2011-10-05]:
    Is it normal for 2119 language to appear in the MIB description sections? Seems
    like an odd thing to put in there, given that it occurs nowhere else in the
    document.
  4. Dan Romascanu: Discuss [2011-10-04]:
        DISCUSS and COMMENT modified following the RFC Editor Note. 
    
    This document went a long way and is now in a pretty good shape. A couple of
    issues are worth being fixed before I can cast a Yes ballot:
    
    1. closed
    
    2. I find the description of the vulnerabilities of the writeable objects in the
    Security Considerations section as insufficient. Please describe what are the
    effects settings of the vrrpv3OperationsPriority, vrrpv3OperationsPrimaryIpAddr,
    vrrpv3OperationsAdvInterval, vrrpv3OperationsPreemptMode,
    vrrpv3OperationsAcceptMode objects at the wrong values, or of creating or
    deleting rows using vrrpv3AssociatedIpAddrRowStatus.
    
        
  5. Dan Romascanu: Comment [2011-10-04]:
    1. closed
    
    2. It would be useful to add UNITS clauses for the counter objects. 
    
    3.  closed
  6. Robert Sparks: Comment [2011-10-03]:
    Section 7 (Interpretation of RFC5798) as written does not provide enough
    information to let readers who were not involved in the conversation know what
    the disagreement actually was - they can only guess. As written, it's hard to
    know whether or not this is updating/profiling RFC5798.
    
    Is it the case that this assumption was chosen because it is the "safest" (in
    the sense of providing a useful MIB in as many circumstances as possible)? If
    so, characterizing the choice that way would be clearer. Either way, could the
    document capture why this work won't have to be revisited if the disagreement is
    ultimately resolved with a different interpretation?
  7. Sean Turner: Comment [2011-10-04]:
    I support Dan's #2 discuss.

draft-salgueiro-mmusic-image-iana-registration

  1. Dan Romascanu: Discuss [2011-10-06]:
        I would like to clarify the statement made about the document that it
    'simplifies the usage of previously registered MIME media sub-types like
    'image/t38' [RFC3362] that are used as SDP media descriptors for T.38 [T38].' In
    what way it 'simplifies'? Should this document update RFC 3362? 
        
  2. Peter Saint-Andre: Discuss [2011-10-03]:
        Overall this is a fine document. There are two issues I'd like to chat about.
    
    Section 3 appears to limit the 'image' media type to still images. Would that
    exclude media such as animated GIFs or .mov files? If so, why?
    
    Section 4 claims that there are no security considerations beyond those
    described in RFC 4566. Yet it is known that images can contain malicious code or
    trigger attacks such as buffer overflows and code injection. As far as I can
    see, such attacks are not covered by RFC 4566. Perhaps such attacks are not
    possible with T.38 media, but the 'image' media type could be used to
    communicate other kinds of image data. Does this specification need to take such
    attacks into consideration? 
        

draft-jesske-dispatch-update3326-reason-responses

  1. Adrian Farrel: Comment [2011-10-04]:
    I have cleared my Discuss after the editor convinced me that my concern had been
    the subject of discussion. I am still not convinced that this document is
    formally needed, but it certainly will not do any harm.
    
    ---
    
    The Abstract could usefully mention SIP at the start, not at the end.
    
    Ditto the introduction.
  2. Peter Saint-Andre: Comment [2011-10-03]:
    Some examples would be welcome (in fact, there is one example already in RFC
    3326).

draft-ietf-tsvwg-sctpsocket

  1. Adrian Farrel: Discuss [2011-10-04]:
        I would like to see some generic discussion of the definition within
    this document of "deprecated" data structures, options, and functions.
    
    As it currently reads, you are defining sockets for SCTP as a new
    concept, and part of this definition includes things that you should
    no longer do! That looks a bit weird, especially in Section 9 which
    has the heading "New Functions" (they are so new, they are old :-)
    
    I'd suggest a new section 1.1 called "Deprecated Features"
    
    You need to say:
    - why they are marked deprecated
    - why you are still documenting them
    - what a new implementation is supposed to implement
    
    Hopefully, you can do this as a simple paragraph that can be inserted
    with an RFC Editor note. 
        
  2. Adrian Farrel: Comment [2011-10-04]:
    idnits notes that RFC 1644 has been obsoleted by RFC 6247
    
    This is also noted in the Shepherd write-up.
    Please enter an RFC Editor note so the RFC Editor knows how to resolve this.
  3. Stephen Farrell: Comment [2011-10-05]:
    - In section 2, it'd be good to provide a (normative?) reference for
    the Posix API. Also, you're specifying the 1997 version - is that
    deliberate? (There seems to be a later version, but I'm not sure what
    today's systems follow.)
    
    - The security considerations might benefit from adding a generic
    sentence about implementation security, e.g.  warning about buffer
    overruns, or maybe telling developers to go check out the CVE
    databases.
    
    - I was surprised not to see a mention of RFC 6083 (DTLS over SCTP).
    I'm not sure how DTLS would be implemented with this API. If its
    analogous to TLS/TCP then it'd be above this API I guess, but that'd
    be worth a mention, e.g. saying "If you want transport security, then
    DTLS [RFC 6083] can be used, but is expected to be implemented above,
    and not inside, this API." or something like that.
    
  4. Russ Housley: Discuss [2011-10-04]:
        
      The Gen-ART Review by Joel Halpern on 15-Sept-2011 raised a question:
      >
      > For the shepherd's consideration:  Is it sufficiently clear how the
      > source address will be selected when sending a message, if bindx or
      > wildcarding has been used to bind multiple source addresses?  My
      > guess is that this lack of description matches other specs in how
      > that is handled, but I wanted to check.
      >
      The authors suggested some text for the document, but a new version
      has not been posted and no RFC Editor note has been entered. 
        
  5. Peter Saint-Andre: Comment [2011-10-05]:
    I agree that a normative reference to the POSIX specification (IEEE 1003.1)
    would be appropriate.
  6. Robert Sparks: Comment [2011-10-04]:
    While addressing Adrian's discuss, please look for a way to capture that this
    _has been_ the api definition for some time (the document's been around for a
    decade) and that you are deprecating parts of the API previously documented
    here. Please make it clear that there is no other formal definition of the API
    elsewhere that this is obsoleting.
    
     
  7. Sean Turner: Discuss [2011-10-05]:
        <process weenie> 
    
    I think based on the IETF's TLP you need to put 
    
    <CODE BEGINS>
    
    /*
    
       Copyright (c) 2011 IETF Trust and the persons identified
       as authors of the code. All rights reserved.
    
       Redistribution and use in source and binary forms, with
       or without modification, is permitted pursuant to, and subject
       to the license terms contained in, the Simplified BSD License
       set forth in Section 4.c of the IETF Trust’s Legal Provisions
       Relating to IETF Documents (http://trustee.ietf.org/license-info).
    
    */ 
    
    code goes here
    
    <CODE ENDS>
    
    in appendix A and B.
    
    </process weenie> 
        

draft-ietf-genarea-milestones-tool

  1. Stewart Bryant: Comment [2011-10-03]:
    One minor comment:
    
    "The IETF Secretariat needs to be able to perform the same tasks as
    the WG chairs and ADs in order to fix problems or to make emergency
    changes."
    
    Surely it is simpler to say that the Secretariat should be able to 
    perform the same tasks as the ADs (since WGC privs are a subset of
    AD privs).
  2. Adrian Farrel: Discuss [2011-09-30]:
        Thanks for the work. I have a number of points that I hope are
    relatively easy to handle.
    
    ---
    
    This document also updates RFC 6293 (see Section 7)
    
    ---
    
    Section 2
    
    Sorry if I missed this in the discussion before: did we make an 
    active decision that working group secretaries will not allowed to
    use the tool?
    
    ---
    
    Section 3
    
       The chair
       also needs to be able to delete existing milestones.
    
    This has worried me for a while. By "deleting" a milestone we might
    infer that all record is lost. I should not like that. Maybe "abort"
    would be a better word so that the milestone no longer remains something
    that the WG is trying to achieve, but the record remains in the
    database.
    
    (obvious ripples into the rest of the document)
    
    ---
    
    Did I miss it? I don't see any discussion of how the AD approves changes
    that need AD approval. Obviously, a mechanism must be supplied.
    
    ---
    
    Section 6
    
       The Datatracker needs to have a method for ADs and the Secretariat to
       see all the milestones that are pending approval.
    
    Although this list is probably short, it would be nice to be able to
    filter the list by AD and by Area.
    
    BTW This paragraph belongs in Section 4, not Section 6. 
        
  3. Adrian Farrel: Comment [2011-09-30]:
    Section 1 second paragrpah read oddly:
                                                      
       Today, the tasks associated with creating and updating WG milestones
       are performed manually.  Normally, WG chairs send email to their AD
       requesting that milestones be created or updated, or saying that one
       or more milestone has been met.  These messages used to come as part
       of charter creation or updating, but will be a separate tool after
       the requirements in this document and in [RFC6292] are met.  WG
       chairs sometimes send mail directly to the IETF Secretariat to make a
       change to the database of milestones, such as to change the dates for
       milestones or to say that they are completed.  When a WG chair sends
       email to the Secretariat, the Secretariat must obtain the approval of
       the AD before taking the requested action.
    
    I'm also not sure that "milestone met" has involved the AD approval for
    a long  time. The chairs have simply communicated to the Secretariat 
    direct.
    
    How about:
    
       Today, the tasks associated with creating and updating WG milestones
       are performed manually by the Secretariat.  Normally, WG chairs send
       email to their AD requesting that milestones be created or updated,
       or direct to the Secretariat saying that one or more milestone has 
       been met.  Apart from during WG creation, these updates will be made
       through a separate tool after the requirements in this document and 
       in [RFC6292] are met.
    
    ---
    Section 1
    
       This document is intended to bring that discussion to a general
       consensus among WG chairs and ADs for the requirements for the
       eventual tool.
    
    Since this went to IETF last call, I think you could add
    "and the wider IETF community"
    
    ---
    
    Section 3
    
    There seems to be some duplication between the paragraphs.
    
    ---
    
    Section 4
                                       
       Once a day, the Datatracker will look for changes to the milestones
       for a WG.  If changes to milestones have been made in the past 24
       hours, the Datatracker will send one message to the WG listing all
       the changes from that period.
    
    I don't really care, but this seems more work than just sending an email
    when the change is made. The purpose is to avoid swamping the WG when
    multipe changes are made?
  4. Pete Resnick: Comment [2011-10-05]:
    Like Adrian, I would like WG secretaries to be able to also perform the same
    tasks as chairs, but I think the document is fine if it does not contain this
    feature.
  5. Robert Sparks: Discuss [2011-10-03]:
        Apologies for catching this so late, but a point came up during testing of the
    charter tracking tool that probably should be clarified in this set of
    requirements. Paul - please wait for some discussion before updating the
    document to reflect 
    any of this.
    
    We often want to see the milestones associated with the charter for a new group,
    and a recharter that's a significant
    rewrite for consideration as part of the
    approval process.
    
    When a group is active, and a recharter is being considered, the set of
    milestones the group is currently operating against (those associated with the
    currently approved charter) need to be editable separately from any milestones
    associated with a proposed recharter.
    
    The majority of the requirements in this document apply to maintaining
    milestones associated with a currently approved
    charter. I suggest stating
    explicitly that's the only data the tool being considered maintains.
    
    I propose that the set of milestones associated with a new unapproved charter
    for consideration or for a recharter be kept separately - we do not need the
    approval/reminder mechanics in the document for these. We could extend the
    (re)chartering tracking tool to carry the proposed milestones as a separate
    field, and can discuss (outside the context
    of this document) how we make sure
    they get applied to a newly approved charter at approval time.
    
        

draft-ietf-karp-design-guide

  1. Adrian Farrel: Comment [2011-09-21]:
    Thank you for your work on this important document. I am balloting
    "Yes", but I have a small raft of comments that you should look 
    through.
    
    ---
    
    There is no need to include a reference to RFC 3036. That has been 
    obsoleted and is no more.
    
    ---
    
    Section 1
    
          o  More secure mechanisms and practices for operating routers. 
             This work is being addressed in the OPSEC Working Group. 
    
    Increased security or increased number? Please clarify.
    
    ---
    
    Section 2
    
          and have design 
          teams focus on the specification work within those groupings. 
    
    I think you can leave out this piece of IETF process that may or may
    not be executed as it is not really relevant to the discussion of how
    the protocols are split up on the road map or in this document.
    
    Similarly
    
    OLD
          so that the work can be easily leveraged by the 
          various Routing Protocol teams.
    NEW
          so that the work can be easily leveraged by for
          use in the various Routing Protocol groupings.
    
    ---
    
    Section 2
    
          It is believed that the groupings will have like requirements 
          for their authentication mechanisms, and that reuse of 
          authentication mechanisms will be greatest within these 
          grouping. 
    
    Yeah I know what you mean :-)
    
    How about:
    
          The protocols will be grouped according to the requirements 
          for authentication mechanisms that they are believed to have,
          and it is assumed that reuse of authentication mechanisms will
          be possible and deisrable within each group. 
    
    ---
    
    Section 2.1
    
    s/some mechanism for some protocols/some mechanisms for some protocols/
    
    ---
    
    Section 2.1
    
          The first categorization defines four types of messaging 
          transactions used on the wire by the base Routing Protocol.  
    
    You go on to list only three mechanisms under sub-headings. It is
    possible that you intend "Mixed" to be the fourth type.
    
    ---
    
    Section 2.2
    
    OLD
    The second axis of categorization groups protocols by the 
    NEW
    The second axis of categorization groups protocols is by the 
    
    ---
    
    Section 2.2
    
          Peer keying   
           
          One router sends the keying messages directly and only to one 
          other router, such that a one-to-one, unique keying security 
          association (SA) is established between the two routers. This 
          would be employed by protocols like BGP, BFD, LDP, etc. 
    
    How "direct" does the sending have to be? For example, can't it be
    via a trusted proxy or key server? I am not sure that "directly" is
    relevant to the distinction that needs to be drawn between "peer 
    keying" and "group keying".
    
    (And, for what it is worth, "directly" means in time, and "direct" 
    means in space - except in some US usage where meaning has become
    confusnicatified.)
    
    ---
    
    Section 2.2 Peer keying
    
          This 
          would be employed by protocols like BGP, BFD, LDP, etc. 
    
    The "etc." is very ambiguous in this case because the last time
    protocols were mentioned in groupings they included other protocols
    along with BGP, BFD, and LDP. One was RSVP-TE and we know that group
    keys are potentially applicable to RSVP-TE.
    
    Maybe just strike "etc." as it is bad style to say "such as" (which 
    you mean in place of "like") and "etc." in the same clause.
    
    ---
    
    Section 3.1
    
          The form of the identity proof could be either raw keys, the 
          more easily administrable self-signed certificate format, or a 
          PKI issued certificate credential. 
    
    I think you intend there to be a choice of three options here, in 
    which case delete "either" to avoid confusion.
    
    ---
    
    Section 3.2
    
    This one is almost at the level of a Discuss...
    
          Additionally, key chains 
          will not help if the routing transport subsystem does not 
          support rolling over to the new keys without bouncing the 
          adjacencies. So the first step is to fix all routing protocols 
          so that they can change keys without breaking or bouncing the 
          adjacencies.
                                                                       
    It is not clear that the conclusion is correct. This is certainly 
    an option, but so are:
    
    - changing usage such that the routing protocol uses a different
      routing transport subsystem that does not bounce the adjacency
    
    - changing (fixing?) the preferred routing tansport subsystem
      such that it does not bounce the adjacensy
    
    ---
    
    Section 5
    
    Would it be OK to add PCEP [RFC5440] to the category "BGP, LDP and
    MSDP" as it runs over TCP, is peer-based, and would simply pick up
    TCP-AO in the same way as BGP?
    
    ---
    
    Section 5
    
    I find no fault with the discussion of "RSVP and RSVP-TE", but I
    note that other categories in this section describe the categroy
    in a brief(ish) paragraph while for RSVP we have a lecture.
    
    This also seems to make use of RFC2119 language in earnest. Is 
    that right?
    
    Does this text actually belong in one of the later, protocol-
    specific documents?
  2. Stephen Farrell: Comment [2011-10-04]:
    --- 04 and -05 cleared up my discuss points
    
    ---- original comments on -03 below
    
    - Abstract: "This document is one of a series concerned with
    defining a roadmap of protocol specification work for the use of
    modern cryptographic mechanisms and algorithms for message
    authentication in routing protocols. " What does that mean? What
    series? Why is the document "concerned with defining a roadmap" and
    not just setting out a roadmap or guidelines or something
    understandable?
    
    - Abstract: presumably the KMP "framework" is for managing keys for
    routing protocol security and not more generally?
    
    - Section 1: "Thus, it is concerned with guidelines for describing
    issues and techniques for protecting the messages and their contents
    between directly communicating peers." That is incredibly vague -
    the guidelines are really about "describing issues"?
    
    - Section 1: What are "individual protocol analysis" documents?
    RFCs tend to specify, but not analyse, protocols.  (This became
    clear later but was not at this point.)
    
    - Section 2: what is "Phase 2"? Does it assume a "Phase 1"? If so,
    what is/was phase 1? (You explain that in section 4.2 but refer to
    it much earlier).
    
    - Section 3.1: "will be very secret" seems optimistic (and is 
    presumably referring only to the private component of the key 
    pair). "will not be subject to change" seems to make a lot of
    assumptions. I've never heard tell of a dictionary attack on
    an asymmetric key pair - why even mention it?
    
    - Section 3.1: asymmetric algorithm key lengths are discussed
    in rfc 3766 and in the literature, some references would be
    good here (and maybe better than the current text) in particular
    to the "NIST guidlines" cited but not referenced.
    
    - 3.1: s/Once asymmetric key pair/Once an asymmetric key pair/
    
    - 3.1 is missing references to rfcs related to PKI (5280 etc.)
    
    - 3.2 says "using the key chains" - what are those? There is at
    least a missing reference. And use "key chain" or "keychain" but not
    both. 
    
    - 4.1: The first paragraph here is confusing. I don't get what "KARP
    parameters" might mean.
    
    - 4.1: References for "inter-connection replay" and "two time pads"
    would be good.
    
    - Section 6 says: "Design teams while defining the new
    authentication and security mechanisms MUST design in such a manner
    that the routing protocol authentication mechanism remains oblivious
    of how the keying material is derived." What does that mean? How
    does one validate the MUST there? Does it really mean that a
    'pluggable' KDF must be used to generate keying material? If so, why
    not say so?
    
    - There are many typos. Too many to identify.
    
    - Section 7.1 says "...use of a KMP network-wide increases peer-wise
    security so greatly." I don't think that can be justified in the
    absence of a specific KMP. 
    
    - Section 7.3 says: "In this context, the attack target size
    represents the number of unique routing exchanges across a network
    that an attacker may be able to observe in order to gain security
    association credentials, i.e. crack the keys." I disagree with that.
    I don't know how "attack size" is defined, but it sounds like you
    should be discussing the impact of a successful attack. Also,
    "cracking" keys by observing routing exchanges should really not be
    possible and doesn't distinguish between key management schemes - if
    that's possible, the routing protocol's security mechanism is just
    broken at least for any sensible number of (pairs of) nodes, or else
    a weak key has been chosen.
    
    - Section 7.4: I've no idea what "one routing peer-to-peer key
    management protocol exchanges" means.
    
    - Section 7.4: I think peer-to-peer isn't a great term here. Maybe
    router-to-router would be better?
    
    - Section 7.4: " The desired end goal for KARP WG is develop a
    strong peer-to- peer KMP as an Out-of-and external Key Management
    protocol is out of scope." Huh?
  3. Russ Housley: Discuss [2011-10-06]:
        
      This is a long DISCUSS write-up.  That is because I find that
      this document is not providing the design guidance that I expected
      based on the title of the document.
    
      Please consider these four points, each of them is significant I
      believe.  Addressing them all together will, I fear, require a
      significant revision to the document.
    
      1.  The KARP WG charter says:
    
        A goal of the working group is to add incremental security
        to existing mechanisms rather than replacing them. Better
        deployable solutions to which vendors and operators can
        migrate is more important than getting a perfect security
        solution.
      
      This is a very important bit of design guidance.  The document does
      say that incremental deployment is needed, but I cannot find this
      important tradeoff described in this document.
      
      2.  The KARP WG charter says:
    
         This working group is concerned with message authentication,
         packet integrity, and denial of service (DoS) protection.
    
      This document talks about authentication and integrity, but it
      says noting about DoS protection.
    
      3.  The KARP WG charter says:
    
        Routing protocols use a range of transport mechanisms and
        communication relationships. There are also differences in
        details among the various protocols. The working group will
        attempt to describe the security relevant characteristics of
        routings protocols, such as the use or non-use of TCP, or the
        frequent use of group communication versus purely pairwise
        communication. Using these characteristics, the working group
        will then provide suitable common frameworks that can be applied,
        and tailored, to improve the communication security of the routing
        protocols.
    
      This document covers much of this material.  It talks about
      "transport mechanisms" and "communications relationships".
      It covers part of the material I would expect in a discussion of
      "security relevant characteristics of routings protocols".  It
      covers the difference in "group" and "pairwise" communications.
      It does not come up with "common frameworks".  I suggest that
      this document is a very good start at this charter deliverable.
      
      4.  Please update [I-D.ietf-saag-crypto-key-table] to point to
      the KARP WG document: draft-ietf-karp-crypto-key-table. 
        
  4. Russ Housley: Comment [2011-10-06]:
      The document tries to define "on the wire".  I do not find the
      definition helpful.  I think it is sufficient to say that "on the
      wire" protection can be achieved by the addition of authentication
      and integrity mechanisms to the routing protocol or by running the
      routing protocol over a security protocol the provides them.
    
      Why define the KMP acronym?  It is not used many places.
    
      Please remove the URL to the MSEC charter.
  5. Peter Saint-Andre: Comment [2011-09-21]:
    Various paragraphs mention "modern, strong security algorithms", but that term
    is never defined. Given that the only algorithm mentioned in the text is SHA-1,
    the reader is left to wonder what is meant by "modern" and "strong".
    
    I don't see a need for the use of RFC 2119 keywords in this document.
  6. Sean Turner: Discuss [2011-10-05]:
        I had great difficulty getting through this document because I found it really
    hard to understand.  I know I should learn to let go more, but since I think
    this is important I decided not to.  I apologize for not spending more time with
    this document earlier.   I have a lengthy set of comments, but none came to the
    level of discuss until I got to the last section and I couldn't get "it".
    
    #1) s7.4: Contains the following:
    
      The desired end goal for KARP WG is to develop a strong peer-
      to-peer KMP; an Out-of-and external Key Management protocol is 
      out of scope.
    
    s4.1 said there there were several goals for the end state of KARP.  The second
    goal is a KMP.   Maybe it's better to say something like:
    
      One of the desired end goals for KARP is to develop a KMP.  We
      further refine that goal by specifying a peer-to-peer KMP and
      declaring an out-of-band KMP out-of-scope.
    
    After reading the bullets that follow, I'm confused.  In the bullets that
    follow, you're saying an out-of-band KMP is out-of-scope but the first option in
    the constraint is to use a out-of-band key management protocol? 
        
  7. Sean Turner: Comment [2011-10-05]:
    I do not mean for any of these comments to change the intent of what was there
    before.
    
    #1) s1: I think you should quote the bullets from 4948 and then say where
    they're being done:
    
    OLD:
           
      o  Increased security mechanisms and practices for operating  
         routers. This work is being addressed in the OPSEC Working  
         Group. 
           
      o  Cleaning up the Internet Routing Registry repository [IRR],   
         and securing both the database and the access, so that it  
         can be used for routing verifications.  This work should be  
         addressed through liaisons with those running the IRR's  
         globally. 
         
      o  Specifications for cryptographic validation of routing  
      message content.  This work is being addressed in the  
      SIDR Working Group. 
           
      o  Securing the routing protocols' packets on the wire
    
    NEW:
      
      o  Increased security mechanisms and practices for operating  
         routers.
           
      o  Cleaning up the Internet Routing Registry repository [IRR],   
         and securing both the database and the access, so that it  
         can be used for routing verifications.
           
      o  Specifications for cryptographic validation of routing  
         message content. 
           
      o  Securing the routing protocols' packets on the wire. 
    
    The first bullet is being addressed in the OPSEC Working Group.
    The second bullet should be addressed through liaisons with
    those running the IRR's globally.  The third bullet is being
    addressed in the SIDR Working Group.
    
    This document addresses ...
    
    #2) s1: Contains the following:
    
      This may overlap with, but is strongly distinct from, 
      protection designed to ensure that routing information is 
      properly authorized relative to sources of this information.
    
    maybe "protection" is supposed to be "mechanism":
    
      This may overlap with, but is strongly distinct from, 
      mechanisms designed to ensure that routing information is 
      properly authorized relative to sources of this information.
    
    #3) s1: Contains the following:
    
      Such assurances are provided by other mechanisms and are 
      outside the scope of this document and work that relies on it. 
    
    maybe "assurances" is "authorizations":
    
      Such authorizations are provided by other mechanisms and are 
      outside the scope of this document and work that relies on it. 
    
    #4) s1: Contains the following:
    
      In 
      this document, it is used to refer both to information 
      exchanged between routing protocol instances, and to underlying 
      protocols that may also need to be protected in specific 
      circumstances.
    
    what's a routing protocol instance?  Is it just routing protocols or maybe it
    should be "exchanged between routers"?
    
    #5) s1: Contains the following:
    
      Individual protocol analysis documents will 
      need to be more specific in their usage. 
    
    Maybe:
    
      Other documents that will analyze individual protocols will
      need to indicate how they use the term "on the wire".
    
    #6) s1: I couldn't parse this:
    
      The 
      term is used here to allow a referent for discussing both 
      common and disparate issues that affect or interact with this 
      dimension of the routing systems.
    
    actually the 2nd to last paragraph confuses me.  I think you're trying to say
    that:
    
      The term "routing transport" is used to refer to the layer
      that exchanges the routing protocols.  Examples include: TCP, UDP,
      or even direct link level messaging.
    
    Do you need to say anything else?
    
    #7) s2: Contains the following:
    
       For the purpose of this security roadmap definition, we categorize 
       routing protocols into groups and anticipate that design teams will 
       focus on the specification of security mechanisms within each 
       group. The protocols will be grouped according to the requirements 
       for authentication mechanisms that they are believed to have, and 
       it is assumed that reuse of authentication mechanisms will be 
       possible and desirable within each group. The work items placed on 
       the roadmap will be defined and assigned based on these 
       categorizations.
    
    How about 
    
      This document places the routing protocols into two categories according
      to their requirements for authentication.  We hope these categories will
      allow design teams to focus on security mechanisms for a given category.
      Further, we hope that the each protocol in the group will be able to reuse
      the authentication mechanism.
    
    #8) s2: Contains the following:
    
      KMPs are useful for 
      allowing simple, automated updates of the traffic keys used in a 
      base protocol.
    
    Maybe:
    
       KMPs allowing simple, automated updates of the traffic keys used in a 
       base protocol.
    
    #9) s2.1: r/categorization/category
              r/message which is intended for consumption by multiple peers/
                message which is intended for multiple peers
              r/because of the fact that they are inherently/
                because they are inherently/
    
    #10) s2.1: Need to describe how multicast is different from one-to-many
    
    #11) s2.1: Contains the following:
    
      As a result, some mechanisms for a few routing protocols,
    
    I'm not sure what you mean by "some mechanisms"?  Are these message transaction
    types?
    
    #12) s2.1: Contains the following:
    
       This may include any ...
    
    What's the "this referring to?
    
    #13) s2.1: contains the following:
    
       the techniques that are used for the message exchanges. 
    
    Maybe:
    
       the techniques that are used for the message transaction type.   
     
    #14) s2.2: Contains the following:
    
       The second axis of categorization groups protocols is by the 
       keying mechanism that will be necessary for distributing 
       session keys to the actual Routing Protocol transports.
    
    Maybe:
    
       The second category is the
       keying mechanism that will be used to distribute the
       session keys to the routing transports.
    
    #15) s2.2: Contains the following:
    
       routers. This would be 
       employed by protocols like BGP, BFD and LDP. 
    
    Maybe:
    
       routers (e.g., BGP, BFD, and LDP).
    
    #17) s3.1: r/2048 for/2048 bits for
    
    #18) s3.1: When describing the symmetric key to asymmetric key size comparison
    please add a reference to RFC 3766.  It describes exactly this comparison (look
    in Section 5).
    
    #19) s3.1:r/using SSH/using Secure SHell (SSH) Protocol
              r/employed to by SSH/employed by SSH
              r/when a user/when an administrator
    
    #20) s3.1: Contains the following:
    
      Once an asymmetric key pair is generated, the KMP generating 
      security association parameters and keys for routing protocol 
      may use the machine's asymmetric keys for the identity proof.
    
    r/asymmetric key/asymmetric key (the sentence is talking about one key pair)
    
    Is it an "identity proof" or is it that the public key is used during an
    authentication token/credential?  Maybe it's use "the machine's asymmetric key
    pair as an authentication credential".  Then the next sentence is about the type
    of token/credential:
    
       The form of the token could be raw keys, the more 
       easily administrable self-signed certificate, or a PKI-
       issued certificate [RFC5280]. 
    
    and then:
    
      Regardless of which credential is standardized, the proof of 
      this identity presentation can be as simple as a strong hash,
      which could be represented in a human readable and transferable 
      form of some pairs of ASCII characters. 
    
    Actually I'm not sure what the "proof of this identity presentation" is all
    about.  Maybe it's authentication:
    
      Regardless of which credential is standardized, the authentication
      mechanism can be as simple as a strong hash over a string of ASCII
      characters.
    
    later r/identity proof/authentication mechanism
    
    #21) s3.1: I'll give you a free pass on the self-signed certificate, but it's at
    least one person's hot button in PKIX - that 5280 only defines self-signed
    certificates as a CA certificates.
    
    #22) s3.2: Is there a reference for the key chain?  I think I know what you're
    talking about, but is that written down for a protocol now?
    
    #23) s3.2: r/for doing the same./for rolling the key.  
               r/they are
    likely to get disclosed/they are likely to be disclosed
               r/with the
    send and the receive keys/with the send and the received keys ?
    
    #24) s4.1: Contains the following:
    
      It is believed that improving security for any routing protocol 
      will be a two step process or could be said to involve two 
      phases.
    
    just pick one :)
    
      It is believed that improving security for any routing protocol 
      will be a two phase process.
    
    #25) s4.1: Contains the following:
    
      The first would be to fix the manual key management 
      procedures that currently exist within the routing protocols 
      today using modern cryptography algorithms and key agility. 
    
    Isn't the first step to add modern crypto and key agility to the protocols?
    
      The first phase would be to modify routing protocols to support modern
      cryptography algorithms and key agility. 
    
    #26) s4.1: this is a little wordy:
    
      In order to deliver that to the operators in a way 
      that we could complete these action items a little bit a time 
      and make some incremental advance over what is currently 
      deployed in the wild, we believe that it is therefore useful to 
      cleanly separate the key management protocol from the routing 
      transport subsystem mechanism.
    
    How about:
    
      In order for operators to accept these phases, we believe that
      the key management protocol should be clearly separated from the
      routing transport.
    
    and later:
    
      written by 
      people good in security and who will be maintaining it over the 
      time and insert those parameters in the routing exchange.
    
    with
    
      written, maintained, and operated by security experts
    
    #27) s4.1: contains the following:
    
      The desired end state for the KARP work contains several items.  
      First, the people desiring to deploy securely authenticated and 
      integrity validated packets between routing peers have the 
      tools specified, implemented and shipping in order to deploy.
    
    Maybe
    
      The ultimate goals of KARP contain several items.  
      First, provide a mechanism to allow routing peers to exchange
      authenticated and integrity protected packages.
    
    #28) s4.1: contains the following:
    
      In larger 
      deployments, this end state will be much more operationally 
      difficult to reach with only manual keys.  Thus, there will be 
      a need for key life cycle management, in the form of a key 
      management protocol, or KMP.
    
    Maybe the following to be explicit that a KMP is the second goal:
    
      However, manual keying in larger deployments will be too burdensome
      for operators.  Thus, the second goal is to support key life cycle
      management with a KMP.
    
    and maybe instead of:
    
      We expect that the two forms, 
      manual key usage and KMP usage, will co-exist in the real 
      world.   
    
    this:
    
      We expect that both manual and automated key management will
      co-exist in the real world.
    
    #29) s5: r/[RFC2747/[RFC2747]
    
    #30) s6: r/be at least on set of cryptography algorithms or constructions 
              /be at least one set of cryptographic algorithms
    
    I'd just strike "or constructions" from the rest of the draft.  I'm not sure
    what you mean by it.
    
    #31) s6: contains the following:
    
       If such algorithms or constructions 
       are not available then some should be defined to support 
       interoperability by having a single default. 
    
    I think you're trying to say:
    
       If such algorithms have not been defined, then define them and
       pick a default algorithm.
    
    #32) s6: I think you want to say support algorithm agility:
    
       Care should also be taken to ensure that the routing protocol 
       authentication scheme is capable of supporting algorithms other 
       than its defaults, in order to adapt to future discoveries. 
    
    Maybe:
    
       Care should also be taken to ensure that the routing protocol 
       authentication scheme has algorithm agility (i.e., it is capable
       of supporting algorithms other than its defaults).
    
    #33)  s6:
    
    OLD:
    
       Ideally, authentication MUST be performed on routing protocols 
       packets oblivious to the order in which they have arrived, so 
       that it does not get influenced by packets loss and reordering. 
    
    NEW:
    
       Ideally, the authentication mechanism MUST NOT be affected by
       packets loss and reordering. 
    
    #34) s6: r/authentication mechanism remains oblivious of how the 
              /authentication mechanism remains oblivious to how the
    
    #35) s6: Maybe
    
    OLD:
       
       The KARP work is but one step in 
       a necessary system of security improvements.
    
    NEW:
    
       The KARP work is but one step needed to improve core routing
       infrastructure.
    
    #36) s7: Need to add something in the first paragraph to talk about key lengths.
    Maybe the pointer to RFC 3766.  Maybe:
    
      In addition to generating good keys, care should be taken when
      choosing the length of the key.  [RFC3766] provides some additional
      information on asymmetric and symmetric key sizes and how they related
      to system requirements for attack resistance.
    
    #37) s7:
    
       This is because if 
       attackers sitting between two routers learn or guess the 
       Traffic Key for that connection, it still does not gain them 
       access to the Traffic key being used in other connections.
    
    Maybe:
    
       Consider an attacker that learns or guesses the Traffic Key used
       by two peer-routers: if the Traffic key is only used between those
       two routers, then the attacker has only compromised that one connection
       not the entire network.
    
    #38) s7: doesn't the following presuppose a solution:
    
       Doing so has the following advantages: the Traffic Keys 
       used in the per-message MAC operation are peer-wise unique, it 
       provides inter-connection replay protection, and, if the per-
       message MAC covers some connection counter, intra-connection 
       replay protection. 
    
    Maybe replace MAC with authentication mechanism?  Or are we all really just
    fooling ourselves?
    
    #39) s7.1: contains the following:
    
      Administrators are encouraged to follow [RFC4086.
    
    Add the "]" and maybe we should also be pointing to the NIST spec on password
    (Special Publication 800-118)
    
    r/, in as/as
    
    It might be worth mixing in that the reason you need the key prep is that
    administrators are NEVER EVER going to put in a password that is 16 bytes in
    length ;)
    
    And, maybe saying operators do stupid things isn't such a good idea ;)
    
    #40) s7.3: r/The goal for designers/ One goal for designers    - s4.1 says
    there's more than one goal.
    
    #41) s7.4: r/Out-of-and/Out-of-band

draft-ietf-lisp-ms

  1. Ron Bonica: Discuss [2011-10-05]:
        (Discuss has been updated yet again, based on information gleaned from the
    versioning draft)
    
    General:
    
    This document cannot be reviewed meaningfully before the LISP base document,
    LISP ALT  and LISP SEC have been reviewed.
    
    General:
    
    Where are the trust boundaries in this system? Can all ALT nodes trust one
    another because they reside within the same security domain? Can all Map Servers
    trust one another because they reside within the same security domain? This
    question is important because it determines where security mechanisms are
    required.
    
    How are the trust boundaries maintained? Do all devices that reside within a
    trust boundary need to be managed by the same party?
    
    General:
    
    Given the considerations raised in Section 5 and in this review,  the abstract
    and introduction should warn users against deploying LISP MS in mission
    critical, production environments.
    
    Section 1:
    
    In the second paragraph of Section 1, you say:
    
    "There are two types of operation for a LISP Map Server: as a Map Resolver,
    which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping
    using the distributed mapping database, and as a Map Server, which learns
    authoritative EID-to-RLOC mappings from an ETR and publish them in the database.
    A single device may implement  one or both types of operation.
    
    In this paragraph, the term "Map Server" is overloaded. A Map Server can be a
    device or one of the two functions that the device can serve. Please fix this.
    It makes the rest of the document unnecessarily difficult to read.
    
    -----------------------------------------------------------------------------
    Section 3:
    
    The opening words of Section 3, Paragraph 1 imply that you are speaking
    generically about the Map Server Device (both the Map Server and Resolver
    functions). However, the opening words of Section 3, Paragraph 3 you introduce
    the Resolver function for the first time. This causes the reader to go back and
    reinterpret what was read in the two previous paragraphs, understanding that
    these paragraphs address the Map Server function, not the Map Server device.
    
    Please fix this. Also, in Paragraph 1, be specific about from whence the Map
    Request come.
    
    ------------------------------------------------------------------------------
    Section 4.2:
    
    In paragraph 6 you say:
    
    "When an ETR requests proxy reply service, it should include all RLOCs for all
    ETRs for the EID-prefix being registered, along with the "R" bit setting for
    each RLOC."
    
    What should the Map-Register message include when it does not request the proxy
    reply service? Are all RLOCs required? Must they include the same attributes and
    version numbers.
    
    This document is silent in that regard, however, the versioning document says:
    
    "Indeed, ETRs belonging to the same LISP site must return for a specific EID-
    prefix the same mapping, including the same Map-Version number.  In principle
    this is orthogonal to whether or not map-versioning is used.  The
    synchronization problem is out of the scope of this document."
    
    This leads us to the following questions:
    
    - How are all ETRs servicing an EID kept in sync?
    - What are the consequence of becoming out of sync?
    
    Section 8.1 of the Versioning document says:
    
    "So far, LISP does not provide any specific synchronization mechanism,  but
    assumes that synchronization is provided by configuring the different xTRs
    consistently."
    
    Section 8.1 of the Versioning document also demonstrates that loss of
    synchronization can cause network failure, whether or not version checking is
    enabled.
    
    I doubt if a manual ETR synchronization process will be sufficient. What happens
    during the period between the configuration of one ETR and another? What happens
    in case of operator error? What happens when one ETR goes offline, another is
    reconfigured, and the first comes back on line?
    
    -------------------------------------------------------------------------
    
    Section 4.3
    
    What does the Map Server do if it receives a Map Request for a prefix that is
    outside of its aggregate (i.e., something that it never advertised into ALT
    using BGP). Shouldn't the Negative Map Reply indicate that something appears to
    be amiss?
    
    ------------------------------------------------------------------------
    
    Section 4.4
    
    In bullet number 2, you describe how the caching map generates a new nonce,
    stores that nonce and uses it in a locally generated Map-Request. How long
    should the resolver wait for a map-response before flushing state regarding the
    locally generated map-request?
    
    ------------------------------------------------------------------------------
    Section 4.4
    
    How does the caching resolver protect itself from a trivial DoS attack, in which
    it receives a sustained stream of Map-Request. The map requests appear to come
    from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the
    requested EID mappings requested are well-randomized.
    
    --------------------------------------------------------------------------------
    -
    Section 4.4
    
    Is it wise to run an open, caching resolver? Or should requests to a caching
    resolver be authenticated.
    
    --------------------------------------------------------------------------------
    --
    Section 4.4
    
    Are there any database consistency rules regarding the resolver cache? For
    example, is there any case where flushing one cache entry before another would
    cause the resolver to behave badly? If so, what are those rules? What mechanisms
    enforce them.
    
        
  2. Ron Bonica: Comment [2011-10-04]:
    Section 4.2
    
    You say:
    
    "In addition to the set of EID-prefixes defined for each ETR that may register,
    a Map Server is typically also be configured with one or more aggregate prefixes
    that define the part of the EID numbering space assigned to it."
    
    Grammar.
    ----------------------------------------------------------------------------
    
    Section 4.3:
    
    You say:
    
    "If any of the registered ETRs for the EID-prefix have requested proxy reply
    service, then the Map Server answered the request instead of forwarding it."
    
    Grammar
    
  3. Wesley Eddy: Comment [2011-10-05]:
    I support the first 2 parts of Stephen's DISCUSS
  4. Adrian Farrel: Discuss [2011-10-06]:
        The LISP Charter says (of the WG)...
     Its
     specifications are Experimental and labeled with accurate disclaimers
     about their limitations and not fully understood implications for
     Internet traffic.
    
    I do not find such disclaimers in this document.
    Section 5 is a good collection of issues for future analysis, but is
    not the same thing.
    
    ---
    
    Section 2
    
       Map Server:   a network infrastructure component which learns EID-to-
          RLOC mapping entries from an authoritative source (typically, an
          ETR, via the registration mechanism described below). 
    
    I couldn't find a description of other authoritative sources.
    
    ---
    
    Section 4.1
    
       o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
          possibly from a Map Server answering on behalf of the ETR.  Note
          that the stateless nature of non-caching Map Resolver forwarding
          means that the Map-Reply may not be from the Map Resolver to which
          the Encapsulated Map-Request was sent unless the target Map
          Resolver offers caching.  See (Section 4.4) for more details on
          Map Resolver message processing.
    
    This is the first mention of the "stateless nature" of MR forwarding.
    The forward reference to 4.4 is helpful, but that indicates that one of
    the modes of operation is stateful frowarding (using the nonce).
    
    This is also the first indication (or rather the forward reference to 
    4.4 provides the first indication) that an MR might forward the request
    to another MR rather than direct to the ETR. I think that all the text
    up to this point has given the impression that the longest query flow is
    ITR-MR-ETR. It would be really helpful to bring out this fact earlier in
    the document.
    
    I think this might be aided by some clear description of the 
    architecture in use and the roles of the components. A figure might even
    help.
    
    ---
    
    Section 4.2
    
       Map-Register messages are sent periodically from an ETR to a Map
       Server with a suggested interval between messages of one minute.  A
       Map Server should time-out and remove an ETR's registration if it has
       not received a valid Map-Register message within the past three
       minutes.  When first contacting a Map Server after restart or changes
       to its EID-to-RLOC database mappings, an ETR may initially send Map-
       Register messages at an increased frequency, up to one every 20
       seconds.  This "quick registration" period is limited to five minutes
       in duration.
    
    I understand why this is a good idea when an ETR starts, but it seems a
    big risk when a MS starts. In that case, there may be a large number of
    ETRs making contact and all sending Map-Reegister messages. The more
    rapid transmission means that the MS's queue (which might in any case be
    getting quite full) will get very full, yet many of the messages will be
    unnecessary duplicates.
    
    ---
    
    Section 4.2
    
       Note that a one-minute minimum registration interval during
       maintenance of an ETR-MS association does set a lower-bound on how
       quickly and how frequently a mapping database entry can be updated.
       This may have implications for what sorts of mobility can supported
       directly by the mapping system.
    
    A peculiar paragraph given that we have just been told that the period 
    for sending the messages is only suggested at one minute.
    
       Map-Register messages are sent periodically from an ETR to a Map
       Server with a suggested interval between messages of one minute.
    
    Surely the choice of words here implies that an ETR can send a Map-
    Register whenever it considers it appropriate.
    
    ---
    
    Section 4.3
    
       If none are found, then the Map-Server returns
       a negative Map-Reply with action code "forward-native" and a 1-minute
       TTL.
    
    Does this mean that the convergence time experienced by a device in a
    site is 1-minute because the ITR will cache a failed resolution for this
    amount of time. Is this a design decision of the pull nature of the ITR
    in a LISP system? I couldn't find any discussion of this on a quick scan
    of the base spec.
    
    I do note that you list convergence as an open issue in Section 5 (which
    is good).
    
    ---
    
    Section 4.4.1 is rather sparse.
    
    I wonder if you should punt this "for future study" rather than open
    the gates here but not address the issues. For example, when you use
    any-cast MRs I assume that the ITR will receive multiple responses.
    That would mean that this document should discuss the case and explain
    how the ITR selects between (potentially different) non-authoratative
    responses. 
        
  5. Adrian Farrel: Comment [2011-10-06]:
    I find it very regrettable that this document was brough forward for
    IESG review before the architecture and protocol on which it depends.
    
    The very first word of the bdy of the document is a normative reference
    to the base specification which is currently in AD Review with a new
    revision required and a good dolop of questions from the AD for the
    authors to resolve.
    
    This means that any review of this document is necessarily moot. I am
    very sorry, but I may have to come back and extend my Discuss after
    we have reviewed the base spec.
    
    I recognise that this issue is not actionable by the authors, and simply
    supply it as a comment for the record. However, I strongly encourage the
    authors to keep a tight track of this document since it contains 
    statements of protocol behavior that are lifted from the base LISP spec 
    and which may be subject to change. Actually, I am not clear why it is
    helpful to restate protocol details (such as use of port numbers) in 
    this document.
    
    ---
    
    Please expand acronyms in the Introduction on first use.
    
    ---
    
    For clarity, it is not helpful that a LISP Map Server contains two
    components called Map Resolver and Map Server. This means that the term
    "Map Server" can be confusing. For example, in Section 1
    
       There are two types of operation for a LISP Map Server: as a Map
       Resolver, which accepts Map-Requests from an ITR and "resolves" the
       EID-to-RLOC mapping using the distributed mapping database, and as a
       Map Server, which learns authoritative EID-to-RLOC mappings from an
       ETR and publish them in the database.  A single device may implement
       one or both types of operation.
    
        
  6. ...yet in Section 4.3... In response to a Map-Request (received over the ALT if LISP+ALT is in use), the Map Server first checks to see if the destination EID matches a configured EID-prefix. If there is no match, the Map Server returns a negative Map-Reply with action code "forward-native" and a 15-minute TTL. This may occur if a Map Request is received for a configured aggreate EID-prefix for which no more-specific EID- prefix exists; it indicates the presence of a non-LISP "hole" in the agregate EID-prefix. The latter implies that the "Map Server" operation processes a Map- Request message, where the former implies that this is processed by the "Map Resolver" operation. --- Section 4.2 a Map Server is typically also be configured d/be/ --- I didn't feel that the use of LISP+ALT as an example in the text actually helped the document. In fact, in order to get a clear view of what the MS does, I found it helpful to skip those paragraphs. Additionally, it felt to me that the inclusion of discussion of this one DB scheme was prejudicing the working group's discussion of DBs. --- Section 4.3 s/Map-Server/Map Server/ --- I really like section 5 and thank you for your frankness. The LISP experiment might be enhanced by the addition of more details to this section to help guide the experimenters and more quickly gather the necessary information. --- I confess that I found the repeated use of the same letters for flags in different messages and different components of messages very tricky to process. I appreciate that this would become easier with deeper experience with the protocol, and I also understand that *this* document can only use the assignments from the base spec. It might be wise to go through this document making sure that all things like "S bit" are given full context such as "the S bit of the foo message". I *think* the same issue arrises with "nonce".
  7. Stephen Farrell: Discuss [2011-10-06]:
        (added a few more points following further reading)
    
    - Section 2, definition of Map Server (and elsewhere) refers to *the*
    distributed mapping database. But you've previously said there are
    multiple schemes LISP+ALT etc so how can you talk about *the*
    distributed database? I think database needs to be used in the plural
    with possible consequences elsewhere (e.g. security guarantees might be
    DB dependant, implying that DB naming needs to be present in other
    messages). If, however, it is one DB, then you'll need to explain
    how LISP+ALT and others are really different schemes but yet use the
    same DB with the same guarantees.
    
    - In this case, the packet definitions are in the base document, so its
    not really possible to review sections 4 & 5 of this properly without
    first doing base.  (When I got to the last sentence of section 3, my
    thought was: "Ah, FFS...";-)
    
    - 4.2: provision a shared secret - it seems odd to preclude signatures
    for authenticating map register messages at this level. Why do that?
    If you don't need to then I'd suggest s/secret shared-key/shared secret
    or other relevant authentication information/
    
    - I may need to come back about the security considerations of this
    document after I've reviewed [LISP] and [LISP-SEC].
     
        
  8. Stephen Farrell: Comment [2011-10-06]:
    - Section 1, 2nd para says that a "Map Server" can be a "Map Resolver"
    or a "Map Server" - huh? Terminology a bit messed up there really it
    seems. I'd suggest inventing a new term for one of the uses of "Map
    Server."
    
    - Definition of Map Resolver says "quickly" and "immediately" which are
    being used as marketing terms it seems. Better not to do that.
    
    - Map Request defn: Be good to point out somewhere (IANA considerations
    I guess) that port 4342 is already registered.
    
    - Map register defn: is "its" associated EID-prefixes correct? That
    implies there's no way for some other node to register EIDs on 
    behalf of a bunch of ETRs for example. 
    
    - typo: s/outdate, cached/outdated, cached/
    
    - Text in 4.1 is inconsistent about whether an ITR has one or can
    have more than one map resolver configured. I assume that "one or
    more" is the right rule, if not, you should probably say.
    
    - 4.1 - I've no clue why a negative map reply has to have a 
    15 minute ttl - why is that? (Same for other fixed TTL values.)
    
    - On the topic of an ETR registering bogus aggregates. It might be that
    a system like LISP could often detect that and react to it by dropping
    that ETR? Say if there were an error alerting system built into the LISP
    mapping store - when an ITR sees above-threshold errors for a given ETR
    it tells its resolver, when the resolver sees above threshold errors it
    passes that back etc. Not suggesting that you add that now, just a
    thought.
    
    - typo: s/outdate, cached/outdated, cached/
    
  9. Sean Turner: Discuss [2011-10-06]:
        Updated..again..
    
    #1) (no action required) I get know why the doc primarily talks about LISP+ALT.
    
    #2) s4.2 contains the following:
    
       A Map-Register message includes
       authentication data, so prior to sending a Map-Register message, the
       ETR and Map Server must be configured with a secret shared-key. 
    
    I figured I'd find something in lisp-sec about this, but that draft points back
    to this one.  I'll note that s7 contains the following:
    
       During experimental and prototype deployment, authentication key
       changes will be manual.
    
    But, I don't think it's just changes that get done manually.  It's also initial
    configuration.  That ought to be called out either in s4.2 or 7. 
        
  10. Sean Turner: Comment [2011-10-06]:
    #1) I support Stephen's discusses.
    
    #2) s1: I support Ron's discuss about the term "Map Server" is overloaded.
    
    #3) Half-tongue-in-cheek: what no ping message to see if the peer is alive? ;)
    
    #4) s2: Maybe add to the last paragraph: "the port number assignments".  I
    figured oh this protocol does have some assignments - they do they're just not
    in this draft ;)

draft-ietf-lisp-multicast

  1. Ron Bonica: Discuss [2011-10-05]:
        I concur with Ralph's evaluation, but will hold a separate discuss so that the
    termination of his evaluation does not unintentionally terminate mine. 
        
  2. Ralph Droms: Discuss [2011-10-05]:
        I've reviewed this document keeping in mind the DISCUSS positions on
    other LISP documents. I found I could review the document, based on my
    background knowledge of LISP, but there are several details I will
    need to research in the LISP base spec to convince myself that this
    document is correct.
    
    That situation raises a slightly different problem than was raised in
    the DISCUSS positions on the other LISP documents: in my opinion, to
    complete my due diligence on this document, I will need to review it
    again after the LISP base spec has been reviewed and approved, to
    confirm that the approved version of the LISP base spec is still in
    sync with this document.
    
    I understand that we face a similar situation every time we review a
    document that contains normative references to documents that have not
    been approved for publication.  In the case of this document set, the
    dependencies are sufficiently important and numerous that, again in my
    opinion, an additional review of this document will be required once
    the LISP base spec is approved.
    
    Therefore, I will maintain a DISCUSS position on this document until
    the LISP base spec is approved.  I also note that I will have to do
    extra work in reviewing the document twice because of the order in
    which the documents have been brought to the IESG. 
        
  3. Ralph Droms: Comment [2011-10-05]:
    In the numbered list of scenarios in section 9.1, there are a couple
    of occurrences of the term "LISP sites."  Should "LISP sites" be
    replaced by "LISP-Multicast sites"?
    
    Is it assumed that a uLISP site uses non-LISP transport for multicast?
    If so, it would be helpful for the document to state that situation
    explicitly.
    
    In the Security Considerations section, if this document introduces
    no additional security concerns beyond those in LISP base spec,
    that assertion should be made explicitly.
  4. Wesley Eddy: Comment [2011-10-05]:
    I support Peter's DISCUSS
  5. Stephen Farrell: Discuss [2011-10-05]:
        
    (I bet this was a 100% predictable discuss, sorry for that. I'm even
    kind of wondering if its deliberate:-)
    
    It's really hard to believe that there are *no* new security
    considerations here compared to [LISP]. I suspect you might need to say
    that security in this environment is basically an unknown, or is that
    the case? 
    
    You might also refer to some generic multi-cast security RFCs
    as well.
     
        
  6. Stephen Farrell: Comment [2011-10-05]:
    - It'd be good to know if this use of LISP claims some benefit 
    over "ordinary" multicast, or if you're just making multicast
    work ok in a LISP environment. It doesn't matter much, but it'd
    be nice to say so the reader knows whether or not to get excited:-)
    
    - The intro leaves me wondering if a multicast group address is regarded
    as an EID or RLOC, or if it varies or if it matters. Just wondering.
    That is described at the start of section 5, but earlier would be good
    too.
    
    - You may want to expand the RPF acronym. 
    
    - p5, 1st para after bullets - the 1st sentence talks about "protocols"
    but the 2nd talks about "the protocol" - seems wrong.  
    
    - p17, oif_list is not explained here. Probably worth adding that, or
    a reference.
    
    - Section 10, 1st para, last sentence is missing something, maybe
    s/need to/and need to/?
    
  7. Russ Housley: Comment [2011-10-04]:
      Please consider the editorial comments in the Gen-ART Review by
      Kathleen Moriarty on 3-October-2011.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06774.html
  8. Peter Saint-Andre: Comment [2011-10-05]:
    draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations",
    which provides a good start toward understanding the parameters of the
    experiment we're engaging in here, and perhaps some dimensions for measuring
    success. It would be helpful for this document to contain a similar section.
    
    The terminology section repeats definitions from the base LISP spec. This seems
    like a bad idea. It would be better to reference those definitions and here
    simply provide the extended information that applies only to multicast
    environments.
    
    The Security Considerations section seems rather sparse. Does the use of LISP in
    a multicast environment truly have no security implications whatsoever?

draft-ietf-lisp-map-versioning

  1. Ron Bonica: Discuss [2011-10-05]:
        General:
    
    This document cannot be reviewed in a meaningful way before:
    
    - the LISP base document is reviewed
    - my DISCUSS against section 4.2 of the LISP Map Server document is resolved
    
    --------------------------------------------------------------------------------
    ----------
    Section 5.1
    
    In Bullet 2, you say:
    
    "2.  The packet arrives with a Destination Map-Version number greater
           (i.e., newer) than the one stored in the EID-to-RLOC Database.
           Since the ETR is authoritative on the mapping, meaning that the
           Map-Version number of its mapping is the correct one, this
           implies that someone is not behaving correctly with respect to
           the specifications.  In this case the packet carries a version
           number that is not valid, otherwise the ETR would have the same,
           and SHOULD be silently dropped."
    
    This reaction might be too strong, especially in a case where ETRs are
    temporarily out of sync (e.g., during a configuration change).
    
    --------------------------------------------------------------------------------
    -------------
    In Section  5.2 you say:
    
    "3.  The packet arrives with a Source Map-Version number smaller
           (i.e., older) than the one stored in the local EID-to-RLOC Cache.
           Such a case is not valid with respect to the specifications.
           Indeed, if the mapping is already present in the EID-to-RLOC
           Cache, this means that an explicit Map-Request has been sent and
           a Map-Reply has been received from an authoritative source.
           Assuming that the mapping system is not corrupted anyhow, the
           Map-Version in the EID-to-RLOC Cache is the correct one, while
           the one carried by the packet is stale.  In this situation the
           packet MAY be silently dropped."
    
    Why would you want to drop a packet if your return route to the source is
    potentially corrupt?
    
        
  2. Wesley Eddy: Comment [2011-10-05]:
    I support Ron and Robert's DISCUSSes
  3. Stephen Farrell: Comment [2011-09-20]:
    If there's conflict in normative text between this and base,
    which takes precedence? I think you need to say, even if
    you believe there is no such conflict, just in case it turns out
    that there's some hidden conflict or the base draft changes
    after this one is done.
  4. Russ Housley: Discuss [2011-10-06]:
        
      I hope I am missing something, but I spent a fair amount of time
      trying to figure this out.  So, if I missed something, I am sure
      other readers will miss it too.
    
      The document uses a fixed-length version number.  When a received
      number is smaller than the stored one, the conclusion is that the
      sender has an older version.  See for example the the 3rd numbered
      paragraph in Section 5.2.  However, Section 4 defines a more complex
      algorithm that I believe is intended to recognize that a version
      number of 0x001 might be newer than a version number of 0xFFE.
    
      I found the use of "smaller" confusing in the face of wrap around.
    
      Further, I think the formula in Section 4 is incorrect.  In my
      example above, 0x001 is newer than 0xFFE, so if I understand the
      document correctly, 0x001 should be "greater than" 0xFFE, and 0xFFE
      should be "less than" 0x001.  The formula says:
      
        V1 < V2 :  True if and only if V1 < V2 < (V1 + 2**(N-1)).
    
       This translates to: 0xFFE < 0x001 < (0xFFE + 2**11), which fails. 
        
  5. Robert Sparks: Discuss [2011-10-04]:
        Related to the questions Richard Barnes asked in his 2Sep GenArt review (which
    afaict has not seen a response) - what keeps an ETR that has restarted from
    discarding traffic from ITRs that still have a map version cached from before
    the ETRs restart that happened fall in the half of the buffer the ETR would now
    consider "too new"? 
        
  6. Robert Sparks: Comment [2011-10-04]:
    The comparison operator on the circular range of version numbers currently is
    not well defined when comparing against the value that's exactly half-way around
    the buffer (for example, if N were 3, it is not defined whether 1 is less than
    or greater than 5 (1<5<5 isn't true, nor is 5>1>1)).

draft-li-pwe3-ms-pw-pon

  1. Stephen Farrell: Comment [2011-10-04]:
    The IPR declaration refers to "the standard" a couple of times
    so, since this is targetted at informational, its not possible
    for me to know if the stated terms apply or not. (Yet again;-)
  2. Pete Resnick: Discuss [2011-10-05]:
        I'd like to push Stephen's point to a DISCUSS at least until the telechat,
    though I am unwilling to continue this discussion past the telechat unless other
    ADs are really on board:
    
    I don't understand why this document is being put forward for IESG endorsement.
    It appears to be deployment instructions for a particular L2 network
    configuration, which doesn't seem terribly relevant to the IETF. Further, there
    is a patent disclosed (by the company of two out of the three authors) where
    that disclosure does not say how it would apply to a non-standard. It's not
    clear to my why this is relevant to the IETF community in the first place (the
    obvious WG for it had no interest in the document), and given the disclosure, I
    don't see clear benefit to the community to publish it. 
        
  3. Dan Romascanu: Discuss [2011-10-06]:
        The document describes (also) the usage of OMCI for configuring end-to-end MPLS
    PWs over G-PON or XG-PON.  However the Security Considerations section talks
    only about the security mechanisms of G-PON and XG-PON ('as good as those
    provided in a well secured MPLS PSN') and says nothing about the security
    mechanisms of OMCI. Are these also 'as good' as the ones used to manage MPLS
    networks? 
        

draft-baker-bmwg-testing-eyeball-happiness

  1. Wesley Eddy: Comment [2011-09-21]:
    In the timing requirements for each metric, it's confusing whether the
    requirement is 0.1 ms error over 60 seconds, or 1ppm, since both are mentioned.
  2. Stephen Farrell: Comment [2011-09-13]:
    (1) 2.2 says to do "at least N" runs when Bob has N addresses, but
    isn't that a bit misleading when alice has M addresses as well given
    that you're interested in the min and max over (I guess) all
    combinations of the (M,N) pairs that can ever work, blocking all but
    one each time? Maybe characterising the number of iterations like
    that would be better?
    
    (2) I wasn't clear if these metrics are also intended to be used
    e.g. for a config with a middlebox between router1 and router2 that
    enables one of Alice's IPv6 addresses setup a TCP session with one
    Bob's IPv4 addresses.  I'm not asking for anything in particular, I
    just wondered and didn't get an answer from the text. 
    
    Editorial nit-like stuff:
    
    - Saying "installing" "Path MTU issues" is awkward at best and
    possibly misleading - maybe put the word "installing" in each of the
    bullets but the last, and say "creating path MTU issues" for the
    last bullet and merge the next paragraph into that bullet?
    
    - Section 2.2: the sentence "Different measurement trials revise..."
    is hard to understand and I think could just be omitted.
    
    - 3wHS is a bit cryptic in Figure 2 - if you just add the
    abbreviation to the text describing figure 2, that'd be ok, as in
    "three-way handshake (3wHS)", or maybe even make that paragraph be
    the caption for figure 2.
    
    - 2.3.1: Name == "Session Setup Interval" but then you say that
    "Session setup time" is measured in ms. Better to use the
    terminology consistently. Similarly the "units" text in 2.3.2 &
    2.3.3 also seems wrong. Just saying "Units: milliseconds" would be
    fine.
    
    - Seems odd for the measurement point(s) text in 2.3.2 and 2.3.3 to
    refer to 2.3.1 but to then repeat the text for Timing. Same thing
    for 2.3.4 I guess.
    
    - I guess I don't understand what a "Descriptive Metric" might be,
    but I assume the intended readership would.  I also don't see how it
    has "units" of ms if it requires text to be understood? If there's
    an RFC that defines this term then referencing that would be
    good.
    
  3. Dan Romascanu: Comment [2011-09-18]:
    The Security Considerations section should mention the potential threat of
    overloading production networks if the conditions described in the last
    paragraph in Section 1 are not respected and advise care in using the test
    procedures in operational networks.