IESG Narrative Minutes

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

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

The scribe had difficulty with Lars's connection, and had a hard time understanding him, and so apologizes that the notes about what he said are spotty.

Corrections from:

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Using the NETCONF Configuration Protocol over Secure Shell (SSH) (Proposed Standard)
    draft-ietf-netconf-rfc4742bis-07
    Token: Dan Romascanu
    Note: Mehmet Ersue (mehmet.ersue@nsn.com) is the document shepherd.
    Discusses/comments (from ballot 3610):
    1. David Harrington: Discuss [2011-02-28]:
      1) 4741bis says: "The authentication process MUST result in an authenticated client identity whose permissions are known to the server...:
      4742bis says: "How the NETCONF Server extracts the SSH user name from the SSH layer is implementation-dependent."
      This is not an explanation. Assuming an operator must specify access control rights for a user in the configuration o fthe server, it is important that the operator understands what the netconf username(s) will be. That is presumably why it is important for the Netconf transport protocol specification to explain the algorithm for deriving the username.
      RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal with similar issues, including constraints about not changing the username associated with a session, allowing "user@host" style naming, etc. Maybe those are not needed for netconf, but the above "implementation-dependent" explanations seems woefully inadequate.
    2. David Harrington: Comment [2011-02-28]:
      1) The IANA section does not specify that the assigned port is a TCP port. should it?
    3. Alexey Melnikov: Discuss [2011-03-03]:
      In general I support publication of this document. However I would like to discuss the following issue before I can recommend its approval:
      1) I support David's DISCUSS about lack of information about username extraction.
    4. Tim Polk: Comment [2011-03-02]:
      I suspect I am disclosing my lack of netconf clue, but here goes:
      Why is the example in section 4.2 (chunked encoding) declaring the base1.0 namespace? I thought that base1.1 support is required of both the server and client to use chunked encoding...
    5. Peter Saint-Andre: Comment [2011-03-02]:
      (blank)
    6. Sean Turner: Comment [2011-03-02]:
      #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be a "MUST"?
      #2) Sec 4.2: Would any XML decoding error cause termination as stated at the end of 4.2? E.g. some unknown xmlns value or something?
      #3) If it's worth changing the framing protocol at all, which I'm willing to accept as a given, it is far from obvious to me that the current negotiated upgrade is the right way to do it, as this will require implementation of the old bad mechanism forever. Switching to a new SSH subsystem name seems like a much simpler solution.
      #4) As a matter of stylistic consistency with the last several decades of Internet protocols, the delimiter sequence in the new framing protocol should have been <CRLF>, not <LF>.

    Telechat:

  2. Network Configuration Protocol (NETCONF) (Proposed Standard)
    draft-ietf-netconf-4741bis-09
    Token: Dan Romascanu
    Note: Bert Wijnen (bertietf@bwijnen.net) is the document shepherd.
    Discusses/comments (from ballot 3613):
    1. Ron Bonica: Comment [2011-03-01]:
      Rob Enns has left Juniper Networks. We need an updated affiliation for him.
    2. Lars Eggert: Comment [2011-03-01]:
      Section 2 should have a requirement that NETCONF transport that are to be used over the Internet MUST implement congestion control, in accordance with RFC2914. It can also simply note that all NETCONF transports that use TCP (such as the SSH transport) automatically fulfill this requirement.
      (This really is a no-brainer. I just want to prevent a future argument when someone wants to do a "lightweight" NETCONF transport over UDP...)
    3. Adrian Farrel: Comment [2011-03-02]:
      I am entering a No Objection position on the basis of the Yes ballots from the Ops ADs.
      Appendix C seems to claim that "this value is pre-determined by RFC 4741" but since 4741 is now obsoleted (by this document) you should find some new text.
    4. David Harrington: Discuss [2011-03-01]:
      1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8?
      2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol?
      3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service?
    5. David Harrington: Comment [2011-03-01]:
      1) copyright in yang module needs updating.
      2) appendix F doesn't mention dropping the local file requirement for URLs,
      3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0.
      4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability.
      5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control.
    6. Russ Housley: Comment [2011-03-01]:
      Please add a sentence to the Abstract that indicates that this document obsoletes RFC 4741.
    7. Tim Polk: Comment [2011-03-02]:
      (1) 2.2. paragraph 1 - last sentence is awkward. In general connections are encrypted "in" an algorithm (e.g., AES) or "using" a protocol (e.g., TLS).
      Suggest: s/encrypted in TLS [16] or SSH [14]/encrypted using TLS [16] or SSH [14]/
      (2) 3.1. Namespace: Should this text reference the namespace base:1.1 instead of base:1.0 ??
      (3) The example in 6.2.2 Attribute Match Expressions references containment nodes and selection nodes, which are described in 6.2.3 and 6.2.4, respectively.
      It might be cleaner to reorder as 6.2.2 Containment Nodes, 6.2.3 Selection Nodes, and 6.2.4 Attribute Match Expressions so that concepts are introduced sequentially
      (4) Section 8.1: The following sentence implies that clients can attack other sessions by guessing session-ids: "A server receiving a <session-id> element MUST close the NETCONF session."
      I believe the intent was as follows: "A server receiving a <hello> element that includes a <session-id> element MUST ignore the session-id and close the NETCONF session."
      If that is the intent, I suggest the latter wording.
      (5) Section 9. Security Considerations, paragraph five states: "Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol SHOULD be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces."
      The clause "and without integrity checking" is not relevant to eavesdropping attacks.
      Suggest: s/classic eavesdropping attacks/classic eavesdropping and false data injection attacks/
    8. Peter Saint-Andre: Comment [2011-03-02]:
      1. DTDs are forbidden (presumably you mean internal or external DTD subsets in accordance with section 2.8 of the XML specification). What about comments, processing instructions, and internal or external entity references?
      2. In Section 6.2.5, 'for which the <name> element is equal to "fred"' is more precisely expressed as 'for which XML character data of the <name> element is equal to "fred"'. (The same text occurs in Section 6.4.5.)
      3. Section 6.4.3 states: "In a real data model, the <company-info> would not likely be returned with the list of users for a particular host or network."
      Why not?
      4. In Section 7.5, is the server allowed to terminate a lock for reasons other than session closure? If not, it appears than an entity could maintain a lock indefinitely.

    Telechat:

  3. The Local Domain Name DHCPv6 Option (Proposed Standard)
    draft-ietf-hokey-ldn-discovery-06
    Token: Tim Polk
    Note: The document shepherd is Tina Tsou <tena@huawei.com>
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-hokey-ldn-discovery-03
    Discusses/comments (from ballot 3623):
    1. Jari Arkko: Comment [2011-03-03]:
      I agree with others that the document must be changed so that its title, abstract, and the option name match the use for ERP. This is not about general domains (e.g., DNS).
    2. Ralph Droms: Comment [2011-03-01]:
      Small suggestion for clarity: s/EAP domain/domain/ in the Abstract., for those of us who leap to associating "domain" with "DNS"...
    3. Adrian Farrel: Comment [2011-03-01]:
      Acronyms need to be expaneded on first use in the body of the document. For example, EAP, DSRK, etc.
    4. Peter Saint-Andre: Discuss [2011-03-02]:
      1. The reference to RFC 3315, along with the lack of a reference to RFC 5891, seems to imply that internationalized domain names are not supported. If so, please make that clear in the specification.
      2. The apps-review team review raised the following major issues:
      - The option specified in this draft is to be used for the specific purpose of ERP, and may not be appropriate for other uses, such as use in a search list. See Section 2 of RFC 5296. Both the option name and the text should make this clear.
      - While this is an Applications Area review, the Security Considerations section should still conform to the requirements of RFC 3552.
    5. Peter Saint-Andre: Comment [2011-03-02]:
      1. Please spell out FQDN and other relevant acronyms (e.g., perhaps AAA) on first use.
      2. Section 5 has "DHPv6" instead of "DHCPv6".
      3. The apps-review team review raised the following issue:
      - This document also specifies a length limitation of 256 octets that does not take into account issues raised by RFC 4282. My recommendation would be to either match or reference the text in RFC 4282.
    6. Sean Turner: Discuss [2011-03-01]:
      #1) Is there no way that a relay agent might be acting on behalf of many domains without knowing? If so, then section 5 may need a few more words.
      #2) Section 6 says authentication is needed. I assume it's mutual authentication, but this should be explicitly stated.
      #3) Section 6, for how long must replays be detected? (And by whom?) How can that be done? (E.g. for a mobile device)
    7. Sean Turner: Comment [2011-03-01]:
      #1) In the security considerations can you say something more about what happens if mutual authentication is not performed.
      #2) Section 5 should indicate why the DHCPv6 relay should include the LDN.
      #3) Sec 3: Can this option be used other than "after full EAP authentication"? Either way, just say so.

    Telechat:

  4. RTP Payload Format for MIDI (Proposed Standard)
    draft-ietf-payload-rfc4695-bis-01
    Token: Robert Sparks
    Note: Roni Even (even.roni@huawei.com) is the document shepherd.
    Discusses/comments (from ballot 3709):
    1. Adrian Farrel: Discuss [2011-03-01]:
      An easy Discuss that can be resolved with just a few words.
      idnits points out...
      -- The draft header indicates that this document obsoletes RFC4695, but the abstract doesn't seem to mention this, which it should.
      It should also be discussed in the Introduction.
      I would also say that Appendix F (changes from 4695) should be pulled back into the body of the document, but this is not important.
      (See also the Comment from Russ Housley)
    2. Adrian Farrel: Comment [2011-03-01]:
      Section 1.2: "In this document, the packet bitfields that share a common name often have identical semantics."
      This left me wondering how I find the cases where they have common names but different semantics.
    3. Russ Housley: Comment [2011-03-01]:
      Please add a sentence to the Abstract that indicates that this document obsoletes RFC 4695.
    4. Alexey Melnikov: Discuss [2011-03-03]:
      My apologies for spending so little time to review this document, but the following things caught my attention:
      1). 11. IANA Considerations: "This document does not change any of the registrations in RFC 4695. Therefore, this document does not require any IANA actions, apart from updating the references to RFC 4695 to point to this document."
      I don't think this is Ok. Please correct me if I am wrong, but this document has updated ABNF for various parameters specified in RFC 4695. This clearly updates the MIME type registration.
      I think the right thing to do here is to keep the MIME type registration from RFC 4695 in this document.
      2). Somewhat related to #1: RFC 4695 registers audio/mpeg4-generic MIME type.
      audio/mpeg4-generic MIME type registration on <http://www.iana.org/assignments/media-types/audio/index.html> doesn't point to RFC 4695 or this draft. This seems to be an omission.
      And again, correct me if I am wrong, but it looks like the MIME type registration is implicitly updated due to changes to the ABNF of various MIME type parameters.
    5. Alexey Melnikov: Comment [2011-03-03]:
      [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
      This reference needs to be Normative. No extra IETF LC is needed to make this change, as this RFC is already in the DownRef registry.
      Because this is a -bis document, I am entering the following issues as Comment-level (as opposed to DISCUSS-level), however I would like to ask to serious consider fixing these as well:
      D. Parameter Syntax Definitions
      - mime-type = "audio" / "application"
      - mime-subtype = token ; See Appendix C.6.2 for registration requirements for rinit type/subtypes.
      The mime-subtype definition should be pointing to the definition in RFC 4288, Section 4.2:
      4.2. Naming Requirements
      - type-name = reg-name
      - subtype-name = reg-name
      - reg-name = 1*127reg-name-chars
      - reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_"
      In RFC 4695: 11.3. asc Media Type Registration
      - Media type name: audio
      - Subtype name: asc
      [...]
      Restrictions on usage: "This type is only defined for data object (stored file) transfer. The most common transports for the type are HTTP and SMTP."
      And there is no registered file extension? I think this is a serious omission for something which can be stored in a file.
    6. Dan Romascanu: Comment [2011-03-02]:
      In the IANA Considerations Section: "This document does not change any of the registrations in RFC 4695. Therefore, this document does not require any IANA actions, apart from updating the references to RFC 4695 to point to this document."
      It looks to me that both documents (this one and RFC 4695) need to be referenced in the IANA pages. The reason is that while this document obsolets RFC 4695 it does not carry the text that refers to the creation of the registries.
    7. Sean Turner: Comment [2011-03-01]:
      #1) Since this is a bis document, I presume it's been used for a while. Maybe the tense should change in intro to reflect this? Likewise, the original premise of 4965 was to allow musicians to be in different locations but still jam together - did it work?

    Telechat:

2.1.2 Returning Items

  1. Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (Proposed Standard)
    draft-ietf-sipcore-199-05
    Token: Robert Sparks
    Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3223):
    1. Lars Eggert: Comment [2010-02-02]:
      INTRODUCTION, paragraph 2: "Response Code for Indication of Terminated Dialog"
      Add something to the title that makes it clear this is for SIP?
      Section 3., paragraph 1: "REQ 1: It must be possible to indicate to the UAC that an early dialog has been terminated before a final response is sent."
      I don't understand the purpose of including this single requirement in this specification document. At least not without further explanation.
    2. Adrian Farrel: Comment [2010-02-02]:
      The document does not say what track it is targeting. I assume from the ballot that it is intended as Standards Track. Please can you confirm and update the document header.
      The abbreviations UAC and UAS will need to be expanded in the Abstract and on first usage in the body text.
    3. Russ Housley: Comment [2010-01-29]:
      The Gen-ART Review by Avshalom Houri on 26 Jan 2010 suggested adding references to other relevant RFCs in the Security Considerations. A few editorial changes were suggested. Please consider these changes.
    4. Cullen Jennings: Discuss [2010-02-04]:
      The draft needs to be explicitly clear about what conditions it helps in. The current text is not clear enough given that many people end up debating it and or confused. I think this is just a matter of getting more explicitly about these points and deleting any ones where it is not clear exactly what cases it helps in. We just need to get these to the point where it is clear that they are factually correct.
      1. "Codec release - when resources for a specific codec has been reserved only for the stream that is terminated. In that case the resources associated with that codec can be released."
      I don't understand what resource is released...
      2. "Pre-conditions - when the dialog is terminated, procedures and resources associated to the pre-conditions for that dialog can be released."
      Please clarify this to around the allocated bandwidth....
      3. "In-band security negotiation - when the dialog is terminated, procedures and resources associated with the in-band security negotiation for that dialog can be released."
      Ditto on this.
      You wrote "[Christer] Whatever procedures takes place on the media plane in order to establish the security associated, and resources reserved in order to deal (encrypt/decrypt) with the secure media itself."
      I still don't understand what resources...
      4. "ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is terminated, procedures and resources associated with the ICE related in-band procedures for that dialog can be released."
      In email you mentioned that it is the sending of keep alives that can be stopped. This is a good answer and makes sense. Can you update the text to say that and also mention how frequently they are sent and what sort of scenarios benefit from this optimization.
      5. "Limited access resources - in case of forking and multiple stream it may not be possible to allow early media on all dialogs, so media sessions associated with some dialogs may e.g. be set to "inactive". When a dialog is terminated, media sessions associated with other dialogs can be allowed."
      From email "[Christer] The probably most common scenario is when an application server in the network creates an early dialog with the UA in order to send an announcement, while the INVITE is forwarded towards the remote UA(s). There are specified procedures (in TISPAN and 3GPP) where this occur, and I believe this mechanism has also been discussed on the IETF SIP lists."
      Can you help educate me about theses a bit more. The ones I saw before involved the announcement finishing before the PSTN got the call.
      6. "Secure media selection - when SRTP is used to encrypt the media."
      I'm still not following what this allows that would not be otherwise possible without the 199...
      ...
    5. Cullen Jennings: Comment [2010-02-04]:
      (blank)
    6. Alexey Melnikov: Comment [2011-03-03]:
      I agree that Experimental for this document is going to be better.
      I don't think the document is doing a very good job convincing readers about utility of this mechanism. At least not until it starts describing detailed use cases.
      4.1. Examples of resource types: "NOTE: When using SRTP [RFC3711], the secure media stream is bound to the crypto context setup for the dialog, and can be identified using the MKI (if used) of SRTP."
      Please expand the acronym on first use.
      "If the client only has a single early dialog (other early dialogs MAY not have been established, or they MAY have been established and..."
      It doesn't look like use of these 2 MAYs is correct - they don't describe requirements.
      4.2. Examples of policy procedures: "2. SBC early media selection - when an SBC is used to control which..."
      Please expand the acronym on first use. 14.1. Normative References
      [RFC3711]...
      [RFC3841]...
      [I-D.ietf-mmusic-ice]...
      I think the above references are Informative.
    7. Tim Polk: Comment [2010-02-03]:
      Section 1 states: "The 199 response code is an optimization, which allows the UAC to be informed about terminated early dialogs. However, since the support of the 199 response is optional, a UAC cannot assume that it will always receive a 199 provisional response for all terminated early dialogs."
      Section 4 seems to imply that there are some applications that will not work unless 199 is supported:
      "The UAC SHOULD NOT insert the 199 option-tag in the Require header, unless the particular session usage requires the UAS to support the response code. Also, the UAC SHOULD NOT insert the 199 option-tag in the Proxy-Require header, unless the particular session usage requires every proxy on the path to support the response code."
      Are these two sections in conflict?
    8. Peter Saint-Andre: Comment [2011-03-01]:
      The introduction is difficult to understand. It would be helpful to provide a picture of the scenario that motivates this document, or at least to provide a forward reference to the "swim lane" diagrams in Section 9.
    9. Robert Sparks: Comment [2010-04-13]:
      (blank)
    10. Sean Turner: Comment [2011-03-02]:
      #1) Sec 1: Can you provide an example of policy related decision?
      In addition, SIP entities might also use the 199 response to make policy related decisions related to early dialogs.
      #2) Sec 5: This is a little hard to parse (it's all one sentence):
      "If a UAS receives an initial dialog initiation request, with a Supported header field that contains a "199" option-tag, it SHOULD NOT send a 199 response on an early dialog associated with the request, before it sends a non-2xx final response, unless it e.g. has been configured to do so due to lack of support of the 199 response code by forking proxies or other intermediate SIP entities, or it is used in an environment that specifies that it shall send a 199 response before sending a non-2xx response."
      #3) I'm trying to reconcile the statement in the 2nd to last para of Sec 5, which says that the 199 is only for informational purposes, with the MUST NOT In the last paragraph. If it's informational then why is it a MUST NOT?

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields (Proposed Standard)
    draft-bryan-metalinkhttp-21
    Token: Alexey Melnikov
    Discusses/comments (from ballot 3640):
    1. Ralph Droms: Comment [2011-03-03]:
      I've cleared my DISCUSS.
      1) Resolved.
      2) Is there a registry for the various attributes references in this document, including "pri", "pref", "geo", etc.? If not, in my opinion it would be beneficial to give a list and some formal definitions of the attriubtes; at least, some indication that the attributes are defined in this document.
      (added 2011/3/3) The latest rev almost resolves this comment. My remaining comment is admittedly pedantic and just a nit, based on avoiding the use of passive voice:
      The following OPTIONAL attributes are defined:
      - "depth" : mirror depth in Section 3.4.
      - "geo" : mirror geographical location in Section 3.2.
      - "pref" : a preferred mirror server in Section 3.3.
      - "pri" : mirror priority in Section 3.1.
      Is this text the authoritative definition for the OPTIONAL attributes or are they defined somewhere else and the definitions repeated here?
    2. Lars Eggert: Discuss [2011-02-15]:
      INTRODUCTION, paragraph 4: "This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Clients can use this information to make file transfers more robust and reliable."
      DISCUSS: The document title and this summary aren't really accurate. In addition to describing how to store Metalink info in HTTP header fields, a large part of the document (Section 7) is actually specifying how Metalink clients MUST/SHOULD/MAY operate.
      Section 3.3., paragraph 1: "There are two types of mirror servers: preferred and normal. Preferred mirror servers are HTTP mirror servers that MUST share the same ETag policy as the originating Metalink server and/or MUST provide Instance Digests using the same algorithm as the Metalink server."
      DISCUSS: Section 1 said "SHOULD share the same ETag policy" - which is it?
      Section 7., paragraph 13: "If the object is large and gets delivered slower than expected, then the Metalink client MAY start a number of parallel ranged downloads (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these ranged requests."
      DISCUSS: I realize that this spec doesn't really cover the client, but I find this description of permitted client operation problematic. What it basically says is "if the download is slow, open more connections." This is NOT a good general practice. There need to be limits on the number of parallel connections, ideally based on observing how the aggregate throughput changes as connections are opened - blindly opening connections once the path bottleneck is filled is pointless. (There is some text later in this section that goes in this direction, but not far enough.)
    3. Lars Eggert: Comment [2011-02-15]:
      Section 3.2., paragraph 1: "Entries for a mirror servers can have a "geo" value, which is a [ISO3166-1] alpha-2 two letter country code for the geographical location of the physical server the URI is used to access. A client can use this information to select a mirror, or set of mirrors, that are geographically near (if the client has access to such information), with the aim of reducing network load at inter-country bottlenecks."
      s/can/MAY/? The document is generally pretty sloppy in its use of RFC2119 terms; it would be very good if the authors would go over it once more.
      Section 4., paragraph 1: "Entries for metainfo files, which describe ways to download a file over Peer-to-Peer networks or otherwise, are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter that indicates the MIME type of the metadata available at the URI. Since metainfo files can sometimes describe multiple files, or the filename may not be the same on the Metalink server and in the metainfo file but still have the same content, an optional name parameter can be used."
      s/optional/OPTIONAL/ and/or s/may/MAY/
      Section 4.1., paragraph 1: "Full Metalink/XML files for a given resource can be specified as shown in the example in Section 4."
      Specify-by-example isn't how things are usually done in the IETF. It would be good to have an actual specification.
    4. Adrian Farrel: Comment [2011-03-01]:
      Section 1... "extremely minimal" means what? It either minimal or it isn't.
      Section 3.1: "Entries for mirror servers are listed in order of priority (from most preferred to least) or have a "pri" value, where mirrors with lower values are used first."
      "This is purely an expression of the server's preferences; it is up to the client what it does with this information, particularly with reference to how many servers to use at any one time."
      There is a contradiction between "are used first" and the second paragraph that says the client can do what it likes. Maybe the word "priority" and the "pri" value are poor choices since they reflect only a preference.
    5. Alexey Melnikov: Discuss [2011-03-02]:
      From the GenArt review: "Also, is there a risk the initial server could cause a loop by pointing to _itself_?"
    6. Alexey Melnikov: Comment [2011-03-01]:
      (blank)
    7. Tim Polk: Comment [2011-02-16]:
      I support Sean's discuss on signature formats. There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory to implement, but the installed base with X.509 would seem to justify including S/MIME signatures.
      I also share Robert's and Peter's concerns about amplification and DoS attacks.
    8. Dan Romascanu: Comment [2011-03-02]:
      1. If the draft is based on the experiences made in a project the community would like to know more on the project. It would be good to mention in the Introduction section of the draft the open source project, what it does and the experience made based on the project, and also provide a reference to the project in the references section.
      2. The document does not have a Terminology and Abreviations section, which would be very useful to make it more readable
    9. Robert Sparks: Comment [2011-03-01]:
      1) What prevents a malicious server from returning a 200 with many Link: headers, all indicating rel=duplicate, perhaps indicating non-overlapping subsets of the entity, and all pointing to a victim, driving many, possibly parallel, connection attempts?
      2) When a Link (indicating an HTTP resource) is followed, does anything prevent that referenced server from also replying with MetaLink headers in its response? If not, what prevents loops, intentionally or unintentionally created, from being followed? If a client would automatically follow these, especially in parallel, exponential attacks against the victims in item 1) are possible. At the very least, a client could be sent into an infinite ping-pong loop.
    10. Sean Turner: Comment [2011-02-28]:
      (blank)

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Socket Application Program Interface (API) for Multihoming Shim (Informational)
    draft-ietf-shim6-multihome-shim-api-16
    Token: Jari Arkko
    Note: Document Shepherd is Geoff Huston
    Discusses/comments (from ballot 3567):
    1. Ralph Droms: Discuss [2011-03-01]:
      The description of SHIM_LOC_LOCAL_PREF in section 6.4 is unclear to me. Does this mecahnism set the preferred local locator or the preference values (lc_prio and lc_weight) on a local locator? Does it get the currently preferred locator or the preference values for the specified locator? The same questions apply to section 6.5.
      lc_proto is not specified in any of the examples in section 6, while lc_ifidx and lc_flags are explicitly set to 0 even in the cases where they are not used (e.g., section 6.4). Is lc_proto a "don't care"; does it need to be set to 0 to show no NAT is involved; is it set to a non-zero value to indicate a NAT will be traversed?
      In section 8: :lc_proto: Internet Protocol number for the protocol which is used to handle locator behind NAT. Typically, this value is set as UDP (17) when the locator is a UDP encapsulation interface.:
      What is the value of lc_proto if the locator is not behind a NAT, or is there some other way to indicate that the lcoator is not behind a NAT? "Typically" is imprecise; if the value is not always IPPROTO_UDP, where are the values formally defined?
      Also in section 8: "lc_addr: Contains the locator. In the case where a locator whose size is smaller than 16 bytes, an encoding rule should be provided for each locator of a given address family. For instance, in case of AF_INET (IPv4), the locator should be in the format of an IPv4-mapped IPv6 address as defined in [RFC4291]."
      Why not "must be provided"? Where are these encoding rules provided? Why not "in case of AF_INET (IPv4), the locator is encoded in the format of [...]"
      Still in section 8: "lc_ifidx: Interface index of the network interface to which the locator is assigned. This field is only used in a read (getsockopt()) operation."
      But the example in section 6.8 seems to indicate the use of lc.ifidx with setsockopt(). I recommend dopping the last sentence here in section 8 and leaving the explanation of the use of lc_ifidx (and lc_flags, which also appears to be unused in some setsockopt() calls) to the specific specifications in section 6.
    2. Ralph Droms: Comment [2011-03-01]:
      The fourth and fifth paragraphs of the Introduction would fit better someplace else; perhaps in section 2, renamed "Terminology and Background".
      In section 5, what is a "context"?
      Third bullet in section 5: s/Notification from applications/Notification from applications and upper layer protocols/ (for consistency throughout the text of this bullet).
      (Nit) Fifth bullet in section 5: s/for the/for a/
      (Clarification) "The host" seems imprecise; is it really the shim sub-layer that makes the substitution?
      Ninth bullet: define "deferred context" (as well as "context"?) in section 3.
      In the description of SHIM_ASSOCIATED, I suggest leaving out the specific parameter values (0/1), as those values are specified in section 6.1; in fact, there appears to be a third value specified for SHIM_ASSOCIATED (2) in section 6.1 that is not mentioned in the earlier description.
      The indication of which parameters are unused in a given setsockopt() call, as in this text from section 6.4:
      "Note that some members of the shim_locator (lc_ifidx and lc_flags) are ignored in the set operation."
      is not consistently specified in section 6.1-14.
      The word "placeholder" seems unnecessary at the beginning of section 8.1. Why not just call it a "data structure"?
      8.1. Data structure for Locator Information: "As defined in Section 6, the SHIM_LOC_*_PREF, SHIM_LOC_*_SEND, and SHIM_LOCLIST_* socket options need to handle one or more locator information. Locator information includes not only the locator itself but also additional information about the locator which is useful for locator management."
      "Figure 4 illustrates [...]"
      Also, for readability, perhaps s/locator information/locator information block/ ?
    3. Lars Eggert: Discuss [2011-03-01]:
      Section 5., paragraph 2: "Providing locator information to applications. An application should be able to obtain information about the locator pair which was actually used to send or receive the packet."
      DISCUSS: What do you mean by "the packet"? Applications see sockets out of which they read data. With UDP, you could add a sockopt to get information about the last packet sent or received, but with TCP, I don't see how this is supposed to work? Or do you mean the addresses the shim layer is currently using for the socket?
      Section 6.2., paragraph 3: "Default value is set as 0, which means that the shim sub-layer performs identifier/locator adaptation if available."
      DISCUSS: I don't think an Informational API document is the place to specify mandatory default protocol behavior. (If this default behavior is in the protocol specification, please rephrase this and refer to the text there.) Note that there are several sections below (6.3, 6.12, etc.) that define "default" protocol behavior, and this issue occurs whenever the default value for an option turns protocol behavior on or off (i.e., it doesn't apply in cases where the default merely affects the behavior of the API itself.)
      Section 8.2., paragraph 0: "8.2. Path Exploration Parameter"
      DISCUSS: This section needs to use a RFC2119 MUST whenever it talks about what do do with parameters from RFC5334. It's not up to an Informational API document to weaken what is mandated there.
    4. Lars Eggert: Comment [2011-03-01]:
      Section 2., paragraph 1: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]."
      This document is very inconsistent with its use of RFC2119 terms. There are many lower-case instances of those terms that I think should be capitalized. There are other cases where wording changes to use RFC2119 terms would clarify things.
      Section 6., paragraph 0: "6. Socket Options for Multihoming Shim Sub-layer"
      In many of the subsections under Section 6 that discuss the individual options, the explanatory text doesn't always explicitly state if what is being described is when an option is used with setsockopt vs. with getsockopt. The (unstated) default seems to assume setsockopt. It would be very good to explicitly clarify this, maybe even by explicitly adding subsections for set and get under each.
    5. Sean Turner: Comment [2011-03-02]:
      #1) Why assume only one shim sub-layer is active at a time? Wouldn't the most useful thing for this API to work when WiFi and GSM data are both usable? (Or maybe I'm misunderstanding the text.) In any case, it'd be useful to say why handling both being active is hard or out of scope.
      #2) I'm curious why there are no requirements to expose security related information, esp IPsec? If it's available wouldn't it be good to provide that?

    Telechat:

  2. Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats and Suggested Countermeasures (Informational)
    draft-ietf-speermint-voipthreats-07
    Token: Gonzalo Camarillo
    Note: Jason Livingood (Jason_Livingood@cable.comcast.com) is the document shepherd.
    Discusses/comments (from ballot 3577):
    1. Alexey Melnikov: Discuss [2011-03-02]:
      4.2. DNSSEC: "DNSSEC has not seen wide deployment on the Internet (due to various reasons which are out of the scope of this document)."
      Is this statement still true to life, or at least something which should be preserved in an RFC?
      4.12. Minimization of Session Establishment Data: "In order to give attackers as few chances as possible for eavesdropping, session hijacking, and other attacks, SSPs should try to minimize session establishment data. Unnecessary data exchange also increases the risk of an implementation vulnerability that could be exploited by attackers. In addition. unnecessary data exchange among SSPs can increase the risk of call patterns analysis or discovery of some SSPs interior topology."
      Easier said than done. How exactly this can be achieved? Can you provide some specific examples?
    2. Alexey Melnikov: Comment [2011-03-02]:
      2.3.1. Threats to SF Confidentiality: "Password cracking - the challenge-response authentication mechanism of SIP can be attacked with offline dictionary attacks."
      Did you mean SIP Digest? If yes, please say so.
    3. Tim Polk: Discuss [2011-03-02]:
      This document does not seem to consider an attack on one SSP from another, compromised, SSP. Is this attack explicitly out of scope (then it should state that) or do any of the countermeasures address such a scenario? To be clear, I am not pushing to expand the scope of the document, just to clarify it....
      The discussion of SRTP and SRTCP in 4.13 does not address which external key management protocol should be used to set up the initial master key. Is there a well-defined mechanism for speermint, or is this choice left to the deployment?
    4. Tim Polk: Comment [2011-03-02]:
      SQL injection is mentioned first in section 4. Suggest adding a quick description in section 2 somewhere.
      Section 4.5 only talks about IPsec and (D)TLS. Have SIP folks given up entirely on message oriented protection?
    5. Peter Saint-Andre: Comment [2011-03-01]:
      Overall this document appears to provide a helpful summary of the relevant security issues.
      Are the suggested countermeasures meant to be exhaustive? (Even I can think of additional countermeasures, such as limiting authentication attempts and obscuring certain error messages to help mitigate directory harvesting attacks.) It would be good to explain whether or not the list is exhaustive.
      Regarding denial of service attacks, please expand "DoS" on first use and cite RFC 4732.
      Various other acronyms are not expanded on first use (e.g., SSP).
      Citations are not provided for several technologies (e.g., ZRTP).
      The document contains several statements that are dubious (e.g., that scalability requirements lead SSPs to use UDP instead of TCP -- perhaps they need to write better code?) or that might not be true for much longer (e.g., that DNSSEC has not been widely deployed on the Internet -- at least qualify this by saying "at the time of this writing"). As far as I can see, these statements are not material to the recommendations provided in this document, and could be safely removed.
    6. Robert Sparks: Discuss [2011-03-01]:
      1) The descriptions of several of the threats are incomplete, and as a result significantly misleading. Rather than try to expand the description to provide enough detail to not be misleading, I suggest up-leveling the descriptions.
      For example, it is not clear in the forged 200 response bullet in section 2.3.2.2 if you are describing an on-path or off-path attacker. Assuming that you are only trying to describe off-path, the example doesn't capture the important differences on the injected 200 being sent to a proxy or directly to originating UA, nor does it note that the element receiving the injected 200 will also see another final response to the original INVITE (most likely a 487 due to the CANCEL you call out in the description of the threat).
      It should be sufficient to say "Having seen the contents of an INVITE request, an eavesdropper can inject a 200 response, affecting the processing of the transaction of all proxies between the injection point and the originating UA and at the originating UA itself. In the extreme, this can result in a hijacked call." And in the countermeasures section, call out that such an attack will leave signaling artifacts that will allow it to be detected.
      A similar shift in detail would be necessary for many of the other threat descriptions, particularly the forged 302 and 404 response threats in section 2.2.2.
      2) 2.3.2.1 mentions exploiting broken implementations in its introduction, but provides no threats that do so. More detail about what you mean by "guessing" might help.
      3) "SRTP and ZRTP are vulnerable to bid-down attacks, i.e. by selectively dropping key exchange protocol packets may result in the establishment of a non-secure communications."
      needs adjustment. It is the keying mechanism, not SRTP itself that is vulnerable, and the vulnerability depends greatly on which mechanism is used. If you are trying to call out the vulnerability of a particular mechanism, such as RFC4568, please call it out explicitly. For ZRTP, what bid-down attack are you pointing to?
      4) The description of Media Hijack in 2.4.2 calls out to a missing Figure 8.
      5) Was section 4.8 crafted before RSERPOOL closed? Could it be updated to reflect the output of that concluded working group?
      6) The first two sentences of 4.13 need adjusting to note that the algorithms used by SRTP are negotiated.
      7) [refs.voipsataxonomy] should point to a particular version of that taxonomy draft.
    7. Robert Sparks: Comment [2011-03-01]:
      Nits: In section 2.3.2.3, alternation should be alteration; In section 4.1 I suggest substituting "document" for "literatures"
    8. Sean Turner: Discuss [2011-03-03]:
      #1) I support Tim's discusses. One the 1st one I assume an SSP can be an attacker based on the call-pattern attacks.
      #2) Sec 2.3.2.2, shouldn't this draft address -199 spoofing?
      #3) Sec 2.4, is masquerading a concern? That is one UE spoofs another?

    Telechat:

  3. Design and Application Spaces for 6LoWPANs (Informational)
    draft-ietf-6lowpan-usecases-09
    Token: Ralph Droms
    Note: Geoff Mulligan (geoff.ietf@mulligan.com)is the document shepherd.
    Discusses/comments (from ballot 3631):
    1. Jari Arkko: Comment [2011-03-03]:
      Some comments from Ari Keränen:
      One question/comment: 3.6.2. 6LoWPAN Applicability: "Communication schedules must be set up between master and leaf nodes, and global time synchronization is needed to account for clock drift."
      Wouldn't time synchronization within the LoWPAN (i.e., not globally) be enough for this use case?
      And some nits:
      3.2.1. A Use Case and its Requirements: The second sentence of this paragraph is a bit hard to parse:...
      Perhaps add something like "and act" before the "as the [...]" part (if that's what it means)? Also: s/an sink/a sink/
      3.3.2. 6LoWPAN Applicability: "In home network, installation and management must as extremely simple for the user."
      s/as/be/
      Figure 4: "I" in the legend is redundant (there's no "I" in the figure)
    2. Stewart Bryant: Comment [2011-03-02]:
      An interesting and well written document.
      I agree with Peter that RFC2119 language does not seem appropriate.
    3. Lars Eggert: Discuss [2011-03-01]:
      I have a pretty fundamental issue with this document. Many of the described use cases make requirements on the 6lowpan architecture that I don't think are realistic, or at least it's very unclear how and if they can be achieved. The key example is the "support for QoS" requirement that is said to be very important for many use cases, yet I see no mechanisms in the actual 6lowpan specs that would support different levels of QoS, or even any text that would define what "support for QoS" even means in low-powered, maybe-disconnected networks. Surely it cannot only mean priority queuing, because that's clearly not sufficient for many of the described uses. Another requirement that is similarly problematic is "reliable delivery" (which is for some reason included under security). It's not clear at all to me whether reliable delivery can be achieved with any sort of timing constraints.
      I'm not quite sure how I can make this discuss actionable.
    4. Adrian Farrel: Discuss [2011-03-02]:
      A splendid and useful document that is let down by the Security Considerations section.
      The applicability of 6LowPANs is significantly dependent on suitable security mechanisms being available. Since 6LowPANs are very vulnerable to physical layer attacks, it is important to discuss the options and to identify when the use of these networks is not advisable.
      If you can add some beef to that section, I would happily change my ballot to Yes.
    5. Tim Polk: Discuss [2011-03-02]:
      The Security Considerations overlooks a number of very important issues/challenges raised by the use cases.
      First, a number of the use cases are vulnerable to physical threats, including device theft and simple vandalism. Given the safety issues involved in some use cases, this would seem to place specific demands for resiliency and survivability upon the 6lowpan. This issue seems to be overlooked entirely.
      Second, while the existing security considerations briefly touch on the need for encryption, the treatment does not expose the real issues at play. There is a reference to "lightweight key mechanisms" that deserves expansion - what are those mechanisms (references please!) The discussion of encryption overlooks a fundamental problem - the slow processors and limited memory capacity described in section 1 will be challenged by generally accepted cryptographic algorithms. However, the safety concerns associated with many use cases precludes deployment of weak cryptography!
      I suspect that authentication will provide a similar set of challenges. Configuration of strong authentication, with role-based access controls, on the nodes of even a medium sized lowpan seems problematic. (I don't recall the specific deployment challenge of provisioning/configuring the security controls being addressed in the body of the document.)
    6. Tim Polk: Comment [2011-03-02]:
      In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-planned". Somehow these seem in conflict.
      I share Lars' concern about QoS requirements.
    7. Peter Saint-Andre: Comment [2011-03-01]:
      This is a pleasant document. However, given that it discusses use cases and deployment scenarios, I doubt that it needs to use RFC 2119 conformance terms at all. For example, consider the following sentence from Section 3.2: "Some data is not critical for security protection (such as normal room temperature), but event-driven emergency data (such as a fire alarm) MUST be handled in a very critical manner." Well, that's probably the case, but it's really a matter of local service policy, isn't it? Similarly, the assertion in Section 3.4.1 that "Data privacy and security MUST be provided" in healthcare systems is really a matter of either local service policy or applicable legislation (e.g., HIPAA), not RFC 2119 conformance.
    8. Robert Sparks: Comment [2011-03-02]:
      Consider clarifying whether the set of dimensions here is intended as a complete list, or is just an important set currently identified.
    9. Sean Turner: Comment [2011-03-03]:
      I support Tim's discussion.

    Telechat:

  4. Host Identity Protocol Signaling Message Transport Modes (Experimental)
    draft-ietf-hip-over-hip-05
    Token: Ralph Droms
    Note: Gonzalo Camarillo (gonzalo.camarillo@ericsson.com) is the document shepherd
    Discusses/comments (from ballot 3697):
    1. Jari Arkko: Discuss [2011-03-03]:
      I think it would be useful for the document to talk about what happens when there's a NAT, and what the interaction with the HIP NAT traversal mechanisms is. Do you run UDP-ESP-TCP?
    2. Jari Arkko: Comment [2011-03-03]:
      The document should state that hiding HIP control packets inside ESP will make it impossible to build NATs or other middleboxes that look inside the HIP packets to do something useful. There used to be a proposal called SPINAT that did this, allowing ESP to go through NATs without UDP encapsulation. SPINAT isn't used anywhere anymore AFAIK, and the one implementation that exists isn't in open source. So this is not a big deal, but for completeness the impact should be noted.
    3. Lars Eggert: Discuss [2011-03-01]:
      Section 4.2., paragraph 1: "If the ESP-TCP mode is selected, the host with the larger HIT (calculated as defined in Section 6.5 of [RFC5201]) MUST start to listen for an incoming TCP connection on the encrypted connection on the port it used in the Port field of the transport mode parameter."
      DISCUSS: TCP listens on IP address/port number tuples. What's the IP address to listen on here? (I don't understand what you mean by "on the encrypted connection".)
    4. Lars Eggert: Comment [2011-03-01]:
      INTRODUCTION, paragraph 2: "Host Identity Protocol Signaling Message Transport Modes"
      I think this title sets a record for most number of consecutive nouns. Can we maybe stick a verb and an object in there to improve clarity?
      Section 4.2., paragraph 4: "Since TCP provides reliable transport, the HIP messages sent over TCP MUST NOT be retransmitted for the purpose of achieving reliable transmission."
      Does this mean that HIP messages may be retransmitted for other purposes? Or it this phrasing inaccurate?
    5. Adrian Farrel: Comment [2011-03-02]:
      I was surprised to see no discussion of TCP-AO.
      I agree with the Discuss about downgrade attacks. These seem to be particularly open in the mobility/multi-homing case described in Section 6.
    6. Dan Romascanu: Comment [2011-03-02]:
      The OPS-DIR review performed by David Black pointed to the following problem:
      "The draft is somewhat inconsistent about support for a HIP node policy that requires use of an encrypted transport for HIP signaling. Section 3.3 provides an essential building block, the error signaling mechanism to indicate that an encrypted transport is required and none was proposed. On the other hand, Section 5 is unclear with respect to this class of policy in that it strongly recommends (SHOULD) fallback to a non-encrypted HIP connection but requires (MUST) that "messages that are intended to be sent only encrypted" not be sent unencrypted. If the "messages that are intended to be sent only encrypted" are all HIP messages after the base exchange, these two requirements appear to be in conflict."
      I suggest adding a short explanation to Section 5 of what would be reasonable vs. unreasonable policy for "messages that are intended to be sent only encrypted", and how to use the Section 3.3 error report when a failed encrypted connection is recovered by attempting to fall back to an unencrypted connection when HIP node policy requires encryption of all signaling after the base exchange.
      The change was agreed by the document editor and the OPS-DIR reviewer and needs to find its way either in a revised I-D or in a note to the RFC Editor.
    7. Peter Saint-Andre: Discuss [2011-03-01]:
      Given that bootstrapping of secure communication depends on transmission of the HIP_TRANSPORT_MODE parameter during HIP base exchange, I'm surprised that the security considerations do not discuss the possibility of downgrade attacks.
    8. Sean Turner: Comment [2011-03-02]:
      1) It would have helped me had the packet figures from RFC 5201 were added here...
      2) Sec 4.2: Difficult to parse the sentence Lars has a discuss on.
      3) Why SHOULD the TCP originator use the source port they said they'd use? I could understand a MUST or with NATs a MAY but can't figure why SHOULD?

    Telechat:

  5. Host Identity Protocol Certificates (Experimental)
    draft-ietf-hip-cert-09
    Token: Ralph Droms
    Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3698):
    1. Adrian Farrel: Comment [2011-03-01]:
      Agree with Peter's Discuss. The update to 5201 should be noted in the document header and the Abstarct.
      Section 2: "It MAY either carry SPKI certificates or X.509.v3 certificates."
      I think lower case "may" is more appropriate. Unless you mean... "It MUST carry either SPKI certificates or X.509.v3 certificates.
    2. Alexey Melnikov: Discuss [2011-03-02]:
      3. X.509.v3 Certificate Object and Host Identities: "When using X.509.v3 certificates to transmit information related to HIP hosts, HITs MAY be enclosed within the certificates. HITs can represent an issuer, a subject, or both. In X.509.v3 HITs are represented as issuer or subject alternative name extensions as defined in [RFC5280]."
      Using which type(s)? Examples below show IP Address, but this is not stated normatively.
      "If only the HIT of the host is presented as either the issuer or the subject the respective HIT MUST be placed into the respective entity's DN's Common Name (CN) section in a colon delimited presentation format defined in [RFC5952]. Inclusion of CN is not necessary if DN contains any other naming information. It is RECOMMENDED to use the FQDN/NAI"
      How are these going to be represented in DNs? Are you assuming CN=<FQDN> or something else? What about NAI?
      "In this scenario, it is RECOMMENDED that the HIP peers have and use some mechanism of defining trusted root CAs for the purpose of establishing HIP communications. Furthermore it is recommended that the HIP peers have and use some mechanism of checking peer certificate validity for revocation, signature, minimum cryptographic strength, etc., up to the trusted root CA."
      The whole paragraph: this looks way too informative and way too weak. Maybe point to RFC 5280?
      7. IANA Considerations: "The CERT parameter has 8-bit unsigned integer field for different certificate types, for which IANA is to create and maintain a new sub-registry entitled "HIP certificate types" under the "Host Identity Protocol (HIP) Parameters". Initial values for the Certificate type registry are given in Section 2."
      What is the IANA registration procedure for this registry?
    3. Peter Saint-Andre: Discuss [2011-03-01]:
      Section 7 states: "This document defines the CERT parameter for the Host Identity Protocol [RFC5201]. This parameter is defined in Section 2 with type 768. The parameter type number is also defined in [RFC5201]."
      Therefore does this document need to say that it updates RFC 5201?
    4. Peter Saint-Andre: Comment [2011-03-01]:
      Please spell out acronyms on first use (I1, HI, HIT, FQDN, NAI, etc.).
      A reference to RFC 4282 might be appropriate with respect to NAI.
      References to various DNS-related specifications might be appropriate with respect to FQDN (also please clarify if internationalized domain names are allowed).
    5. Sean Turner: Discuss [2011-03-01]:
      #1) I was expecting a profile of RFC 5280 to identify which extensions MUST/SHOULD be present in X.509 certificates. Shouldn't this draft specify a profile and indicate things like:
      - The IAN and SAN extensions MUST be present? Assuming yes: which GeneralName form MUST be used?
      - Are there any HIP specific EKUs?
      - What algorithms (signature and hash) MUST be used to sign the certificates/CRLs (just pointing to 5201bis)?
      #2) Section 2 includes the following: "It MAY either carry SPKI certificates or X.509.v3 certificates."
      Are OpenPGP certificates prohibited? Are you just trying to say that this document specifies the semantics for carrying SPKI or X.509.v3 certificates? It sounds like the registry is limited to only these two types.
      #3) X.690 is normative because you require it be supported.
    6. Sean Turner: Comment [2011-03-01]:
      #1) <nit picking alert>r/Digital certificates bind a piece of information/Digital certificates bind a pieces of information</nit picking alert>
      #2) Section 2 3rd para: "not recommended" is used but should it be "NOT RECOMMENDED". It is 2119 language, but you'd need to update the Sec 1.1 as per the following errata: http://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499.
      #3) Cert Type Number: Should probably reserve value 0.
      #4) It may be useful to say that a receiver SHOULD validate the certificate signature against the octets received in case the sender/CA sent some bad DER that doesn't re-encode identically. This has happened in the past.
      #5) Checking a URL, or LDAP entry creates a potential DoS. That should be mentioned in the security considerations.
      #6) Should this be RECOMMENDED: "Furthermore it is recommended that the HIP peers have and use some mechanism of checking peer certificate validity for revocation, signature, minimum cryptographic strength, etc., up to the trusted root CA."
      Also, RFC 5280 indicates that revocation checking is optional. Was upping this to RECOMMENDED done on purpose?
      #7) Is there no way for a responder to signal trust anchor information to an initiator? That can be handy, but if the WG didn't want it then fine.
      #8) IANA Considerations: Do you need to specify how the registry is updated (e.g., specification required, IETF consensus)?
      #9) Should point to 5280 for security considerations X.509v3 certificates and 2693 for SPKI certificate security considerations.
      #10) Probably should just the same reference for X.690 as RFC 5280 uses: [X.690]...
      #11) Should expand HIT, HI, NAI, and FQDN.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. OCRA: OATH Challenge-Response Algorithms (Informational)
    draft-mraihi-mutual-oath-hotp-variants-13
    Token: Sean Turner
    Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd.
    IPR: VeriSign's Statement about IPR related to RFC 4226, draft-mraihi-mutual-oath-hotp-variants-08, draft-mraihi-totp-timebased-01, draft-ietf-keyprov-dskpp-07, draft-ietf-keyprov-pskc-01, and None
    IPR: VeriSign's Statement about IPR related to RFC 4226, draft-mraihi-mutual-oath-hotp-variants-08, draft-mraihi-totp-timebased-01, draft-ietf-keyprov-dskpp-07, and draft-ietf-keyprov-pskc-02
    Discusses/comments (from ballot 3570):
    1. Adrian Farrel: Comment [2011-03-02]:
      I found the list of requirements in Section 3 helpful in understanding why the algorithm is built the way it is. But I also found the requirements a little lacking in motives. Would it be possible to add a single sentence to each requirement to say *why* the requirement holds?
      I think you need to add a reference to the definition of the BNF you are using.
    2. Alexey Melnikov: Discuss [2011-03-02]:
      3. Algorithm Requirements: "R1 - The algorithm MUST support asynchronous challenge-response based authentication."
      Can you please explain in more details what this means?
      5.1. DataInput Parameters: "T is an 8-byte unsigned integer in big endian (i.e. network byte order) representing the number of time-steps(seconds, minutes, hours or days depending on the specified granularity) since midnight UTC of January 1, 1970."
      Where is the granularity is specified?
      "More specificatlly, if the OCRA computation includes a timestamp T, you SHOULD first convert your current local time to UTC time (text form);"
      Is use of the "text form" really a SHOULD? This looks like an implementation detail. I think the use of a RFC 2119 keyword is incorrect here.
      5.2. CryptoFunction: "The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of computation for OCRA is HOTP with the default 6-digit dynamic truncation and a combination of DataInput values as the message to compute the HMAC-SHA1 digest."
      What is "digit" in this case? A decimal digit? A hex digit?
      6. The OCRASuite: "An OCRASuite value is a text string that captures one mode of operation for the OCRA algorithm, completely specifying the various options for that computation. An OCRASuite value is represented as follows: Algorithm:CryptoFunction:DataInput"
      It is not clear to me if this is supposed to represent a pseudo-ABNF or something else. Is this saying that 3 strings are separated by ":" characters?
      6.1. Algorithm: "Description: Indicates the version of OCRA algorithm."
      "Values: OCRA-v where v represents the version number (e.g. 1, 2 etc.). This document specifies version 1 of the OCRA algorithm."
      Are there any rules about backward compatibility between higher versions and lower versions?
      In Section 8.2: "IC8 - We recommend that implementations MAY use the session information, S as an additional input in the computation. For example, S could be the session identifier from the TLS session. This will mitigate against certain types of man-in-the-middle attacks. However, this will introduce the additional dependency that first of all the prover needs to have access to the session identifier to compute the response and the verifier will need access to the session identifier to verify the response."
      Should this paragraph point to RFC 5056 and RFC 5929?
      Appendix A. Reference Implementation...
      Is the license for this code compatible with IETF rules?
    3. Alexey Melnikov: Comment [2011-03-02]:
      5.1. DataInput Parameters: "P is a hash (SHA1, SHA256 and SHA512 are supported) value of PIN/..."
      This is missing some references.
      "S is an UTF-8 encoded string of length upto 512 bytes that..."
      A normative reference for UTF-8 is missing here.
      In Section 8.2: "IC6 - All the communications SHOULD take place over a secure channel e.g. SSL/TLS, IPsec connections."
      Informative reference to TLS is needed here.
      "IC9 - In the signature mode, whenever the counter or time (defined as optional elements) are not used in the computation, there might be a risk of replay attack and the implementers should carefully consider this issue in the light of their specific application requirements and security guidelines."
      Is any advice about time synchronization needed here?
    4. Dan Romascanu: Comment [2011-03-02]:
      This is a clear and well-written document.
      The OPS-DIR review performed by David Black made one comment, which refers to a clarification aspect. It is not a blocking issue, but addressing it would be useful:
      "I do have one suggestion for improved clarity. The first sentence in the introduction states that a primary motivation for these algorithms as support for "users who do not want to maintain a synchronized authentication system." In contrast, the C component of DataInput in Section 5.1 is a counter that "MUST be synchronized between all parties." The reason that these two statements are not in conflict is the counter is optional for all of the algorithm modes defined in the draft. A statement to that effect should be added to Section 5.1 - IMHO, assuming that the optional nature of the counter will be inferred from the omission of the word "mandatory" is insufficient.

    Telechat:

  2. Internet Protocols for the Smart Grid (Informational)
    draft-baker-ietf-core-12
    Token: Russ Housley
    Discusses/comments (from ballot 3636):
    1. Lars Eggert: Comment [2011-03-03]:
      None of the comments below taken alone is discuss-worthy, but I do think at least several of them should really be addressed.
      Section 2.1.2., paragraph 3: "For example, TCP will reduce rate to avoid loss, while DCCP accepts some level of loss if necessary to maintain timeliness."
      TCP doesn't really reduce its rate to avoid loss - it uses loss as an indication for congestion, and basic congestion control principles mandate a rate reduction. DCCP does the same - the difference is that DCCP will not bother to retransmit lost data while TCP will.
      Section 3.2.2.3., paragraph 3: "In that research, the IETF imposed guidelines [RFC2357] on the research community regarding what was desirable. Important results from that research include a number of papers and several proprietary protocols including some that have been used in support of business operations. RFCs in the area include The Use of Forward Error Correction (FEC) in Reliable Multicast [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) [RFC4410]. These are considered experimental."
      This section has outdated information. NORM is now PS (RFC 5401), and FLUTE is almost there (IETF LC of draft-ietf-rmt-flute-revised is imminent). Reliable multicast is not experimental anymore.
      Section 3.3.2., paragraph 2: "it delivers data to its peer and provides acknowledgement to the sender, or it dies trying. It has extensions for Congestion Control [RFC5681] and Explicit Congestion Notification [RFC3168]."
      As well as many other extensions - it may be useful to cite RFC 4614 here.
      Section 3.3.2., paragraph 3: "For message-stream interfaces, we generally use the ISO Transport Service on TCP [RFC1006][RFC2126] in the application."
      Who is "we"? Is anyone really using RFC1006 and RFC2126?
      Section 3.3.2., paragraph 5: "Finally, note that TCP has been the subject of ongoing research and development since it was written. The End to End research group has published a Roadmap for TCP Specification Documents [RFC4614] to capture this history, to guide TCP implementors, and provide context for TCP researchers."
      RFC 4614 did not come out of end-to-end, it was a WG document in TCPM. And while it does capture some of the history and research aspects, the motivation was very much to be a "start reading here" document for implementors, similar in spirit to this I-D.
      Section 3.6.2., paragraph 8: "The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is being developed in IETF with these goals in mind."
      I'm surprised to see that COAP is only mentioned under resource discovery. While that's one aspect of it, the broader aspect is as an application/transport protocol for constraint environments. IMO it would make more sense to discuss COAP under Section 3.3 or 3.3.1.
      Section 4., paragraph 0: "4. A simplified view of the business architecture"
      At least to my mind, it would be a bit more logical to see this section merged into Section 2 or following it. (Also, it'd be nice to replace domain names and IP addresses in this section with ones from the "example" spaces.)
      Section 5., paragraph 1: "This memo asks the IANA for no new parameters."
      Although this document makes no requests from IANA, I wonder if the smartgrid guys know about the role that IANA plays in the standardization and administration of the IPS. Is there an IANA overview document that you could cite here for them to read?
      Section 8., paragraph 0: "8. References"
      Is there a logic to the split between normative and informative references?
      Appendix A., paragraph 1: "This appendix provides a worked example of the use of the Internet Protocol Suite in a network such as the Smart Grid's Advanced Metering Infrastructure (AMI). There are several possible models."
      I don't think this example is worked out enough to illustrate how the IPS can be applied here. There's a little bit of text about layer 3, and nothing at all about higher layers. I wonder if this material would be better split off into a standalone document for further development.
      Section 2.2., paragraph 1: "solutions to many Internet security problems have already exist."
      Nit: s/have//
      Section 2.2.1., paragraph 3: "For wirless transmission technologies eavesdropping on the"
      Nit: s/wirless/wireless/
      Section 3.2.3.1., paragraph 1: "Autoconfiguation enables various different models of network"
      Nit: s/Autoconfiguation/Autoconfiguration/
      Section 802.11, paragraph 0: "networks between various sensors in the home (e.g., betweeen the"
      Nit: s/betweeen/between/
    2. Adrian Farrel: Comment [2011-03-02]:
      Fine work.
      I should have liked to see some forward reference to the Appendix from early in the document since (I assume) the readers will find the Appendix quite useful and (although it is mentioned in the ToC) there is no other hint that it is there.
    3. Dan Romascanu: Discuss [2011-03-02]:
      Before I vote YES on this document I would suggest fixing a few obvious editorial problems. Fixes should be easy.
      1. Section 2.1.1 - please do not refer to [RFC1157] when speaking about SNMP. This one is Historical. Best would be to refer to [RFC3411] and remove the reference to 1157
      2. Section 2.1.3.2 - IEEE 802.16 is not a local wireless network - they define themselves as metropolitan wireless network
      3. Section 2.3.2 - remove the words 'and is a polled architecture' when refering to SNMP. This is not completely accurate and conflicts with what is written later in Section 3.5.1
    4. Tim Polk: Discuss [2011-03-03]:
      Two actionable discusses, one discuss-discuss:
      Actionable 1: Please add a brief section 3.1.5 Key Management Infrastructures to cover PKI (PKIX) and Kerberos. These are a very important building block in the security toolbox. I would suggest mentioning the DANE work in this section as well.
      Actionable 2: Please add a brief section 3.1.6 secure shell. This is another and widely used key building block.
      Discuss-discuss: I would have expected to see some discussion of SRTP and SRTCP, but neither RTP nor RTCP is mentioned. Was there a specific decision not to include these protocols? If so, excluding SRTP and SRTCP makes perfect sense.
    5. Tim Polk: Comment [2011-03-03]:
      technical comments:
      2.2: OLD: "While it is popular to complain about the security of the Internet, solutions to many popular Internet security problems have already exist."
      NEW: "While it is popular to complain about the security of the Internet, it is important to distinguish between attacks on protocols and attacks on user (e.g., phishing). Attacks on users are largely independent of protocol details, reflecting interface design issues or user education problems, and are out of scope for this document. Security problems with Internet protocols are in scope, of course, and can often be mitigated using existing security features already specified for the protocol, or by leveraging the security services offered by other IETF protocols."
      2.2.2: Append to the paragraph beginning "A number of mechanisms": "Another mechanism, specifically targeting the reset attack cited above, provides authentication services in TCP itself to ensure that fake resets are rejected."
      3.1: OLD: "It is important to highlight that in addition to the mentioned security tools every protocol often comes with additional, often unique security considerations that are very unique to the specific domain that protocol operates in."
      : "NEW: "It is important to highlight that in addition to the mentioned security tools every protocol often comes with additional, often unique security considerations that are very unique to the specific domain that protocol operates in. Many protocols include features specifically designed to mitigate these protocol-specific risks. In other cases, the security considerations will identify security-relevant services that are required from other network layers to achieve appropriate levels of security."
      3.1.2: [Note: The TLS section talks about negotiating parameters as suites, but the IKE section is silent. The following suggestion would be more complete and provide some parallelism.}
      OLD: "For the former step the Internet Key Exchange protocol version 2 (IKEv2 [RFC5996]) is the most recent edition of the standardized protocol."
      NEW: "For the former step, the Internet Key Exchange protocol version 2 (IKEv2 [RFC5996]) is the most recent edition of the standardized protocol. IKE negotiates each of the cryptographic algorithms that will be used to protect the data independently, somewhat like selecting items a la carte."
      3.1.2 penultimate paragraph: Please append:
      "Since ESP can also provide authenctication services, most recent protocol development making use of IPsec only specify use of ESP and do not use AH."
      3.1.3: Adding a reference to RFC 6090 in 3.1.3 would be good, e.g. "The basic cryptogaphic mechanims for ECC have been documented in RFC 6090." That could be added to the end of the 2nd last para in 3.1.3.
      3.1.4: CMS paragraph: Please append the following:
      "CMS has been leveraged to supply security services in a variety of protocols, including secure email [RFC5751], key management [RFC5958] and [RFC6031], and firmware updates [RFC4108]."
      Digitally signed XML paragraph: Please append the following:
      "Digitally signed XML is a good choice where applications natively support XML encoded data."
      Section 3.7: What about email, ftp, http? Do these have any application in this space?
      4. (current page 36): Firewalls are also common on end-hosts as well. This may be worth a mention in this section.
      editorial comments:
      2.1.3.2: s/can recursively subdivided/can be recursively subdivided/
      2.2: s/takes security serious/takes security seriously/
      s/provides recommendations how/provides recommendations on how/
      2.2.2: s/are round/exist/
      3. (last sentence): s/such analyzes/such analysis/
      3.1: s/we outline of/outline a/
      3.1.1: first sentence: s/The term/While the term/
      second Para: s/prior to access a/prior to accessing a/
    6. Dan Romascanu: Comment [2011-03-02]:
      1. [SmartGrid] - I am unconfortable to providing wikipedia references - not because I do not trust the principle of shared wisdom, but because they are unstable to my taste even for Informational References. If there is really nothing else around (even not from NIST?) I wouls suggest that at least we provide together with the reference a date when the quote was extracted from the wikipedia article
      2. It is not clear to me why from all applications possible section 3.7 selects exactly SIP and calendaring. Are these applications considered candidates to run on the Smart Grid more than other applications?
    7. Peter Saint-Andre: Comment [2011-03-02]:
      The introduction states: "Section 3 outlines the set of protocols that will be useful in Smart Grid deployment."
      Is this statement (*the* set of protocols) meant to imply that no other protocols might be useful in smart grid deployments? (Naturally, I know of several companies that have deployed XMPP quite widely for smart grid deployments, but I'm sure there are other protocols one could add to the set, as well.)
      Regarding Section 3.7.2, is calendaring really of strong interest or use in smart grid deployments?
    8. Robert Sparks: Discuss [2011-03-02]:
      1) Would it be possible (and would it preserve the intended meaning) to say "identifies the key infrastructure protocols of the Internet Protocol Suite" instead of just "the key protocols" in the introduction?
      2) Echoing 1) above, would text along these lines be acceptable for the introduction to section 3.7?
      "There are many applications that rely on the IP infrastructure, but are not properly thought of as part of the IP infrastructure itself. These applications may be useful in the context of the Smart Grid. The choices made when constructing a profile of the Internet Profile Suite may impact how such applications could be used. Two such protocols (not by any means an exhaustive list) are discussed here."
      3) The description of the impact of NATs on SIP needs tweaking. As it is, it implies the only way to work through NATs is for the NAT itself to be an ALG, modifying signaling packets, but the endpoints themselves can work (using tools like STUN) through SIP unaware NATs. SIP messaging itself does have an issue with NATs (see RFC5626, or draft-ietf-sipping-nat-scenarios). I suggest just noting that choosing to introduce NATs as part of the profile will increase the complexity of deploying SIP applications and point to 5626 for a discussion of the details.
    9. Sean Turner: Discuss [2011-03-03]:
      #1) Sec 2.2.2: How about we use CIA, Confidentiality, Integrity, and Availability (the classic model), and throw in Authenticity:
      At the network, transport, and application layers it is common to demand a few basic security requirements, commonly referred to as CIA (Confidentiality, Integrity, and Availability):
      1. Confidentiality: Protect the transmitted data from unauthorized disclosure (i.e., keep eavesdroppers from learning what was transmitted). For example, for trust in e-commerce applications credit card transactions are exchanged encrypted between the Web browser and a Web server.
      2. Integrity: Protect against unauthorized changes to exchanges, including both intentional change or destruction and accidental change or loss, by ensuring that changes to exchanges are detectable. It has two parts: one for the data and one for the peers.
      - Peers need to verify that information that appears to be from a trusted peer is in fact from that peer. This is typically called 'data origin authentication'.
      - Peers need to validate that the content of the data exchanged is unmodified. The term typically used for this property is data integrity.
      To this we add authenticity, which requires that the communicating peers prove that they are in fact who they say they are. One peer can prove to the other who they are (i.e., one-way authentication), but in general two-way (or mutual) authentication is best. Mutual authentication is performed at a minimum by using a) something the user knows and the b) something the user has. Single-factor authentication assumes the user knows their username and they have a secret (think password). Two-factor authentication assumes the user knows their password (typically to unlock a key stored on the token) and the user has a token (think smartcard). Multi-factor authentication adds a c) the user is (e.g., biometrics).
      #2) Section 2.2.2: Many times we say people say use TLS - we're done right. I think we should say something about hop-by-hop security vs end-to-end security.
      #3) How do we see OAUTH playing in this space? Should Kerberos be discussed?
      #4) Should we talk about TCP security (i.e., TCP-AO)?
      #5) Section 3.2 talks about routing. Should we discuss routing security as well?
    10. Sean Turner: Comment [2011-03-03]:
      #1) Politics layer is missing from Figure 1 ;)
      #2) <nit alert>r/"host./"host."</nit alert>
      #3) Could we point to SNMPv3 instead of v1? (i.e., something that's not historic)
      #4) Is it worth mention HIP at all or the concept of splitting the identifier and locator? It's experimental so maybe not.
      #5) Is it worth adding an informative reference to https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/ in 2.2.2 where it talks about TCP attacks/counter measures? Also maybe pointing to https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ for IP attacks/counter measures would be helpful.
      #6) Section 3.1.1: can we also add EAP-TLS: "For access to remote networks, such as enterprise networks, the ability to utilize EAP within IKEv2 [RFC5996] and within TLS [RFC5216] have also been developed."
      #7) While the Suite B IPsec profiles are near and dear to my heart, I'm not sure they need to be included in Sec 3.1.2.
      #8) Sec 3.1.3: It's probably worth noting that TLS supports hop-by-hop security and depending on the architecture this might not be end-to-end (i.e., TLS isn't one size fits all).
      #9) Sec 3.1.4: for truth in advertising: "The CMS can support a variety of architectures for key management included: certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [RFC5280], or symmetric key management."
      #10) Sec 3.1.4: Should also add that a variety of algorithms are supported: "CMS supports a number of algorithms: RSA, DSA, DH, ECDSA, and ECDH as well as the SHA family of algorithms."
      #11) Sections 3.1.2-3.1.4: When renaming 3.1.4 to "Application Security" makes me think that 3.1.2 should be called "Network Security" and 3.1.3 should be called "Transport Security". Then put SSH in 3.1.3 (maybe no need for a new 3.1.6 as Tim suggests). Could have two subsections.
      #12) I think this needs to be updated: "Note that since IPv4 free pool (the pool of available, unallocated IPv4 addresses) is almost exhausted,"

    Telechat:

  3. Test vectors for the stream cipher RC4 (Informational)
    draft-josefsson-rc4-test-vectors-02
    Token: Sean Turner
    Note: Simon Josefsson (simon@josefsson.org) is the Document Shepherd.
    Discusses/comments (from ballot 3699):
    1. (none)

    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)

