IESG Narrative Minutes

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

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

Corrections from: Dan

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Negotiation of Generic Image Attributes in SDP (Proposed Standard)
    draft-ietf-mmusic-image-attributes-10
    Token: Robert Sparks
    Note: Tom Taylor (tom111.taylor@bell.net) is the Document Shepherd.
    Discusses/comments (from ballot 3533):
    1. Adrian Farrel: Comment [2011-01-20]:
      I have only partially reviewed this document, but I have no objection to the technical content in this document. I found a lot of the text somewhat ambiguous or hard to parse, and the number of such issues was (IMHO) close to making the document quality suspect and warranting a Discuss. Although the RFC Editor will work on these issues, it is my opinion that such a level of changes will result in a proportion of cases will result in:
      - bad fixes made by the RFC Editor
      - issues being missed.
      I urge the authors to at least make fixes to the issues I have identified, and preferably find a technology-aware native speaker to review and update the text.
      The Abstract really needs to mention SDP. I would prefer if the Introduction was also clearer sooner that this document applies to SDP
      SDP is not a well-known acronym according to the RFC Editor so should be expanded...
      You should expunge all references to "draft" and replace with "document"
      In the Abstract...: "The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted."
      A nice trick if you can do it, but actually, I think that someone needs to implement something! How about...
      "The mechanisms defined in this document can also be used to help maintain an optimal bitrate for video, as only the image size that is desired by the receiver is transmitted."
      Section 1: "This document proposes a new attribute to make it possible to negotiate different image attributes such as image size. The term image size is defined here as it may differ from the physical screen size of for instance a hand-held terminal."
      I do not find the term "image size" defined. You may want s/defined/used/ or you may want to add the definition.
      Section 1: "There are a number of benefits with a possibility to negotiate the image size:"
      /with a/to the/
      Section 1: "Optimal quality for the given bitrate: The sender does not need to encode an entire CIF (352x288) image if only an image size of 288x256 is displayed on the receiver screen. This alternatively gives a saving in bitrate."
      s/alternatively/alternative/ ?
      REQ-1: s/wish/wishes/
      3.1.1: "The attribute typically contains a "send" and a "recv" keyword. These specify the preferences for the media once the session is set up, in the send and receive direction respectively from the point of view of the sender of the session description. One of the keywords ("send" or "recv") MAY be omitted, see Section 3.2.4 and Section 3.2.2 for a description of cases when this may be appropriate."
      I see this saying: "The attribute MUST contain at least one of the keywords "send" and "recv"."
      3.1.1: "For sendrecv streams both of the send and recv directions SHOULD BE present in the SDP.
      s/BE/be/
      3.1.1: "For inactive streams it is RECOMMENDED that both of the send and recv directions are present in the SDP."
      s/SDP/SDP message/ ?
      3.1.1.1: "Payload type number (PT): The image attribute is bound to a specific codec by means of the payload type number."
      It may be obvious, but there is no statement of where the possible values of PT can be found. I think you should add this.
    2. David Harrington: Comment [2011-01-18]:
      This document is well-written. These comments require no action by the authors, but if these fixes were applied, it might make for a cleaner document...
    3. Russ Housley: Comment [2011-01-20]:
      As noted in the Gen-ART Review by Avshalom Houri on 19-Jan-2011, the following lines in Section 4.2.4 need to be reworded:
      Neither part is required to rescale like this (sar may be ignored), the consequence will of course be a distorted image."
      Also, please consider the editorial changes proposed in the Gen-ART Review by Avshalom Houri.
    4. Alexey Melnikov: Comment [2011-01-14]:
      I've done a detailed review of the document and overall I think it is fine. Some comments below...
    5. Tim Polk: Discuss [2011-01-17]:
      This is mostly a discuss-discuss, but also is a reminder that the authors have agreed to add security considerations about DoS attacks after a discussion with the security directorate reviewer (Stephen Farrell). Since no text has been proposed as yet, and I agree with his premise, I will hold the discuss as a placeholder even after the discussion takes place...
      Actionable part:
      When an offeror "sees no reason to use the image attribute", section 3.2.1 recommends including the attribute with the wildcard. The security directorate review notes that an answerer could select attributes that would demand significant resources, resulting in a DOS attack. To resolve this, I believe some text needs to be added noting that memory and other resource considerations need to be considered before accepting the response, even if the specified attributes can be supported/accepted.
      Here's the discuss-discuss part: the ABNF permits the attribute list to be a wild card for both send and recv. Is there any good reason for the offeror to specify the wildcard (as opposed to an explicit list) for the send attribute list? Are there really any systems that would not restrict the formats it was willing to send to a list? Offering to send media without restricting the format seems to invite the kind of DoS attack that Stephen was thinking about. (Flexibility regarding reception of media seems more logical to me, although there is still a clear attack vector.)
    6. Peter Saint-Andre: Comment [2011-01-18]:
      The document is difficult to read in numerous places because of run-on sentences and non-standard English.
      I suggest that the authors review the conformance terms in accordance with RFC 2119, because sometimes lowercase keywords (lacking any conformance meaning) are used when uppercase keywords seem more appropriate...
      There are also several instances of uppercase keywords when no conformance meaning is in force...
    7. Sean Turner: Comment [2011-01-19]:
      I support Tim's discuss.

    Telechat:

  2. Datagram Transport Layer Security version 1.2 (Proposed Standard)
    draft-ietf-tls-rfc4347-bis-04
    Token: Sean Turner
    Note: Joe Salowey (jsalowey@cisco.com) is the document Shepherd.
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    Discusses/comments (from ballot 3537):
    1. Ron Bonica: Comment [2011-01-17]:
      Support OPS-DIR DISCUSS
    2. Stewart Bryant: Comment [2011-01-19]:
      (blank)
    3. Adrian Farrel: Discuss [2011-01-20]:
      Section 4.3 needs to inanding the factwithstclude a reference to RFC 5246 for the defnition of the syntax used. This is important (not that the changes are relative to 5246) because although the format looks like 'C' it is not 'C'
    4. Adrian Farrel: Comment [2011-01-20]:
      I support Alexey's Discuss about description of the changes since/to 4347
      Should the version numbering be recorded by IANA?
      How is wrapping of epoch and sequence number handled? Or is it considered that they will never need to wrap?
      It might be valuable to repeat the UDP warning from 4.1.2.7 in section 5
      Section 4.3: "This section includes specifications for the data structures that have changed between TLS 1.2 and DTLS."
      I think s/DTLS/DTLS 1.2/
    5. Russ Housley: Discuss [2011-01-18]:
      The Gen-ART Review by Miguel Garcia on 12-Dec-2010 raised a question about Section 4.1 that deserves a response. The reivew says:
      Section 4.1, previous last paragraph on page 8: The sentence requires implementations to compute the TCP maximum segment lifetime. If an implementation runs DTLS over UDP, how can it compute the TCP maximum segment lifetime, which is a parameter for a different protocol? I suspect DTLS implementations running over UDP (or even SCTP) will not have a clue of what is the TCP maximum segment lifetime.
    6. Alexey Melnikov: Discuss [2011-01-02]:
      1). 7. IANA Considerations: "This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS."
      Does this mean that this document Updates [TLS12]? Section 4.1.2.5 also confirms that.
      2). I don't see a section "changes since DTLS 1.0" required by ID-nits. Can you convince me that it is not needed?
    7. Alexey Melnikov: Comment [2011-01-02]:
      SCTP, RC4, SCTP-AUTH should have Informative references.
    8. Tim Polk: Comment [2011-01-20]:
      placeholder for Charlie Kaufman's secdir review - this deserves a response. I made this a comment since I know that the sponsoring AD intends to seem them addressed.
    9. Dan Romascanu: Discuss [2011-01-17]:
      The DISCUSS and COMMENT is largely based on the OPS-DIR review by Pekka Savola. I did not see the issues raised by Pekka answered and I believe that part of them (listed below) need to be addressed.
      1. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well.
      2. 3.2.3. Message Size: "TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length."
      4.1.1. Transport Layer Mapping: "Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer."
      ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation.
      3. "If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error."
      Why a 'should'? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure
      4. 7. IANA Considerations: "This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS."
      ... this may be inadequate. I was unable to find from the registry (tls-parameters) which of these parameters this applies to. All of them?
      If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables "DTLS-OK?" or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own.
    10. Dan Romascanu: Comment [2011-01-17]:
      1. The document does not have a "Changes from DTLS 1.0 (RFC4347)" section which is customary in 'bis' documents. Why?
      2. For the completeness, when referring to PMTU discovery, in addition to RFC1191 one should probably also refer to RFC1981 (the IPv6 version).
      [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, October 2003. ... this should probably be rfc5406?
    11. Peter Saint-Andre: Comment [2011-01-18]:
      I support Alexey's DISCUSS regarding the need for a section describing the changes from DTLS 1.0 (RFC 4347).

    Telechat:

  3. Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (Proposed Standard)
    draft-ietf-xmpp-3921bis-19
    Token: Gonzalo Camarillo
    Note: Joe Hildebrand (jhildebr@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3579):
    1. Lars Eggert: Comment [2011-01-17]:
      (two Nits)
    2. Adrian Farrel: Comment [2011-01-17]:
      I'm ballotting "no objection" based on selective reading of a few sections of this I-D and "trust" of the WG, the author, and the ADs who have ballotted "yes".
    3. Alexey Melnikov: Comment [2011-01-19]:
      I like Robert's comments, modulo the 4th point in his DISCUSS, which I think is already covered by rfc3920bis.
      In 4.3.2: "Implementation Note: The handling of the 'id' attribute in relation to presence probes was unspecified in RFC 3921..."
      Use of "however" can be read as if the 'id' attribute is not to be returned in the case specified below, however it is still returned. I suggest dropping "however" here.
      In 4.5.2: "The user's server MUST also send the unavailable notification to all of the user's available resources (including the resource that generated the presence notification in the first place)."
      Comment: The text in (): but the resource is unavailable :-).
      "The <subject/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML])."
      Should the same be said about presence' <status> element?
      11. Security Considerations: "A user's server MUST NOT leak the user's network availability to entities who are not authorized to know the user's presence, either via an explicit subscription as described herein or via an existing trust relationship (such as presence-enabled user directories within organizations)."
      I don't understand this paragraph. If a user is subscribed to presence, then she is authorized to know user's presence?
    4. Robert Sparks: Discuss [2011-01-19]:
      In section 3.1.3 item 4, a server is required to keep a complete presence stanza for an unbounded amount of time (potentially forever). This looks like a vector for a state-exhaustion attack. The restriction for keeping only one such stanza per sender helps, but a malicious attacking server could send stanzas from an arbitrary number of identites. I suggest providing implementation guidance on when it's ok to drop information that's truly stale, and call out the potential for this attack in the security considerations.
      Section 5.2.4 calls out "for the purpose of providing alternate versions of the same subject" when allowing multiple subjects to appear with different xml:lang attributes. Section 5.2.3 does not have analogous text constraining multiple bodies. Should it?
      Section 5.3 - Was the intent to constrain the contents of a message stanza to things intended to be rendered to a user? As written, this section would allow <message/> to be used as part of the framing of an arbitrary transport protocol.
      Section 5.3 - The document should say what an implementation receiving a child element in a namespace it doesn't understand should do with that child.
    5. Robert Sparks: Comment [2011-01-19]:
      In section 2.3.3, is the intent that error conditions listed earlier in the section take precedence over error conditions listed later in the section? What's the appropriate response if a message qualifies for both a <forbidden/> and a <bad-request/> as described in this section?
      When would an element choose not to follow the SHOULD in 3.1.2 item 1, and what are the consequences?
      The end of section 4.3 has an implementation note containing normative requirements. Can these be moved into the main prose? This same implementation note may be easy to misinterpret. I don't believe it is meant to prevent an implementation from returning an error to a malformed presence probe, but it could be read that way.
      Section 5.2.5 does not prevent a thread from claiming it is its own parent (should that be allowed?), or warn implementations about the possibility of thread A indicating a parent of B, and thread B indicating a parent of A (generalize this to any kind of cycle). I don't think XEP-0201 calls this out either. Should it be mentioned as an implementation consideration? (A naive implementation would very likely crash or do something surprising with its UI.)
      In section 8.5.2.1, I encourage adding text explaining why delivering to all non-negative resources is SHOULD and not MUST. I understand from out-of-band communication that local policy may determine that some particular resource not receive the message, but the document does not say this. As written, I can see implementations that adopt a policy of delivering to the first non-negative resource and claim they've met the requirement.

    Telechat:

  4. Pseudowire (PW) OAM Message Mapping (Proposed Standard)
    draft-ietf-pwe3-oam-msg-map-14
    Token: Stewart Bryant
    Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd.
    IPR: Cisco's Statement about IPR Claimed in draft-ietf-pwe3-oam-msg-map-05.txt
    Discusses/comments (from ballot 3588):
    1. Adrian Farrel: Discuss [2011-01-03]:
      There are a couple of nits reported by idnits (an out of date reference, an old license statement). I think the license statement should be fixed and posted (to reflect the authors' intent) before the document is approved.
      I see IPR disclosed at http://datatracker.ietf.org/ipr/863/ I don't see this declared in the proto write-up. More important, it is not present in the IETF last call announcement in datatracker.
      What is the situation wrt multi-segment PWs? I can understand that this document was developed before the WG turned to MS-PWs, but we now have RFC 5254 and RFC 5659.
      I would prefer that this document fully addressed MS-PWs. That would not be hard because each PW segment at an S-PE regards the adjacent segments as ACs, so it could probably be addressed in just one or two paragraphs in a new section.
      However, an option is to declare MS-PW out of scope, and provide a forward reference to work being done on OAM message mapping for MS-PWs in the PWE3 WG.
      Section 4.2: "If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it will be referred to as "VCCV-Ping". "
      I believe s/RFC4377/RFC5085/
      Section 5: You should add a note to explain why the CE ends of the ACs are not considered as possible defect locations. They are part of the emulated service, so a naif reader might expect to see them listed. Possibly you will want to explicitly include it in case (a).
      Additionally, your text does not match the figure: "c. Defect on a PE1 PSN interface." But (c) also appears on the PE2-PSN interface in the figure.
      Furthermore, (e) and (f) appear tbe reversed in the figure compared to the text.
      Section 13: RFC 5085 and RFC 4447 should be presented as references.
      I will let Security experts comment further, but:
      It seems to me that facilitating end-to-end coordination of PW status and fualt reporting provides an extra tool for attackers. I would expect this to be pointed out and held up as a reason for ensuring the use of the security mechanisms.
      I think that there are security coordination issues. Perhaps these are already mentioned in the references. Consider carrying NS OAM from CE to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM Loops mode. The security relationship perceived by the CEs would presumably be between each other, but doesn't the PE need to participate?
    2. Adrian Farrel: Comment [2011-01-03]:
      Section 3: s/whereby/where/
      The Introduction uses a number of acronyms without prior expansion...
      Section 4.1: Several acronyms are not used in the rest of the document...
      Section 4.2: "The words "defect" and "fault" are used interchangeably..." I'm fine with this, but I think "obstructs" is ambiguous. Do you mean "impose a complete blockage", or do you mean to include degradation in some form? Perhaps you could add a clarification.
      Section 4.2: "If BFD is run over a PW as described in [RFC5885], it will be referred to as "VCCV-BFD"." Add a reference to [RFC5880]
      Section 4.2: "A "transmit defect" is any defect that impacts traffic that is meant to be sent or relayed by the observing PE. A "receive defect" is any defect that impacts traffic that is meant to be received by the observing PE."
      While "meant to be" is appropriate for the reception of data, I don't think it necessarily applies to transmission. Consider that the defect may be somewhat downstream of (and not yet notfied to) the upstream PE such that the traffic that is impaced is that which *has* been sent or relayed by the observing PE.
      Additionally, the term "observing PE" has not been defined and may clarify or complicate the meaning of the text.
      I had a few problems with Section 8.1. I think my issue is with the use of the control plane as an OAM exchange mechanism (this also shows up in Appendix B). I believe the section could benefit from some polishing.
      "For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label Distribution Protocol [RFC3036] MUST use the LDP status TLV as the mechanism for AC and PW status and defect notification, as explained in [RFC4447]."
      I don't think that this "MUST" is good or consitent with:
      - the text in Section 7 that is relaxed in saying "LDP or in the ACH"
      - the work in MPLS-TP
      It sounds like 3036 (or rather 5036) is a normative reference.
      While conveying PW status in LDP per 4447 is fine, it is not OAM with the utility of rapid propagation of fault notifications. LDP, reliant as it is on TCP, is not suitable to that purpose.
      Wouldn't it be better to require the use of the ACH for OAM fault notification messages, and (if you must :-) mandate the use of LDP for status information propagation when LDP is present (but not as a replacement for real OAM).
      Additionally... "Additionally, a PE MAY use VCCV-BFD Connectivity Verification (CV) for fault detection only (CV types 0x04 and 0x10 [RFC5885]) but SHOULD notify the remote PE using the LDP Status TLV." The "SHOULD" here seems to be in conflict with te previous "MUST"
      And it goes on... "A PE that establishes a PW using means other than LDP, e.g., by static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types 0x08 and 0x20 [RFC5885]) for AC and PW status and defect notification. Note that these CV types SHOULD NOT be used when the PW is established with the LDP control plane."
      If you supply only a "MAY" you should probably describe how else the fault notification might work.
      As to the "SHOULD NOT" in the last sentence. Well, see my previous comments. And what possible harm could it do?
      Section 6: "Generally, a PE cannot detect transmit defects directly and will therefore need to be notified of AC transmit or PW transmit defects by other devices."
      I think you mean s/directly/direct/
      Section 8.1.1: "[RFC4447] specifies that the "Pseudowire forwarding" code point is used to clear all faults. It also specifies that the "Pseudowire Not Forwarding" code is used to convey any defect that cannot be represented by the other code points."
      The language seems rather week. The use of the code point does not clear the faults. It is used to report (notify) that the faults have been cleared. Likewise, defects are not conveyed by the use of a control points, but existence of the defect can be reported (or conveyed, if you like).
    3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

    Telechat:

  5. Indication of support for keep-alive (Proposed Standard)
    draft-ietf-sipcore-keep-11
    Token: Robert Sparks
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3595):
    1. Adrian Farrel: Comment [2011-01-17]:
      Section 1.2: "In some cases all SIP entities that need to be able to negotiate the usage of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them."
      Do you actually mean... "In some cases not all SIP entities that need to be able to negotiate the use of keep-alives might support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them."
      Or maybe more elegant as... "In some cases some SIP entities that need to be able to negotiate the use of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them."
    2. Alexey Melnikov: Comment [2011-01-12]:
      8. Grammar: "This specification defines a new Via header field parameter, "keep". The ABNF [RFC5234] is:
      via-params =/ keep
      keep = "keep" [ EQUAL 1*(DIGIT) ]
      "
      This doesn't tell me where <via-params>, <EQUAL> or <DIGIT> is defined. Please add the references as either ABNF comments or in the text before the grammar.
    3. Peter Saint-Andre: Comment [2011-01-10]:
      1. In second paragraph of the Security Considerations, please spell out "TLS" and "DTLS" on first use and add informative references for the relevant specifications.
      2. In the fourth paragraph of the Security Considerations, the specification says that a SIP entity MUST stop sending keep-alive requests if it does not receive responses to the STUN keep-alives that it sends to an adjacent downstream SIP entity. However, this does not take into account the fact that STUN requests and responses could be dropped, so it would be good to provide some more specific guidance here, e.g., stop sending STUN keep-alive requests if no STUN responses are received after sending two or more STUN requests (it seems suboptimal to stop sending STUN keep-alive requests if no response is received to only the very first STUN keep-alive request). Furthermore, no guidance is provided about the number of seconds the sender should wait before concluding that the adjacent downstream SIP entity has not responded. If these matters are covered in RFC 5389 then it would be helpful to cite the specific sections where they are discussed (e.g., Section 7.2.1 regarding retransmission timeouts).
    4. Sean Turner: Comment [2011-01-20]:
      Juergen Schoenwaelder spotted two editorial nits in the security considerations during his SECDIR review:
      a) [...] This specification does not specify a connection reuse mechanism, and it does it address security issues related to connection reuse. [...]
      s/it does it/it does not/
      b) [...] They do not instruct the enity to place a value in a "keep" parameter of any request it forwards. [...]
      s/enity/entity/

    Telechat:

  6. Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-martini-gin-12
    Token: Gonzalo Camarillo
    Note: Bernard Aboba (Bernard_Aboba@hotmail.com) is the document shepherd.
    Discusses/comments (from ballot 3597):
    1. Adrian Farrel: Comment [2011-01-20]:
      AOR is used without expansion in the abstract.
    2. Alexey Melnikov: Comment [2011-01-19]:
      In Section 7.1.2: "All base64 encoding discussed in the following sections MUST use the character set and encoding defined in RFC 2045 [1],"
      RFC 4648 is a better reference here.
      In Section 7.1.2.1: SHA256-80 needs a reference and an explanation (i.e. that the output of the hash function is truncated to 80 bits).
      The first reference to TLS needs an Informative reference.
    3. Dan Romascanu: Comment [2011-01-18]:
      The OPS-DIR review by Warren Kumari signalled a number of nits which would be useful to fix...
    4. Robert Sparks: Comment [2011-01-19]:
      The examples in section 8 have bugs that are important to fix before publication. The Call-ID changes unintentionally in each example. The messages that have two Via header field values have the values in the wrong order.
    5. Sean Turner: Discuss [2011-01-20]:
      #1) Section 7.1.2.2: The following threw me for a loop: "A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an HMAC key, PK_a. This value is used to validate that incoming GRUUs were generated by the SIP-PBX."
      I'm probably reading more in to "PK_a" than I ought to but it isn't a Public Key (PK) - right!? It would be bad to use a public key as the HMAC secret. SK_a is terminology used in Section 7.1.2.1 - can we use the same term or SK_SSP and SK_SIP-PBX?
      #2) The scenarios in Section 8.1 and 8.2 do not show the authentication step called. I think it should or the text should say we left them out but you still need to do them.
      #3) Alexey caught the bit about HMAC-256-80 needing a reference. I think it's a bigger deal because I don't which which parts of the output get used: 1st 80bits, last 80bits, etc.? It's hard to interoperate without knowing this. But, if a reference exists it'll be easy to clear.
    6. Sean Turner: Comment [2011-01-20]:
      Section 7.1.2.2: Seems like there should be a pointer to RFC 4086 for the "D" method.

    Telechat:

  7. Base Deployment for Multicast Listener Support in PMIPv6 Domains (BCP)
    draft-ietf-multimob-pmipv6-base-solution-07
    Token: Jari Arkko
    Note: Behcet Sarikaya (sarikaya@ieee.org) is the document shepherd.
    Discusses/comments (from ballot 3609):
    1. Stewart Bryant: Comment [2011-01-19]:
      I agree with Lars.
    2. Ralph Droms: Discuss [2011-01-18]:
      If I'm reading the document correctly, the LMAs arrange to receive multicast streams and forward the streams to the MAGs, which then forward the streams to subscribed MNs.
      In figure 1, suppose MN1, associated with LMA1, and MN2, associated with LMA2, are both associated with multicast stream MC. Will MAG1 receive copies of MC from both LMA1 and LMA2?
      Was a design considered in which the MAG arrange directly for the delivery of multicast streams as required by attached MNs?
    3. Lars Eggert: Discuss [2011-01-17]:
      DISCUSS: I'm not getting why this document is going for BCP. Informational seems fully adequate to me.
    4. Adrian Farrel: Discuss [2011-01-20]:
      The use of RFC 2119 language puzzles me. Are statement like:
      "As links connecting MNs and MAGs change under mobility, MLD proxies at MAGs MUST be able to dynamically add and remove downstream interfaces in its configuration."
      Making new definitions of behavior, or are they refering to existing norms specified elsewhere (that is, restating requirements)? In the former case, it looks like the document is actually Standards Track. In the latter case, I suggest inserting a reference and dropping to lower case.
      And other statements like: "In summary, the following steps are executed on handover:" [SNIP] "4. The MAG SHOULD determine whether the MN is admissible to multicast services, and stop here otherwise."
      In this case "SHOULD" is not indicative of a step that is executed.
    5. Adrian Farrel: Comment [2011-01-20]:
      MN-HNP is used without expansion
    6. Alexey Melnikov: Comment [2011-01-19]:
      I agree with Lars, although I don't have a strong opinion on the matter.
    7. Peter Saint-Andre: Comment [2011-01-18]:
      I concur with Lars's DISCUSS regarding the intended status of this document. Other than that, the document seems fine.

    Telechat:

  8. Routing Metrics used for Path Calculation in Low Power and Lossy Networks (Proposed Standard)
    draft-ietf-roll-routing-metrics-16
    Token: Adrian Farrel
    Note: David Culler (culler@eecs.berkeley.edu) is the document shepherd.
    Discusses/comments (from ballot 3622):
    1. Jari Arkko: Discuss [2011-01-18]:
      I am concerned about the complexity of the RPL system. The set of attributes is relatively complex, 8 different attributes (The BGP parameters registry has 26, but RPL is expected to be run in environments where there is no experts to monitor its operation or fine-tune the parameters.) The large set of attributes, dynamically changing parameters, complex topologies, and unattended operation seems like a recipe for operational and interoperability problems. I do recognize the need to have dynamic metrics, power-aware routing, and many of the other things in this specification, however. My question is whether this is the absolute minimum set that we should define. Do we need Section 2.1 A field? Section 3.1 A or O flags? The mid-complexity solution from Section 3.2? Section 4.3.1 *and* Section 4.3.2 reliability metrics?
      A few more specific concerns:
      Section 3.1: "A Flag: data Aggregation Attribute. Data fusion involves more complicated processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data."
      This is underspecified. And why do you talk about data fusion, if the attribute signals data aggregation. Please define what the semantics of the bit and the participant's behaviour is with respect to data aggregation, or point to a reference.
    2. Jari Arkko: Comment [2011-01-18]:
      I agree with Lars Eggert's Discuss.
      Section 4.3: "In LLNs, link reliability is degraded by external interference and multi-path interference (wireless links). Multipath typically affects both directions on the link equally, whereas external interference is sometimes unidirectional."
      I'm not sure I understand the term "multi-path interference" in this context. Perhaps you should use some other term. Multi-path usually refers to the use of multiple paths simultaneously. Radio interference from multiple links can certainly occur in ROLL networks. But I'm not sure why you call it "multi-path interference". I would probably just say "... degraded by attenuation (due to distance and objects) and interference (from external objects or within the RPL network)".
    3. Ron Bonica: Discuss [2011-01-19]:
      This may be a DISCUSS-DISCUSS.
      I believe that in order to achieve loop-free routing, the following conditions must be true:
      - all nodes must construct identical link state data bases (LSDB)
      - all nodes must run identical (or at least equivalent) SPF algorithms over that LSDB
      While I understand how ROLL devices might construct identical LSDBs, I don't understand how all nodes will run and identical (or even equivalent) SPF algorithms. The first problem is that all nodes don't neccessarily understand all metrics advertised with C-bit == 0. So, if all SPFs don't understand all of the same inputs, how can they be expected to produce the same outputs? THe second problem is an SPF with multiple inputs is pretty complex. Is it documented well enough that multiple vendors may produce interworking implementations? Finally, a node might advertise a metric with C-bit = 0 and then override that same metric with C-bit =1. When that happens, does the old advertisement disappear from the LSDB.
    4. Lars Eggert: Discuss [2011-01-17]:
      DISCUSS: My high-level concern with this document is that it focuses on how metrics are encoded in RPL TLVs, rather than giving formal and therefore unambiguous definitions of the metrics. Not in all cases, but in several. For example, the misnamed "throughput" metric doesn't make it clear whether it describes nominal link capacity or residual capacity, or whether it is an instantaneous metric or averaged over some period, etc. The "delay" metric leaves it open whether buffering delays are supposed to be included or not. The link reliability metric is much too open; when does e.g. a ZigBee link have a reliability of 5? When of 6? Hat about a BT-LE link? And so on.
      The reason I'm bringing this up is that in oder to have route selection pick paths for end systems based on these metrics, it needs to be understood what these metrics concretely *mean*. I don't think that's currently possible, and I believe that makes them rather less useful that advertised. If IPPM has taught us anything it's that metrics really do need to be unambiguously defined for them to be useful.
      I realize this discuss isn't really actionable. I plan to clear it after discussing my concern with the IESG call.
    5. Lars Eggert: Comment [2011-01-17]:
      (mostly Nits)
    6. Alexey Melnikov: Comment [2011-01-15]:
      In 2.1: "The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and he only valid when the R bit is cleared. Otherwise, the A field MUST"
      Is "he" should be here at all?
      4.1. Throughput: "Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format,"
      In network byte order? (Also in 4.2)
    7. Dan Romascanu: Discuss [2011-01-18]:
      1. Section 2.1 - Value: variable for Routing Metric/Constraint TLVs. What is the length range. 255 is maximum I assume, but is zero an acceptable length value?
      2. Section 3.1 - "An implementation MAY decide to add optional TLVs (not currently defined) to further describe the node traffic aggregator functionality."
      It is not clear to me how an implementation can make such a decision. Two different implementations would not be interoperable if this is not defined some place. Is this about extensibility?
      3. Section 3.2 - it is not clear from the text that estimating the 'energetic happiness' - actually the remaining power battery for battery operated devices is always possible, and if not how this metrics is being filled in. Will just the E bit be cleared and no estimation provided?
      4. Section 4.2 - the latency metric is unsufficiently defined. What is the measurement observation point? is buffering taken into consideration?
      5. Section 4.3.1: "The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7 where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document."
      This seems broken. How can interoperability be ensured between two independent implementations if the metric is a discrete value whose algorithm of determination is implementation specific?
    8. Dan Romascanu: Comment [2011-01-18]:
      1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear.
      2. Expand DIO at first occurence
      3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity.
    9. Peter Saint-Andre: Comment [2011-01-19]:
      Based on the reviews provided by IESG members more expert than I in the technology under consideration, I am ballotting "No Objection". That said, based on my own review I concur with the DISCUSS raised by Jari Arkko regarding the complexity of the system.

    Telechat:

  9. Compression Format for IPv6 Datagrams in 6LoWPAN Networks (Proposed Standard)
    draft-ietf-6lowpan-hc-13
    Token: Ralph Droms
    Note: The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann
    (cabo@tzi.org).
    Discusses/comments (from ballot 3627):
    1. Jari Arkko: Comment [2011-01-19]:
      Ari Keränen reviewed this draft. His comments: ...
    2. Ron Bonica: Comment [2011-01-19]:
      I also support the GENART DISCUSS on the checksum
    3. Stewart Bryant: Comment [2011-01-19]:
      I support Russ' Discuss on the checksum.
      The mandatory use of checksum in IPv6 is controversial amongst some IETF communities (particularly the community using UDP as a tunnel type). Either this controversy needs to be resolved, or draft-ietf-6lowpan-hc needs to deal correctly with the c/s /no c/s case. It could of course do this by always carrying the c/s, but it seems perverse to have to carry 16 bits of c/s to say that there is no c/s.
    4. Lars Eggert: Discuss [2011-01-17]:
      [Edited to include David Black's gen-art review, since I'm already holding a discuss on part of the issues he has raised.]
      Section 4.3.2., paragraph 1: "The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason [RFC4944] disallows the compression of the UDP checksum. With this specification, a compressor in the source transport endpoint MAY elide the UDP checksum if it is authorized by the Upper Layer. The compressor SHOULD NOT set the C bit unless it has received such authorization. The Upper Layer SHOULD only provide the authorization in the following cases"
      DISCUSS: First, I think you want to use "MUST NOT" and "MAY only" here. Second, there are additional issues here (see draft-ietf-6man-udpzero). For example, even if there is an upper layer integrity check present for a given app, if the port number field gets corrupted and a message gets mis-delivered to an incorrect application (port), *that* application may not have an upper layer integrity check implemented to protect it. And so on. Have you run this part of the spec by 6MAN?
      Also, from David Black: "A forwarding node MAY imply authorization from an incoming packet if the C bit is set. A forwarding node that cannot unambiguously derive such authorization SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression."
      This needs to be a MUST NOT.
    5. Adrian Farrel: Discuss [2011-01-16]:
      Section 4.3.1: "This specification introduces a range of well-known ports (0xF0Bx) that can be compressed to 4 bits."
      I don't believe that these are "Well Known Ports". They would be in the range 0-1023.
      They appear to be "Dynamic and/or Private Ports"
      I guess you are trying to say that these ports are known by 6lowpan hc implementers. Maybe a complete rewriting of this sentence?
      "This specification defines the use of range of ports from the Dynamic and/or Private Ports range. Using only ports of the type 0xF0Bx means that the port number can be compressed to 4 bits."
      But I am unclear that you are really using this range of port numbers! Are you not actually using 4 bits to encode up to 16 port number aliases and, as your text says, you require some mapping to be installed to expand those aliases back to real port numbers.
      If I am wrong (and you are really using ports in the range you state) you need to add text to indicate how this is safe and will not clash with other usage of these port numbers that might happen randomly as an application picks (dynamically or privately) some port number to use.
    6. Adrian Farrel: Comment [2011-01-16]:
      I found a few small points of house-keeping: ...
    7. Russ Housley: Discuss [2011-01-18]:
      The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion about the use of checksums with UDP. This discussion does not seem to be over. The last thing that I saw was:
      "I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point."
      This discussion needs to reach a resolution before this document is approved.
    8. Peter Saint-Andre: Comment [2011-01-10]:
      1. According to Section 2, this document appears to update RFC 4944. However, the document header does not include "Updates: RFC 4944".
      2. In Section 6, please add an informative reference for Transport Layer Security (TLS).
    9. Sean Turner: Comment [2011-01-20]:
      I support Russ's discuss.

    Telechat:

  10. Extensions to IS-IS for Layer-2 Systems (Proposed Standard)
    draft-ietf-isis-layer2-09
    Token: Stewart Bryant
    Note: David Ward (dward@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3645):
    1. Ron Bonica: Comment [2011-01-17]:
      Please run the nit-checker. There are a few missing and unused references.
    2. Ralph Droms: Discuss [2011-01-18]:
      IESG Writeup appears to be missing; will clear when I can review the background on WG review and consensus.
    3. Ralph Droms: Comment [2011-01-18]:
      Extraordinarily pedantic nit: MAC address in section 2.1 is not to scale...
    4. Lars Eggert: Comment [2011-01-17]:
      Section 2.2., paragraph 2: "Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]."
      What's TBD here?
    5. Russ Housley: Comment [2011-01-19]:
      Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 19- Jan-2011.
    6. Alexey Melnikov: Comment [2011-01-14]:
      2.2. Multi Topology aware Port Capability TLV: "Topology Identifier: MT ID is a 12-bit field containing the MT ID of the topology being announced. This field when set to zero implies that it is being used to carry base topology information."
      Excuse my ignorance, but is this description actually sufficient for interoperability? Which values are valid here and where are they coming from?
      Also I don't think specifying exact values before they are assigned by IANA is a good idea.
    7. Dan Romascanu: Discuss [2011-01-18]:
      The OPS-DIR review by Menachem Dodge (posted in the tracker) raised a number of issues which I believe require clarification and edits. As the authors of the document answered that they will deal with the comments in a revised version of the document I am holding a DISCUSS until the comments are resolved by edits or detailed clarification answers.

    Telechat:

  11. TRILL Use of IS-IS (Proposed Standard)
    draft-ietf-isis-trill-04
    Token: Stewart Bryant
    Note: David Ward (dward@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3646):
    1. Ralph Droms: Discuss [2011-01-20]:
      This DISCUSS is a placeholder to ensure an issue with draft-ietf-trill-rbridge-protocol-16 is addressed before publication. I"ll clear as soon as updates to draft-ietf-trill-rbridge-protocol-16 are agreed to and the RFC Editor is informed of the changes.
      draft-ietf-trill-rbridge-protocol-16 was written before draft-ietf-isis-layer2 was split into 3 documents. A reference to draft-ietf-isis-trill needs to be added to draft-ietf-trill-rbridge-protocol-16, and citations to draft-ietf-isis-layer2 need to be checked against the split between draft-ietf-isis-layer2 and draft-ietf-isis-trill.
      This DISCUSS also applies to draft-ietf-isis-layer2, but there is no need to delay publication of draft-ietf-isis-layer2 while draft-ietf-trill-rbridge-protocol-16 is updated.
    2. Lars Eggert: Comment [2011-01-17]:
      (Nit)
    3. Alexey Melnikov: Comment [2011-01-16]:
      It might be worth mention the byte order used for fields longer than 1 byte.
    4. Dan Romascanu: Discuss [2011-01-17]:
      Before approving this document I believe that the following statement made in the Introduction section needs clarification:
      "Intermediate Systems (ISs) implementing TRILL are compatible with IEEE 802.1 customer bridges and can incrementally replace such bridges."
      What does 'compatible' mean in this context? What are the IEEE 802.1 customer bridges that can incrementally be replaced by ISs implementing TRILL. Either a reference to the exact IEEE 802.1 standards or a reference to the IETF documents that specify these would be useful.

    Telechat:

  12. Generalized Labels for Lambda-Switching Capable Label Switching Routers (Proposed Standard)
    draft-ietf-ccamp-gmpls-g-694-lambda-labels-11
    Token: Adrian Farrel
    Note: Lou Berger (lberger@labn.net) is the document shepherd.
    Discusses/comments (from ballot 3670):
    1. Stewart Bryant: Comment [2011-01-19]:
      "In the scenario of Figure 1, consider the setting up of a bidirectional LSP from ingress switch 1 to egress switch 9 using GMPLS RSVP-TE."
      Figure 1 shows them as nodes
      "To deal with the widening scope of MPLS into the optical and time domains"
      I think that you mean ... optical switching and time division multiplexing domains.
      "In a case, the label indicates the wavelength to be used for the LSP."
      Do you mean "In this case.." ?
    2. Alexey Melnikov: Comment [2011-01-20]:
      I am missing some text about byte order for 16bit fields.
      4. Security Considerations: "This document introduces no new security considerations to [RFC3471] and [RFC3473]. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]."
      Surely lasers are dangerous weapons and kids shouldn't be allowed to play with them.

    Telechat:

  13. IPv4 and IPv6 Infrastructure Addresses in Multicast-VPN Routes (Proposed Standard)
    draft-ietf-l3vpn-mvpn-infra-addrs-02
    Token: Stewart Bryant
    Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the document shepherd.
    Discusses/comments (from ballot 3671):
    1. Stewart Bryant: Comment [2011-01-18]:
      - In a couple of places, the word "route" occurs where it would be clearer to say "NLRI"
      - The paragraph on "VRF Route Import Extended Community" is misplaced, as it is an attribute of IP-VPN routes rather than of MCAST-VPN routes; this paragraph should probably be a top-level section of its own.
      - That paragraph contains the term "IPv6 Address Specific Route Target" when it should say "IPv6 Extended Community".
    2. Lars Eggert: Comment [2011-01-17]:
      I agree with Alexey's discuss that this document is probably missing a bunch of "updates" relationships.
      Additionally, with regards to [MVPN-BGP], could some or maybe all of the content of this ID rolled into [MVPN-BGP]? (Since that isn't actually published yet?)
    3. Adrian Farrel: Comment [2011-01-16]:
      I have reviewed this I-D and support its publication as an RFC with the change proposed to resolve Alexey's Discuss.
    4. Russ Housley: Discuss [2011-01-18]:
      The Gen-ART Review by Suresh Krishnan on 17-Jan-2011 asks a question that deserves a response: will this document update draft-ietf-l3vpn-2547bis-mcast-bgp-08, once it is published as an RFC?
    5. Alexey Melnikov: Discuss [2011-01-16]:
      The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW needs to be. Maybe it would need to update multiple RFCs.
      For example, when I read this text:
      1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes: "[MVPN-BGP] defines a new set of BGP route types that are used by SPs to provide Multicast Virtual Private Network service to their customers. These routes have a newly defined BGP NLRI, the "MCAST-VPN" NLRI... ..."
      It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or [BGP-MP]. Thus it looks like it should be Updating at least one of them.
      As per reply from Eric Rosen: the document should use "Updates: [MVPN-BGP]"

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (BCP)
    draft-saintandre-tls-server-id-check-14
    Token: Alexey Melnikov
    Note: There is an open question on whether this document should be a BCP or PS. As the shepherding AD I don't have a strong opinion either way.

    Discusses/comments (from ballot 3205):
    1. Lars Eggert: Comment [2011-01-17]:
      Section 1.5., paragraph 8: "These suggestions are not entirely consistent with all practices that are currently followed by certification authorities, client developers, and service providers. However, they reflect the best aspects of current practices and are expected to become more widely adopted in the coming years."
      This seems to argue that the doc should be a BCP and not a PS?
      (three Nits)
    2. Tim Polk: Discuss [2011-01-20]:
      This is a discuss-discuss. I support publication as a BCP, but thought some of the guidance should be much stronger.
    3. Robert Sparks: Discuss [2011-01-19]:
      I agree with the review comments supporting publishing this as PS and not as BCP.
      The majority of this document is specifying behavior that is appropriate to progress through the standards ladder. There is a small section providing guidance to certificate authorities that could be written as a BCP, encouraging "full and immediate instantiation" (see section 5.1 of RFC2026). If it's important to give that section BCP designation, I suggest placing it in a separate document. However, I think it will have the same effect in this document, published as PS.
      Assuming the consensus is to move forward as proposed standard, I expect to move to a "Yes" position.

    Telechat:

  2. Signer Info Algorithm Protection Attribute (Proposed Standard)
    draft-schaad-smime-algorithm-attribute-04
    Token: Sean Turner
    Note: Jim Schaad (ietf@augustcellars.com) is the Document Shepherd.
    Discusses/comments (from ballot 3664):
    1. Lars Eggert: Comment [2011-01-17]:
      INTRODUCTION, paragraph 4: Signer Info Algorithm Protection Attribute: "A new attribute is defined that allows for protection of the digest and signature algorithm structures in an authenticated data or a signer info structure. Using the attribute includes the algorithm definition information in the integrity protection process."
      It's be good if the title and abstract had some context that this stuff is about CMS...
    2. Adrian Farrel: Comment [2011-01-18]:
      The use of the passive voice in the first sentence of the Abstract is disconcerting!
      There is also some missing context!
      The second sentence is pretty hard to parse. Why not write:
      "This document defines a new attribute that allows for protection of the digest and signature algorithm structures in an authenticated data or a signer info structure used in the Cryptographic Message Syntax (CMS). When the new attribute is used, the algorithm definition information is included in the integrity protection process."
      The introduction would benefit from a similar (but more verbose) fix.
      I think it is conventional to include a reference to the ASN.1 spec that defines the language you are using. Presumably X.208 (1988) and X.209 (1988) could be added as references.
    3. Russ Housley: Discuss [2011-01-19]:
      Some signature algorithms, such as RSA PKCS#1 v1.5, sign both the digest algorithm identifier and the message digest. So, if the attacker changes the identifier, the signature will not validate. While this is not true of all signature algorithms, it does significantly diminish the scope of the concern being addressed by this document. Please add this to the discussion.
    4. Robert Sparks: Comment [2011-01-19]:
      Can the section on comparing fields in the verification process (2nd paragraph of section 3) be made more precise? Currently, it says "It is not required that a field which is absent in one case and present in another case be compared as equivalent". Does that mean it's allowed to compare those as equivalent? Or was the intent that they MUST NOT be equivalent?

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Example call flows using Session Initiation Protocol (SIP) security mechanisms (Informational)
    draft-ietf-sipcore-sec-flows-08
    Token: Gonzalo Camarillo
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3629):
    1. Alexey Melnikov: Comment [2011-01-19]:
      6. Additional Test Scenarios: "assure that the most specific CommonName in the Subject field matches if there are no dNSName entries in the subjectAltName at all (which is not the same as there being no matching dNSName entries). This match can be either exact, or against an entry that uses the wildcard matching character '*' "
      Anywhere in the domain pattern or only in the leftmost position?
      Nits: The usual (many acronyms are not spelled out on first use, etc.)
    2. Dan Romascanu: Comment [2011-01-18]:
      The 'Observed Interoperability Issues' section includes a number of example of implementation problems detected during the SIPit events. I can guess that this information canges in time, as interoperability problems due to implementation bugs or lack of clarity in documents are in the majority of the cases being fixed in the coming releases of the implementations. For this purpose it would be useful I think to mention what is the time reference (may be the indication of the SIPit event) when the problems were detected.
    3. Peter Saint-Andre: Comment [2011-01-18]:
      This is a fine document. My only nits ...
    4. Sean Turner: Discuss [2011-01-20]:
      #1) The AKIs seems to include all three possibilities. RFC 5280 says: "The identification MAY be based on either the key identifier (the subject key identifier in the issuer's certificate) or the issuer name and serial number."
      It also goes on to recommend using the keyIdentifier choice. I'd remove the other two (authorityCertIssuer and authorityCertSerialNumber) they're just making the certificates bigger than they need to be.
      #2) User certificate subject names: look a lot like email addresses. RFC 5280 requires that new implementations put the email address in the SAN extension with the rfc822Name choice. Shouldn't the last component of the user's common name be Cullen Jennings, Kumiko, etc and then put the email addresss in SAN:rfc822Name?
    5. Sean Turner: Comment [2011-01-20]:
      Appendix A: Add an informative reference to PKCS#8 [RFC5958].
      ASN.1 dumps: The "hority" wraps around the line oddly.
      Section 5: Is it worth noting that the SHA2 algs also say don't include the parameters according to [RFC5754].

    Telechat:

  2. A Security Framework for Routing over Low Power and Lossy Networks (Informational)
    draft-ietf-roll-security-framework-04
    Token: Adrian Farrel
    Note: JP Vasseur (jpv@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3630):
    1. Russ Housley: Discuss [2011-01-19]:
      The Gen-ART Review by David Black raised a significant concern. The confidentiality and privacy requirements are SHOULD. It seems to me that they ought to be "MUST implement" so that every implementation can be configured to make use of confidentiality and privacy. An alternative would be "MUST implement" coupled with "SHOULD use when" statements, or "SHOULD" coupled with "geographic information MUST NOT be handled when confidentiality protection is not enabled."
    2. Tim Polk: Discuss [2011-01-20]:
      I think this is a really good document, and support its publication. However, I think some of the issues I was persuaded to remove from my discuss on roll-rpl because they would be more appropriate in this document were omitted. I am specifically concerned about punting the details on public key distribution, then finding they are not covered here either.
      Did I get the wrong document? Where are those issues going to be addressed?
      I will hold this discuss while we sort out the best place to address these issues...
    3. Peter Saint-Andre: Comment [2011-01-19]:
      1. In Section 3.2, "the service of non-repudiation implies after-the-fact" sounds like it should be "the service of non-repudiation applies after-the-fact" but instead the authors seem to mean that "the service of non-repudiation implies that the attack occurs after the fact" or somesuch.
      2. In Section 3.3, "can all contribute to key management issues" could be construed as contributing to important or critical ("key") issues related to network management, not as "complicating the operations of key management" as in the previous paragraph; I suggest repeating the previously-used phrasing.
      There are also several unfortunate typographical errors (e.g., "fundament" instead of "fundamental" in Section 3.4, "undue utilization of exhaustion" instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local or remote" instead of "any local or remote device" in Section 5.1.5, "compliment" instead of "complement" in Section 6.1, "aimed the manipulation" instead of "aimed at the manipulation" in Section 6.5).
      With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference to RFC 4732.
      Please provide informative references for OSPF and ISIS in Section 5.2.5.
      In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may therefore be concurrently generated or updated"?
      In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a process for key and credential distribution"?
      In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the routing protocol(s) specified by the ROLL Working Group should assume that the system affords key management mechanisms consistent with the guidelines given in [RFC4107]"?
      In Section 6.5, is uppercase "SHOULD" meant in the text " As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy"?
      (And so on; in general, I suggest that the authors check all lowercase keywords throughout Section 6.)

    Telechat:

  3. MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (Informational)
    draft-ietf-mpls-tp-uni-nni-03
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    Discusses/comments (from ballot 3656):
    1. Russ Housley: Discuss [2011-01-19]:
      The Gen-ART Review by Ben Campbell on 21-Dec-2010 lead to a discussion. The discussion of Figure 1 and Figure 2 does not seem to be finished. The discussion needs to reach closure before this document is approved.

    Telechat:

  4. Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses (Informational)
    draft-ietf-mptcp-threat-07
    Token: Lars Eggert
    Note: Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the document shepherd.
    Discusses/comments (from ballot 3669):
    1. Jari Arkko: Comment [2011-01-19]:
      In Section 3, where the document discusses differences between MIPv6 RO and MPTCP situation I had a couple of comments. First, I'm not sure I understand what you mean with the bullet about MIPv6 relying on the original path always being available. MIPv6 certainly assumes that the path that we are using at that moment is working, and if it is not, the system will attempt to move to some other address or network attachment point. Secondly, I think you are missing one additional difference: in MIPv6 we assume that there's always a trusted third party (the home agent) that can help us with some of the security problems. In MPTCP there is no such entity. You might also be missing the difference that MPTCP intends to be able to use multiple paths simultaneously, which was not an original design goal of the MIPv6 work.
      In Section 6.3, the text discusses the effects of NAT on securing the implicitly reported new address. The text fails to explain that while explicit mode would allow better protection of the reported new address, such protection would be pointless because it would protect an address that is no longer relevant on the outside of the NAT. You actually *need* to report the address as changed by the NAT. And by the way, I see nothing wrong with that... that's is how current TCP works, too.
      I like the basic recommendations in Section 7. But I am unsure if the analysis in the document actually supports the advanced recommendation to have optional support for HMAC. Why would that needed? Also, should the conclusions say something about how MPTCP design should deal with sequence number spaces -- it seems that different choices here would result in different impacts.
    2. David Harrington: Comment [2011-01-19]:
      While fully understandable, I found the text a bit wordy, with extra phrases and clauses thrown in where they really weren't needed. This document could be much more concise, and if you are doing a new revision, you might want to consider tightening up the text. But this is purely a style issue, and the authors are free to ignore this comment if they so choose. ...
    3. Alexey Melnikov: Comment [2011-01-15]:
      In Section 1: "This note includes a threat analysis for MPTCP. It should be noted that there are there may other ways to provide multiple paths for a TCP"
      This doesn't read well
      In Section 3: "Similarly to the MPTCP case,"
      Did you mean "MIPv6 RO" here?
    4. Dan Romascanu: Comment [2011-01-20]:
      In the OPS-DIR review Lionel Morand raised the issue that it is recommended to allow the support of multiple security mechanisms but there is nothing about potential related mechanism negotiation issues. I suggest that this be addressed before the publication of the document, even if it is not a blocking issue.

    Telechat:

  5. Architectural Guidelines for Multipath TCP Development (Informational)
    draft-ietf-mptcp-architecture-04
    Token: Lars Eggert
    Note: Philip Eardley (philip.eardley@bt.com) is the Document Shepherd.
    Discusses/comments (from ballot 3672):
    1. Jari Arkko: Comment [2011-01-19]:
      An excellent document. Thanks for writing it. I would change the urgent data support to a MAY, however.
    2. David Harrington: Comment [2011-01-19]:
      1) The architecture document has no discussion of how MPTCP should be managed, or what types of information should be made accessible for management purposes. I believe it should - at an architectural level.
      However, since this is the architecture document for a protocol being put forth as Experimental, it would be beneficial to take the results of the experiment into consideration when designing an appropriate management solution. Therefore, I have reduced this to a comment.
      TCP is intrumented with a MIB that is widely implemented on devices and used by network management applications. MPTCP should share that MIB for aspects that are designed to be transparent to the application. However, there should be extensions specific to MPTCP so an operator can monitor the operational state and impact of MPTCP. For example,
      a) MPTCP should be able to be enabled/disabled, the enabled/disabled state should be able to be queried, and the fallback mentioned in section 2.1 should be indicated in operational state.
      b) if there are errors or congestion on a path and MPTCP can detect those errors or congestion, it should make that information available to an operator via the MIB.
      c) if MPTCP can determine the performance of each path, that information should be made available via the MIB for use by performance monitoring applications.
      d) if MPTCP can determine the different security state of different paths, that information should be made available via the MIB. It would probbaly be good if an operator can choose to provide a weight for different paths based on the security properties of the path.
    3. Russ Housley: Discuss [2011-01-19]:
      The Gen-ART Review by Joel Halpern on 14-Jan-2011 raises one concern that needs to be addressed. That is, "break-before-make" is added in the security design decisions in section 5.8. Even if this is merely a desirable behavior, it should be described in the behaviors before being referenced in the design decisions.
    4. Alexey Melnikov: Comment [2011-01-16]:
      5.6. Connection Identification: "Legacy applications will not, however, have access to this identifier and in such cases a MPTCP connection will be identified by the 5-tuple of the first TCP subflow. It is out of the scope of this document, however, to define the behaviour of the MPTCP implementation if the first TCP subflow later fails... In the case of applications that have used an existing API call to bind to a specific address or interface, the MPTCP extension MUST NOT be used, since the applications are indicating a clear choice of path to use and thus will have expectations of behaviour that must be maintained, in order to adhere to the application compatibility goals."
      I am not convinced your use of MUST NOT is correct here. In fact, it seems that it is in direct conflict with the following paragraph:
      "Since the requirements of applications are not clear at this stage, however, it is as yet unconfirmed what the best behaviour is. It will be an implementation-specific solution, however, and as such the behaviour is expected to be chosen by implementors once more research has been undertaken to determine its impact."
      I.e., it is actually possible to know from the current socket API what is the application intent in this case?
    5. Dan Romascanu: Comment [2011-01-20]:
      I support David's COMMENT

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. URI Scheme for Java(tm) Message Service 1.0 (Informational)
    draft-merrick-jms-uri-11
    Token: Alexey Melnikov
    Discusses/comments (from ballot 3514):
    1. Lars Eggert: Comment [2011-01-17]:
      INTRODUCTION, paragraph 4: "The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it."
      So are there vendor implementations of 'jms' already? If yes, what it the value in publishing a specification that is not compatible with any of them? Or do we have an indication that the vendors will adopt this spec?
    2. Alexey Melnikov: Comment [2011-01-14]:
      It looks like IANA issue was actually addressed in the last revision.

    Telechat:

  2. Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) (Informational)
    draft-nsri-tls-aria-01
    Token: Sean Turner
    Note: Woo-Hwan Kim (whkim5@ensec.re.kr) is the document shepherd
    Discusses/comments (from ballot 3662):
    1. Adrian Farrel: Comment [2011-01-20]:
      "This document proposes the addition of new cipher suites to the Transport Layer Security (TLS)"
      Please don't be so timid. "This document defines/specifies ..."
    2. Dan Romascanu: Comment [2011-01-18]:
      Please expand PRF at first occurence.

    Telechat:

  3. Experiment: Hash functions with parameters in CMS and S/MIME (Experimental)
    draft-schaad-smime-hash-experiment-04
    Token: Sean Turner
    Note: Jim Schaad (ietf@augustcellars.com) is the document shepherd.
    Discusses/comments (from ballot 3665):
    1. Lars Eggert: Discuss [2011-01-17]:
      DISCUSS: ID is missing the RFC2119 boilerplate and reference.
    2. Lars Eggert: Comment [2011-01-17]:
      (Nits)
    3. Russ Housley: Discuss [2011-01-19]:
      There are many algorithm identifiers that specify a hash algorithm and a signature algorithm used in combination. It is highly desirable that the same hash algorithm be used for computing the digest of the attributes and the content. How would xor-md5WithRSAEncryption be handled?
    4. Alexey Melnikov: Discuss [2011-01-19]:
      I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved: ...
    5. Alexey Melnikov: Comment [2011-01-19]:
      RFC 1847 needs to be an Informative Reference. I think MIME as well.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational)
    draft-zorn-radius-keywrap-18
    Token: Dan Romascanu
    Discusses/comments (from ballot 2377):
    1. Lars Eggert: Comment [2007-01-25]:
      Agree with Russ and Dan.
    2. Dan Romascanu: Comment [2011-01-13]:
      In the Abstract Section s/This attributes/These attributes/

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. The Internet Routing Overlay Network (IRON) (Experimental)
    draft-templin-iron-17
    Token: Jari Arkko
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot 3638):
    1. Jari Arkko: Comment [2010-12-16]:
      (blank)
    2. Stewart Bryant: Comment [2010-12-15]:
      I am surprise that the document contains no reference to LISP which is operating broadly in this space.
      SRA is not a defined abbreviation.
      This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay: "After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages."
      "If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping."
      "quickly" is a non-specific metric
      [I-D.templin-intarea-seal] looks like it should be normative
      [I-D.templin-intarea-vet] looks like it should be normative
      Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.
    3. Ralph Droms: Comment [2010-12-16]:
      I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it?
      The remainder of my COMMENTs are editorial. ...
    4. Adrian Farrel: Comment [2010-12-16]:
      Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions.
      I feel that it would be helpful if the document contained a pointer to draft-irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.

    Telechat:

1257 EST break

1302 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Light-Weight Implementation Guidance (lwig)
    Token: Jari

    Telechat:

4.1.2 Proposed for Approval

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

    Telechat:

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

    Telechat:

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

    Telechat:

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

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Mobility EXTensions for IPv6 (mext)
    Token: Jari

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IPR disclosure mailing list selections (Jari Arkko)

    Telechat:

  2. Archiving Media Type registrations from other SDOs on www.iana.org (Alexey Melnikov)

    Telechat:

  3. Request for early allocation [IANA #419797] (Michelle Cotton)

    Telechat:

  4. Posting rights to the iesg-only@ietf.org mailing list (Alexey Melnikov)

    Telechat:

  5. Executive Session (Russ)

    Telechat:

7. Agenda Working Group News

1458 EST End of open session

Appendix: Snapshot of discusses/comments

(at 2011-01-20 07:27:33 PST)

draft-ietf-mmusic-image-attributes

  1. Adrian Farrel: Comment [2011-01-20]:
    I have only partially reviewed this document, but I have no objection to
the technical content in this document. I found a lot of the text 
somewhat ambiguous or hard to parse, and the number of such issues was 
(IMHO) close to making the document quality suspect and warranting a 
Discuss. Although the RFC Editor will work on these issues, it is my 
opinion that such a level of changes will result in a proportion of
cases will result in:
- bad fixes made by the RFC Editor
- issues being missed.

I urge the authors to at least make fixes to the issues I have
identified, and preferably find a technology-aware native speaker to
review and update the text.

---

The Abstract really needs to mention SDP

I would prefer if the Introduction was also clearer sooner that this 
document applies to SDP

---

SDP is not a well-known acronym according to the RFC Editor
(http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)
so should be expanded:
- in the title
- in the Abstract when you add it
- on first use in the main text

---

You should expunge all references to "draft" and replace with "document"
(when published as an RFC, this will not be a draft!)                    

---

In the Abstract...

   The draft also helps to maintain an optimal bitrate for video
   as only the image size that is desired by the receiver is
   transmitted.

A nice trick if you can do it, but actually, I think that someone needs
to implement something! How about...

   The mechanisms defined in this document can also be used to help
   maintain an optimal bitrate for video, as only the image size that is
   desired by the receiver is transmitted.

---

Section 1

   This document proposes a new attribute to make it possible to
   negotiate different image attributes such as image size.  The term
   image size is defined here as it may differ from the physical screen
   size of for instance a hand-held terminal.

I do not find the term "image size" defined.
You may want s/defined/used/ or you may want to add the definition.

---

Section 1

   There are a number of benefits with a possibility to negotiate the
   image size:

/with a/to the/

---

Section 1

   o  Optimal quality for the given bitrate: The sender does not need to
      encode an entire CIF (352x288) image if only an image size of
      288x256 is displayed on the receiver screen.  This alternatively
      gives a saving in bitrate.

s/alternatively/alternative/  ?

---

REQ-1
s/wish/wishes/

---

3.1.1

   o  The attribute typically contains a "send" and a "recv" keyword.
      These specify the preferences for the media once the session is
      set up, in the send and receive direction respectively from the
      point of view of the sender of the session description.  One of
      the keywords ("send" or "recv") MAY be omitted, see Section 3.2.4
      and Section 3.2.2 for a description of cases when this may be
      appropriate.

I see this saying:
   The attribute MUST contain at least one of the keywords "send" and
   "recv".

---

3.1.1

   o  For sendrecv streams both of the send and recv directions SHOULD
      BE present in the SDP.

s/BE/be/

---

3.1.1

   o  For inactive streams it is RECOMMENDED that both of the send and
      recv directions are present in the SDP.

s/SDP/SDP message/ ?

---

3.1.1.1

   Payload type number (PT):  The image attribute is bound to a specific
      codec by means of the payload type number.

It may be obvious, but there is no statement of where the possible 
values of PT can be found. I think you should add this.
  2. David Harrington: Comment [2011-01-18]:
    This document is well-written. These comments require no action by the authors,
but if these fixes were applied, it might make for a cleaner document.

1) in the first sentence of the introduction, s/attribute/SDP attribute/
2) in
the introduction, sar used without definitinon or reference
3) in 3.1.1, for
sendrecv streams you use SHOULD BE - BE is not an RFC2119 keyword. The next
bullet uses RECOMMENDED. RECOMMENDED and SHOULD mean the same things in RFC2119.
It woul dbe nice to be consistent so people ar enot in any way confused by the
different language.
4) in 3.1.1.1, the sentence starting "several image
attributes can be defined" is a bit convoluted, and it makes it difficult to
parse. "conditioned that" is an unusual wording that makes it harder to parse.
It is unclear whether the "conditioned that" is part of the "for instance", or
part of the "can be defined".
5) payload type - what s the range? are these
types defined in a registry someplace?
6) preference - what is the range of q?
is this 0.0-1.0, or are 100.0 and -65537.7 valid values? 
7) sar - what is the
range of values?
7) sar - I am confused by the "(range)" in this sentence - do
you mean it defines a specific range of sample aspect ratios associated to a
given x and y image size?
8) "The response MUST NOT include a sar parameter if
there is no acceptable value given." - what does acceptable mean here?  
9) how
does one express a sar range? is it "0.1-0.7" or "0.1...0.7" or dx/dy "0.1/0.7"
or 0.142857143?
10) "The offerer must be able to support ... The exception is"
Isn't MUST with an exception a SHOULD?
11) Can we capitalize the RFC2119
keywords?
12) "to reduce this risk", why isn't this a MUST?
13) in 3.2.2
s/answer/answerer/
14) in 3.2.2, if the third approach solves the problem and
has no drawbacks, why not make that one a MUST, and make the other two options
MUST NOT?
  3. Russ Housley: Comment [2011-01-20]:
      As noted in the Gen-ART Review by Avshalom Houri on 19-Jan-2011, the
  following lines in Section 4.2.4 need to be reworded:
  >
  > Neither part is required to rescale like this (sar may be ignored),
  > the consequence will of course be a distorted image.

  Also, please consider the editorial changes proposed in the Gen-ART
  Review by Avshalom Houri.
  4. Alexey Melnikov: Comment [2011-01-14]:
    I've done a detailed review of the document and overall I think it is fine. Some