3.3.3 For Action

  1. Survey of proposed use cases for the IPv6 flow label (Informational)
    draft-hu-flow-label-cases-03
    Token: Russ Housley
    Note: ISE submission

    Telechat:

1250 EST break

1255 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Verification Involving PSTN Reachability (VIPR)
    Token: Robert

    Telechat:

  2. Adddress Resolution for Massive Numbers of Hosts in the Data Center (ARMD)
    Token: Ron

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. DNS Extensions (DNSEXT)
    Token: Ralph

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IESG statement on MIME type registrations from other SDOs in the standards tree with no drafts (Alexey Melnikov)

    Telechat:

  2. Room during Prague IETF for HTTPBIS WG editors (Alexey Melnikov)

    Telechat:

  3. Trill WG charter (Ralph Droms)

    Telechat:

  4. IETF Stream Candidate for RSOC (Russ Housley)

    Telechat:

  5. Expert Reviewer for Kerberos Pre-authentication and Typed Data Registry (Tim Polk)

    Telechat:

7. Agenda Working Group News

1325 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-03-03 07:29:51 PST)

draft-ietf-netconf-rfc4742bis

  1. David Harrington: Discuss [2011-02-28]:
        1) 4741bis says: "The authentication process MUST result in an authenticated
    client
       identity whose permissions are known to the server.  The
    authenticated identity of a client is commonly referred to as the
       NETCONF
    username.  The algorithm used to derive the username is
       transport protocol
    specific and in addition specific to the
       authentication mechanism used by the
    transport protocol.  NETCONF
       transport protocols therefore MUST explain how a
    NETCONF username is
       derived from the authentication mechanisms supported by
    the transport
       protocol.
    
       The access permissions of a given client, identified by its NETCONF
       username, are part of the configuration of the NETCONF server.  These
       permissions MUST be enforced during the remainder of the NETCONF
       session.  The details how access control is configured is outside the
       scope of this document."
    
    4742bis says: "How the NETCONF Server extracts the SSH user name from the SSH
    layer
       is implementation-dependent."
    
    This is not an explanation. Assuming an operator must specify access control
    rights for a user in the configuration o fthe server, it is important that the
    operator understands what the netconf username(s) will be. That is presumably
    why it is important for the Netconf transport protocol specification to explain
    the algorithm for deriving the username.
    
    RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal with
    similar issues, including constraints about not changing the username associated
    with a session, allowing "user@host" style naming, etc.
    Maybe those are not
    needed for netconf, but the above "implementation-dependent" explanations seems
    woefully inadequate.
    
        
  2. David Harrington: Comment [2011-02-28]:
    1) The IANA section does not specify that the assigned port is a TCP port.
    should it?
  3. Alexey Melnikov: Discuss [2011-03-03]:
        In general I support publication of this document. However I would like to
    discuss the following issue before I can recommend its approval:
    
    1) I support David's DISCUSS about lack of information about username
    extraction. 
        
  4. Tim Polk: Comment [2011-03-02]:
    I suspect I am disclosing my lack of netconf clue, but here goes:
    
    Why is the example in section 4.2 (chunked encoding) declaring the base1.0
    namespace?  I thought that base1.1 support is required of both the server and
    client to use chunked encoding...
  5. Peter Saint-Andre: Comment [2011-03-02]:
    
        
  6. Sean Turner: Comment [2011-03-02]:
    This is updated to add two new comments from the SECDIR review.
    
    #1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be
    a "MUST"?
    
    #2) Sec 4.2: Would any XML decoding error cause termination as stated at the end
    of 4.2? E.g. some unknown xmlns value or something?
    
    #3) If it's worth changing the framing protocol at all, which I'm willing to
    accept as a given, it is far from obvious to me that the current negotiated
    upgrade is the right way to do it, as this will require implementation of the
    old bad mechanism forever.  Switching to a new SSH subsystem name seems like a
    much simpler solution.
    
    #4) As a matter of stylistic consistency with the last several decades of
    Internet protocols, the delimiter sequence in the new framing protocol should
    have been <CRLF>, not <LF>.