comments below:

Last paragraph of section 3.1.1.1, last sentence:

      Where ratio_min and ratio_max are the min and max allowed picture
      aspect ratios.
      If sar and the sample aspect ratio that the receiver actually uses
      in the display are the same (or close), the relation between the x
      and y pixel resolution and the physical size of the image is
      straightforward.  If however sar differs from the sample aspect
      ratio of the receiver display this must be taken into
      consideration when the x and y pixel resolution alternatives are
      sorted out.

This doesn't say how to achieve that.

In 3.1.1.2:

  o  Answerer receiving the offer and sending the answer:

      *  The answerer should not include an image attribute in the
         answer if it was not present in the offer.

s/should not/SHOULD NOT ?

Also check if "may"s in this section should be MAYs.

3.2.7.4.  Possible solutions

   o  2nd session-wide offer/answer round: In the 2nd offer/answer the
      codec payload format specific parameters are defined based on the
      outcome of the 'imageattr' negotiation.  The drawback with this is
      that set up of the entire session (including audio) may be delayed
      considerably, especially as the 'imageattr' negotiation can
      already itself cost up to two offer/answer rounds.  Also the
      conflict between the 'imageattr' negotiation and the payload
      format specific parameters is still present after the first offer/
      anser round and a fuzzy/buggy implementation may start media