draft-ietf-netconf-4741bis

  1. Ron Bonica: Comment [2011-03-01]:
    Rob Enns has left Juniper Networks. We need an updated affiliation for him.
  2. Lars Eggert: Comment [2011-03-01]:
    Section 2 should have a requirement that NETCONF transport that are to be used
    over the Internet MUST implement congestion control, in accordance with RFC2914.
    It can also simply note that all NETCONF transports that use TCP (such as the
    SSH transport) automatically fulfill this requirement.
    
    (This really is a no-brainer. I just want to prevent a future argument when
    someone wants to do a "lightweight" NETCONF transport over UDP...)
  3. Adrian Farrel: Comment [2011-03-02]:
    I am entering a No Objection position on the basis of the Yes ballots fromt the
    Ops ADs.
    
    Appendix C seems to claim that "this value is pre-determined by RFC 4741" but
    since 4741 is now obsoleted (by this document) you should find some new text.
  4. David Harrington: Discuss [2011-03-01]:
        1) should there be constraints on the basic format of username? if it is
    expected to be specified by an operator in config files or databases, should it
    be human-readable? ascii? utf-8?
    
    2) should the format be predictable, so the operator can determine what the NC
    username will be, given a knowledge of the corresponding identifier in the
    secure transport protocol?
    
    3) commit MUST revert at 600 secs, but timeout is configurable., what if
    somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout
    cause a denial of service? 
        
  5. David Harrington: Comment [2011-03-01]:
    1) copyright in yang module needs updating.
    
    2) appendix F doesn't mention dropping the local file requirement for URLs, 
    
    3) terminology should probably define username, not user. It is doubtful
    username is commonly referred, since it did not exist in 1.0.
    
    4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can"
    probbaly should have been MAY. Some uses of "are" probbaly should have been
    MUST, to ensure interoperability.
    
    5) I support Lars' Discuss. There is no requirement to use a transport protocol
    that provides congestion control. If a transport is used that does not already
    provide congestion control, then the NC transport should provide congestion
    control. It is RECOMMENDED to use an existing transprt standard that provides
    congestion control.
  6. Russ Housley: Comment [2011-03-01]:
      Please add a sentence to the Abstract that indicates that this
      document obsoletes RFC 4741.
  7. Tim Polk: Comment [2011-03-02]:
    (1)
    
    2.2.  paragraph 1 - last sentence is awkward.   In general connections are
    encrypted "in" an algorithm (e.g., AES) or "using" a protocol (e.g., TLS).
    Suggest:
    
    s/encrypted in TLS [16] or SSH [14]/encrypted using TLS [16] or SSH [14]/
    
    (2)
    
    3.1.  Namespace
    
    Should this text reference the namespace base:1.1 instead of base:1.0 ??
    
    (3)
    
    The example in 6.2.2 Attribute Match Expressions references containment nodes
    and selection nodes, which are described in 6.2.3 and 6.2.4, respectively.
    
    It might be cleaner to reorder as 6.2.2 Containment Nodes, 6.2.3 Selection
    Nodes,
    and 6.2.4 Attribute Match Expressions so that concepts are introduced
    sequentially
    
    (4)
    
    Section 8.1  The following sentence implies that clients can attack other
    sessions
    by guessing session-ids:
    
    A server receiving a <session-id> element MUST close the NETCONF
       session.
    
    I believe the intent was as follows:
    
    A server receiving a <hello> element that includes a <session-id> element
    MUST ignore the session-id and close the NETCONF session.
    
    If that is the intent, I suggest the latter wording.
    
    (5)
    
    Section 9.  Security Considerations, paragraph five states:
    
       Configuration information is by its very nature sensitive.  Its
       transmission in the clear and without integrity checking leaves
       devices open to classic eavesdropping attacks.  Configuration
       information often contains passwords, user names, service
       descriptions, and topological information, all of which are
       sensitive.  Because of this, this protocol SHOULD be implemented
       carefully with adequate attention to all manner of attack one might
       expect to experience with other management interfaces.
    
    The clause "and without integrity checking" is not relevant to eavesdropping
    attacks.
    Suggest:
    
    s/classic eavesdropping attacks/classic eavesdropping and false data injection
    attacks/
    
    
  8. Peter Saint-Andre: Comment [2011-03-02]:
    1. DTDs are forbidden (presumably you mean internal or external DTD subsets in
    accordance with section 2.8 of the XML specification). What about comments,
    processing instructions, and internal or external entity references?
    
    2. In Section 6.2.5, 'for which the <name> element is equal to "fred"' is more
    precisely expressed as 'for which XML character data of the <name> element is
    equal to "fred"'. (The same text occurs in Section 6.4.5.)
    
    3. Section 6.4.3 states:
    
       In a real data model, the <company-info> would not
       likely be returned with the list of users for a particular host or
       network.
    
    Why not?
    
    4. In Section 7.5, is the server allowed to terminate a lock for reasons other
    than session closure? If not, it appears than an entity could maintain a lock
    indefinitely.
    
    5. In Appendix B, it seems that some of the enumerated datatypes could be
    changed from xs:string to something more restrictive, such as xs:NMTOKEN (e.g.,
    error types, error tags, error severity, edit operation type).