typo: answer

      before the second offer/answer is completed with unwanted results.
  5. Tim Polk: Discuss [2011-01-17]:
        This is mostly a discuss-discuss, but also is a reminder that the authors have
agreed to add security considerations
about DoS attacks after a discussion with
the security directorate reviewer (Stephen Farrell).  Since no text has been
proposed as yet, and I agree with his premise, I will hold the discuss as a
placeholder even after the discussion
takes place...

Actionable part:
When an offeror "sees no reason to use the image attribute",
section 3.2.1 recommends including the attribute with
the wildcard.  The
security directorate review notes that an answerer could select attributes that
would demand
significant resources, resulting in a DOS attack.  To resolve this,
I believe some text needs to be added noting
that memory and other resource
considerations need to be considered before accepting the response, even if the
specified attributes can be supported/accepted.

Here's the discuss-discuss part: the ABNF permits the attribute list to be a
wild card for both send and recv.  Is there
any good reason for the offeror to
specify the wildcard (as opposed to an explicit list) for the send attribute
list?  Are
there really any systems that would not restrict the formats it was
willing to send to a list?  Offering to send media
without restricting the
format seems to invite the kind of DoS attack that Stephen was thinking about.
(Flexibility
regarding reception of media seems more logical to me, although
there is still a clear attack vector.)
  6. Peter Saint-Andre: Comment [2011-01-18]:
    The technical content of this document appears to be acceptable.

The document is difficult to read in numerous places because of run-on sentences
and non-standard English.

I suggest that the authors review the conformance terms in accordance with RFC
2119, because sometimes lowercase keywords (lacking any conformance meaning) are
used when uppercase keywords seem more appropriate. For example, in the
following sentence "MUST" seems better than "must":

      *  The offerer must be able to support the image attributes that
         it offers.

There are also several instances of uppercase keywords when no conformance
meaning is in force. For example, in the following sentence "needs to" seems
better than "MUST":

      *  If the image attribute is included in the SDP answer but none
         of the entries are usable or acceptable, the offerer MUST
         resort to other methods to determine the appropriate image
         size.
  7. Sean Turner: Comment [2011-01-19]:
    I support Tim's discuss.

draft-ietf-tls-rfc4347-bis

  1. Ron Bonica: Comment [2011-01-17]:
    Suport OPS-DIR DISCUSS
  2. Stewart Bryant: Comment [2011-01-19]:
  3. Adrian Farrel: Discuss [2011-01-20]:
        A small but important point, I think.

Section 4.3 needs to inanding the factwithstclude a reference to RFC 5246 for
the defnition of the syntax used. This is important (not that the changes are
relative to 5246) because although the format looks like 'C' it is not 'C'
  4. Adrian Farrel: Comment [2011-01-20]:
    I support Alexey's Discuss about description of the changes since/to 4347

---

Should the version numbering be recorded by IANA?

---

How is wrapping of epoch and sequence number handled? Or is it considered that
they will never need to wrap?

---

It might be valuable to repeat the UDP warning from 4.1.2.7 in section 5

---

Section 4.3

   This section includes specifications for the data structures that
   have changed between TLS 1.2 and DTLS.

I think s/DTLS/DTLS 1.2/

---
  5. Russ Housley: Discuss [2011-01-18]:
        
  The Gen-ART Review by Miguel Garcia on 12-Dec-2010 raised a question
  about Section 4.1 that deserves a response.  The reivew says:

  Section 4.1, previous last paragraph on page 8: The sentence requires
  implementations to compute the TCP maximum segment lifetime. If an
  implementation runs DTLS over UDP, how can it compute the TCP maximum
  segment lifetime, which is a parameter for a different protocol? I
  suspect DTLS implementations running over UDP (or even SCTP) will not
  have a clue of what is the TCP maximum segment lifetime.
  6. Alexey Melnikov: Discuss [2011-01-02]:
        This is a fine document and I generally support its publication. However I have
2 minor issues which I would like to discuss before recommending approval of
this document:

1). 7. IANA Considerations

   This document uses the same identifier space as TLS [TLS12], so no
   new IANA registries are required.  When new identifiers are assigned
   for TLS, authors MUST specify whether they are suitable for DTLS.