draft-ietf-hokey-ldn-discovery

  1. Jari Arkko: Comment [2011-03-03]:
    I agree with others that the document must be changed so that its title,
    abstract, and the option name match the use for ERP. This is not about general
    domains (e.g., DNS).
  2. Ralph Droms: Comment [2011-03-01]:
    Small suggestion for clarity: s/EAP domain/domain/
    in the Abstract., for those of us who leap to associating
    "domain" with "DNS"...
  3. Adrian Farrel: Comment [2011-03-01]:
    Acronyms need to be expaneded on first use in the body of the document. 
    For example, EAP, DSRK, etc.
  4. Peter Saint-Andre: Discuss [2011-03-02]:
        [Updated 2011-03-02 to reference the apps-review team review by Eliot Lear.]
    
    1. The reference to RFC 3315, along with the lack of a reference to RFC 5891,
    seems to imply that internationalized domain names are not supported. If so,
    please make that clear in the specification.
    
    2. The apps-review team review raised the following major issues:
    
       The option specified in this draft is to be used for the specific
       purpose of ERP, and may not be appropriate for other uses, such as use
       in a search list.  See Section 2 of RFC 5296.  Both the option name and
       the text should make this clear.
    
       While this is an Applications Area review, the Security Considerations
       section should still conform to the requirements of RFC 3552.
     
        
  5. Peter Saint-Andre: Comment [2011-03-02]:
    1. Please spell out FQDN and other relevant acronyms (e.g., perhaps AAA) on
    first use.
    
    2. Section 5 has "DHPv6" instead of "DHCPv6".
    
    3. The apps-review team review raised the following issue:
    
       This document also specifies a length limitation of 256 octets that does
       not take into account issues raised by RFC 4282.  My recommendation
       would be to either match or reference the text in RFC 4282.
    
  6. Sean Turner: Discuss [2011-03-01]:
        #1)  Is there no way that a relay agent might be acting on behalf of many
    domains without knowing? If so, then section 5 may need a few more words.
    
    #2) Section 6 says authentication is needed. I assume it's mutual
    authentication, but this should be explicitly stated.
    
    #3) Section 6, for how long must replays be detected? (And by whom?) How can
    that be done? (E.g. for a mobile device) 
        
  7. Sean Turner: Comment [2011-03-01]:
    #1) In the security considerations can you say something more about what happens
    if mutual authentication is not performed.
    
    #2) Section 5 should indicate why the DHCPv6 relay should include the LDN.
    
    #3) Sec 3: Can this option be used other than "after full EAP authentication"?
    Either way, just say so.

draft-ietf-payload-rfc4695-bis

  1. Adrian Farrel: Discuss [2011-03-01]:
        An easy Discuss that can be resolved with just a few words.
    
    idnits points out...
      -- The draft header indicates that this document obsoletes RFC4695, 
         but the abstract doesn't seem to mention this, which it should.
    
    It should also be discussed in the Introduction.
    
    I would also say that Appendix F (changes from 4695) should be pulled
    back into the body of the document, but this is not important.
    
    (See also the Comment from Russ Housley) 
        
  2. Adrian Farrel: Comment [2011-03-01]:
    Section 1.2
    
       In this document, the packet bitfields that share a common name often
       have identical semantics.
    
    This left me wondering how I find the cases where they have common names
    but different semantics.
  3. Russ Housley: Comment [2011-03-01]:
      Please add a sentence to the Abstract that indicates that this
      document obsoletes RFC 4695.
  4. Alexey Melnikov: Discuss [2011-03-03]:
        My apologies for spending so little time to review this document, but the
    following things caught my attention:
    
    1).
    11.  IANA Considerations
    
    This document does not change any of the registrations in RFC 4695.
    Therefore, this document does not require any IANA actions, apart from
    updating the references to RFC 4695 to point to this document.
    
    I don't think this is Ok. Please correct me if I am wrong, but this document has
    updated ABNF for various parameters specified in RFC 4695. This clearly updates
    the MIME type registration.
    
    I think the right thing to do here is to keep the MIME type registration from
    RFC 4695 in this document.
    
    2). Somewhat related to #1: RFC 4695 registers audio/mpeg4-generic MIME type.
    
    audio/mpeg4-generic MIME type registration on 
    <http://www.iana.org/assignments
    /media-types/audio/index.html> doesn't point to
    RFC 4695 or this draft. This
    seems to be an omission.
    And again, correct me if I am wrong, but it looks like
    the MIME type registration is implicitly updated due to changes to the ABNF of
    various MIME type parameters.
    
        
  5. Alexey Melnikov: Comment [2011-03-03]:
       [RFC2818]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
    
    This reference needs to be Normative. No extra IETF LC is needed to make this
    change, as this RFC is already in the DownRef registry.
    
    Because this is a -bis document, I am entering the following issues as Comment-
    level (as opposed to DISCUSS-level), however I would like to ask to serious
    consider fixing these as well:
    
    D.  Parameter Syntax Definitions
    
       mime-type          = "audio" / "application"
       mime-subtype       = token
                          ;
                          ; See Appendix C.6.2 for registration
                          ; requirements for rinit type/subtypes.
    
    The mime-subtype definition should be pointing to the definition in RFC 4288,
    Section 4.2:
    
    4.2.  Naming Requirements
    
           type-name = reg-name
           subtype-name = reg-name
    
           reg-name = 1*127reg-name-chars
           reg-name-chars = ALPHA / DIGIT / "!" /
                           "#" / "$" / "&" / "." /
                           "+" / "-" / "^" / "_"
    
    In RFC 4695:
    
    11.3.  asc Media Type Registration
    
       Media type name:
    
           audio
    
       Subtype name:
    
           asc
    
     [...]
    
       Restrictions on usage:
    
           This type is only defined for data object (stored file)
           transfer.  The most common transports for the type are
           HTTP and SMTP.
    
    And there is no registered file extension? I think this is a serious omission
    for something which can be stored in a file.
    
  6. Dan Romascanu: Comment [2011-03-02]:
    In the IANA Considerations Section: 
    
    > This document does not change any of the registrations in RFC 4695.
    Therefore, this document does not require any IANA actions, apart from
    updating the references to RFC 4695 to point to this document.
    
    It looks to me that both documents (this one and RFC 4695) need to be referenced
    in the IANA pages. The reason is that while this document obsolets RFC 4695 it
    does not carry the text that refers to the creation of the registries.
  7. Sean Turner: Comment [2011-03-01]:
    #1) Since this is a bis document, I presume it's been used for a while.  Maybe
    the tense should change in intro to reflect this? Likewise, the original premise
    of 4965 was to allow musicians to be in different locations but still jam
    together - did it work?

draft-ietf-sipcore-199

  1. Lars Eggert: Comment [2010-02-02]:
    INTRODUCTION, paragraph 2:
    >            Response Code for Indication of Terminated Dialog
    
      Add something to the title that makes it clear this is for SIP?
    
    Section 3., paragraph 1:
    >    REQ 1: It must be possible to indicate to the UAC that an early
    >    dialog has been terminated before a final response is sent.
    
      I don't understand the purpose of including this single requirement in
      this specification document. At least not without further explanation.
  2. Adrian Farrel: Comment [2010-02-02]:
    The document does not say what track it is targeting. I assume from the
    ballot that it is intended as Standards Track. Please can you confirm 
    and update the document header.
    
    The abbreviations UAC and UAS will need to be expanded in the Abstract
    and on first usage in the body text.
  3. Russ Housley: Comment [2010-01-29]:
      The Gen-ART Review by Avshalom Houri on 26 Jan 2010 suggested adding
      references to other relevant RFCs in the Security Considerations.  A
      few editorial changes were suggested.  Please consider these changes.
  4. Cullen Jennings: Discuss [2010-02-04]:
        
    The draft needs to be explicitly clear about what conditions it helps in. The
    current text is not clear enough given that many people end up debating it and
    or confused. I think this is just a matter of getting more explicitly about
    these points and deleting any ones where it is not clear exactly what cases it
    helps in. We just need to get these to the point where it is clear that they are
    factually correct.
    
    1.  Codec release - when resources for a specific codec has been
      reserved only for the stream that is terminated.  In that case the
      resources associated with that codec can be released.
    
    I don't understand what resource is released. On some very old large gateways
    that loaded codecs into the DSP du to DSP memory limitations, I understand what
    codec released means but that does not make sense in this context. Please
    explain in email what gets released and in what real world scenarios this occurs
    then we can sort out what the draft needs to say. I obviously consider mobile
    batter operated devices over wireless to be very important use cases.
    
      2.  Pre-conditions - when the dialog is terminated, procedures and
      resources associated to the pre-conditions for that dialog can be
      released.
    
    Please clarify this to around the allocated bandwidth. I would also like to
    understand in what real world scenarios this is going to result in additional
    dialogs being set up once the bandwidth becomes available. You need to walk me
    through a scenario of how this is going to work.
    
      3.  In-band security negotiation - when the dialog is terminated,
      procedures and resources associated with the in-band security
      negotiation for that dialog can be released.
    
    Ditto on this. 
    
    You wrote "[Christer] Whatever procedures takes place on the media plane in
    order to establish the security associated, and resources reserved in order to
    deal (encrypt/decrypt) with the secure media itself." I still don't understand
    what resources. Jari said that if a slow UA was still trying to set up a
    security associations by the time the 199 arrived, this could allow it to stop
    that and it might take a long time due to CPU speed and doing PKi computations.
    If this is what you mean, I'd be interested in understanding when that might
    happen. It does make sense but I don't understand when it would occur.
    
      4.  ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
      terminated, procedures and resources associated with the ICE related
      in-band procedures for that dialog can be released.
    
    In email you mentioned that it is the sending of keep alives that can be
    stopped. This is a good answer and makes sense. Can you update the text to say
    that and also mention how frequently they are sent and what sort of scenarios
    benefit from this optimization.
    
      5.  Limited access resources - in case of forking and multiple stream
      it may not be possible to allow early media on all dialogs, so media
      sessions associated with some dialogs may e.g. be set to "inactive".
      When a dialog is terminated, media sessions associated with other
      dialogs can be allowed.
    
    From email "[Christer] The probably most common scenario is when an application
    server in the network creates an early dialog with the UA in order to send an
    announcement, while the INVITE is forwarded towards the remote UA(s). There are
    specified procedures (in TISPAN and 3GPP) where this occur, and I believe this
    mechanism has also been discussed on the IETF SIP lists."
    
    Can you help educate me about theses a bit more. The ones I saw before involved
    the announcement finishing before the PSTN got the call.
    
      6.  Secure media selection - when SRTP is used to encrypt the media.
    
    I'm still not following what this allows that would not be otherwise possible
    without the 199. I did read the Note about SRTP.
    
    I'm not understanding why 199 allows the SBC to do something it can not do today
    in the section where latching is discussed.  Typically "Latching" in SBC is not
    at all what you describe here. It is the process by which an SBC decide to send
    RTP to a IP address that is different than what is in the SDP. Can walk me
    through in email what is going on propose some text.
    
    In  the case of early ring tone termination where say a PSTN gateway roles over
    to voicemail, I don't see who this will accelerate the move in any useful way
    from the PSTN ringback tone to the voicemail server media.
    
    I see no reason to allow this in a Require or proxy-Require and think that
    should be a MUST NOT. As you can tell, I think the value of this draft is
    somewhat limited but I am OK with publishing it as long as it does no harm. I
    view adding a require or proxy-require as something that would reduce
    interoperability of SIP call in a significant way and thus be harmful. I am very
    unlikely to be convinced to change my position on this one but I would be happy
    to hear concrete reasons why this needs to be a SHOULD.
    
    It's unclear to me what Reason code to insert or why this is a MUST. The reason
    code seems non necessary for the describes uses of this mechanism. I read your
    email and it did not help me understand why the Reason was mandated. Mandating
    things that are not needed and can be separated seldom turns out to be good [as
    you rightly pointed out in putting the keep-alives in the same draft as rest of
    outbound]. Unless there is a compelling technical reason for this we should not
    do it.
    
    The actual specification of how you deal with SDP in a 199 containing an offer
    is probably all correct in the draft but it is very difficult to understand the
    logic that lead to this and what one is supposed to do. Could you rephrase it be
    clear on exactly how this interacts with invites with no offer and explain why
    it needs to work the way it does.
    
    The not sending things reliably that have a Require: 100rel seems like it will
    break some IDS, firewalls, and middles boxes that are expecting any 1xx to
    reliable since that was signaled. I'd like to see text that helped explain this.
    I'm not asking you to change this - I am asking to discuss and point out the
    implications of if.
    
    I would like to see it very clear in the document at if you receive SDP in a
    199, the UA MUST ceases sending all media on the RTP streams associated with
    that dialog. I would not want this to be used in an attack where one could send
    an an authenticated 199 and cause devices to star sending media to random 3rd
    parties that showed up in the SDP.
    
    I imagine more than one of these thing may just be talking past each other so
    I'm glad to have a phone call if that helps clear any of this up. I'm sure some
    rounds of email will be needed. 
        
  5. Cullen Jennings: Comment [2010-02-04]:
    
        
  6. Alexey Melnikov: Comment [2011-03-03]:
    I agree that Experimental for this document is going to be better.
    
    I don't think the document is doing a very good job convincing readers about
    utility of this mechanism. At least not until it starts describing detailed use
    cases.
    
    4.1.  Examples of resource types
    
       NOTE: When using SRTP [RFC3711], the secure media stream is bound to
       the crypto context setup for the dialog, and can be identified using
       the MKI (if used) of SRTP.
    
    Please expand the acronym on first use.
    
       If the client only has a single early dialog (other early dialogs MAY
       not have been established, or they MAY have been established and
    
    It doesn't look like use of these 2 MAYs is correct - they don't describe
    requirements.
    
       later terminated) and a 199 response is received for that early
       dialog, the client terminates the early dialog.  Afterwards, the
       client SHOULD act as before the first early dialog was established.
    
    4.2.  Examples of policy procedures
    
       2.  SBC early media selection - when an SBC is used to control which
    
    Please expand the acronym on first use.
    
       media is processed and forwarded.  In many cases, the SBC only
       processes media associated with a single early dialog.  Typical for
       NAT traversal, the SBC often "latches" onto a media stream.  If a 199
       response is received, the SBC can choose to start processing media
       associated with another dialog.  If the SBC performs latching, it can
       trigger a "re-latch" onto a new media stream when the 199 response is
       received.
    
  7. Tim Polk: Comment [2010-02-03]:
    Section 1 states
    
       The 199 response code is an optimization, which allows the UAC to be
       informed about terminated early dialogs.  However, since the support
       of the 199 response is optional, a UAC cannot assume that it will
       always receive a 199 provisional response for all terminated early
       dialogs.
    
    Section 4 seems to imply that there are some applications that will not work
    unless 199
    is supported:
    
     The UAC SHOULD NOT insert the 199 option-
       tag in the Require header, unless the particular session usage
       requires the UAS to support the response code.  Also, the UAC SHOULD
       NOT insert the 199 option-tag in the Proxy-Require header, unless the
       particular session usage requires every proxy on the path to support
       the response code.
    
    Are these two sections in conflict?
  8. Peter Saint-Andre: Comment [2011-03-01]:
    The introduction is difficult to understand. It would be helpful to provide a
    picture of the scenario that motivates this document, or at least to provide a
    forward reference to the "swim lane" diagrams in Section 9.
  9. Robert Sparks: Comment [2010-04-13]:
    
        
  10. Sean Turner: Comment [2011-03-02]:
    #1) Sec 1: Can you provide an example of policy related decision?
    
       In addition, SIP entities might also use the 199 response to make
       policy related decisions related to early dialogs.
    
    #2) Sec 5: This is a little hard to parse (it's all one sentence):
    
       If a UAS receives an initial dialog initiation request, with a
       Supported header field that contains a "199" option-tag, it SHOULD
       NOT send a 199 response on an early dialog associated with the
       request, before it sends a non-2xx final response, unless it e.g. has
       been configured to do so due to lack of support of the 199 response
       code by forking proxies or other intermediate SIP entities, or it is
       used in an environment that specifies that it shall send a 199
       response before sending a non-2xx response.
    
    #3) I'm trying to reconcile the statement in the 2nd to last para of Sec 5,
    which says that the 199 is only for informational purposes, with the MUST NOT In
    the last paragraph.  If it's informational then why is it a MUST NOT?