Does this mean that this document Updates [TLS12]?
Section 4.1.2.5 also confirms that.

2). I don't see a section "changes since DTLS 1.0" required by ID-nits. Can you
convince me that it is not needed?
  7. Alexey Melnikov: Comment [2011-01-02]:
    SCTP, RC4, SCTP-AUTH should have Informative references.
  8. Tim Polk: Comment [2011-01-20]:
    placeholder for Charlie Kaufman's secdir review - this deserves a response.  I
made this a comment since I know that the sponsoring AD intends to seem them
addressed.
  9. Dan Romascanu: Discuss [2011-01-17]:
        The DISCUSS and COMMENT is largely based on the OPS-DIR review by Pekka Savola.
I did not see the issues raised by Pekka answered and I believe that part of
them (listed below) need to be addressed.

1. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if
it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will
apply, but there are likely some DTLS specifics as well.

2. 

> 3.2.3. Message Size

     TLS and DTLS handshake messages can be quite large (in theory up to
     2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
     datagrams are often limited to <1500 bytes if fragmentation is not
     desired.  In order to compensate for this limitation, each DTLS
     handshake message may be fragmented over several DTLS records.  Each
     DTLS handshake message contains both a fragment offset and a fragment
     length.

> 4.1.1. Transport Layer Mapping

     Each DTLS record MUST fit within a single datagram.  In order to
     avoid fragmentation, clients of the DTLS record layer SHOULD attempt
     to size records so that they fit within any PMTU estimates obtained
     from the record layer.

... these seem somewhat contradictory.  Maybe I'm missing something.  The latter
seems to be saying that DTLS implementations should try to avoid IP
fragmentation, but the former seems to imply that it's de-facto mode of
operation.

3. 
>      If there is a transport protocol indication (either via ICMP or via a
     refusal to send the datagram as in DCCP Section 14), then DTLS record
     layer should inform the upper layer protocol of the error.

Why a 'should'?  I've have thought that it would be natural that if DTSLS record
layer gets this notification (which, in the case of ICMP and omitting
information, is not necessarily given), it MUST pass this information up. Note
that the refusal to send could also apply to UDP if packet is bigger than PMTU
and DF bit is set or IPv6 is used.
What is the alternative if it doesn't?  It
would be fine if the alternative is that the DTLS record layer react to that
information itself, but completely ignoring e.g. ICMP packet too big would lead
to communication failure

4. 

> 7. IANA Considerations

     This document uses the same identifier space as TLS [TLS12], so no
     new IANA registries are required.  When new identifiers are assigned
     for TLS, authors MUST specify whether they are suitable for DTLS.

... this may be inadequate.  I was unable to find from the registry
(tls-parameters) which of these parameters this applies to.  All of them?

If I understand what you mean, 1) you should actually be asking IANA to reformat
the registry so that there is an additional column in all the tables "DTLS-OK?"
or some such, and possibly 2) modifying TLS 1.2 spec IANA registration
guidelines (i.e. what should the IANA requesters know about when they're making
their request), and also possibly 3) asking IANA to ask future registrants about
DTLS-OK feature if the requestor fails to do so on their own.
  10. Dan Romascanu: Comment [2011-01-17]:
    1. The document does not have a "Changes from DTLS 1.0 (RFC4347)" section which
is customary in 'bis' documents. Why?

2. For the completeness, when referring to PMTU discovery, in addition to
RFC1191 one should probably also refer to RFC1981 (the IPv6 version).

     [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
                Work in Progress, October 2003.

... this should probably be rfc5406?

     [IKEv2]    C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
                December 2005.

... remove the latter 'reference' (edit glitch?)
  11. Peter Saint-Andre: Comment [2011-01-18]:
    I support Alexey's DISCUSS regarding the need for a section describing the
changes from DTLS 1.0 (RFC 4347).

draft-ietf-xmpp-3921bis

  1. Lars Eggert: Comment [2011-01-17]:
    Section 2.3.3., paragraph 1:
>    the roster get, or even <not-llowed/> if the server only allows

  Nit: s/<not-llowed/>/<not-allowed/>/

Section 4., paragraph 7:
>       presence, or an error occurs in relation to the proble, then the

  Nit: s/proble,/probe,/
  2. Adrian Farrel: Comment [2011-01-17]:
    I'm ballotting "no objection" based on selective reading of a few sections of
this I-D and "trust" of the WG, the author, and the ADs who have ballotted
"yes".
  3. Alexey Melnikov: Comment [2011-01-19]:
    I like Robert's comments, modulo the 4th point in his DISCUSS, which I think is
already covered by rfc3920bis.

In 4.3.2:

      Implementation Note: The handling of the 'id' attribute in
      relation to presence probes was unspecified in RFC 3921.  Although
      the pattern of "send a probe and receive a reply" might seem like
      a request-response protocol similar to the XMPP <iq/> stanza, in
      fact it is not because the response to a probe might consist of
      multiple presence stanzas (one for each available resource
      currently active for the contact).  For this reason, if the
      contact currently has available resources then the contact's
      server SHOULD preserve the 'id' attribute of the contact's
      original presence stanza (if any) when sending those presence
      notifications to the probing entity; however,

Use of "however" can be read as if the 'id' attribute is not to be returned
in the case specified below, however it is still returned. I suggest dropping
"however" here.

      if the contact
      currently has no available resources, the probing entity is not
      authorized (via presence subscription) to see the contact's
      presence, or an error occurs in relation to the proble, then the
      contact's server SHOULD mirror the 'id' of the user's presence
      probe when replying to the probing entity.

In 4.5.2:

   The user's server MUST also send the unavailable notification to all
   of the user's available resources (including the resource that
   generated the presence notification in the first place).

Comment: The text in (): but the resource is unavailable :-).

   The <subject/> element MUST NOT contain mixed content (as defined in
   Section 3.2.2 of [XML]).

Should the same be said about presence' <status> element?

11.  Security Considerations

   o  A user's server MUST NOT leak the user's network availability to
      entities who are not authorized to know the user's presence,
      either via an explicit subscription as described herein or via an
      existing trust relationship (such as presence-enabled user
      directories within organizations).

I don't understand this paragraph. If a user is subscribed to presence,
then she is authorized to know user's presence?
  4. Robert Sparks: Discuss [2011-01-19]:
        DISCUSS
In section 3.1.3 item 4, a server is required to keep a complete
presence stanza for an unbounded amount of time (potentially forever).  This
looks like a vector for a state-exhaustion attack. The restriction for keeping
only one such stanza per sender helps, but a malicious attacking server could
send stanzas from an arbitrary number of identites. I suggest providing
implementation guidance on when it's ok to drop information that's truly stale,
and call out the potential for this attack in the security considerations.

Section 5.2.4 calls out "for the purpose of providing alternate versions of the
same subject" when allowing multiple subjects to appear with different xml:lang
attributes. Section 5.2.3 does not have analogous text constraining multiple
bodies. Should it?

Section 5.3 - Was the intent to constrain the contents of a message stanza to
things intended to be rendered to a user? As written, this section would allow
<message/> to be used as part of the framing of an arbitrary transport protocol.
Section 5.3 - The document should say what an implementation receiving a child
element in a namespace it doesn't understand should do with that child.
  5. Robert Sparks: Comment [2011-01-19]:
    COMMENT

In section 2.3.3, is the intent that error conditions listed earlier in the
section take precedence over error conditions listed later in the section?
What's the appropriate response if a message qualifies for both a <forbidden/>
and a <bad-request/> as described in this section?

When would an element choose not to follow the SHOULD in 3.1.2 item 1, and what
are the consequences?

The end of section 4.3 has an implementation note containing normative
requirements. Can these be moved into the main prose?  This same implementation
note may be easy to misinterpret. I don't believe it is meant to prevent an
implementation from returning an error to a malformed presence probe, but it
could be read that way.

Section 5.2.5 does not prevent a thread from claiming it is its own parent
(should that be allowed?), or warn implementations about the possibility of
thread A indicating a parent of B, and thread B indicating a parent of A
(generalize this to any kind of cycle). I don't think XEP-0201 calls this out
either. Should it be mentioned as an implementation consideration? (A naive
implementation would very likely crash or do something surprising with its UI.)

In section 8.5.2.1, I encourage adding text explaining why delivering to all
non-negative resources is SHOULD and not MUST. I understand from out-of-band
communication that local policy may determine that some particular resource not
receive the message, but the document does not say this. As written, I can see
implementations that adopt a policy of delivering to the first non-negative
resource and claim they've met the requirement.

draft-ietf-pwe3-oam-msg-map

  1. Adrian Farrel: Discuss [2011-01-03]:
        There are a couple of nits reported by idnits (an out of date reference,
an old license statement). I think the license statement should be
fixed and posted (to reflect the authors' intent) before the document is
approved.

---

I see IPR disclosed at http://datatracker.ietf.org/ipr/863/
I don't see this declared in the proto write-up. More important, it is
not present in the IETF last call announcement in datatracker.

---
What is the situation wrt multi-segment PWs? I can understand that this
document
was developed before the WG turned to MS-PWs, but we now have
RFC 5254 and RFC
5659.

I would prefer that this document fully addressed MS-PWs. That would not
be hard because each PW segment at an S-PE regards the adjacent segments
as ACs, so it could probably be addressed in just one or two paragraphs
in a new section.

However, an option is to declare MS-PW out of scope, and provide a
forward
reference to work being done on OAM message mapping for MS-PWs
in the PWE3 WG.

---

Section 4.2

   If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it
   will be referred to as "VCCV-Ping".

I believe s/RFC4377/RFC5085/

---

Section 5
You should add a note to explain why the CE ends of the ACs are not
considered
as possible defect locations. They are part of the emulated
service, so a naif
reader might expect to see them listed. Possibly you
will want to explicitly
include it in case (a).

Additionally, your text does not match the figure:
   c. Defect on a PE1 PSN interface.
But (c) also appears on the PE2-PSN interface in the figure.

Furthermore, (e) and (f) appear tbe reversed in the figure compared to
the text.

---

Section 13

RFC 5085 and RFC 4447 should be presented as references.

I will let Security experts comment further, but:

 It seems to me that facilitating end-to-end coordination of PW status
 and fualt reporting provides an extra tool for attackers. I would
 expect this to be pointed out and held up as a reason for ensuring the
 use of the security mechanisms.

 I think that there are security coordination issues. Perhaps these are 
 already mentioned in the references. Consider carrying NS OAM from CE 
 to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM
 Loops mode. The security relationship perceived by the CEs would 
 presumably be between each other, but doesn't the PE need to 
 participate?
  2. Adrian Farrel: Comment [2011-01-03]:
    Section 3                  
s/whereby/where/

---

The Introduction uses a number of acronyms without prior expansion.
On the other hand, having defined acronyms in Section 4.1, you don't
gave to expand them in subsequent sections.

---

Section 4.1
Several acronyms are not used in the rest of the document.
BDI
CPCS
IWF

s/label Switched Path/Label Switched Path/
s/Operations, Administration and Maintenance/
  Operations, Administration, and Maintenance/

---

Section 4.2

   The words "defect" and "fault" are used interchangeably to mean any
   condition that obstructs forwarding of user traffic between the CE
   endpoints of the PW service.

I'm fine with this, but I think "obstructs" is ambiguous. Do you mean
"impose a complete blockage", or do you mean to include degradation in
some form? Perhaps you could add a clarification.

---

Section 4.2

   If BFD is run over a PW as
   described in [RFC5885], it will be referred to as "VCCV-BFD".

Add a reference to [RFC5880]

---

Section 4.2

   A "transmit defect" is any defect that impacts traffic that is meant
   to be sent or relayed by the observing PE.  A "receive defect" is any
   defect that impacts traffic that is meant to be received by the
   observing PE.

While "meant to be" is appropriate for the reception of data, I don't
think it necessarily applies to transmission. Consider that the defect
may be somewhat downstream of (and not yet notfied to) the upstream PE
such that the traffic that is impaced is that which *has* been sent or
relayed by the observing PE.

Additionally, the term "observing PE" has not been defined and may
clarify or complicate the meaning of the text.

---

I had a few problems with Section 8.1. I think my issue is with the
use of the control plane as an OAM exchange mechanism (this also shows
up in Appendix B). I believe the section could benefit from some
polishing.

   For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label
   Distribution Protocol [RFC3036] MUST use the LDP status TLV as the
   mechanism for AC and PW status and defect notification, as explained
   in [RFC4447].

I don't think that this "MUST" is good or consitent with:
- the text in Section 7 that is relaxed in saying "LDP or in the ACH"
- the work in MPLS-TP

It sounds like 3036 (or rather 5036) is a normative reference.

While conveying PW status in LDP per 4447 is fine, it is not OAM with 
the utility of rapid propagation of fault notifications. LDP, reliant
as it is on TCP, is not suitable to that purpose.

Wouldn't it be better to require the use of the ACH for OAM fault
notification messages, and (if you must :-) mandate the use of LDP
for status information propagation when LDP is present (but not as a
replacement for real OAM).

Additionally...

   Additionally, a PE MAY use VCCV-BFD Connectivity
   Verification (CV) for
fault detection only (CV types 0x04 and 0x10
   [RFC5885]) but SHOULD notify the
remote PE using the LDP Status TLV.
The "SHOULD" here seems to be in conflict with te previous "MUST"

And it goes on...

   A PE that establishes a PW using means other than LDP, e.g., by
   static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types
   0x08 and 0x20 [RFC5885]) for AC and PW status and defect
   notification.  Note that these CV types SHOULD NOT be used when the
   PW is established with the LDP control plane.

If you supply only a "MAY" you should probably describe how else the
fault notification might work.

As to the "SHOULD NOT" in the last sentence. Well, see my previous
comments. And what possible harm could it do?

---   

Section 6

   Generally, a PE cannot detect transmit defects directly and will
   therefore need to be notified of AC transmit or PW transmit defects
   by other devices.

I think you mean s/directly/direct/

---

Section 8.1.1
                                                                          
   [RFC4447] specifies that the "Pseudowire forwarding" code point is
   used to clear all faults.  It also specifies that the "Pseudowire Not
   Forwarding" code is used to convey any defect that cannot be
   represented by the other code points.

The language seems rather week.
The use of the code point does not clear the faults. It is used to 
report (notify) that the faults have been cleared.
Likewise, defects are not conveyed by the use of a control points, but
existence of the defect can be reported (or conveyed, if you like).
  3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

draft-ietf-sipcore-keep

  1. Adrian Farrel: Comment [2011-01-17]:
    I found this a clear and well-written document, thanks. I have two
smal points I would like the authors to think about, but nothing that
blocks publication.

Section 1.2

   In some cases all SIP entities that need to be able to negotiate the
   usage of keep-alives might not support SIP Outbound.  However, they
   might still support the keep-alive mechanisms defined in SIP
   Outbound, and need to be able to negotiate usage of them.

Do you actually mean...

   In some cases not all SIP entities that need to be able to negotiate
   the use of keep-alives might support SIP Outbound.  However, they
   might still support the keep-alive mechanisms defined in SIP
   Outbound, and need to be able to negotiate usage of them.

Or maybe more elegant as...

   In some cases some SIP entities that need to be able to negotiate
   the use of keep-alives might not support SIP Outbound.  However, they
   might still support the keep-alive mechanisms defined in SIP
   Outbound, and need to be able to negotiate usage of them.
  2. Alexey Melnikov: Comment [2011-01-12]:
    I read the whole document and in general I don't have any objections to
publishing it as an RFC. However I have a minor complain:

8.  Grammar

   This specification defines a new Via header field parameter, "keep".

   The ABNF [RFC5234] is:

   via-params =/ keep

   keep       = "keep" [ EQUAL 1*(DIGIT) ]

This doesn't tell me where <via-params>, <EQUAL> or <DIGIT> is defined. Please
add the references as either ABNF comments or in the text before the grammar.
  3. Peter Saint-Andre: Comment [2011-01-10]:
    This is a fine document. I have only a few comments.

1. In second paragraph of the Security Considerations, please spell out "TLS"
and "DTLS" on first use and add informative references for the relevant
specifications.

2. In the fourth paragraph of the Security Considerations, the specification
says that a SIP entity MUST stop sending keep-alive requests if it does not
receive responses to the STUN keep-alives that it sends to an adjacent
downstream SIP entity. However, this does not take into account the fact that
STUN requests and responses could be dropped, so it would be good to provide
some more specific guidance here, e.g., stop sending STUN keep-alive requests if
no STUN responses are received after sending two or more STUN requests (it seems
suboptimal to stop sending STUN keep-alive requests if no response is received
to only the very first STUN keep-alive request). Furthermore, no guidance is
provided about the number of seconds the sender should wait before concluding
that the adjacent downstream SIP entity has not responded. If these matters are
covered in RFC 5389 then it would be helpful to cite the specific sections where
they are discussed (e.g., Section 7.2.1 regarding retransmission timeouts).
  4. Sean Turner: Comment [2011-01-20]:
    Juergen Schoenwaelder spotted two editorial nits in the security considerations
during his SECDIR review:

a) [...]  This specification does not specify a connection
   reuse mechanism, and it does it address security issues related to
   connection reuse.  [...]

   s/it does it/it does not/

b) [...]  They do not instruct the enity to
   place a value in a "keep" parameter of any request it forwards.  [...]

   s/enity/entity/