draft-bryan-metalinkhttp

  1. Ralph Droms: Comment [2011-03-03]:
    I've cleared my DISCUSS.
    
    1) Resolved.
    
    2) Is there a registry for the various attributes references in this
    document, including "pri", "pref", "geo", etc.?  If not, in my opinion
    it would be beneficial to give a list and some formal definitions of
    the attriubtes; at least, some indication that the attributes are
    defined in this document.
    
    (added 2011/3/3) The latest rev almost resolves this comment.  My
    remaining comment is admittedly pedantic and just a nit, based on
    avoiding the use of passive voice:
    
       The following OPTIONAL attributes are defined:
    
        o  "depth" : mirror depth in Section 3.4.
        o  "geo" : mirror geographical location in Section 3.2.
        o  "pref" : a preferred mirror server in Section 3.3.
        o  "pri" : mirror priority in Section 3.1.
    
    Is this text the authoritative definition for the OPTIONAL attributes
    or are they defined somewhere else and the definitions repeated here?
    
  2. Lars Eggert: Discuss [2011-02-15]:
        INTRODUCTION, paragraph 4:
    >    This document specifies Metalink/HTTP: Mirrors and Cryptographic
    >    Hashes in HTTP header fields, a different way to get information that
    >    is usually contained in the Metalink XML-based download description
    >    format.  Metalink/HTTP describes multiple download locations
    >    (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures,
    >    and other information using existing standards for HTTP header
    >    fields.  Clients can use this information to make file transfers more
    >    robust and reliable.
    
      DISCUSS: The document title and this summary aren't really accurate.
      In addition to describing how to store Metalink info in HTTP header
      fields, a large part of the document (Section 7) is actually
      specifying how Metalink clients MUST/SHOULD/MAY operate.
    
    Section 3.3., paragraph 1:
    >    There are two types of mirror servers: preferred and normal.
    >    Preferred mirror servers are HTTP mirror servers that MUST share the
    >    same ETag policy as the originating Metalink server and/or MUST
    >    provide Instance Digests using the same algorithm as the Metalink
    >    server.
    
      DISCUSS: Section 1 said "SHOULD share the same ETag policy" - which is
      it?
    
    Section 7., paragraph 13:
    >    If the object is large and gets delivered slower than expected, then
    >    the Metalink client MAY start a number of parallel ranged downloads
    >    (one per selected mirror server other than the first) using mirrors
    >    provided by the Link header fields with "duplicate" relation type.
    >    Metalink clients SHOULD use the location of the original GET request
    >    in the "Referer" header field for these ranged requests.
    
      DISCUSS: I realize that this spec doesn't really cover the client, but
      I find this description of permitted client operation problematic.
      What it basically says is "if the download is slow, open more
      connections." This is NOT a good general practice. There need to be
      limits on the number of parallel connections, ideally based on
      observing how the aggregate throughput changes as connections are
      opened - blindly opening connections once the path bottleneck is
      filled is pointless. (There is some text later in this section that
      goes in this direction, but not far enough.)
     
        
  3. Lars Eggert: Comment [2011-02-15]:
    Section 3.2., paragraph 1:
    >    Entries for a mirror servers can have a "geo" value, which is a
    >    [ISO3166-1] alpha-2 two letter country code for the geographical
    >    location of the physical server the URI is used to access.  A client
    >    can use this information to select a mirror, or set of mirrors, that
    >    are geographically near (if the client has access to such
    >    information), with the aim of reducing network load at inter-country
    >    bottlenecks.
    
      s/can/MAY/? The document is generally pretty sloppy in its use of
      RFC2119 terms; it would be very good if the authors would go over it
      once more.
    
    Section 4., paragraph 1:
    >    Entries for metainfo files, which describe ways to download a file
    >    over Peer-to-Peer networks or otherwise, are specified with the Link
    >    header fields [RFC5988] and a relation type of "describedby" and a
    >    type parameter that indicates the MIME type of the metadata available
    >    at the URI.  Since metainfo files can sometimes describe multiple
    >    files, or the filename may not be the same on the Metalink server and
    >    in the metainfo file but still have the same content, an optional
    >    name parameter can be used.
    
      s/optional/OPTIONAL/ and/or s/may/MAY/
    
    Section 4.1., paragraph 1:
    >    Full Metalink/XML files for a given resource can be specified as
    >    shown in the example in Section 4.
    
      Specify-by-example isn't how things are usually done in the IETF.
      It would be good to have an actual specification.
  4. Adrian Farrel: Comment [2011-03-01]:
    Section 1...
    
    "extremely minimal" means what? It either minimal or it isn't.
    
    ---
    
    Section 3.1
    
       Entries for mirror servers are listed in order of priority (from most
       preferred to least) or have a "pri" value, where mirrors with lower
       values are used first.
    
       This is purely an expression of the server's preferences; it is up to
       the client what it does with this information, particularly with
       reference to how many servers to use at any one time.
    
    There is a contradiction between "are used first" and the second
    paragraph that says the client can do what it likes. Maybe the word
    "priority" and the "pri" value are poor choices since they reflect only
    a preference.
    
  5. Alexey Melnikov: Discuss [2011-03-02]:
        From the GenArt review:
    
    Also, is there a risk the initial server could cause a loop by pointing to
    _itself_? 
        
  6. Alexey Melnikov: Comment [2011-03-01]:
    
        
  7. Tim Polk: Comment [2011-02-16]:
    I support Sean's discuss on signature formats.  There is nothing wrong with
    OpenPGP, and it would be fine to make that the mandatory to implement, but the
    installed base with X.509 would seem to justify including S/MIME signatures.
    
    I also share Robert's and Peter's concerns about amplification and DoS attacks.
  8. Dan Romascanu: Comment [2011-03-02]:
    1. If the draft is based on the experiences made in a project the community
    would like to know more on the project. It would be good to mention in the
    Introduction section of the draft the open source project, what it does and the
    experience made based on the project, and also provide a reference to the
    project in the references section.
    
    2. The document does not have a Terminology and Abreviations section, which
    would be very useful to make it more readable
    
    
  9. Robert Sparks: Comment [2011-03-01]:
    (I'm moving these points to a comment based on -21 and the email conversation
    that followed. The changes discussed
    in that email thread will satisfy these
    points.)
    
    1) What prevents a malicious server from returning a 200 with many Link:
    headers, all indicating rel=duplicate, perhaps indicating non-overlapping
    subsets of the entity, and all pointing to a victim, driving many, possibly
    parallel, connection attempts?
    
    2) When a Link (indicating an HTTP resource) is followed, does anything prevent
    that referenced server from also replying with MetaLink headers in its response?
    If not, what prevents loops, intentionally or unintentionally created, from
    being followed? If a client would automatically follow these, especially in
    parallel, exponential attacks against the victims in item 1) are possible.  At
    the very least, a client could be sent into an infinite ping-pong loop.
  10. Sean Turner: Comment [2011-02-28]:
    
      

draft-ietf-shim6-multihome-shim-api

  1. Ralph Droms: Discuss [2011-03-01]:
        The description of SHIM_LOC_LOCAL_PREF in section 6.4 is unclear to
    me.  Does this mecahnism set the preferred local locator or the
    preference values (lc_prio and lc_weight) on a local locator?  Does it
    get the currently preferred locator or the preference values for the
    specified locator?  The same questions apply to section 6.5.
    
    lc_proto is not specified in any of the examples in section 6, while
    lc_ifidx and lc_flags are explicitly set to 0 even in the cases where
    they are not used (e.g., section 6.4).  Is lc_proto a "don't care";
    does it need to be set to 0 to show no NAT is involved; is it set to a
    non-zero value to indicate a NAT will be traversed?
    
    In section 8:
    
       lc_proto
          Internet Protocol number for the protocol which is used to handle
          locator behind NAT.  Typically, this value is set as UDP (17) when
          the locator is a UDP encapsulation interface.
    
    What is the value of lc_proto if the locator is not behind a NAT, or
    is there some other way to indicate that the lcoator is not behind a
    NAT?  "Typically" is imprecise; if the value is not always
    IPPROTO_UDP, where are the values formally defined?
    
    Also in section 8:
    
       lc_addr
          Contains the locator.  In the case where a locator whose size is
          smaller than 16 bytes, an encoding rule should be provided for
          each locator of a given address family.  For instance, in case of
          AF_INET (IPv4), the locator should be in the format of an IPv4-
          mapped IPv6 address as defined in [RFC4291].
    
    Why not "must be provided"?  Where are these encoding rules provided?
    Why not "in case of AF_INET (IPv4), the locator is encoded in the
    format of [...]"
    
    Still in section 8:
    
       lc_ifidx
          Interface index of the network interface to which the locator is
          assigned.  This field is only used in a read (getsockopt())
          operation.
    
    But the example in section 6.8 seems to indicate the use of lc.ifidx
    with setsockopt().  I recommend dopping the last sentence here in
    section 8 and leaving the explanation of the use of lc_ifidx (and
    lc_flags, which also appears to be unused in some setsockopt() calls)
    to the specific specifications in section 6. 
        
  2. Ralph Droms: Comment [2011-03-01]:
    The fourth and fifth paragraphs of the Introduction would fit better
    someplace else; perhaps in section 2, renamed "Terminology and
    Background".
    
    In section 5, what is a "context"?
    
    Third bullet in section 5: s/Notification from
    applications/Notification from applications and upper layer protocols/
    (for consistency throughout the text of this bullet).
    
    (Nit) Fifth bullet in section 5: s/for the/for a/
    (Clarification) "The host" seems imprecise; is it really the shim
    sub-layer that makes the substitution? 
    
    Ninth bullet: define "deferred context" (as well as "context"?) in
    section 3. 
    
    In the description of SHIM_ASSOCIATED, I suggest leaving out the
    specific parameter values (0/1), as those values are specified in
    section 6.1; in fact, there appears to be a third value specified for
    SHIM_ASSOCIATED (2) in section 6.1 that is not mentioned in the
    earlier description.
    
    The indication of which parameters are unused in a given setsockopt()
    call, as in this text from section 6.4:
    
       Note that some members of the
       shim_locator (lc_ifidx and lc_flags) are ignored in the set
       operation.
    
    is not consistently specified in section 6.1-14.
    
    The word "placeholder" seems unnecessary at the beginning of
    section 8.1.  Why not just call it a "data structure"?
    
    8.1.  Data structure for Locator Information
    
       As defined in Section 6, the SHIM_LOC_*_PREF, SHIM_LOC_*_SEND, and
       SHIM_LOCLIST_* socket options need to handle one or more locator
       information.  Locator information includes not only the locator
       itself but also additional information about the locator which is
       useful for locator management.
    
       Figure 4 illustrates [...]
    
    Also, for readability, perhaps s/locatior information/locator
    information block/ ?
    
  3. Lars Eggert: Discuss [2011-03-01]:
        Section 5., paragraph 2:
    >    o  Providing locator information to applications.  An application
    >       should be able to obtain information about the locator pair which
    >       was actually used to send or receive the packet.
    
      DISCUSS: What do you mean by "the packet"? Applications see sockets
      out of which they read data. With UDP, you could add a sockopt to get
      information about the last packet sent or received, but with TCP, I
      don't see how this is supposed to work? Or do you mean the addresses
      the shim layer is currently using for the socket?
    
    Section 6.2., paragraph 3:
    >    Default value is set as 0, which means that the shim sub-layer
    >    performs identifier/locator adaptation if available.
    
      DISCUSS: I don't think an Informational API document is the place to
      specify mandatory default protocol behavior. (If this default behavior
      is in the protocol specification, please rephrase this and refer to
      the text there.) Note that there are several sections below (6.3,
      6.12, etc.) that define "default" protocol behavior, and this issue
      occurs whenever the default value for an option turns protocol
      behavior on or off (i.e., it doesn't apply in cases where the default
      merely affects the behavior of the API itself.)
    
    Section 8.2., paragraph 0:
    > 8.2.  Path Exploration Parameter
    
      DISCUSS: This section needs to use a RFC2119 MUST whenever it talks
      about what do do with parameters from RFC5334. It's not up to an
      Informational API document to weaken what is mandated there.
     
        
  4. Lars Eggert: Comment [2011-03-01]:
    Section 2., paragraph 1:
    >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    >    document are to be interpreted as described in [RFC2119].
    
      This document is very inconsistent with its use of RFC2119 terms.
      There are many lower-case instances of those terms that I think should
      be capitalized. There are other cases where wording changes to use
      RFC2119 terms would clarify things.
    
    Section 6., paragraph 0:
    > 6.  Socket Options for Multihoming Shim Sub-layer
    
      In many of the subsections under Section 6 that discuss the individual
      options, the explanatory text doesn't always explicitly state if what
      is being described is when an option is used with setsockopt vs. with
      getsockopt. The (unstated) default seems to assume setsockopt. It
      would be very good to explicitly clarify this, maybe even by
      explicitly adding subsections for set and get under each.
  5. Sean Turner: Comment [2011-03-02]:
    #1) Why assume only one shim sub-layer is active at a time?  Wouldn't the most
    useful thing for this API to work when WiFi and GSM data are both usable? (Or
    maybe I'm misunderstanding the text.) In any case, it'd be useful to say why
    handling both being active is hard or out of scope.
    
    #2) I'm curious why there are no requirements to expose security related
    information, esp IPsec? If it's available wouldn't it be good to provide that?

draft-ietf-speermint-voipthreats

  1. Alexey Melnikov: Discuss [2011-03-02]:
        (I am likely to clear this DISCUSS after some discussion with the editors)
    
    4.2.  DNSSEC
    
       DNSSEC has not seen wide deployment on the Internet (due to various
       reasons which are out of the scope of this document).
    
    Is this statement still true to life, or at least something which should
    be preserved in an RFC?
    
    4.12.  Minimization of Session Establishment Data
    
       In order to give attackers as few chances as possible for
       eavesdropping, session hijacking, and other attacks, SSPs should try
       to minimize session establishment data.  Unnecessary data exchange
       also increases the risk of an implementation vulnerability that could
       be exploited by attackers.  In addition. unnecessary data exchange
       among SSPs can increase the risk of call patterns analysis or
       discovery of some SSPs interior topology.
    
    Easier said than done. How exactly this can be achieved?
    Can you provide some specific examples?
     
        
  2. Alexey Melnikov: Comment [2011-03-02]:
    2.3.1.  Threats to SF Confidentiality
    
       o  Password cracking - the challenge-response authentication
          mechanism of SIP can be attacked with offline dictionary attacks.
    
    Did you mean SIP Digest? If yes, please say so.
    
          With such attacks, an attacker tries to exploit weak passwords
          that are used by incautious users.
    
  3. Tim Polk: Discuss [2011-03-02]:
        This document does not seem to consider an attack on one SSP from another,
    compromised, SSP.  Is this attack explicitly out of scope (then it should state
    that) or do any of the countermeasures address such a scenario?  To be clear, I
    am not pushing to expand the scope of the document, just to clarify it....
    
    The discussion of SRTP and SRTCP in 4.13 does not address which external key
    management protocol should be used to set up the initial master key.  Is there a
    well-defined mechanism for speermint, or is this choice left to the deployment? 
        
  4. Tim Polk: Comment [2011-03-02]:
    SQL injection is mentioned first in section 4. Suggest adding a quick
    description in section 2 somewhere.
    
    Section 4.5 only talks about IPsec and (D)TLS. Have SIP folks given up entirely
    on message oriented protection?
  5. Peter Saint-Andre: Comment [2011-03-01]:
    Overall this document appears to provide a helpful summary of the relevant
    security issues.
    
    Are the suggested countermeasures meant to be exhaustive? (Even I can think of
    additional countermeasures, such as limiting authentication attempts and
    obscuring certain error messages to help mitigate directory harvesting attacks.)
    It would be good to explain whether or not the list is exhaustive.
    
    Regarding denial of service attacks, please expand "DoS" on first use and cite
    RFC 4732.
    
    Various other acronyms are not expanded on first use (e.g., SSP).
    
    Citations are not provided for several technologies (e.g., ZRTP).
    
    The document contains several statements that are dubious (e.g., that
    scalability requirements lead SSPs to use UDP instead of TCP -- perhaps they
    need to write better code?) or that might not be true for much longer (e.g.,
    that DNSSEC has not been widely deployed on the Internet -- at least qualify
    this by saying "at the time of this writing"). As far as I can see, these
    statements are not material to the recommendations provided in this document,
    and could be safely removed.
  6. Robert Sparks: Discuss [2011-03-01]:
        1) The descriptions of several of the threats are incomplete, and as a result 
    significantly misleading. Rather than try to expand the description to provide
    enough detail to not be misleading, I suggest up-leveling the descriptions.
    
    For example, it is not clear in the forged 200 response bullet in section
    2.3.2.2 
    if you are describing an on-path or off-path attacker.  Assuming that
    you are only 
    trying to describe off-path, the example doesn't capture the
    important differences 
    on the injected 200 being sent to a proxy or directly to
    originating UA, nor does it 
    note that the element receiving the injected 200
    will also see another final response 
    to the original INVITE (most likely a 487
    due to the CANCEL you call out in the 
    description of the threat).
    
    It should be sufficient to say "Having seen the contents of an INVITE request,
    an
    eavesdropper can inject a 200 response, affecting the processing of the
    transaction
    of all proxies between the injection point and the originating UA
    and at the
    originating UA itself. In the extreme, this can result in a hijacked
    call." And
    in the countermeasures section, call out that such an attack will
    leave signaling
    artifacts that will allow it to be detected.
    
    A similar shift in detail would be necessary for many of the other threat
    descriptions,
    particularly the forged 302 and 404 response threats in section
    2.2.2.
    
    2) 2.3.2.1 mentions exploiting broken implementations in its introduction, but
    provides
    no threats that do so. More detail about what you mean by "guessing"
    might help.
    
    3) "SRTP and ZRTP are vulnerable to bid-down attacks, i.e. by selectively
    dropping key 
    exchange protocol packets may result in the establishment of a
    non-secure communications."
    needs adjustment. It is the keying mechanism, not
    SRTP itself that is vulnerable, and
    the vulnerability depends greatly on which
    mechanism is used. If you are trying to call
    out the vulnerability of a
    particular mechanism, such as RFC4568, please call it out 
    explicitly. For ZRTP,
    what bid-down attack are you pointing to?
    
    4) The description of Media Hijack in 2.4.2 calls out to a missing Figure 8.
    
    5) Was section 4.8 crafted before RSERPOOL closed? Could it be updated to
    reflect the
    output of that concluded working group?
    
    6) The first two sentences of 4.13 need adjusting to note that the algorithms
    used by 
    SRTP are negotiated.
    
    7) [refs.voipsataxonomy] should point to a particular version of that taxonomy
    draft.
    
        
  7. Robert Sparks: Comment [2011-03-01]:
    Nits:
    
    In section 2.3.2.3, alternation should be alteration
    In section 4.1 I suggest substituting "document" for "literatures"
  8. Sean Turner: Discuss [2011-03-03]:
        #1) I support Tim's discusses.  One the 1st one I assume an SSP can be an
    attacker based on the call-pattern attacks.
    
    #2) Sec 2.3.2.2, shouldn't this draft address -199 spoofing?
    
    #3) Sec 2.4, is masquerading a concern?  That is one UE spoofs another?
    
        