draft-ietf-martini-gin

  1. Adrian Farrel: Comment [2011-01-20]:
    AOR is used without expansion in the abstract.
  2. Alexey Melnikov: Comment [2011-01-19]:
    In Section 7.1.2:

   All base64 encoding discussed in the following sections MUST use the
   character set and encoding defined in RFC 2045 [1],

RFC 4648 is a better reference here.

   except that any
   trailing "=" characters are discarded on encoding, and added as
   necessary to decode.

In Section 7.1.2.1:

SHA256-80 needs a reference and an explanation (i.e. that the output of the hash
function
is truncated to 80 bits).

The first reference to TLS needs an Informative reference.
  3. Dan Romascanu: Comment [2011-01-18]:
    The OPS-DIR review by Warren Kumari signalled a number of nits which would be
useful to fix:

Abstract:
In the abstract many acronyms are expanded (SIP, SIP-PBX, UA), but AOR
is not. Having them all expanded (or none expanded) would be nice.

Section 4:
Globally Routable UA URI's (GRUU) are first mentioned, but the
reference to the RFC is in section 7.1.

Section 5.1:
Acronym "UAC" not expanded / defined.

Section 6:
s/An SSP using this mechanism/A SSP using this mechanism/

Section 7.1.2.1 (indented):
s/The registrar maintains a counter, I. this
counter is/The registrar maintains a counter, I. This counter is/
(Capitalization of 't').
  4. Robert Sparks: Comment [2011-01-19]:
    The examples in section 8 have bugs that are important to fix before
publication.
The Call-ID changes unintentionally in each example. The messages
that have two Via header field values have the values in the wrong order.
  5. Sean Turner: Discuss [2011-01-20]:
        #1) Section 7.1.2.2: The following threw me for a loop:

   A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an
   HMAC key, PK_a.  This value is used to validate that incoming GRUUs
   were generated by the SIP-PBX.

I'm probably reading more in to "PK_a" than I ought to but it isn't a Public Key
(PK) - right!?  It would be bad to use a public key as the HMAC secret.  SK_a is
terminology used in Section 7.1.2.1 - can we use the same term or SK_SSP and
SK_SIP-PBX?

#2) The scenarios in Section 8.1 and 8.2  do not show the authentication step
called.  I think it should or the text should say we left them out but you still
need to do them.

#3) Alexey caught the bit about HMAC-256-80 needing a reference.  I think it's a
bigger deal because I don't which which parts of the output get used: 1st
80bits, last 80bits, etc.?  It's hard to interoperate without knowing this.
But, if a reference exists it'll be easy to clear.
  6. Sean Turner: Comment [2011-01-20]:
    Section 7.1.2.2: Seems like there should be a pointer to RFC 4086 for the "D"
method.

draft-ietf-multimob-pmipv6-base-solution

  1. Stewart Bryant: Comment [2011-01-19]:
    I agree with Lars.
  2. Ralph Droms: Discuss [2011-01-18]:
        If I'm reading the document correctly, the LMAs arrange to receive
multicast streams and forward the streams to the MAGs, which then
forward the streams to subscribed MNs.

In figure 1, suppose MN1, associated with LMA1, and MN2, associated
with LMA2, are both associated with multicast stream MC.  Will MAG1
receive copies of MC from both LMA1 and LMA2?

Was a design considered in which the MAG arrange directly for the
delivery of multicast streams as required by attached MNs?
  3. Lars Eggert: Discuss [2011-01-17]:
        DISCUSS: I'm not getting why this document is going for BCP. Informational seems
fully adequate to me.
  4. Adrian Farrel: Discuss [2011-01-20]:
        The use of RFC 2119 language puzzles me. 
Are statement like:
   As links connecting MNs and MAGs change under
   mobility, MLD proxies at MAGs MUST be able to dynamically add and
   remove downstream interfaces in its configuration.
Making new definitions of behavior, or are they refering to existing
norms specified elsewhere (that is, restating requirements)? In the
former case, it looks like the document is actually Standards Track.
In the latter case, I suggest inserting a reference and dropping to
lower case.

And other statements like:
   In summary, the following steps are executed on handover:
  [SNIP]
   4.  The MAG SHOULD determine whether the MN is admissible to
       multicast services, and stop here otherwise.
In this case "SHOULD" is not indicative of a step that is executed.
  5. Adrian Farrel: Comment [2011-01-20]:
    MN-HNP is used without expansion
  6. Alexey Melnikov: Comment [2011-01-19]:
    I agree with Lars, although I don't have a strong opinion on the matter.
  7. Peter Saint-Andre: Comment [2011-01-18]:
    I concur with Lars's DISCUSS regarding the intended status of this document.
Other than that, the document seems fine.

draft-ietf-roll-routing-metrics

  1. Jari Arkko: Discuss [2011-01-18]:
        I am concerned about the complexity of the RPL system. The set of attributes is
relatively complex, 8 different attributes (The BGP parameters registry has 26,
but RPL is expected to be run in environments where there is no experts to
monitor its operation or fine-tune the parameters.) The large set of attributes,
dynamically changing parameters, complex topologies, and unattended operation
seems like a recipe for operational and interoperability problems. I do
recognize the need to have dynamic metrics, power-aware routing, and many of the
other things in this specification, however. My question is whether this is the
absolute minimum set that we should define. Do we need Section 2.1 A field?
Section 3.1 A or O flags? The mid-complexity solution from Section 3.2? Section
4.3.1 *and* Section 4.3.2 reliability metrics?

A few more specific concerns:

Section 3.1:

   o  A Flag: data Aggregation Attribute.  Data fusion involves more
      complicated processing to improve the accuracy of the output data,
      while data aggregation mostly aims at reducing the amount of data.

This is underspecified. And why do you talk about data fusion, if the
attribute signals data aggregation. Please define what the semantics
of the bit and the participant's behaviour is with respect to data
aggregation, or point to a reference.
  2. Jari Arkko: Comment [2011-01-18]:
    I agree with Lars Eggert's Discuss.

Section 4.3:

   In LLNs, link reliability is degraded by external interference and
   multi-path interference (wireless links).  Multipath typically
   affects both directions on the link equally, whereas external
   interference is sometimes unidirectional.

I'm not sure I understand the term "multi-path interference" in this context.
Perhaps you should use some other term. Multi-path usually refers to the use of
multiple paths simultaneously. Radio interference from multiple links can
certainly occur in ROLL networks. But I'm not sure why you call it "multi-path
interference". I would probably just say "... degraded by attenuation (due to
distance and objects) and interference (from external objects or within the RPL
network)".
  3. Ron Bonica: Discuss [2011-01-19]:
        This may be a DISCUSS-DISCUSS.

I believe that in order to achieve loop-free routing, the following conditions
must be true:

- all nodes must construct identical link state data bases (LSDB)
- all nodes
must run identical (or at least equivalent) SPF algorithms over that LSDB

While I understand how ROLL devices might construct identical LSDBs, I don't
understand how all nodes will run and identical (or even equivalent) SPF
algorithms. The first problem is that all nodes don't neccessarily understand
all metrics advertised with C-bit == 0. So, if all SPFs don't understand all of
the same inputs, how can they be expected to produce the same outputs? THe
second problem is an SPF with multiple inputs is pretty complex. Is it
documented well enough that multiple vendors may produce interworking
implementations? Finally, a node might advertise a metric with C-bit = 0 and
then override that same metric with C-bit =1. When that happens, does the old
advertisement disappear from the LSDB.
  4. Lars Eggert: Discuss [2011-01-17]:
          DISCUSS: My high-level concern with this document is that it focuses
  on how metrics are encoded in RPL TLVs, rather than giving formal and
  therefore unambiguous definitions of the metrics. Not in all cases,
  but in several. For example, the misnamed "throughput" metric doesn't
  make it clear whether it describes nominal link capacity or residual
  capacity, or whether it is an instantaneous metric or averaged over
  some period, etc. The "delay" metric leaves it open whether buffering
  delays are supposed to be included or not. The link reliability metric
  is much too open; when does e.g. a ZigBee link have a reliability of
  5? When of 6? Hat about a BT-LE link? And so on.

  The reason I'm bringing this up is that in oder to have route selection pick
  paths for end systems based on these metrics, it needs to be understood
  what these metrics concretely *mean*. I don't think that's currently
  possible, and I believe that makes them rather less useful that
  advertised. If IPPM has taught us anything it's that metrics really do
  need to be unambiguously defined for them to be useful.

  I realize this discuss isn't really actionable. I plan to clear it after
  discussing my concern with the IESG call.
  5. Lars Eggert: Comment [2011-01-17]:
    Section 1., paragraph 16:
>    flexibility to use link and node characterisics either as constraints

  Nit: s/characterisics/characteristics/

Section 1., paragraph 21:
>    and unneccessary routing changes.

  Nit: s/unneccessary/unnecessary/

Section 3., paragraph 1:
>    objet MUST silently be ignored.

  Nit: s/objet/object/

Section 4.1., paragraph 0:
> 4.1.  Throughput

  I think you mean (link) capacity here and not throughput. See the
  definition in RFC5136; could you adopt this definition here?

Section 4.2., paragraph 0:
> 4.2.  Latency

  See the definitions in RFC2679, can they be adopted here? Also, is
  this metric supposed to include buffering/queueing delay (which is
  load dependent) or is it purely supposed to capture the link
  transmission delay? If the former, that can vary quite a bit more...

Section 4.3.2., paragraph 12:
>    the path (cummulative path ETX calculated as the sum of the link ETX

  Nit: s/(cummulative/(cumulative/

Section 7., paragraph 1:
>    consist of making intermitment attacks on a link in an attempt to

  Nit: s/intermitment/intermittent/

Section 8., paragraph 1:
>    valuable comments.  Special thank to Adrian Farrel for his thourough

  Nit: s/thourough/thorough/
  6. Alexey Melnikov: Comment [2011-01-15]:
    In 2.1:

   The A field has no meaning when the C Flag is set (i.e. when the
   Routing Metric/Constraint object refers to a routing constraint) and
   he only valid when the R bit is cleared.  Otherwise, the A field MUST

Is "he" should be here at all?

   be set to 0x00 and MUST be ignored on receipt.

4.1.  Throughput

   Throughput: 32 bits.  The Throughput is encoded in 32 bits in
   unsigned integer format,

In network byte order? (Also in 4.2)

   expressed in bytes per second.
  7. Dan Romascanu: Discuss [2011-01-18]:
        A few issues need to be addressed before I can ballot favorably this document: 

1. Section 2.1 - Value: variable for Routing Metric/Constraint TLVs. What is the
length range. 255 is maximum I assume, but is zero an acceptable length value?

2. Section 3.1 - 

      An implementation MAY
      decide to add optional TLVs (not currently defined) to further
      describe the node traffic aggregator functionality.

It is not clear to me how an implementation can make such a decision. Two
different implementations would not be interoperable if this is not defined some
place. Is this about extensibility?

3. Section 3.2 - it is not clear from the text that estimating the 'energetic
happiness' - actually the remaining power battery for battery operated devices
is always possible, and if not how this metrics is being filled in. Will just
the E bit be cleared and no estimation provided?

4. Section 4.2 - the latency metric is unsufficiently defined. What is the
measurement observation point? is buffering taken into consideration?

5. Section 4.3.1

> The Link Quality Level (LQL) object is used to quantify the link
   reliability using a discrete value, from 0 to 7 where 0 indicates
   that the link quality level is unknown and 1 reports the highest link
   quality level.  The mechanisms and algorithms used to compute the LQL
   are implementation specific and outside of the scope of this
   document.

This seems broken. How can interoperability be ensured between two independent
implementations if the metric is a discrete value whose algorithm of
determination is implementation specific?
  8. Dan Romascanu: Comment [2011-01-18]:
    1. The way the Flag field is defined in Figure 1 is confusing. The field is
defined as length 16 bits, but then there are 5 bits labelled Flags on the
diagram which are actually the currently reserved or un-allocated Flags. The A
field and PRec filed are part of the Flag field, but there is no indication or
indent to make this clear.

2. Expand DIO at first occurence

3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like
Link Capacity.
  9. Peter Saint-Andre: Comment [2011-01-19]:
    Based on the reviews provided by IESG members more expert than I in the
technology under consideration, I am ballotting "No Objection". That said, based
on my own review I concur with the DISCUSS raised by Jari Arkko regarding the
complexity of the system.

draft-ietf-6lowpan-hc

  1. Jari Arkko: Comment [2011-01-19]:
    Ari Keränen reviewed this draft. His comments:

Abstract

Missing "updates RFC4944" text.

Section 1

Abbreviations ND & MAC should be expanded.

Section 3.1.1.

First time "ECN" and "DSCP" are used. Could move the expanded versions and
references from Section 3.2.1 to here.

        01:  64 bits.  The address is derived using context information
           and the 64 bits carried in-line.  Any bits of the IID not
           covered by context information are taken directly from the
           corrseponding bits carried in-line.  Any remaining bits are
           zero.

If the context defines some of the same bits as the in-line data, are context
bits always used (and in-line bits ignored)? That could be said more explicitly
too.

Also: s/corrseponding/corresponding/

Section 3.2.4

Expand RIID.

    DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression

Should that be "DAM = 00"?

Section 4.3.1

  This specification introduces a range of well-known ports (0xF0Bx)

This is a bit strange way to express a port range, and the term "well-known
ports" is already reserved for ports < 1024. You could say something like:

  This specification introduces a range of ports, 61616 - 61631 (0xF0B0 -
0xF0BF), that can be compressed more efficiently, using only 4 bits.

  Transport Layer Security (TLS) Message Integrity Check (MIC) that
  validates that the content is expected and checked for integrity.

"validates" and "is expected and checked" sound a bit strange here. Could use
something like "makes sure" and "is what is expected and is checked"

Section 4.3.2

Expand PDU.
  2. Ron Bonica: Comment [2011-01-19]:
    I also support the GENART DISCUSS on the checksum
  3. Stewart Bryant: Comment [2011-01-19]:
    I support Russ' Discuss on the checksum.

The mandatory use of checksum in IPv6 is controversial amongst some IETF
communities (particularly the community using UDP as a tunnel type). Either this
controversy needs to be resolved, or  draft-ietf-6lowpan-hc needs to deal
correctly with the c/s /no c/s case. It could of course do this by always
carrying the c/s, but it seems perverse to have to carry 16 bits of c/s to say
that there is no c/s.
  4. Lars Eggert: Discuss [2011-01-17]:
        [Edited to include David Black's gen-art review, since I'm already holding a
discuss on part of the issues he has raised.]

Section 4.3.2., paragraph 1:
>    The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
>    packets.  For that reason [RFC4944] disallows the compression of the
>    UDP checksum.
>    With this specification, a compressor in the source transport
>    endpoint MAY elide the UDP checksum if it is authorized by the Upper
>    Layer.  The compressor SHOULD NOT set the C bit unless it has
>    received such authorization.  The Upper Layer SHOULD only provide the
>    authorization in the following cases:

  DISCUSS: First, I think you want to use "MUST NOT" and "MAY only"
  here. Second, there are additional issues here (see
  draft-ietf-6man-udpzero). For example, even if there is an upper layer
  integrity check present for a given app, if the port number field gets
  corrupted and a message gets mis-delivered to an incorrect application
  (port), *that* application may not have an upper layer integrity check
  implemented to protect it. And so on. Have you run this part of the
  spec by 6MAN?

Also, from David Black:

>  A forwarding node MAY imply authorization from an incoming packet if
> the C bit is set.  A forwarding node that cannot unambiguously derive
>  such authorization SHOULD NOT elide the UDP checksum when performing
>  6LoWPAN compression.

This needs to be a MUST NOT.
  5. Adrian Farrel: Discuss [2011-01-16]:
        Thanks for this document which I have reviewed in detail. I will 
ballot "no objection" when one small point has been resolved.

Section 4.3.1
                                                                                
   This specification introduces a range of well-known ports (0xF0Bx)
   that can be compressed to 4 bits.

I don't believe that these are "Well Known Ports". They would be in the
range 0-1023.

They appear to be "Dynamic and/or Private Ports"

I guess you are trying to say that these ports are known by 6lowpan hc
implementers. Maybe a complete rewriting of this sentence?

   This specification defines the use of range of ports from the 
   Dynamic and/or Private Ports range. Using only ports of the type
   0xF0Bx means that the port number can be compressed to 4 bits.

But I am unclear that you are really using this range of port numbers!
Are you not actually using 4 bits to encode up to 16 port number aliases
and, as your text says, you require some mapping to be installed to
expand those aliases back to real port numbers.

If I am wrong (and you are really using ports in the range you state) 
you need to add text to indicate how this is safe and will not clash 
with other usage of these port numbers that might happen randomly as
an application picks (dynamically or privately) some port number to
use.
  6. Adrian Farrel: Comment [2011-01-16]:
    I found a few small points of house-keeping:

---

I would like to see "6LowPAN" expanded in the title, Abstract, and
Introduction. I think that you will find "6LowPAN network" includes
tautology.

---

Section 2

   New            
   implementations MAY implement compression according to Section 10 of
   [RFC4944], but SHOULD NOT send packets compressed according to
   Section 10 of [RFC4944].

s/compression/decompression/  ?

---

Figure 2

You might replace
OLD
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
NEW
       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
END

---

The text in section 3.2.1 is correct and can be understood, but it 
took me several readings to be sure that the text actually matched the
figures. If the authors looked at this piece again and polished it, it
would help the document.

---

Section 3.2.2

   When the encapsulating header carries
   IPv6 addresses, bits for the source
and destination addresses are
   copied verbatim from the source and destination
addresses of the
   encapsulating IPv6 header.
"verbatim" is incorrect in this context. And, anyway, it is redundant -
"copied" is adequate.

---

Section 3.2.2

I think this section could usefully include a reference to 
[IEEE 802.15.4]

---

A number of figures are not numbered, which is mildly inconsistent.

---

Section 4.2

   For the most part, the IPv6 Extension Header is carried verbatim in
   the bytes immediately following the LOWPAN_NHC octet, with two
   important exceptions: Length Field and Next Header Field.

"verbatim" again :-)
I think in this case you should use "unmodified"

---

Seciotn 4.2

      1: The Next Header field is elided and the next header is encoded
         using LOWPAN_NHC, which is discussed in Section 4.

s/4/4.1/

---

Section 4.3.2

   A forwarding node MAY imply authorization from an incoming packet if
   the C bit is set.

I think you mean "infer" not "imply".
  7. Russ Housley: Discuss [2011-01-18]:
        
  The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion
  about the use of checksums with UDP.  This discussion does not seem to
  be over.  The last thing that I saw was:

    I'm still unhappy since the text allows a middle point to recomputed
    the checksum which then might be delivered erroneously to the wrong
    IP or port.  This was done to ensure that a packet that flows on the
    Internet would 'look right' to middle boxes and end points.  It  is
    probably OK for most 802.15.4 cases since L2 security is almost
    always on and protects the frames a lot better than 2 octets of
    checksum.  But if there's no security at work, it would probably be
    better to let the packet go with a zero checksum and add some text
    on authorizing that an arbitrary end point.

  This discussion needs to reach a resolution before this document is
  approved.
  8. Peter Saint-Andre: Comment [2011-01-10]:
    This is a fine document. I have only a few comments.

1. According to Section 2, this document appears to update RFC 4944. However,
the document header does not include "Updates: RFC 4944".

2. In Section 6, please add an informative reference for Transport Layer
Security (TLS).
  9. Sean Turner: Comment [2011-01-20]:
    I support Russ's discuss.

draft-ietf-isis-layer2

  1. Ron Bonica: Comment [2011-01-17]:
    Please run the nit-checker. There are a few missing and unused references.
  2. Ralph Droms: Discuss [2011-01-18]:
        IESG Writeup appears to be missing; will clear when
I can review the background on WG review and
consensus.
  3. Ralph Droms: Comment [2011-01-18]:
    Extraordinarily pedantic nit: MAC address in section 2.1 is not to scale;
suggested

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MAC (1)    (6 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MAC (N)    (6 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4. Lars Eggert: Comment [2011-01-17]:
    Section 2.2., paragraph 2:
>    o  Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD].

  What's TBD here?
  5. Russ Housley: Comment [2011-01-19]:
      Please consider the editorial comments in the Gen-ART Review by
  Kathleen Moriarty on 19- Jan-2011.
  6. Alexey Melnikov: Comment [2011-01-14]:
    2.2.  Multi Topology aware Port Capability TLV

   o  Topology Identifier: MT ID is a 12-bit field containing the MT ID
      of the topology being announced.  This field when set to zero
      implies that it is being used to carry base topology information.

Excuse my ignorance, but is this description actually sufficient for
interoperability? Which values are valid here and where are they coming from?

Also I don't think specifying exact values before they are assigned by IANA is
a good idea.
  7. Dan Romascanu: Discuss [2011-01-18]:
        The OPS-DIR review by Menachem Dodge (posted in the tracker) raised a number of
issues which I believe require clarification and edits. As the authors of the
document answered that they will deal with the comments in a revised version of
the document I am holding a DISCUSS until the comments are resolved by edits or
detailed clarification answers.

draft-ietf-isis-trill

  1. Ralph Droms: Discuss [2011-01-20]:
        
This DISCUSS is a placeholder to ensure an issue with
draft-ietf-trill-rbridge-protocol-16 is addressed before publication.
I"ll clear as soon as updates to draft-ietf-trill-rbridge-protocol-16
are agreed to and the RFC Editor is informed of the changes. 

draft-ietf-trill-rbridge-protocol-16 was written before draft-ietf-isis-layer2
was split into 3 documents.  A reference to draft-ietf-isis-trill
needs to be added to draft-ietf-trill-rbridge-protocol-16, and
citations to draft-ietf-isis-layer2 need to be checked against
the split between draft-ietf-isis-layer2 and draft-ietf-isis-trill.

This DISCUSS also applies to draft-ietf-isis-layer2, but there is no
need to delay publication of draft-ietf-isis-layer2 while
draft-ietf-trill-rbridge-protocol-16 is updated.
  2. Lars Eggert: Comment [2011-01-17]:
    Section 6.1, paragraph 6:
>    are sub-TLVs of TLV #TBD [RFCisisLayer2], the MT-PORT-CAP TLV.  Thos

  Nit: s/Thos/Those/
  3. Alexey Melnikov: Comment [2011-01-16]:
    I only skimmed the document, but I have no objections.

It might be worth mention the byte order used for fields longer than 1 byte.
  4. Dan Romascanu: Discuss [2011-01-17]:
        Before approving this document I believe that the following statement made in
the Introduction section needs clarification:

> Intermediate Systems
   (ISs) implementing TRILL are compatible with IEEE 802.1 customer
   bridges and can incrementally replace such bridges.

What does 'compatible' mean in this context? 
What are the IEEE 802.1 customer
bridges that can incrementally be replaced by ISs implementing TRILL. Either a
reference to the exact IEEE 802.1 standards or a reference to the IETF documents
that specify these would be useful.

draft-ietf-ccamp-gmpls-g-694-lambda-labels

  1. Stewart Bryant: Comment [2011-01-19]:
    "In the scenario of Figure 1, consider the setting up of a bidirectional LSP
from ingress switch 1 to egress switch 9 using
 GMPLS RSVP-TE."

Figure 1 shows them as nodes

=======

To deal with the widening scope of MPLS into the optical and time domains

I think that you mean ... optical switching and time division multiplexing
domains.

======= 
In a case, the label indicates the wavelength to be used for the LSP. 

Do you mean "In this case.." ?

======
  2. Alexey Melnikov: Comment [2011-01-20]:
    I am missing some text about byte order for 16bit fields.

4. Security Considerations 

   This document introduces no new security considerations to 
   [RFC3471] and [RFC3473]. For a general discussion on MPLS and 
   GMPLS related security issues, see the MPLS/GMPLS security 
   framework [RFC5920].

Surely lasers are dangerous weapons and kids shouldn't be allowed to play with
them.

draft-ietf-l3vpn-mvpn-infra-addrs

  1. Stewart Bryant: Comment [2011-01-18]:
    From a very late review

- In a couple of places, the word "route" occurs where it would be clearer
  to say "NLRI"

- The paragraph on "VRF Route Import Extended Community" is misplaced, as it
  is an attribute of IP-VPN routes rather than of MCAST-VPN routes; this
  paragraph should probably be a top-level section of its own.

- That paragraph contains the term "IPv6 Address Specific Route Target" when
  it should say "IPv6 Extended Community".
  2. Lars Eggert: Comment [2011-01-17]:
    I agree with Alexey's discuss that this document is probably missing a bunch of
"updates" relationships.

Additionally, with regards to [MVPN-BGP], could some or maybe all of the content
of this ID rolled into [MVPN-BGP]? (Since that isn't actually published yet?)
  3. Adrian Farrel: Comment [2011-01-16]:
    I have reviewed this I-D and support its publication as an RFC with the change
proposed to resolve Alexey's Discuss.
  4. Russ Housley: Discuss [2011-01-18]:
        
  The Gen-ART Review by Suresh Krishnan on 17-Jan-2011 asks a question
  that deserves a response: will this document update 
  draft-ietf-l3vpn-2547bis-mcast-bgp-08, once it is published as an RFC?
  5. Alexey Melnikov: Discuss [2011-01-16]:
        The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW
needs to be. Maybe it would need to update multiple RFCs.

For example, when I read this text:

1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes

   [MVPN-BGP] defines a new set of BGP route types that are used by SPs
   to provide Multicast Virtual Private Network service to their
   customers.  These routes have a newly defined BGP NLRI, the "MCAST-
   VPN" NLRI.  MCAST-VPN NLRI is carried in the NLRI field of the
   MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP].  The
   SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to
   identify the NLRI as being an MCAST-VPN NLRI.

   When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has
   the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2.
   AFI 1 indicates that any customer multicast addresses occurring in
   the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2
   indicates that any such addresses are IPv6 addresses.

   However, some of the MCAST-VPN routes also contain addresses of PE
   routers in the SP network.  An SP with an IPv4 network may provide
   MVPN service for customers that use IPv6, and an SP with an IPv6
   network may provide MVPN service for customers that use IPv4.
   Therefore the address family of the PE addresses MUST NOT be inferred
   from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI
   attribute.

It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or
[BGP-MP]. Thus it looks like it should be Updating at least one of them.

As per reply from Eric Rosen: the document should use "Updates: [MVPN-BGP]"

draft-saintandre-tls-server-id-check

  1. Lars Eggert: Comment [2011-01-17]:
    Section 1.5., paragraph 8:
>    These suggestions are not entirely consistent with all practices that
>    are currently followed by certification authorities, client
>    developers, and service providers.  However, they reflect the best
>    aspects of current practices and are expected to become more widely
>    adopted in the coming years.

  This seems to argue that the doc should be a BCP and not a PS?

Section 1.8., paragraph 28:
>       Transport Layer Security [TLS] negotiation; in this specfication

  Nit: s/specfication/specification/

Appendix A., paragraph 1:
>    recommendations in this specfication: email [EMAIL-SRV] and XMPP

  Nit: s/specfication:/specification:/

Section 7.2., paragraph 1:
>          Implemenations MUST NOT match any form of wildcard, such as a

  Nit: s/Implemenations/Implementations/
  2. Tim Polk: Discuss [2011-01-20]:
        This is a discuss-discuss.  I support publication as a BCP, but thought some of
the guidance should be much stronger.
  3. Robert Sparks: Discuss [2011-01-19]:
        I agree with the review comments supporting publishing this as PS and not as
BCP.

The majority of this document is specifying behavior that is appropriate to
progress through the standards ladder. There is a small section providing
guidance to certificate authorities that could be written as a BCP, encouraging
"full and immediate instantiation" (see section 5.1 of RFC2026). If it's
important to give that section BCP designation, I suggest placing it in a
separate document. However, I think it will have the same effect in this
document, published as PS.

Assuming the consensus is to move forward as proposed standard, I expect to move
to a "Yes" position.

draft-schaad-smime-algorithm-attribute

  1. Lars Eggert: Comment [2011-01-17]:
    INTRODUCTION, paragraph 4:
>               Signer Info Algorithm Protection Attribute
>
>    A new attribute is defined that allows for protection of the digest
>    and signature algorithm structures in an authenticated data or a
>    signer info structure.  Using the attribute includes the algorithm
>    definition information in the integrity protection process.

  It's be good if the title and abstract had some context that this
  stuff is about CMS...
  2. Adrian Farrel: Comment [2011-01-18]:
    I have two issues with this document, but they are not large enough to form a
Discuss. Nevertheless, I hope the authros will find time to address them.

---

The use of the passive voice in the first sentence of the Abstract is
disconcerting!

There is also some missing context!

The second sentence is pretty hard to parse.

Why not write:

   This document defines a new attribute that allows for protection of
   the digest and signature algorithm structures in an authenticated 
   data or a signer info structure used in the Cryptographic Message
   Syntax (CMS).  When the new attribute is used, the algorithm
   definition information is included in the integrity protection 
   process.

The introduction would benefit from a similar (but more verbose) fix.

---

I think it is conventional to include a reference to the ASN.1 spec
that defines the language you are using. Presumably X.208 (1988) and
X.209 (1988) could be added as references.
  3. Russ Housley: Discuss [2011-01-19]:
        
  Some signature algorithms, such as RSA PKCS#1 v1.5, sign both the
  digest algorithm identifier and the message digest.  So, if the
  attacker changes the identifier, the signature will not
  validate. While this is not true of all signature algorithms, it does
  significantly diminish the scope of the concern being addressed by
  this document.  Please add this to the discussion.
  4. Robert Sparks: Comment [2011-01-19]:
    Can the section on comparing fields in the verification process (2nd paragraph
of section 3) be made more precise? Currently, it says "It is not required that
a field which is absent in one case and present in another case  be compared as
equivalent". Does that mean it's allowed to compare those as equivalent? Or was
the intent that they MUST NOT be equivalent?

draft-ietf-sipcore-sec-flows

  1. Alexey Melnikov: Comment [2011-01-19]:
    6.  Additional Test Scenarios

      *  assure that the most specific CommonName in the Subject field
         matches if there are no dNSName entries in the subjectAltName
         at all (which is not the same as there being no matching
         dNSName entries).  This match can be either exact, or against
         an entry that uses the wildcard matching character '*'

Anywhere in the domain pattern or only in the leftmost position?

Nits: The usual (many acronyms are not spelled out on first use, etc.)
  2. Dan Romascanu: Comment [2011-01-18]:
    The 'Observed Interoperability Issues' section includes a number of example of
implementation problems detected during the SIPit events. I can guess that this
information canges in time, as interoperability problems due to implementation
bugs or lack of clarity in documents are in the majority of the cases being
fixed in the coming releases of the implementations. For this purpose it would
be useful I think to mention what is the time reference (may be the indication
of the SIPit event) when the problems were detected.
  3. Peter Saint-Andre: Comment [2011-01-18]:
    This is a fine document. My only nits are:

1. Some of the acronyms are not expanded on first use.

2. There are some trifling typos (e.g., "particulary").

3. Some of the terms are used inconsistently or casually (e.g., "subjAltName"
when "subjectAltName" is meant; it might be even better to re-use the
terminology from draft-saintandre-tls-server-id-check).

4. No rules are provided regarding the process of matching IP addresses (e.g.,
matching of IPv4 addresses vs. IPv6 addresses); however, because use of IP
addresses is deemed inadvisable, the lack of rules probably does not have
implications for interoperability.
  4. Sean Turner: Discuss [2011-01-20]:
        #1) The AKIs seems to include all three possibilities.  RFC 5280 says:

   The identification MAY be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or the issuer name and serial number.

It also goes on to recommend using the keyIdentifier choice.  I'd remove the
other two (authorityCertIssuer and authorityCertSerialNumber) they're just
making the certificates bigger than they need to be.

#2) User certificate subject names: look a lot like email addresses.   RFC 5280
requires that new implementations put the email address in the SAN extension
with the rfc822Name choice.  Shouldn't the last component of the user's common
name be Cullen Jennings, Kumiko, etc and then put the email addresss in
SAN:rfc822Name?
  5. Sean Turner: Comment [2011-01-20]:
    Appendix A: Add an informative reference to PKCS#8 [RFC5958].

ASN.1 dumps: The "hority" wraps around the line oddly.

Section 5: Is it worth noting that the SHA2 algs also say don't include the
parameters according to [RFC5754].

draft-ietf-roll-security-framework

  1. Russ Housley: Discuss [2011-01-19]:
        
  The Gen-ART Review by David Black raised a significant concern. The
  confidentiality and privacy requirements are SHOULD.  It seems to me
  that they ought to be "MUST implement" so that every implementation
  can be configured to make use of confidentiality and privacy.  An
  alternative would be "MUST implement" coupled with "SHOULD use when"
  statements, or "SHOULD" coupled with "geographic information MUST NOT
  be handled when confidentiality protection is not enabled."
  2. Tim Polk: Discuss [2011-01-20]:
        I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on
roll-rpl because they would be
more appropriate in this document were omitted.
I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these
issues...
  3. Peter Saint-Andre: Comment [2011-01-19]:
    Overall this is a fine document. Several infelicities in the text might cause
confusion:

1. In Section 3.2, "the service of non-repudiation implies after-the-fact"
sounds like it should be "the service of non-repudiation applies after-the-fact"
but instead the authors seem to mean that "the service of non-repudiation
implies that the attack occurs after the fact" or somesuch.

2. In Section 3.3, "can all contribute to key management issues" could be
construed as contributing to important or critical ("key") issues related to
network management, not as "complicating the operations of key management" as in
the previous paragraph; I suggest repeating the previously-used phrasing.

There are also several unfortunate typographical errors (e.g., "fundament"
instead of "fundamental" in Section 3.4, "undue utilization of exhaustion"
instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local
or remote" instead of "any local or remote device" in Section 5.1.5,
"compliment" instead of "complement" in Section 6.1, "aimed the manipulation"
instead of "aimed at the manipulation" in Section 6.5).

With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference
to RFC 4732.

Please provide informative references for OSPF and ISIS in Section 5.2.5.

In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may
therefore be concurrently generated or updated"?

In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a
process for key and credential distribution"?

In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the
routing protocol(s) specified by the ROLL Working Group should assume that the
system affords key management mechanisms consistent with the guidelines given in
[RFC4107]"?

In Section 6.5, is uppercase "SHOULD" meant in the text "   As routing is one
component of a LLN system, the actual strength of the security services afforded
to it should be made to conform to each system's security policy"?

(And so on; in general, I suggest that the authors check all lowercase keywords
throughout Section 6.)

draft-ietf-mpls-tp-uni-nni

  1. Russ Housley: Discuss [2011-01-19]:
        
  The Gen-ART Review by Ben Campbell on 21-Dec-2010 lead to a
  discussion.  The discussion of Figure 1 and Figure 2 does not seem to
  be finished.  The discussion needs to reach closure before this
  document is approved.

draft-ietf-mptcp-threat

  1. Jari Arkko: Comment [2011-01-19]:
    This is an excellent document and I can warmly recommend its approval. Thank you
for writing it, Marcelo.

Some small comments:

In Section 3, where the document discusses differences between MIPv6 RO and
MPTCP situation I had a couple of comments. First, I'm not sure I understand
what you mean with the bullet about MIPv6 relying on the original path always
being available. MIPv6 certainly assumes that the path that we are using at that
moment is working, and if it is not, the system will attempt to move to some
other address or network attachment point. Secondly, I think you are missing one
additional difference: in MIPv6 we assume that there's always a trusted third
party (the home agent) that can help us with some of the security problems. In
MPTCP there is no such entity. You might also be missing the difference that
MPTCP intends to be able to use multiple paths simultaneously, which was not an
original design goal of the MIPv6 work.

In Section 6.3, the text discusses the effects of NAT on securing the implicitly
reported new address. The text fails to explain that while explicit mode would
allow better protection of the reported new address, such protection would be
pointless because it would protect an address that is no longer relevant on the
outside of the NAT. You actually *need* to report the address as changed by the
NAT. And by the way, I see nothing wrong with that... that's is how current TCP
works, too.

I like the basic recommendations in Section 7. But I am unsure if the analysis
in the document actually supports the advanced recommendation to have optional
support for HMAC. Why would that needed? Also, should the conclusions say
something about how MPTCP design should deal with sequence number spaces -- it
seems that different choices here would result in different impacts.
  2. David Harrington: Comment [2011-01-19]:
    This document does a good job of analyzing the threats for MPTCP. Thanks you.

While fully understandable, I found the text a bit wordy, with extra phrases and
clauses thrown in where they really weren't needed. This document could be much
more concise, and if you are doing a new revision, you might want to consider
tightening up the text. But this is purely a style issue, and the authors are
free to ignore this comment if they so choose.

Some examples of things that can be tightened:
"It should be noted that yada
yada yada" - this implies that somebody should sometime in the future note this,
but you are noting it now, so all you need is the yada yada yada without "It
should be noted that".

I recommend you check any "Note that" usages; they are almost always
unnecessary.

"Similarly to the MPTCP case, the Shim6 protocol is a layer 3
      protocol so all the communications involving the target address
      are at stake, as opposed to the MPTCP case, where the impact can
      be limited to a single TCP connection."
would be much more concise as simply "The Shim6 protocol is a layer 3
      protocol so all the communications involving the target address
      are at stake; in MPTCP, the impact can
      be limited to a single TCP connection."

s/behaviour of SCTP as defined/behaviour of SCTP/

I recommend checking to see if removing some of these phrases actually changes
the meaning of the sentence:
s/as such//g
s/So,//g
s/As we stated earlier,//
s/In order to do that,//
s/This means that//
s/In particular//g
s/We assume
that//g
s/So, at least,//
s/In addition,//
s/the so called//
s/It should be
noted that/
s/In other words,//
s/namely//
s/In this case,//
s/basically//
s/This implies that//
s/It seems that/
s/It seems reasonable to assume that//
s/This per se,/This/
s/The result is that/
s/This means that//
s/This basically
means that//

and some specific places:
s/In addition, we have the target of the flooding
attack, target T which has an IP address IPT./
   Target T has an IP address
IPT./
s/In the first step of this attack (depicted as step 1 in the figure), the
attacker A/
  The attacker A/
s/the second step of the attack (depicted as step
2 in the figure)/
   the second step of the attack/
 or /step 2 of the attack/
(to align it with the figure labels)

s/The actual details of this/The details/
s/somehow more secure/more secure/
s/Similarly to the previous case,//
s/As opposed to the previous one,//
s/As we have described earlier,//
  3. Alexey Melnikov: Comment [2011-01-15]:
    In Section 1:

   This
   note includes a threat analysis for MPTCP.  It should be noted that
   there are there may other ways to provide multiple paths for a TCP

This doesn't read well

   connection other than the usage of multiple addresses.  The threat
   analysis performed in this document is limited to the specific case
   of using multiple addresses per endpoint.

In Section 3:

   o  Similarly to the MPTCP case,

Did you mean "MIPv6 RO" here?

      the Shim6 protocol is a layer 3
      protocol so all the communications involving the target address
      are at stake, as opposed to the MPTCP case, where the impact can
      be limited to a single TCP connection.
  4. Dan Romascanu: Comment [2011-01-20]:
    In the OPS-DIR review  Lionel Morand raised the issue that it is recommended to
allow the support of multiple security mechanisms but there is nothing about
potential related mechanism negotiation  issues. I suggest that this be
addressed before the publication of the document, even if it is not a blocking
issue.

draft-ietf-mptcp-architecture

  1. Jari Arkko: Comment [2011-01-19]:
    An excellent document. Thanks for writing it.

I would change the urgent data support to a MAY, however.
  2. David Harrington: Comment [2011-01-19]:
    I think this document is well-written and support its publication. 

1)  The architecture document has no discussion of how MPTCP should be managed,
or what types of information should be made accessible for management purposes.
I believe it should - at an architectural level.

However, since this is the architecture document for a protocol being put forth
as Experimental, it would be beneficial to take the results of the experiment
into consideration when designing an appropriate management solution. Therefore,
I have reduced this to a comment.

TCP is intrumented with a MIB that is widely implemented on devices and used by
network management applications. MPTCP should share that MIB for aspects that
are designed to be transparent to the application. However, there should be
extensions specific to MPTCP so an operator can monitor the operational state
and impact of MPTCP.
For example, 
a) MPTCP should be able to be
enabled/disabled, the enabled/disabled state should be able to be queried, and
the fallback mentioned in section 2.1 should be indicated in operational state.
b) if there are errors or congestion on a path and MPTCP can detect those errors
or congestion, it should make that information available to an operator via the
MIB. 
c) if MPTCP can determine the performance of each path, that information
should be made available via the MIB for use by performance monitoring
applications.
d) if MPTCP can determine the different security state of
different paths, that information should be made available via the MIB. It would
probbaly be good if an operator can choose to provide a weight for different
paths based on the security properties of the path.
  3. Russ Housley: Discuss [2011-01-19]:
        
  The Gen-ART Review by Joel Halpern on 14-Jan-2011 raises one concern
  that needs to be addressed.  That is, "break-before-make" is added in
  the security design decisions in section 5.8.  Even if this is merely
  a desirable behavior, it should be described in the behaviors before
  being referenced in the design decisions.
  4. Alexey Melnikov: Comment [2011-01-16]:
    5.6.  Connection Identification

   Legacy applications will not, however, have access to this identifier
   and in such cases a MPTCP connection will be identified by the
   5-tuple of the first TCP subflow.  It is out of the scope of this
   document, however, to define the behaviour of the MPTCP
   implementation if the first TCP subflow later fails.  If there are
   MPTCP-unaware applications that make assumptions about continued
   existence of the initial address pair, their behaviour could be
   disrupted by carrying on regardless.  It is expected that this is a
   very small, possibly negligible, set of applications, however.  In
   the case of applications that have used an existing API call to bind
   to a specific address or interface, the MPTCP extension MUST NOT be
   used, since the applications are indicating a clear choice of path to
   use and thus will have expectations of behaviour that must be
   maintained, in order to adhere to the application compatibility
   goals.