draft-ietf-6lowpan-usecases

  1. Jari Arkko: Comment [2011-03-03]:
    Some comments from Ari Keränen:
    
    One question/comment:
    
    3.6.2.  6LoWPAN Applicability
    
      Communication schedules must be set up between
      master and leaf nodes, and global time synchronization is needed to
      account for clock drift.
    
    Wouldn't time synchronization within the LoWPAN (i.e., not globally) be enough
    for this use case?
    
    And some nits:
    
    3.2.1.  A Use Case and its Requirements
    
    The second sentence of this paragraph is a bit hard to parse:
    
      The physical network topology is changed in case of node failure.  On
      the top part of each pillar, an sink node is placed to collect the
      sensed data.  The sink nodes of each pillar become data gathering
      point of the LoWPAN hosts at the pillar as local coordinators.
    
    Perhaps add something like "and act" before the "as the [...]" part (if that's
    what it means)?
    Also: s/an sink/a sink/
    
    3.3.2.  6LoWPAN Applicability
    
      In home network, installation and management must as extremely simple
      for the user. 
    
    s/as/be/
    
    Figure 4: "I" in the legend is redundant (there's no "I" in the figure)
  2. Stewart Bryant: Comment [2011-03-02]:
    An interesting and well written document.
    
    I agree with Peter that RFC2119 language does not seem appropriate.
  3. Lars Eggert: Discuss [2011-03-01]:
        I have a pretty fundamental issue with this document. Many of the described use
    cases make requirements on the 6lowpan architecture that I don't think are
    realistic, or at least it's very unclear how and if they can be achieved. The
    key example is the "support for QoS" requirement that is said to be very
    important for many use cases, yet I see no mechanisms in the actual 6lowpan
    specs that would support different levels of QoS, or even any text that would
    define what "support for QoS" even means in low-powered, maybe-disconnected
    networks. Surely it cannot only mean priority queuing, because that's clearly
    not sufficient for many of the described uses. Another requirement that is
    similarly problematic is "reliable delivery" (which is for some reason included
    under security). It's not clear at all to me whether reliable delivery can be
    achieved with any sort of timing constraints.
    
    I'm not quite sure how I can make this discuss actionable.  
        
  4. Adrian Farrel: Discuss [2011-03-02]:
        A splendid and useful document that is let down by the Security
    Considerations section.
    
    The applicability of 6LowPANs is significantly dependent on suitable
    security mechanisms being available. Since 6LowPANs are very vulnerable 
    to physical layer attacks, it is important to discuss the options and
    to identify when the use of these networks is not advisable.
    
    If you can add some beef to that section, I would happily change my
    ballot to Yes. 
        
  5. Tim Polk: Discuss [2011-03-02]:
        The Security Considerations overlooks a number of very important
    issues/challenges raised by the use cases.
    
    First, a number of the use cases are vulnerable to physical threats, including
    device theft and simple vandalism.  Given the safety issues involved in some use
    cases, this would seem to place specific demands for resiliency and
    survivability upon the 6lowpan.  This issue seems to be overlooked entirely.
    
    Second, while the existing security considerations briefly touch on the need for
    encryption, the treatment does not expose the real issues at play.  There is a
    reference to "lightweight key mechanisms" that deserves expansion - what are
    those mechanisms (references please!)  The discussion of encryption overlooks a
    fundamental problem - the slow processors and limited memory capacity described
    in section 1 will be challenged by generally accepted cryptographic algorithms.
    However, the safety concerns associated with many use cases precludes deployment
    of weak cryptography!
    
    I suspect that authentication will provide a similar set of challenges.
    Configuration of strong authentication, with role-based access controls, on the
    nodes of even a medium sized lowpan seems problematic.  (I don't recall the
    specific deployment challenge of provisioning/configuring the security controls
    being addressed in the body of the document.) 
        
  6. Tim Polk: Comment [2011-03-02]:
    In 3.5.1, the telematics example has a deployment parameter of "scattered, pre-
    planned".  Somehow these seem in conflict.
    
    I share Lars' concern about QoS requirements.
  7. Peter Saint-Andre: Comment [2011-03-01]:
    This is a pleasant document. However, given that it discusses use cases and
    deployment scenarios, I doubt that it needs to use RFC 2119 conformance terms at
    all. For example, consider the following sentence from Section 3.2: "Some data
    is not critical for security protection (such as normal room temperature), but
    event-driven emergency data (such as a fire alarm) MUST be handled in a very
    critical manner." Well, that's probably the case, but it's really a matter of
    local service policy, isn't it? Similarly, the assertion in Section 3.4.1 that
    "Data privacy and security MUST be provided" in healthcare systems is really a
    matter of either local service policy or applicable legislation (e.g., HIPAA),
    not RFC 2119 conformance.
  8. Robert Sparks: Comment [2011-03-02]:
    Consider clarifying whether the set of dimensions here is intended as a complete
    list, or is just an important set currently identified.
  9. Sean Turner: Comment [2011-03-03]:
    I support Tim's discussion.

draft-ietf-hip-over-hip

  1. Jari Arkko: Discuss [2011-03-03]:
        I think it would be useful for the document to talk about what happens when
    there's a NAT, and what the interaction with the HIP NAT traversal mechanisms
    is. Do you run UDP-ESP-TCP? 
        
  2. Jari Arkko: Comment [2011-03-03]:
    The document should state that hiding HIP control packets inside ESP will make
    it impossible to build NATs or other middleboxes that look inside the HIP
    packets to do something useful. There used to be a proposal called SPINAT that
    did this, allowing ESP to go through NATs without UDP encapsulation. SPINAT
    isn't used anywhere anymore AFAIK, and the one implementation that exists isn't
    in open source. So this is not a big deal, but for completeness the impact
    should be noted.
  3. Lars Eggert: Discuss [2011-03-01]:
        Section 4.2., paragraph 1:
    >    If the ESP-TCP mode is selected, the host with the larger HIT
    >    (calculated as defined in Section 6.5 of [RFC5201]) MUST start to
    >    listen for an incoming TCP connection on the encrypted connection on
    >    the port it used in the Port field of the transport mode parameter.
    
      DISCUSS: TCP listens on IP address/port number tuples. What's the IP
      address to listen on here? (I don't understand what you mean by "on
      the encrypted connection".)
     
        
  4. Lars Eggert: Comment [2011-03-01]:
    INTRODUCTION, paragraph 2:
    >         Host Identity Protocol Signaling Message Transport Modes
    
      I think this title sets a record for most number of consecutive nouns.
      Can we maybe stick a verb and an object in there to improve clarity?
    
    Section 4.2., paragraph 4:
    >    Since TCP provides reliable transport, the HIP messages sent over TCP
    >    MUST NOT be retransmitted for the purpose of achieving reliable
    >    transmission.
    
      Does this mean that HIP messages may be retransmitted for other
      purposes? Or it this phrasing inaccurate?
    
  5. Adrian Farrel: Comment [2011-03-02]:
    I was surprised to see no discussion of TCP-AO.
    
    ---
    
    I agree with the Discuss about downgrade attacks. These seem to be particularly
    open in the mobility/multi-homing case described in Section 6.
  6. Dan Romascanu: Comment [2011-03-02]:
    The OPS-DIR review performed by David Black pointed to the following problem: 
    
    The draft is somewhat inconsistent about support for a HIP node policy that
    requires use of an encrypted transport for HIP signaling.  Section 3.3 provides
    an essential building block, the error signaling mechanism to indicate that an
    encrypted transport is required and none was proposed.  On the other hand,
    Section 5 is unclear with respect to this class of policy in that it strongly
    recommends (SHOULD) fallback to a non-encrypted HIP connection but requires
    (MUST) that "messages that are intended to be sent only encrypted" not be sent
    unencrypted.  If the "messages that are intended to be sent only encrypted" are
    all HIP messages after the base exchange, these two requirements appear to be in
    conflict.
    
    I suggest adding a short explanation to Section 5 of what would be reasonable
    vs. unreasonable policy for "messages that are intended to be sent only
    encrypted", and how to use the Section 3.3 error report when a failed encrypted
    connection is recovered by attempting to fall back to an unencrypted connection
    when HIP node policy requires encryption of all signaling after the base
    exchange.
    
    The change was agreed by the document editor and the OPS-DIR reviewer and needs
    to find its way either in a revised I-D or in a note to the RFC Editor.
  7. Peter Saint-Andre: Discuss [2011-03-01]:
        Given that bootstrapping of secure communication depends on transmission of the
    HIP_TRANSPORT_MODE parameter during HIP base exchange, I'm surprised that the
    security considerations do not discuss the possibility of downgrade attacks. 
        
  8. Sean Turner: Comment [2011-03-02]:
    1) It would have helped me had the packet figures from RFC 5201 were added here
    (assume I'm getting it right):
    
    The HIP header values for the R1 packet:
    
          IP ( HIP ( [ R1_COUNTER, ]
                     PUZZLE,
                     DIFFIE_HELLMAN,
                     HIP_TRANSFORM,
                     HOST_ID,
                     [ ECHO_REQUEST_SIGNED, ]
    ->              [ HIP_TRANSPORT_MODE,]
                     HIP_SIGNATURE_2 )
                     <, ECHO_REQUEST_UNSIGNED >i)
    
    Not sure if it's exactly in the right place.  This would make it clear that the
    transport mode is signed.  Same for I2:
    
       IP ( HIP ( [R1_COUNTER,]
                     SOLUTION,
                     DIFFIE_HELLMAN,
                     HIP_TRANSFORM,
                     ENCRYPTED { HOST_ID } or HOST_ID,
    ->              [ HIP_TRANSPORT_MODE, ]
                     [ ECHO_RESPONSE_SIGNED ,]
                     HMAC,
                     HIP_SIGNATURE
                     <, ECHO_RESPONSE_UNSIGNED>i ) )
    
    2) Sec 4.2: Difficult to parse the sentence Lars has a discuss on.
    
    3) Why SHOULD the TCP originator use the source port they said they'd use? I
    could understand a MUST or with NATs a MAY but can't figure why SHOULD?

draft-ietf-hip-cert

  1. Adrian Farrel: Comment [2011-03-01]:
    Agree with Peter's Discuss. The update to 5201 should be noted in the document
    header and the Abstarct.
    
    ---
    
    Section 2
    
       It MAY either carry SPKI certificates or X.509.v3
       certificates.
    
    I think lower case "may" is more appropriate. Unless you mean...
    
       It MUST carry either SPKI certificates or X.509.v3
       certificates.
    
  2. Alexey Melnikov: Discuss [2011-03-02]:
        3.  X.509.v3 Certificate Object and Host Identities
    
       When using X.509.v3 certificates to transmit information related to
       HIP hosts, HITs MAY be enclosed within the certificates.  HITs can
       represent an issuer, a subject, or both.  In X.509.v3 HITs are
       represented as issuer or subject alternative name extensions as
       defined in [RFC5280].
    
    Using which type(s)? Examples below show IP Address, but this is not stated
    normatively.
    
       If only the HIT of the host is presented as
       either the issuer or the subject the respective HIT MUST be placed
       into the respective entity's DN's Common Name (CN) section in a colon
       delimited presentation format defined in [RFC5952].  Inclusion of CN
       is not necessary if DN contains any other naming information.  It is
       RECOMMENDED to use the FQDN/NAI
    
    How are these going to be represented in DNs? Are you assuming CN=<FQDN>
    or something else? What about NAI?
    
       from the hosts HOST_ID parameter in
       the DN if one exists.  The full HIs are presented in the public key
       entries of X.509.v3 certificates.
    
       In this scenario, it is RECOMMENDED that the HIP peers have and use
       some mechanism of defining trusted root CAs for the purpose of
       establishing HIP communications.  Furthermore it is recommended that
       the HIP peers have and use some mechanism of checking peer
       certificate validity for revocation, signature, minimum cryptographic
       strength, etc., up to the trusted root CA.
    
    The whole paragraph: this looks way too informative and way too weak.
    Maybe point to RFC 5280?
    
    7.  IANA Considerations
    
       The CERT parameter has 8-bit unsigned integer field for different
       certificate types, for which IANA is to create and maintain a new
       sub-registry entitled "HIP certificate types" under the "Host
       Identity Protocol (HIP) Parameters".  Initial values for the
       Certificate type registry are given in Section 2.
    
    What is the IANA registration procedure for this registry?
     
        
  3. Peter Saint-Andre: Discuss [2011-03-01]:
        Section 7 states:
    
       This document defines the CERT parameter for the Host Identity
       Protocol [RFC5201].  This parameter is defined in Section 2 with type
       768.  The parameter type number is also defined in [RFC5201].
    
    Therefore does this document need to say that it updates RFC 5201? 
        
  4. Peter Saint-Andre: Comment [2011-03-01]:
    Please spell out acronyms on first use (I1, HI, HIT, FQDN, NAI, etc.).
    
    A reference to RFC 4282 might be appropriate with respect to NAI.
    
    References to various DNS-related specifications might be appropriate with
    respect to FQDN (also please clarify if internationalized domain names are
    allowed).
  5. Sean Turner: Discuss [2011-03-01]:
        #1) I was expecting a profile of RFC 5280 to identify which extensions
    MUST/SHOULD be present in X.509 certificates.  Shouldn't this draft specify a
    profile and indicate things like:
    
    - The IAN and SAN extensions MUST be present? Assuming yes: which GeneralName
    form MUST be used?
    
    - Are there any HIP specific EKUs?
    
    - What algorithms (signature and hash) MUST be used to sign the
    certificates/CRLs (just pointing to 5201bis)?
    
    #2) Section 2 includes the following:
    
      It MAY either carry SPKI certificates or X.509.v3
       certificates.
    
    Are OpenPGP certificates prohibited?  Are you just trying to say that this
    document specifies the semantics for carrying SPKI or X.509.v3 certificates?  It
    sounds like the registry is limited to only these two types.
    
    #3) X.690 is normative because you require it be supported. 
        
  6. Sean Turner: Comment [2011-03-01]:
    #1) <nit picking alert>r/Digital certificates bind a piece of
    information/Digital certificates bind a pieces of information<nit picking alert>
    
    #2) Section 2 3rd para: "not recommended" is used but should it be "NOT
    RECOMMENDED".  It is 2119 language, but you'd need to update the Sec 1.1 as per
    the following errata: http://www.rfc-
    editor.org/errata_search.php?rfc=2119&eid=499.
    
    #3) Cert Type Number: Should probably reserve value 0.
    
    #4) It may be useful to say that a receiver SHOULD validate the certificate
    signature against the octets received in case the sender/CA sent some bad DER
    that doesn't re-encode identically. This has happened in the past.
    
    #5) Checking a URL, or LDAP entry creates a potential DoS.  That should be
    mentioned in the security considerations.
    
    #6) Should this be RECOMMENDED:
    
      Furthermore it is recommended that
       the HIP peers have and use some mechanism of checking peer
       certificate validity for revocation, signature, minimum cryptographic
       strength, etc., up to the trusted root CA.
    
    Also, RFC 5280 indicates that revocation checking is optional.  Was upping this
    to RECOMMENDED done on purpose?
    
    #7) Is there no way for a responder to signal trust anchor information to an
    initiator? That can be handy, but if the WG didn't want it then fine.
    
    #8) IANA Considerations: Do you need to specify how the registry is updated
    (e.g., specification required, IETF consensus)?
    
    #9) Should point to 5280 for security considerations X.509v3 certificates and
    2693 for SPKI certificate security considerations.
    
    #10) Probably should just the same reference for X.690 as RFC 5280 uses:
    
    [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
                  Information technology - ASN.1 encoding rules:
                  Specification of Basic Encoding Rules (BER), Canonical
                  Encoding Rules (CER) and Distinguished Encoding Rules
                  (DER).
    
    #11) Should expand HIT, HI, NAI, and FQDN.
    

draft-mraihi-mutual-oath-hotp-variants

  1. Adrian Farrel: Comment [2011-03-02]:
    I found the list of requirements in Section 3 helpful in understanding
    why the algorithm is built the way it is. But I also found the
    requirements a little lacking in motives. Would it be possible to add
    a single sentence to each requirement to say *why* the requirement 
    holds?
    
    ---
    
    I think you need to add a reference to the definition of the BNF you
    are using.
  2. Alexey Melnikov: Discuss [2011-03-02]:
        3.  Algorithm Requirements
    
       R1 - The algorithm MUST support asynchronous challenge-response based
       authentication.
    
    Can you please explain in more details what this means?
    
    5.1.  DataInput Parameters
    
    o  T is an 8-byte unsigned integer in big endian (i.e. network byte
          order) representing the number of time-steps(seconds, minutes,
          hours or days depending on the specified granularity) since
          midnight UTC of January 1, 1970.
    
    Where is the granularity is specified?
    
          More specificatlly, if the OCRA
          computation includes a timestamp T, you SHOULD first convert your
          current local time to UTC time (text form);
    
    Is use of the "text form" really a SHOULD? This looks like an implementation
    detail.
    I think the use of a RFC 2119 keyword is incorrect here.
    
          you can then derive
          the UTC time in the proper format (i.e. seconds, minutes, hours or
          days elapsed from Epoch time); the size of the time-step is
          defined in the OCRASuite string
    
    5.2.  CryptoFunction
    
       The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of
       computation for OCRA is HOTP with the default 6-digit dynamic
       truncation and a combination of DataInput values as the message to
       compute the HMAC-SHA1 digest.
    
    What is "digit" in this case? A decimal digit? A hex digit?
    
    6.  The OCRASuite
    
       An OCRASuite value is a text string that captures one mode of
       operation for the OCRA algorithm, completely specifying the various
       options for that computation.  An OCRASuite value is represented as
       follows:
                         Algorithm:CryptoFunction:DataInput
    
    It is not clear to me if this is supposed to represent a pseudo-ABNF or
    something else.
    Is this saying that 3 strings are separated by ":" characters?
    
    6.1.  Algorithm
    
       Description: Indicates the version of OCRA algorithm.
    
       Values: OCRA-v where v represents the version number (e.g. 1, 2
       etc.).  This document specifies version 1 of the OCRA algorithm.
    
    Are there any rules about backward compatibility between higher versions and
    lower versions?
    
    In Section 8.2:
    
    IC8 - We recommend that implementations MAY use the session
       information, S as an additional input in the computation.  For
       example, S could be the session identifier from the TLS session.
       This will mitigate against certain types of man-in-the-middle
       attacks.  However, this will introduce the additional dependency that
       first of all the prover needs to have access to the session
       identifier to compute the response and the verifier will need access
       to the session identifier to verify the response.
    
    Should this paragraph point to RFC 5056 and RFC 5929?
    
    Appendix A.  Reference Implementation
    
       import java.lang.reflect.UndeclaredThrowableException;
       import java.security.GeneralSecurityException;
       import javax.crypto.Mac;
       import javax.crypto.spec.SecretKeySpec;
       import java.math.BigInteger;
    
       /**
        * This an example implementation of the OATH OCRA algorithm.
        * Visit www.openauthentication.org for more information.
        *
        * @author Johan Rydell, PortWise
        */
    
    Is the license for this code compatible with IETF rules?
     
        
  3. Alexey Melnikov: Comment [2011-03-02]:
    5.1.  DataInput Parameters
    
       o  P is a hash (SHA1, SHA256 and SHA512 are supported) value of PIN/
    
    This is missing some references.
    
          password that is known to all parties during the execution of the
          algorithm; the length of P will depend on the hash function that
          is used
       o  S is an UTF-8 encoded string of length upto 512 bytes that
    
    A normative reference for UTF-8 is missing here.
    
          contains information about the current session; the length of S is
          defined in the OCRASuite string
    
    In Section 8.2:
    
       IC6 - All the communications SHOULD take place over a secure channel
       e.g.  SSL/TLS, IPsec connections.
    
    Informative reference to TLS is needed here.
    
       IC9 - In the signature mode, whenever the counter or time (defined as
       optional elements) are not used in the computation, there might be a
       risk of replay attack and the implementers should carefully consider
       this issue in the light of their specific application requirements
       and security guidelines.
    
    Is any advice about time synchronization needed here?
    
       The server SHOULD also provide whenever
       possible a mean for the client (if able) to verify the validity of
       the signature challenge.
    
  4. Dan Romascanu: Comment [2011-03-02]:
    This is a clear and well-written document. 
    
    The OPS-DIR review performed by David Black made one comment, which refers to a
    clarification aspect. It is not a blocking issue, but addressing it would be
    useful:
    
    I do have one suggestion for improved clarity.  The first sentence in the
    introduction states that a primary motivation for these algorithms as support
    for "users who do not want to maintain a synchronized authentication system."
    In contrast, the C component of DataInput in Section 5.1 is a counter that "MUST
    be synchronized between all parties."  The reason that these two statements are
    not in conflict is the counter is optional for all of the algorithm modes
    defined in the draft.  A statement to that effect should be added to Section 5.1
    - IMHO, assuming that the optional nature of the counter will be inferred from
    the omission of the word "mandatory" is insufficient.

draft-baker-ietf-core

  1. Lars Eggert: Comment [2011-03-03]:
    None of the comments below taken alone is discuss-worthy, but I do think at
    least several of them should really be addressed.
    
    Section 2.1.2., paragraph 3:
    >    For example, TCP will
    >    reduce rate to avoid loss, while DCCP accepts some level of loss if
    >    necessary to maintain timeliness.
    
      TCP doesn't really reduce its rate to avoid loss - it uses loss as an
      indication for congestion, and basic congestion control principles
      mandate a rate reduction. DCCP does the same - the difference is that
      DCCP will not bother to retransmit lost data while TCP will.
    
    Section 3.2.2.3., paragraph 3:
    >    In that research, the IETF imposed guidelines [RFC2357] on the
    >    research community regarding what was desirable.  Important results
    >    from that research include a number of papers and several proprietary
    >    protocols including some that have been used in support of business
    >    operations.  RFCs in the area include The Use of Forward Error
    >    Correction (FEC) in Reliable Multicast [RFC3453], the Negative-
    >    acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
    >    [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP)
    >    [RFC4410].  These are considered experimental.
    
      This section has outdated information. NORM is now PS (RFC 5401), and
      FLUTE is almost there (IETF LC of draft-ietf-rmt-flute-revised is
      imminent). Reliable multicast is not experimental anymore.
    
    Section 3.3.2., paragraph 2:
    >    it delivers data to its peer and provides acknowledgement to the
    >    sender, or it dies trying.  It has extensions for Congestion Control
    >    [RFC5681] and Explicit Congestion Notification [RFC3168].
    
      As well as many other extensions - it may be useful to cite RFC 4614
      here.
    
    Section 3.3.2., paragraph 3:
    >    For message-stream interfaces, we generally use the ISO
    >    Transport Service on TCP [RFC1006][RFC2126] in the application.
    
      Who is "we"? Is anyone really using RFC1006 and RFC2126?
    
    Section 3.3.2., paragraph 5:
    >    Finally, note that TCP has been the subject of ongoing research and
    >    development since it was written.  The End to End research group has
    >    published a Roadmap for TCP Specification Documents [RFC4614] to
    >    capture this history, to guide TCP implementors, and provide context
    >    for TCP researchers.
    
      RFC 4614 did not come out of end-to-end, it was a WG document in TCPM.
      And while it does capture some of the history and research aspects,
      the motivation was very much to be a "start reading here" document for
      implementors, similar in spirit to this I-D.
    
    Section 3.6.2., paragraph 8:
    >    The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is
    >    being developed in IETF with these goals in mind.
    
      I'm surprised to see that COAP is only mentioned under resource
      discovery. While that's one aspect of it, the broader aspect is as an
      application/transport protocol for constraint environments. IMO it
      would make more sense to discuss COAP under Section 3.3 or 3.3.1.
    
    Section 4., paragraph 0:
    > 4.  A simplified view of the business architecture
    
      At least to my mind, it would be a bit more logical to see this
      section merged into Section 2 or following it. (Also, it'd be nice to
      replace domain names and IP addresses in this section with ones from
      the "example" spaces.)
    
    Section 5., paragraph 1:
    >    This memo asks the IANA for no new parameters.
    
      Although this document makes no requests from IANA, I wonder if the
      smartgrid guys know about the role that IANA plays in the
      standardization and administration of the IPS. Is there an IANA
      overview document that you could cite here for them to read?
    
    Section 8., paragraph 0:
    > 8.  References
    
      Is there a logic to the split between normative and informative
      references?
    
    Appendix A., paragraph 1:
    >    This appendix provides a worked example of the use of the Internet
    >    Protocol Suite in a network such as the Smart Grid's Advanced
    >    Metering Infrastructure (AMI).  There are several possible models.
    
      I don't think this example is worked out enough to illustrate how the
      IPS can be applied here. There's a little bit of text about layer 3,
      and nothing at all about higher layers. I wonder if this material
      would be better split off into a standalone document for further
      development.
    
    ---
    
    Section 2.2., paragraph 1:
    >    solutions to many Internet security problems have already exist.
    
      Nit: s/have//
    
    Section 2.2.1., paragraph 3:
    >    For wirless transmission technologies eavesdropping on the
    
      Nit: s/wirless/wireless/
    
    Section 3.2.3.1., paragraph 1:
    >    Autoconfiguation enables various different models of network
    
      Nit: s/Autoconfiguation/Autoconfiguration/
    
    Section 802.11, paragraph 0:
    >    networks between various sensors in the home (e.g., betweeen the
    
      Nit: s/betweeen/between/
    
  2. Adrian Farrel: Comment [2011-03-02]:
    Fine work.
    
    I should have liked to see some forward reference to the Appendix from early in
    the document since (I assume) the readers will find the Appendix quite useful
    and (although it is mentioned in the ToC) there is no other hint that it is
    there.
  3. Tim Polk: Discuss [2011-03-03]:
        Two actionable discusses, one discuss-discuss:
    
    Actionable 1: Please add a brief section 3.1.5 Key Management Infrastructures to
    cover PKI (PKIX) and Kerberos.
    These are a very important building block in the
    security toolbox.  I would suggest mentioning the DANE work in this
    section as
    well.
    
    Actionable 2: Please add a brief section 3.1.6 secure shell.  This is another
    and widely used key building block.
    
    Discuss-discuss: I would have expected to see some discussion of SRTP and SRTCP,
    but neither RTP nor RTCP
    is mentioned.  Was there a specific decision not to
    include these protocols?  If so, excluding SRTP and SRTCP
    makes perfect sense. 
        
  4. Tim Polk: Comment [2011-03-03]:
    technical comments:
    2.2
    
    OLD
    While it is popular to complain about the security of the Internet,
    solutions to many popular Internet security problems have already exist.
    NEW
    While it is popular to complain about the security of the Internet,
    it is important to distinguish between attacks on protocols and
    attacks on user (e.g., phishing).  Attacks on users are largely independent
    of protocol details, reflecting interface design issues or user education
    problems, and are out of scope for this document. Security problems with
    Internet protocols are in scope, of course, and can often be mitigated
    using existing security features already specified for the protocol, or
    by leveraging the security services offered by other IETF protocols.
    
    2.2.2
    
    Append to the paragraph beginning "A number of mechanisms":
    
    Another mechanism, specifically targeting the reset attack cited above,
    provides authentication services in TCP itself to ensure that fake resets
    are rejected.
    
    3.1
    
    OLD
       It is important to highlight that in addition to the mentioned
       security tools every protocol often comes with additional, often
       unique security considerations that are very unique to the specific
       domain that protocol operates in.
    NEW
       It is important to highlight that in addition to the mentioned
       security tools every protocol often comes with additional, often
       unique security considerations that are very unique to the specific
       domain that protocol operates in.  Many protocols include features
       specifically designed to mitigate these protocol-specific risks.  In
       other cases, the security considerations will identify security-relevant
       services that are required from other network layers to achieve
       appropriate levels of security.
    
    3.1.2
    
    [Note: The TLS section talks about negotiating parameters as suites, but the
    IKE section is silent.  The following suggestion would be more complete
    and provide some parallelism.}
    
    OLD
       For the former step the Internet Key Exchange protocol version 2
       (IKEv2 [RFC5996]) is the most recent edition of the standardized
       protocol.
    NEW
        For the former step, the Internet Key Exchange protocol version 2
       (IKEv2 [RFC5996]) is the most recent edition of the standardized
       protocol.  IKE negotiates each of the cryptographic algorithms that
       will be used to protect the data independently, somewhat like
       selecting items a la carte.
    
    3.1.2 penultimate paragraph:
    Please append:
    Since ESP can also provide authenctication services, most recent
    protocol development making use of IPsec only specify use of ESP
    and do not use AH.
    
    3.1.3
    
    Adding a reference to RFC 6090 in 3.1.3 would be good, e.g.
    "The basic cryptogaphic mechanims for ECC have been documented
    in RFC 6090." That could be added to the end of the 2nd last
    para in 3.1.3.
    
    3.1.4
    
    CMS paragraph: Please append the following:
    CMS has been leveraged to supply security services in a variety of
    protocols, including secure email [RFC5751], key management [RFC5958]
    and [RFC6031], and firmware updates [RFC4108].
    
    Digitally signed XML paragraph: Please append the following:
    Digitally signed XML is a good choice where applications natively
    support XML encoded data.  
    
    Section 3.7
    
    What about email, ftp, http?  Do these have any application in this space?
    
    4. (current page 36)
    
    Firewalls are also common on end-hosts as well.  This may be worth a mention
    in this section.
    
    ----
    
    editorial comments:
    
    2.1.3.2
    
    s/can recursively subdivided/can be recursively subdivided/
    
    2.2 
    
    s/takes security serious/takes security seriously/
    
    s/provides recommendations how/provides recommendations on how/
    
    2.2.2
    
    s/are round/exist/
    
    3. (last sentence)
    
    s/such analyzes/such analysis/
    
    3.1
    
    s/we outline of/outline a/
    
    3.1.1
    
    first sentence:
    s/The term/While the term/
    
    second Para:
    s/prior to access a/prior to accessing a/
    
  5. Dan Romascanu: Discuss [2011-03-02]:
        Before I vote YES on this document I would suggest fixing a few obvious
    editorial problems. Fixes should be easy.
    
    1. Section 2.1.1 - please do not refer to [RFC1157] when speaking about SNMP.
    This one is Historical. Best would be to refer to [RFC3411] and remove the
    reference to 1157
    
    2. Section 2.1.3.2 - IEEE 802.16 is not a local wireless network - they define
    themselves as metropolitan wireless network
    
    3. Section 2.3.2 - remove the words 'and is a polled architecture' when refering
    to SNMP. This is not completely accurate and conflicts with what is written
    later in Section 3.5.1 
        
  6. Dan Romascanu: Comment [2011-03-02]:
    1. [SmartGrid] - I am unconfortable to providing wikipedia references - not
    because I do not trust the principle of shared wisdom, but because they are
    unstable to my taste even for Informational References. If there is really
    nothing else around (even not from NIST?) I wouls suggest that at least we
    provide together with the reference a date when the quote was extracted from the
    wikipedia article
    
    2. It is not clear to me why from all applications possible section 3.7 selects
    exactly SIP and calendaring. Are these applications considered candidates to run
    on the Smart Grid more than other applications?
  7. Peter Saint-Andre: Comment [2011-03-02]:
    The introduction states:
    
       o  Section 3 outlines the set of protocols that will be useful in
          Smart Grid deployment.
    
    Is this statement (*the* set of protocols) meant to imply that no other
    protocols might be useful in smart grid deployments? (Naturally, I know of
    several companies that have deployed XMPP quite widely for smart grid
    deployments, but I'm sure there are other protocols one could add to the set, as
    well.)
    
    Regarding Section 3.7.2, is calendaring really of strong interest or use in
    smart grid deployments?
  8. Robert Sparks: Discuss [2011-03-02]:
        1) Would it be possible (and would it preserve the intended meaning) to say
    "identifies the key infrastructure protocols of the Internet Protocol Suite"
    instead of just "the key protocols" in the introduction?
    
    2) Echoing 1) above, would text along these lines be acceptable for the
    introduction to section 3.7? 
    "There are many applications that rely on the IP
    infrastructure, but are not properly thought of as part of the IP infrastructure
    itself. These applications may be useful in the context of the Smart Grid. The
    choices made when constructing a profile of the Internet Profile Suite may
    impact how such applications could be used. Two such protocols (not by any means
    an exhaustive list) are discussed here."
    
    3) The description of the impact of NATs on SIP needs tweaking. As it is, it
    implies the only way to work through NATs is for the NAT itself to be an ALG,
    modifying signaling packets, but the endpoints themselves can work (using tools
    like STUN) through SIP unaware NATs. SIP messaging itself does have an issue
    with NATs (see RFC5626, or draft-ietf-sipping-nat-scenarios). I suggest just
    noting that choosing to introduce NATs as part of the profile will increase the
    complexity of deploying SIP applications and point to 5626 for a discussion of
    the details. 
        
  9. Sean Turner: Discuss [2011-03-03]:
        #1) Sec 2.2.2: How about we use CIA, Confidentiality, Integrity, and
    Availability (the classic model), and throw in Authenticity:
    
    At the network, transport, and application layers it is common to demand a few
    basic security requirements, commonly referred to as CIA (Confidentiality,
    Integrity, and Availability):
    
     1. Confidentiality: Protect the transmitted data from unauthorized disclosure
         (i.e., keep eavesdroppers from learning what was transmitted).  For
          example, for trust in e-commerce applications credit card transactions are
          exchanged encrypted between the Web browser and a Web server.
    
     2. Integrity: Protect against unauthorized changes to exchanges, 
         including both intentional change or destruction and accidental
         change or loss, by ensuring that changes to exchanges are detectable.
         It has two parts: one for the data and one for the peers.
    
       - Peers need to verify that information that appears to be from a
          trusted peer is  in fact from that peer.  This is typically called
           'data origin authentication'.
    
       -  Peers need to validate that the content of the data exchanged
          is unmodified. The term typically used for this property is data
          integrity.
    
    To this we add authenticity, which requires that the communicating peers prove
    that they are in fact who they say they are.  One peer can prove to the other
    who they are (i.e., one-way authentication), but in general two-way (or mutual)
    authentication is best.  Mutual authentication is performed at a minimum by
    using a) something the user knows  and the b) something the user has.  Single-
    factor authentication assumes the user knows their username and they have a
    secret (think password).  Two-factor authentication assumes the user knows their
    password (typically to unlock a key stored on the token) and the user has a
    token (think smartcard).  Multi-factor authentication adds a c) the user is
    (e.g., biometrics).
    
    #2) Section 2.2.2: Many times we say people say use TLS - we're done right.  I
    think we should say something about hop-by-hop security vs end-to-end security.
    
    #3) How do we see OAUTH playing in this space?  Should Kerberos be discussed?
    
    #4) Should we talk about TCP security (i.e., TCP-AO)?
    
    #5) Section 3.2 talks about routing.  Should we discuss routing security as
    well? 
        
  10. Sean Turner: Comment [2011-03-03]:
    #1) Politics layer is missing from Figure 1 ;)
    
    #2) <nit alert>r/"host./"host."</nit alert>
    
    #3) Could we point to SNMPv3 instead of v1? (i.e., something that's not
    historic)
    
    #4) Is it worth mention HIP at all or the concept of splitting the identifier
    and locator?  It's experimental so maybe not.
    
    #5) Is it worth adding an informative reference to
    https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/ in 2.2.2 where it
    talks about TCP attacks/counter measures?  Also maybe pointing to
    https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ for IP
    attacks/counter measures would be helpful.
    
    #6) Section 3.1.1: can we also add EAP-TLS:
    
       For access to remote
       networks, such as enterprise networks, the ability to utilize EAP
       within IKEv2 [RFC5996] and within TLS [RFC5216] have also
       been developed.
    
    #7) While the Suite B IPsec profiles are near and dear to my heart, I'm not sure
    they need to be included in Sec 3.1.2.
    
    #8) Sec 3.1.3: It's probably worth noting that TLS supports hop-by-hop security
    and depending on the architecture this might not be end-to-end (i.e., TLS isn't
    one size fits all).
    
    #9) Sec 3.1.4: for truth in advertising:
    
      The CMS can support a variety of
       architectures for key management included: certificate-based key
       management, such as the one
       defined by the PKIX (Public Key Infrastructure using X.509) working
       group [RFC5280], or symmetric key management.
    
    #10) Sec 3.1.4: Should also add that a variety of algorithms are supported:
    
      CMS supports a number of algorithms: RSA, DSA, DH, ECDSA,
       and ECDH as well as the SHA family of algorithms.
    
    #11) Sections 3.1.2-3.1.4: When renaming 3.1.4 to "Application Security" makes
    me think that 3.1.2 should be called "Network Security" and 3.1.3 should be
    called "Transport Security".  Then put SSH in 3.1.3 (maybe no need for a new
    3.1.6 as Tim suggests).  Could have two subsections.
    
    #12) I think this needs to be updated:
    
      Note that since IPv4 free pool (the pool of available, unallocated
       IPv4 addresses) is almost exhausted,

draft-josefsson-rc4-test-vectors

  1. (none)