I am not convinced your use of MUST NOT is correct here. In fact, it seems that
it is in direct conflict with the following paragraph:

   Since the requirements of applications are not clear at this stage,
   however, it is as yet unconfirmed what the best behaviour is.  It
   will be an implementation-specific solution, however, and as such the
   behaviour is expected to be chosen by implementors once more research
   has been undertaken to determine its impact.

I.e., it is actually possible to know from the current socket API what is the
application intent in this case?
  5. Dan Romascanu: Comment [2011-01-20]:
    I support David's COMMENT

draft-merrick-jms-uri

  1. Lars Eggert: Comment [2011-01-17]:
    INTRODUCTION, paragraph 4:
>    The syntax of this 'jms' URI is not compatible with any known current
>    vendor implementation, but the expressivity of the format should
>    permit all vendors to use it.

  So are there vendor implementations of 'jms' already? If yes, what it
  the value in publishing a specification that is not compatible with
  any of them? Or do we have an indication that the vendors will adopt
  this spec?
  2. Alexey Melnikov: Comment [2011-01-14]:
    It looks like IANA issue was actually addressed in the last revision.

draft-nsri-tls-aria

  1. Adrian Farrel: Comment [2011-01-20]:
       This document proposes the addition of new cipher suites to the
   Transport Layer Security (TLS)

Please don't be so timid. "This document defines/specifies ..."
  2. Dan Romascanu: Comment [2011-01-18]:
    Please expand PRF at first occurence.

draft-schaad-smime-hash-experiment

  1. Lars Eggert: Discuss [2011-01-17]:
          DISCUSS: ID is missing the RFC2119 boilerplate and reference.
  2. Lars Eggert: Comment [2011-01-17]:
    INTRODUCTION, paragraph 4:
>    algorithms with parameters, but anecdotic evidence suggests that

  Nit: s/anecdotic/anecdotal/

INTRODUCTION, paragraph 13:
> Internet-Draft            CMS Paramertized Hash             January 2011

  Nit: s/Paramertized/Parametrized/

Section 8., paragraph 0:
>      A.3.  Autenticated Data Example  . . . . . . . . . . . . . . . . 17

  Nit: s/Autenticated/Authenticated/

Section 1., paragraph 9:
>    The ASN.1 defined for the types DigestedData and AthenticatedData are

  Nit: s/AthenticatedData/AuthenticatedData/

Section 1., paragraph 11:
>    SignerInfo.digestedAlgorithm is not seen until the content has been

  Nit: s/SignerInfo.digestedAlgorithm/SignerInfo.digestAlgorithm/ (I
  think?)

Appendix A., paragraph 7:
>  To: BobRSA@examples.com

  "examples.com" is not one of the usual domain names set aside for
  documentation purposes. Do you mean "example.com"?
  3. Russ Housley: Discuss [2011-01-19]:
        
  There are many algorithm identifiers that specify a hash algorithm and
  a signature algorithm used in combination.  It is highly desirable
  that the same hash algorithm be used for computing the digest of the
  attributes and the content.  How would xor-md5WithRSAEncryption be
  handled?
  4. Alexey Melnikov: Discuss [2011-01-19]:
        [Updated.]

I generally support this experiment. However the MIME section contains several
errors that need to be fixed before this document can be approved:

>5.  MIME handling
>
>   This section defines the string that appears in the micalg parameter.
>
>   The algorithm is identified by the string xor-md5.  The parameters
>   for the algorithm are the hex encoded DER ASN.1 encoding.  The
>   parameters and the identifier string are separated by a colon.
>   Arbitrary amounts of white space may be inserted between any two
>   characters in the hex encoded string.

I don't believe this comment is correct according to MIME, you should be using
the mechanism defined in RFC 2231.

>   An example content-type string
>   would be:
>
> Content-Type: multipart/signed; protocol="application/pkcs7-signature";
>      micalg=sha1, xor-md5:04400102030405060708090a0b0c0d0e0f00111213141
>      5161718191a1b1c1d1e1f102122232425262728292a2b2c2d2e2f2031323334353
>      63738393a3b3c3d3e3f30;
>      boundary=boundar42

According to RFC 1847, micalg is defined as:

   parameter := "micalg" "=" value

which I believe is referencing the <value> ABNF production from MIME (RFC 2045):

    value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
                   ; Must be in quoted-string,
                   ; to use within parameter values

So, neither spaces nor commas are allowed in the micalg parameter, unless it is
quoted.

quoted-string is defined in RFC 5322 (/2822/822). I don't remember of the top of
my head
how folding of lines interacts with quoted strings. I will research that
as well.

In Section A.2:

  MIME-Version: 1.0
  To: User2@examples.com
  From: BobRSA@examples.com
  Subject: MD5-XOR signing example
  Message-Id: <091218002550300.249@examples.com>
  Date: Fri, 18 Dec 2010 00:25:21 -0300
  Content-Type: multipart/signed;
      micalg=xor-md5: 0440010203405060708090a0b0c0d0e0f10
       111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e2f30
       313233435363738393a3b3c3d3e3f40

I think the trailing ";" is missing on the above line (in addition to missing
quoting).

      boundary="----=_NextBoundry____Fri,_18_Dec_2009_00:25:21";
      protocol="application/pkcs7-signature"
  5. Alexey Melnikov: Comment [2011-01-19]:
    RFC 1847 needs to be an Informative Reference. I think MIME as well.

draft-zorn-radius-keywrap

  1. Lars Eggert: Comment [2007-01-25]:
    Agree with Russ and Dan.
  2. Dan Romascanu: Comment [2011-01-13]:
    In the Abstract Section s/This attributes/These attributes/

draft-templin-iron

  1. Jari Arkko: Comment [2010-12-16]:
    
    
  2. Stewart Bryant: Comment [2010-12-15]:
    
    
    I am surprise that the document contains no reference to LISP which is
operating broadly in this space.

=======

SRA is not a defined abbreviation.

=======

This needs a few words of clarification - presumably the "locator addresses" are
the addresses learned from the relay.

  After the Client receives an SRA message from the nearby Relay
   listing the locator addresses of nearby Servers, it sends SRS test
   messages to one or more of the locator addresses to elicit SRA
   messages.

=======
				   
If this Server fails, the Client will quickly select a new
   one which will automatically update the VPC overlay network mapping
   system with a new EP-to-Server mapping.

"quickly" is a non-specific metric

=======

[I-D.templin-intarea-seal] looks like it should be normative
[I-D.templin-intarea-vet]  looks like it should be normative

Although the RFCeditor may wish to overlook this if there is a concern that
these drafts will not be taken to completion.


    
    
  3. Ralph Droms: Comment [2010-12-16]:
    
    
    I have one suggestion about the content of the document.  I'd like to
see an analysis of how IRON actually "provide[s] scalable PI
addressing without changing the current BGP [RFC4271] routing system"
along with costs incurred by IRON.  How does hiding the EPA addresses
inside the IRON locator prefixes reduce the routes in the real
Internet core?  What is the cost in the routing tables maintained by
the relays?  How expensive is the anycast routing?  How does inter-VPC
routing work and how expensive is it?

The remainder of my COMMENTs are editorial.

In Section 6.1, I think I understand what this text is trying to
explain, but I don't think it's correct:

   It
   is therefore essential that the Client send the initial packets
   through its Server to avoid loss of SCMP messages that cannot
   traverse a NAT in the reverse direction.

Does this mean to explain that the Client sends packets through its
Server to establish NAT state so SCMP messages from the Server to the
Client can traverse the NAT?

In Section 6.2, this text uses "into the Internet" in a confusing way,
assuming I'm understanding the meaning of the text correctly:

   The Server then
   forwards the revised packet into the Internet via a default or more-
   specific route, where it will be directed to the closest Relay within
   the destination VPC overlay network.

Everywhere else in this section "into the Internet" is used to
describe the forwarding of a decapsulated datagram, after the outer
header with locator addresses have been removed, into the (non-IRON)
Internet.  In the text quoted aboce, "into the Internet" seems to mean
forwarding of an encapsulated datagram, which is described elsewhere
in this section as simply "forwards" or "sends".  I suggest rewriting,
for consistency, as

   The Server then
   forwards to the closest Relay within
   the destination VPC overlay network.

In Figure 6, why would the anycast datagram from Server(A) be
delivered to Relay(B) rather than Relay(A) (which presumably would be
in the routing fabric for ISP A)?  Does it matter? 

Once Server(B) receives the datagram to be forwarded to Client(B), is
it possible for Server(B) to send a redirect to Client(A) so Client(A)
can send traffic directly to Client(B)?

Stylistic nit in section 6.4.1 (and elsewhere) - why start using the
verb "releases" instead of the previously used "forwards" or "sends"?
Seems like lots of unnecessary verbiage right after Figure 6; why not
something like "..., host A sends packets to host B through its EUN.
Client(A), as the defautl router for the EUN, receives the packets,
encapsulates them in the IRON encapsulation and forwards them to
Server(A). ..."  (etc.)  All the explanation of routing, etc., seems
redundant at this point.

Sorry, can't help myself; in section 6.6:

   The IRON approach to
   renumbering avoidance therefore depends on VPCs conducting ethical
   business practices and offering reasonable rates.

... as opposed to the unethical business practices and unreasonably
high rates from those evil, greedy ISPs.

Seriously, has the renumbering problem simply been moved from the ISPs
to the VPCs?

    
    
  4. Adrian Farrel: Comment [2010-12-16]:
    
    
    Thank you for bringing this work forward as Experimental and so increasing the
documentation and discussion of potential solutions.

I feel that it would be helpful if the document contained a pointer to draft-
irtf-rrg-recommendation so that the other ideas in the field can be easily found
and compared.