IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. PIM Multi-Topology ID (MT-ID) Join Attribute (Proposed Standard)
    draft-ietf-pim-mtid-08
    Token: Adrian Farrel
    Note: Mike McBride (mmcbride@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3797):
    1. Adrian Farrel: Comment [2011-06-29]:
      We should pick up the comments raised by Thomas Clasuen in his Routing Directorate review
    2. Stephen Farrell: Comment [2011-06-26]:
      (1) end of 4.2.2, s/choose not/chooses not/
      (2) 4.2.4.1 s/all together/altogether/
    3. David Harrington: Comment [2011-06-28]:
      1) some "may" usage is in lower case and should probably be capitalized for clarity.
    4. Russ Housley: Comment [2011-06-30]:
      Please add introductory text prior to the bullets in sections 3.1, 4.2.4.1, and 4.2.4.2.
    5. Pete Resnick: Comment [2011-06-26]:
      Acronyms should probably be expanded out and defined in the Abstract and the Intro.
    6. Robert Sparks: Comment [2011-06-29]:
      Can you clarify the first paragraph of 4.2.3? It's not yet obvious why you felt a need to call out the Robustness Principle here specifically. Are you trying to note that you have some backwards compatibility with existing systems, provide guidance to implementers of the extension to be careful to achieve that compatibility, both, or something completely different?
    7. Sean Turner: Discuss [2011-06-29]:
      This is updated.
      #1) resolved
      #2) Section 5.2, needs to include something to say how the reserved bits are set and how they're treated. Maybe something like what's in RFC 4601:
      "Reserved: Set to zero on transmission. Ignored upon receipt."
    8. Sean Turner: Comment [2011-06-27]:
      #1) Section 3.2 contains the following:
      "- This value must be unique and consistent within the network domain for the same topology."
      r/must/MUST?

    Telechat:

  2. RTP Payload Format for MPEG-4 Audio/Visual Streams (Proposed Standard)
    draft-ietf-payload-rfc3016bis-01
    Token: Robert Sparks
    Note: Roni Even (even.roni@huawei.com) is the document shepherd.
    Discusses/comments (from ballot 3814):
    1. Adrian Farrel: Discuss [2011-06-30]:
      The only mention of RFC 3640 is in the Abstract, where you seem to state that, in new implementations, *this* I-D is NOT RECOMMENDED.
      That really isn't very good, is it? If you are going to have the specific sentence in the Abstract (and I presume it is there for a good reason) you siply must:
      - include this point in the Introduction
      - take the time somewhere in the document to explain the limitations of this approach (possibly by reference) and make a clear statement about the purpose of this document and when it should or should not be used.
    2. Adrian Farrel: Comment [2011-06-30]:
      Can you please remove the citation ([RFC3640]) from the Abstract.
      For what it is worth, the ballot text says this document updates 3016. Obviously "update" is an overloaded term wrt RFCs, and "adds to" might be safer.
    3. Stephen Farrell: Discuss [2011-06-27]:
      Security considerations says "Therefore, a single mechanism is not sufficient, although if suitable, the usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended."
      I think that's just too vague - are you calling for SRTP to be implemented or used? And what does "if suitable" mean? How's that going to result in interop when crypto is needed?
      If you said "Implementations SHOULD support SRTP." and then gave examples of cases where you don't really want SRTP, and you do want IPsec or TLS or nothing at all, then that would clear this up for me.
      I believe this text has been used elsewhere as well (e.g. rfc 5993) so this may be more a question for the chairs/WG, than the authors of this document.
      There may also be other ways to clarify this as well of course. In particular, this issue is related to draft-ietf-avt-srtp-not-mandatory which has been sitting for a year.
    4. Stephen Farrell: Comment [2011-06-26]:
      (1) VOP is used (2nd para p5) without expansion
      (2) p14, s/PayloadMux elements are contained/PayloadMux element is contained/
      (3) p14, suggest rephrasing this: "is preceding the one or more PayloadMux elements."
      (4) 7.3, s/server must following/server must follow/
      (5) 7.4, s/Followings are some examples/The following are some examples/
      (6) section 11 title s/to/from/
    5. Russ Housley: Comment [2011-06-27]:
      Please consider the editorial comments from the Gen-ART Review by Suresh Krishnan on 26-Jun-2011.
    6. Dan Romascanu: Comment [2011-06-29]:
      Section 1.3 says:
      "Strictly speaking systems that support MPEG-4 Audio as specified in [RFC3016] are incompatible with systems supporting this document. However, all known existing systems do already comply with the specification in 3GPP PSS service [3GPP] and therefore there is no need to consider backward compatibility."
      I do not know what this 'strictly speaking' language exactly means. Also the 'all known' adjective is not a guarantee for the conclusion 'there is no need to consider backward compatibility' to be always true. The text here is probably sufficient, but I would prefer a more exact wording that says something like 'this specification is not bakwords compatible with RFC 3016, existing implementations of RFC 3016 MUST be updated to be compatible with this specification'
    7. Peter Saint-Andre: Discuss [2011-06-29]:
      Why is RFC 3016 a normative reference if it is being obsoleted by this spec?
    8. Peter Saint-Andre: Comment [2011-06-29]:
      Please expand "SIP" on first use and provide an informative reference to RFC 3261. References to H.261, H.323, and H.245 would also be helpful.
    9. Robert Sparks: Comment [2011-06-23]:
      Please clarify that the binary incompatibility the draft is addressing is due to the change in the encodings defined in 14496-3:2009 vs 14496-3:1999
    10. Sean Turner: Discuss [2011-06-28]:
      These ought to be easy enough to answer/clear:
      #1) Section 1.3 says that there's no backwards compatibility with RFC 3016. Should 3016 be made Historic?
      #2) Section 1.3 reads as if the 3GPP specification is the specification everyone wants to be compatible with. Is that specification considered the definitive source? That is, if there's a change made to the 3GPP specification would it get reflected in this draft?

    Telechat:

  3. Terminology Used in Internationalization in the IETF (BCP)
    draft-ietf-appsawg-rfc3536bis-04
    Token: Pete Resnick
    Discusses/comments (from ballot 3825):
    1. Ron Bonica: Discuss [2011-06-28]:
      1) The definitions in this document are not normative, but the document is a BCP. Isn't that a contradiction?
      2) You say that a writing system is a set of rules for using a script to express a language. A better example of this might be helpful. You use the example of the American and British writing systems, but I have no idea what those are.
      3) You use the term "character set" to describe the terms "coded character set" and "repertoire". But you never define this term. In fact, in the definition of charset you say, "Many protocol definitions use the term "character set" in their descriptions. The terms "charset" or "character encoding scheme and "coded character set" are strongly preferred over the term "character set" because "character set" has other definitions in other contexts and this can be confusing.
      4) The definition of "Glyph" leaves me thoroughly confused. The problem is that glyphs are described in terms of "glyph images". If I don't understand what a glyph is, how am I supposed to understand what a glyph image is?
      5) Your definition of Glyph code does more to explain what a glyph is than your definition of glyph. It makes sense that glyphs might have something to do with fonts, because the Greek word "glyphe" means "carving".
    2. Ralph Droms: Discuss [2011-06-29]:
      Ron picked up chains of definitions that I also found confusing. I had one other specific question and a more abstract question:
      1. I'm not clear about the relationship among the terms "character encoding form," "coded character set" and "character encoding scheme." I consulted RFC 2978 for help (would it be appropriate to cite RFC 2978 with the definitions of CCS and CES?), and it seems CCS/CES gives everything needed to go from characters to an octet sequence. Where does the "character encoding form" fit in?
      2. I learned from RFC 2978 that a charset is a mapping from an octet sequence to a character sequence, but the charset may not be a complete mapping in the other direction. Based on this little insight, I wonder about all of the other mappings in the document: are any of the other mappings only useful in one direction? Would it be useful to note the directionality of other mappings?
    3. Adrian Farrel: Comment [2011-06-30]:
      In Section 7.1 the definition ends with "<Stringprep>" but there is no such reference.
      While I found the indications of source references useful, I did not find that angle brackets were the best indicators as they are also used for two other (distinct) purposes in the document.
      Replacing <NONE> with <THIS> might send a more positive message.
    4. Stephen Farrell: Comment [2011-06-27]:
      (1) s/provides identifiers/provide identifiers/ in definition of language (standards is plural)
      (2) s/for global from the/for global use from the/ on p8
      (3) Is anchor9 in 3.2 supposed to remain or not? I would have thought the time for comments on that was past?
    5. Russ Housley: Discuss [2011-06-29]:
      I think this document should be published as an Informational RFC. It seems to play a very similar role to RFC 2828, which is an Informational RFC. Also, this document obsoletes RFC 3536, which is an Informational RFC.
    6. Dan Romascanu: Discuss [2011-06-29]:
      Updated DISCUSS taking into account changes from 02 to 03:
      1. One of the major changes from 3536 is that the future RFC aims to be a BCP, while 3536 was Informational. I expected to find a discussion on this respect including some rationale of the change and including some language that recommends using the terminology defined in this document. However section 1.1. 'Purpose of this Document' keeps using a language that is more appropriate to an Informational document, like: 'This document attempts to define terms in a way that will be most useful to the IETF audience.'
      2. The defition of 'glyph' seems circular to me: "A glyph is an abstract form that represents one or more glyph images. The term "glyph" is often a synonym for glyph image, which is the actual, concrete image of a glyph representation"
      3. Section 6 - is not the SnmpAdminString TC defined in RFC 3411 an example of usage of an ASCII-compatible encoding (ACE) that has reached standard status?
    7. Dan Romascanu: Comment [2011-06-29]:
      1. section 3.1 - why is W3C called 'This group' rather than 'This organization' or 'This consortium'?
      2. Appendix C should mention the change from Informational to BCP. I believe it is significant.
    8. Robert Sparks: Comment [2011-06-29]:
      I don't agree that this document needs BCP status as currently formulated. We can find a way to address the downref inconvenience if that's a primary motivation. I don't find a basis in 2026 for "This is informational but we REALLY mean it".
      If there are requirements being placed on future IETF work (even if those requirements apply only to a particular set of groups), I can see an argument for BCP in the 2026 definitions.
      That said, if this is published as a BCP, I don't believe it does any harm to the work it is attempting to influence, and very little additional harm to how the world (especially outside the IETF) interprets RFCs with this designation (beyond continued erosion of the perception of BCPs as "special"), so I am balloting no objection while stating a preference that the choice be reconsidered.
    9. Sean Turner: Comment [2011-06-28]:
      What no proto write-up ;)
      I'm curious to see how Dan's 1st discuss point shakes out. If it's really going to be a BCP, then the following should be changed:
      "The definitions in this document are not normative for IETF standards; however, they are useful and standards may make informative reference to this document after it becomes an RFC."
      If it's a BCP then, as Barry noted in his response to Dan, everybody could normatively reference this document. I'm not really sure I buy the rationale of wanting to make this a BCP because everybody wants to normatively reference it (because DOWNREFs are easy), but if that is the case, then we ought to say so.
      Is there somebody outside the IETF that can't reference an informational RFC that wants to refer to this draft?

    Telechat:

  4. Packet Loss and Delay Measurement for MPLS Networks (Proposed Standard)
    draft-ietf-mpls-loss-delay-03
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-loss-delay-03
    Discusses/comments (from ballot 3828):
    1. Ron Bonica: Comment [2011-06-28]:
      Please add text to section 2.9.10 stating that in the following conditions, delay measurement will be useless:
      - when the two router clocks differ by a significant portion of the round trip time
      - when probe processing contributes significantly to round trip time
    2. Wesley Eddy: Discuss [2011-06-30]:
      The computation of the throughput metric is only very loosely specified here. Since the counters exchanged can represent either a number of packets or a number of bytes, then the throughput can either be computed in packets/time or bytes/time depending on what units are used.
    3. Adrian Farrel: Discuss [2011-06-23]:
      This is an administrative Discuss - I intend to move to move to a YES ballot.
      This document is in an administrative second IETF last call because of a late IPR disclosure. The IESG will hold its evaluation before this second last call completes. I will hold this Discuss until last call completes in case any issues are raised from the community.
    4. Stephen Farrell: Discuss [2011-06-25]:
      This is just a discuss to check if the chat arising from Steve Kent's secdir review [1] reached closure. The discussion seemed to tail off a bit and I'm not clear if it was done or not.
    5. Stephen Farrell: Comment [2011-06-25]:
      (1) Section 2 as a whole is very wordy. While its fine to spell things out for clarity, this text perhaps demands too little from the reader, at the expense of clarity for the capable reader. (In other words, this seems just too long:-) Feel free to entirely ignore this comment though.
      (2) The "(B1,...,Bk)" notation isn't clear in 2.6 - are we measuring (A,B1) and (A,B2) etc. or are we measuring what happens on the path from A to Bk via B1,B2...etc.? Since the section is about unidirectional LSPs it may be easier to just deal with A and B here.
      (3) (2.9.3) Saying that the detailed measurement behavaiour "MUST be made clear to the user" seems wrong in two respects - a) a programmer won't know what'll be clear to all future users of their code, and b) there may be no (human) user that can see the direct mesurements, (the humans might only see derived statistics I guess). I also don't quite know how I'd test for that MUST. Maybe just loose the 2119 language there?
      (4) 2.9.5 assumes that intermediate nodes can reply to LM/DM messages, but that hasn't yet been stated.
      (5) Two timestamp formats are supported - would be good to include examples of each at the point where that's first mentioned in detail.
    6. Dan Romascanu: Discuss [2011-06-28]:
      This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise.
      1. The document defines new protocols without making any reference to the IPPM OWAMP (RFC 4546) and TWAMP (RFC 5357) despite the bidirectional measurment described in section 2.1 being very similar to the latest, for example, If there are good reasons for which OWAMP and TWAMP are not suited in the MPLS environment I suggest that these need to be clearly explained.
      2. The applicability statement in section 1.1 risks to create confusion with the IPPM work. I would rather drop it.
      "Although the procedures in this document are presented in the context of MPLS, they have no essential dependence on MPLS and generalize easily to other types of packet networks. Such generalizations are, however, outside the scope of this document."
      3. In Section 2.2:
      "The foregoing discussion has assumed the counted objects are packets, but this need not be the case. In particular, octets may be counted instead. This will, of course, reduce the MaxLMInterval proportionately."
      Proportionately to what? Probably with the ratio between 1 and the number of octets in the minimal packet size on the respective media. Either be exact, or use some other more suitable term (accordingly?).
      4. What is the reason for not using the packet loss metrics definition from RFC 2680? (while the delay metrics are referenced from 2679 and 2681 repectively). If that definition is not suitable I suggest that this is discussed if not please add the reference.
      5. I support Wesley's DISCUSS concerning the throuput metrics and discussion and I generally feel very unconfortable with the way it is dealt with in this document. Do we need reference to througput at all? after all the scope of the document focuses on loss and delay. If we do I would also suggest a serious rewrite starting from a proper definition of the metics or reference to existing definitions in other RFCs if appropriate.
      6. The PDV definition in section 2.5 is rather vague. I suggest to refer to section 4 in RFC 5481 which makes a clear distinction between PDV and IPDV.
      7. The document lacks proper manageability considerations:
      section 2.9.7: "This can be achieved in supporting implementations by, for example, configuring the querier, in the case of a bidirectional measurement session, to forward each response it receives to the post-processor via any convenient protocol. Post-processing devices may have the ability to store measurement data for an extended period and to generate a variety of useful statistics from them."
      section 4.1: "Measurement sessions are initiated at the discretion of the network operator and are terminated either at the operator's request or as the result of an error condition."
      There is no mention about how to remotely configure this protocol (example: MIB or YANG module), how to retrieve the results, what are the storage requirements for the results and methods and periodicity of retreival of the results. There is no mention about the security implications of activating two new protocols that generate traffic in the network and what are the admissible levels of traffic that can be generated.
    7. Sean Turner: Discuss [2011-06-30]:
      This is an updated discuss based on an exchange with an author.
      #1) Which of the 5 formats defined in Section 3.1 MUST be supported for an implementation to be considered compliant to this document?
      #2) Section 3.4 contains the following:
      "The Type space is divided into Mandatory and Optional subspaces.. Upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code."
      and Section 8.4 contains the following:
      "IANA is also requested to indicate that Types 0-127 are classified as Mandatory, and that Types 128-255 are classified as Optional."
      Wouldn't it be more 2119-like if you used REQUIRED and OPTIONAL? Isn't this kind of saying that the elements in the 0-127 range MUST be supported?
      Also later in 3.4 it includes:
      "127--Experimental use"
      You're requiring implementations to support the experimental TLV? I would think that would be OPTIONAL.
      #3) Which of the four TLV objects in Section 3.5 MUST be supported for an implementation to be considered compliant to this document? It says zero or more may be present but not which ones MUST be supported. Are any of them a MUST?
      #4) cleared
    8. Sean Turner: Comment [2011-06-28]:
      #1) Section 3.1 and 3.2 contains the following:
      TLV Block--Optional block of Type-Length-Value fields"
      Should Optional be OPTIONAL to indicate support requirement?
      #2) Section 4.2.2 contains the following:
      "When transmitting an LM Query over a channel, the Version field MUST be set to 0."
      Shouldn't "over a channel" be removed? Isn't version always set to 0?
      #3) Section 4.2.2 contains the following:
      "The Origin Timestamp field SHOULD be set to the time at which this message is transmitted,"
      hmmm so what other time would be put there? The definition from earlier sections is:
      Origin Timestamp: Timestamp recording the transmit time of the query message.
      #4) Section 4.3.1 contains the following:
      "When transmitting a DM Query over a channel,"
      Shouldn't "over a channel" be removed? Isn't version always set to 0?

    Telechat:

  5. DomainKeys Identified Mail (DKIM) Signatures (Draft Standard)
    draft-ietf-dkim-rfc4871bis-13
    Token: Sean Turner
    Note: Barry Leiba (barryleiba@computer.org) is the document shepherd.
    IPR: Yahoo! Inc.'s Statement about IPR related to RFC 4871 and draft-ietf-dkim-rfc4871bis-09
    Discusses/comments (from ballot 3868):
    1. Adrian Farrel: Comment [2011-06-29]:
      I note that in Section 1.2 of RFC 4871 (May 2007) it says "there are currently over 70 million domains." So while Section 1.3 of this I-D is not wrong to say "there are currently over 70 million domains," it may be a significant underestimate.
      I am not completely comfortable with the use of "normative" RFC 2119 language in ABNF comments. For example...
      "dkim-safe-char = %x21-3A / %x3C / %x3E-7E ; '!' - ':', '<', '>' - '~' ; Characters not listed as "mail-safe" in [RFC2049] are also NOT RECOMMENDED."
      A terrible nit, but would you consider s/may/might/ in...
      "o The practical constraint that large (e.g., 4096 bit) keys may not fit within a 512-byte DNS UDP response packet"
    2. Stephen Farrell: Comment [2011-06-24]:
      Good job. Other, than (6) & (8) below, which I'd ask that you check, I'm entirely fine if you totally ignore these - they're just the notes I made as I read the thing again (after not having had to do that for a while:-) and are basically all nitty suggestions.
      (1) 2nd para of 2.6 refers to "i=" and "t=s" before those have been introduced. I wouldn't suggest defining them here, so I'm not sure what to change to make it better but maybe worth a look. Maybe you could get rid of the tags though for example by saying:
      "Note that acceptable values for the AUID may be constrained via a flag in public key record. (See Section 3.6.1)"
      (2) end of p20, maybe s/are expected to/may/ since we're doing a new spec now but not changing the version number.
      (3) 2nd last para, p23: signing non-existent header fields does not "prevent" later insertion, it allows detection of that after the fact. Same issue with last para on p23 as well. The change is obvious I guess if you want to make it.
      (4) p26, is "DNS TXT record" or "DNS TXT resource record" more correct? (And if so, do we care or not:-) If the latter then the same change would be needed in a few places.
      (5) Would it be useful for the reader and/or IANA to note that there are no new tags defined in section 7 compared to rfc4871?
      (6) Is 7.9 actually correct? That IANA registry references 4871 but should that be changed to this document or left alone? I've no idea.
      (7) Could/should appendix B.2.3 have an informative reference to dkim-mailinglists? Since that's now approved, it won't add any significant time for the RFC editor to do those together. (I think.)
      (8) The last paragraph of appendix C is odd - maybe the reference in there should be to rfc4870?
    3. Russ Housley: Comment [2011-06-29]:
      Appendix E should probably include a pointer to the errata. Some documents have included a URL for this purpose.
    4. Pete Resnick: Discuss [2011-06-29]:
      1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING" and section 8.1):
      "INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient's eyes, such as via alterations to the MIME structure or exploiting lax HTML parsing in the MUA, and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using this tag, and verifiers might wish to ignore the tag, perhaps based on other criteria."
      This is not an attack against DKIM. If the signer said, "I'm signing the first n bytes of the body of this message" and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. There might be an attack on an MUA that does not verify the DKIM signature, but that is outside the scope of this document. Either way, 3.4.5 and 3.5 should have forward references to 8.1. This is a security consideration, not anything "informative".
      2. Section 6.1.3:
      "verifiers might treat a message that contains bytes beyond the indicated body length with suspicion, such as by declaring the signature invalid (e.g., by returning PERMFAIL (unsigned content)), or conveying the partial verification to the policy module."
      Up to the word "suspicion", fine. After that, it is complete nonsense. The signature is not invalid. If what you mean is "and may choose to treat the signature as if it were invalid (e.g., by going into the PERMFAIL state)", then say that. And again, this is trying to wrap APIs and implementations choices into the protocol.
      3. Section 8.2: I don't see how this is DKIM specific. More importantly, this section doesn't explain how user private keys relate in any way to keys used in DKIM. Shouldn't this be a discussion about security of private keys in general (not just ones on user machines)?
      4. Section 8.5: I don't understand what the attack here is that has anything to do with DKIM. I especially don't see why the accomplice is an essential part of the example, unless all that is meant by "accomplice" is "relay". The attack sounds like, "people can spam signed messages", which is not an attack on DKIM.
      5. Section 8.14: This is a complete mischaracterization of the problem. This is absolutely not an attack vector. If a signer wishes to prevent additional *known* header fields from being verified, it can simply use the technique outlined in 8.15. If the signer chooses not to do that, it is expressing the intent that it considers messages valid that have additional header fields added. *That's* the security consideration: Signers should know that failing to include, e.g., "h=...:from:from:..." on messages with one "From:" header field are leaving themselves open to this attack. The attack is not on the verifier.
      Additionally:
      "Note that the technique for using "h=...:from:from:...", described in Section 8.15 below, is of no effect in the case of an attacker that is also the signer."
      That sentence is utter nonsense. The signer *can't* be the attacker for purposes of DKIM when it comes to the header fields it's willing to sign. The Introduction (section 1) makes it absolutely clear that DKIM is about transmitting information from a signer to a verifier.
      Section 8.14 needs to be completely rewritten. It is nonsensical as it stands.
      6. Section 8.15:
      "Implementers need to consider this possibility when designing their input handling functions. Outright rejection of messages that violate the relevant standards such as [RFC5322], [RFC2045], etc. will interfere with delivery of legacy formats. Instead, given such input, a signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates."
      DKIM can perfectly well deal with the obsolete syntax. The signer can sign as many "From:" fields as the message has when signed, and add a ":from" to the "h=" tag to insure that the right number of them are verified. As in 8.14, the attack is not on DKIM per se; it's on signers that don't properly use the "h=" tag to sign those header fields that they don't want added to.
      Other malformed input might cause problems for a DKIM implementation, but multiple header fields where 5322 3.6 only allows one is not that sort of attack.
    5. Pete Resnick: Comment [2011-06-29]:
      These first 15 comments are things that I think are potentially real problems, but I haven't heard enough back from the authors yet to know if they are worthy of a DISCUSSion.
      [15 comments elided]
      These last 10 comments are simply stylistic and editorial stuff. If they make sense to fix, great. If not, I'm not concerned.
      [10 comments elided]
    6. Peter Saint-Andre: Comment [2011-06-29]:
      1. It's good to see draft-ietf-dkim-implementation-report, which has a thorough overview of the interoperability testing held in 2007. However, that I-D does not discuss interoperability regarding the clarifications in RFC 5672. Are they covered here? Does the community have enough experience with them to enable us to say that there are at least two interoperable implementations of RFC 5672?
      2. In Section 3.2, why not reference RFC 4648, perhaps with text about line feeds (etc.), instead of Section 6.8 of RFC 2045?
      3. In Section 3.2, we might consider adding an informative reference to RFC 3629 with regard to UTF-8.
      4. In Secton 3.6.2, we might consider adding a normative reference to RFC 1464 with regard to DNS TXT RRs.
      5. In Section 6.1, we might consider adding an informative reference to RFC 4732 with regard to denial of service attacks. (Also Sections 8.3, 8.7, 8.12.)
      6. In Section 6.1.1, we might consider changing MAY to SHOULD. This seems like something we'd recommend, not describe as purely optional.
      7. In Section 7, "one has been obsoleted" makes it sound as if a new tag has been defined to replace it (as in RFC 2026); we might consider changing it to "one has been designated as historic".

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Design Considerations for Session Initiation Protocol (SIP) Overload Control (Informational)
    draft-ietf-soc-overload-design-06
    Token: Robert Sparks
    Note: Salvatore Loreto (Salvatore.Loreto@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3712):
    1. Adrian Farrel: Comment [2011-06-29]:
      In Section 1
      "Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse."
      Reading (and re-reading) this paragraph, I could not extract from the text whether the concern is the network throughput of SIP messages, or the impact on the data flows that are controlled by the SIP messages. It seems to me that you need to make this clear up front, and that you should spend some time distinguishing the impact of SIP overload on existing data flows from the case you are describing.
      It may be that this is obvious to the informed reader, but it should be easy for you to explain, and that will make life easier for future readers.
    2. Stephen Farrell: Comment [2011-06-28]:
      Nice document, with good security considerations. Thanks.
      One possible additional security consideration - if an attacker can convince senders that various other nodes are overloaded, then it could cause traffic to be directed towards attacker-chosen servers. That could either be part of a DoS on the attacker-chosen servers, or, if the attacker-chosen servers are operated by or for the attacker, then the attacker could monitor possibly many more calls than otherwise.
    3. Pete Resnick: Comment [2011-06-29]:
      This is a nice piece of architectural work. How did this end up in a WG instead of the IRTF? :-)
      One mostly editorial comment. From the Introduction:
      "Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse."
      That's not congestion collapse. The first paragraph of section 2 talks about what *is* congestion collapse: congestion-related retransmissions themselves increasing congestion. Something's missing from the above paragraph.
    4. Dan Romascanu: Discuss [2011-06-29]:
      This is a very well written document. Before I turn my ballot into a YES I would like to DISCUSS one aspect of the SIP overload control which is related to manageability and specifically to observability. As I understand from the document and from the WG charter several methods of SIP overload control will be proposed and more than one may be supported by a SIP server. How can a network operator know what is supported on each device in the network? Also, for existing deployments, are there any mechanisms (alerts or status indication) that show whether one of the specific mechanism was triggered and activated? I believe that the design document needs to add some text refering to these operational aspects.
    5. Peter Saint-Andre: Comment [2011-06-28]:
      This is a fine document. Please expand acronyms on first use (e.g., "UA", "UAC", "UAS", "RPH"). A reference to RFC 4732 ("Internet Denial-of-Service Considerations") might be appropriate.
    6. Robert Sparks: Comment [2011-06-23]:
      Please take these editorial suggestions into account:
      1) At "Introducing many such short-lived sybils" - I suggest s/sybils/servers. If you want to compare this to a sybil attack, an additional sentence would be better.
      2) I suggest s/affecting a reduce in the service/affecting a reduction in the service/
      3) At "keep the receiver window fill", I suggest s/fill/full/

    Telechat:

  2. A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks (Informational)
    draft-ietf-mpls-tp-loss-delay-profile-03
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    Discusses/comments (from ballot 3829):
    1. Wesley Eddy: Comment [2011-06-30]:
      I'm changing from DISCUSS to No Objection, because I think it's sufficient to address any possible concerns with the throughput metrics via the draft-mpls-loss-delay document that this one refers to.
    2. Stephen Farrell: Comment [2011-06-28]:
      I dunno what security mechanisms are available for use in an MPLS-TP environment, but if there are some that are not available outside that environment, then it might be good to mention those here.
    3. Russ Housley: Comment [2011-06-30]:
      The Gen-ART Review by Wassim Haddad on 29-Jun-2011 suggested one editorial improvement:
      Page 1: Abstract: remove _the_ efficient and accurate measurement
    4. Dan Romascanu: Discuss [2011-06-28]:
      1. I am a little puzzled by this Internet-Draft. Let me copy section 2:
      "2. MPLS-TP Measurement Considerations... "
      First, the version [I-D.ietf-mpls-loss-delay] is two versions back the latest one which is also on the agenda of the IESG telechat. The ECM considerations now belong to Section 2.9.3, and the direct LM considerations belong to section 2.9.8.
      My principal question is however - are these the only two considerations that can be ignored from [I-D.ietf-mpls-loss-delay] and everything else applies? If this is the case I would suggest to include clear text that says it.
      2. The measurement profiles defined in sections 3 and 4 define a restricted set of parameters and modes that need to be configured in a specific manner. Are these the only parameters that need to be configured in a different manner for MPLS-TP and all the rest of the parameters and modes defined in [I-D.ietf-mpls-loss-delay] can be configured in any way the operator choses to? If this is the case I would suggest to include clear text that says it.
      3. As with [I-D.ietf-mpls-loss-delay] I have reservations about the lack of manageability considerations. The only paragraph that deals with manageability is:
      "The assumption of this profile is that the devices involved in a measurement operation are configured for measurement by a means external to the measurement protocols themselves, for example via a Network Management System (NMS) or separate configuration protocol."
      This is too little. It tells nothing about any data model to be used (MIB or YANG module), or about how the results of the measurement are being retrieved from the routers/switches. Moreover, as such a protocol is not mentioned in [I-D .ietf-mpls-loss-delay] the security considerations section need to talk about the need for aunthenticated and privacy protected communications between the NMS and the routers/switches.
    5. Dan Romascanu: Comment [2011-06-28]:
      Please expand LM at first occurence.
    6. Sean Turner: Discuss [2011-06-29]:
      This ought to be easy enough to answer and is tied up in a discuss on draft-ietf-mpls-loss-delay:
      It wasn't clear to me in draft-ietf-mpls-loss-delay that all of the "mandatory" TLV objects MUST be supported and if any of the "optional" TLV object should also be supported. If they are, then this can go away. If not, shouldn't this draft say which TLV objects are required?

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1235 EDT break

1241 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Home Networks (homenet)
    Token: Jari

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Protocol Independent Multicast (pim)
    Token: Adrian

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. executive session (at end of meeting)

7. Agenda Working Group News

Reminder from Secretariat

1300 EDT Move to executive session


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-06-30 07:30:08 PDT)

draft-ietf-pim-mtid

  1. Adrian Farrel: Comment [2011-06-29]:
    We should pick up the comments raised by Thomas Clasuen in his Routing
    Directorate review
  2. Stephen Farrell: Comment [2011-06-26]:
    (1) end of 4.2.2, s/choose not/chooses not/
    
    (2) 4.2.4.1 s/all together/altogether/
    
  3. David Harrington: Comment [2011-06-28]:
    1) some "may" usage is in lower case and should probably be capitalized for
    clarity.
  4. Russ Housley: Comment [2011-06-30]:
      Please add introductory text prior to the bullets in sections 3.1,
      4.2.4.1, and 4.2.4.2.
  5. Pete Resnick: Comment [2011-06-26]:
    Acronyms should probably be expanded out and defined in the Abstract and the
    Intro.
  6. Robert Sparks: Comment [2011-06-29]:
    Can you clarify the first paragraph of  4.2.3? It's not yet obvious why you felt
    a need to call out the Robustness Principle here specifically. Are you trying to
    note that you have some backwards compatibility with existing systems, provide
    guidance to implementers of the extension to be careful to achieve that
    compatibility, both, or something completely different?
  7. Sean Turner: Discuss [2011-06-29]:
        This is updated.
    
    #1) resolved
    
    #2) Section 5.2, needs to include something to say how the reserved bits are set
    and how they're treated.  Maybe something like what's in RFC 4601:
    
       Reserved
            Set to zero on transmission.  Ignored upon receipt.
     
        
  8. Sean Turner: Comment [2011-06-27]:
    #1) Section 3.2 contains the following:
    
         - This value must be unique and consistent within the network
           domain for the same topology.  
    
    r/must/MUST?

draft-ietf-payload-rfc3016bis

  1. Adrian Farrel: Discuss [2011-06-30]:
        The only mention of RFC 3640 is in the Abstract, where you seem to
    state that, in new implementations, *this* I-D is NOT RECOMMENDED.
    
    That really isn't very good, is it? If you are going to have the
    specific sentence in the Abstract (and I presume it is there for a
    good reason) you siply must:
    - include this point in the Introduction
    - take the time somewhere in the document to explain the limitations
      of this approach (possibly by reference) and make a clear statement
      about the purpose of this document and when it should or should not
      be used. 
        
  2. Adrian Farrel: Comment [2011-06-30]:
    Can you please remove the citation ([RFC3640]) from the Abstract.
    
    ---
    
    For what it is worth, the ballot text says this document updates 3016.
    Obviously "update" is an overloaded term wrt RFCs, and "adds to" might
    be safer.
  3. Stephen Farrell: Discuss [2011-06-27]:
        Security considerations says "Therefore, a single mechanism is
    not sufficient, although if suitable, the usage of the Secure
    Real-time Transport Protocol (SRTP) [RFC3711] is recommended." 
    
    I think that's just too vague - are you calling for SRTP to be
    implemented or used? And what does "if suitable" mean? How's
    that going to result in interop when crypto is needed?
    
    If you said "Implementations SHOULD support SRTP." and then gave
    examples of cases where you don't really want SRTP, and you do want
    IPsec or TLS or nothing at all, then that would clear this up for me.
    
    I believe this text has been used elsewhere as well (e.g. rfc 5993)
    so this may be more a question for the chairs/WG, than the authors 
    of this document.
    
    There may also be other ways to clarify this as well of course. In
    particular, this issue is related to draft-ietf-avt-srtp-not-mandatory
    which has been sitting for a year.  
        
  4. Stephen Farrell: Comment [2011-06-26]:
    (1) VOP is used (2nd para p5) without expansion
    
    (2) p14, s/PayloadMux elements are contained/PayloadMux element is contained/
    
    (3) p14, suggest rephrasing this: "is preceding the one or	more
    PayloadMux elements."
    
    (4) 7.3, s/server must following/server must follow/
    
    (5) 7.4, s/Followings are some examples/The following are some
    examples/
    
    (6) section 11 title s/to/from/
  5. Russ Housley: Comment [2011-06-27]:
      Please consider the editorial comments from the Gen-ART Review by
      Suresh Krishnan on 26-Jun-2011.
  6. Dan Romascanu: Comment [2011-06-29]:
    Section 1.3 says: 
    
    >   Strictly speaking systems that support MPEG-4 Audio as specified in
       [RFC3016] are incompatible with systems supporting this document.
       However, all known existing systems do already comply with the
       specification in 3GPP PSS service [3GPP] and therefore there is no
       need to consider backward compatibility.
    
    I do not know what this 'strictly speaking' language exactly means. Also the
    'all known' adjective is not a guarantee for the conclusion 'there is no need to
    consider backward compatibility' to be always true. The text here is probably
    sufficient, but I would prefer a more exact wording that says something like
    'this specification is not bakwords compatible with RFC 3016, existing
    implementations of RFC 3016 MUST be updated to be compatible with this
    specification'
  7. Peter Saint-Andre: Discuss [2011-06-29]:
        Why is RFC 3016 a normative reference if it is being obsoleted by this spec? 
        
  8. Peter Saint-Andre: Comment [2011-06-29]:
    Please expand "SIP" on first use and provide an informative reference to RFC
    3261. References to H.261, H.323, and H.245 would also be helpful.
  9. Robert Sparks: Comment [2011-06-23]:
    Please clarify that the binary incompatibility the draft is addressing is due to
    the change in the encodings defined in 14496-3:2009 vs 14496-3:1999
  10. Sean Turner: Discuss [2011-06-28]:
        These ought to be easy enough to answer/clear:
    
    #1) Section 1.3 says that there's no backwards compatibility with RFC 3016.
    Should 3016 be made Historic?
    
    #2) Section 1.3 reads as if the 3GPP specification is the specification everyone
    wants to be compatible with.  Is that specification considered the definitive
    source?  That is, if there's a change made to the 3GPP specification would it
    get reflected in this draft? 
        

draft-ietf-appsawg-rfc3536bis

  1. Ron Bonica: Discuss [2011-06-28]:
        1) The definitions in this document are not normative, but the document is a
    BCP. Isn't that a contradiction?
    
    2) You say that a writing system is a set of rules for using a script to express
    a language. A better example of this might be helpful. You use the example of
    the American and British writing systems, but I have no idea what those are.
    
    3) You use the term "character set" to describe the terms "coded character set"
    and "repertoire". But you never define this term. In fact, in the definition of
    charset you say, "Many protocol definitions use the term "character set" in
    their descriptions.  The terms "charset" or "character encoding scheme and
    "coded character set" are strongly preferred over the term "character set"
    because "character set" has other definitions in other contexts and this can be
    confusing.
    
    4) The definition of "Glyph" leaves me thoroughly confused. The problem is that
    glyphs are described in terms of "glyph images". If I don't understand what a
    glyph is, how am I supposed to understand what a glyph image is?
    
    5) Your definition of Glyph code does more to explain what a glyph is than your
    definition of glyph. It makes sense that glyphs might have something to do withn
    fonts, because the Greek word "glyphe" means "carving".
    
        
  2. Ralph Droms: Discuss [2011-06-29]:
        Ron picked up chains of definitions that I also found
    confusing.   I had one other specific question and a more abstract
    question:
    
    1. I'm not clear about the relationship among the terms "character
    encoding form," "coded character set" and "character encoding scheme."
    I consulted RFC 2978 for help (would it be appropriate to cite RFC
    2978 with the definitions of CCS and CES?), and it seems CCS/CES gives
    everything needed to go from characters to an octet sequence.  Where
    does the "character encoding form" fit in?
    
    2. I learned from RFC 2978 that a charset is a mapping from an octet
    sequence to a character sequence, but the charset may not be a
    complete mapping in the other direction.  Based on this little
    insight, I wonder about all of the other mappings in the document: are
    any of the other mappings only useful in one direction?  Would it be
    useful to note the directionality of other mappings?
     
        
  3. Adrian Farrel: Comment [2011-06-30]:
    In Section 7.1 the definition ends with "<Stringprep>" but there is no
    such reference.
    
    ---
    
    While I found the indications of source references useful, I did not
    find that angle brackets were the best indicators as they are also 
    used for two other (distinct) purposes in the document.
    
    ---
    
    Replacing <NONE> with <THIS> might send a more positive message.
  4. Stephen Farrell: Comment [2011-06-27]:
    (1) s/provides identifiers/provide identifiers/ in definition
    of language (standards is plural)
    
    (2) s/for global from the/for global use from the/ on p8
    
    (3) Is anchor9 in 3.2 supposed to remain or not? I would
    have thought the time for comments on that was past?
    
  5. Russ Housley: Discuss [2011-06-29]:
        
      I think this document should be published as an Informational RFC.
      It seems to play a very similar role to RFC 2828, which is an
      Informational RFC.  Also, this document obsoletes RFC 3536, which
      is an Informational RFC. 
        
  6. Dan Romascanu: Discuss [2011-06-29]:
        Updated DISCUSS taking into account changes from 02 to 03: 
    
    1. One of the major changes from 3536 is that the future RFC aims to be a BCP,
    while 3536 was Informational. I expected to find a discussion on this respect
    including some rationale of the change and including some language that
    recommends using the terminology defined in this document. However section 1.1.
    'Purpose of this Document' keeps using a language that is more appropriate to an
    Informational document, like: 'This document attempts to define terms in a way
    that will be most useful to the IETF audience.'
    
    2. The defition of 'glyph' seems circular to me: 
    
          > A glyph is an abstract form that represents one or more glyph
          images.  The term "glyph" is often a synonym for glyph image,
          which is the actual, concrete image of a glyph representation
    
    3. Section 6 - is not the SnmpAdminString TC defined in RFC 3411 an example of
    usage of an ASCII-compatible encoding (ACE) that has reached standard status? 
        
  7. Dan Romascanu: Comment [2011-06-29]:
    1. section 3.1 - why is W3C called 'This group' rather than 'This organization'
    or 'This consortium'?
    
    2. Appendix C should mention the change from Informational to BCP. I believe it
    is significant.
  8. Robert Sparks: Comment [2011-06-29]:
    I don't agree that this document needs BCP status as currently formulated. We
    can find a way to address the downref inconvenience if that's a primary
    motivation. I don't find a basis in 2026 for "This is informational but we
    REALLY mean it".
    If there are requirements being placed on future IETF work
    (even if those requirements apply only to a particular set of groups), I can see
    an argument for BCP in the 2026 definitions.
    
    That said, if this is published as a BCP, I don't believe it does any harm to
    the work it is attempting to influence, and very little additional harm to how
    the world (especially outside the IETF) interprets RFCs with this designation
    (beyond continued erosion of the perception of BCPs as "special"), so I am
    balloting no objection while stating a preference that the choice be
    reconsidered.
  9. Sean Turner: Comment [2011-06-28]:
    What no proto write-up ;)
    
    I'm curious to see how Dan's 1st discuss point shakes out.  If it's really going
    to be a BCP, then the following should be changed:
    
       The
       definitions in this document are not normative for IETF standards;
       however, they are useful and standards may make informative reference
       to this document after it becomes an RFC.
    
    If it's a BCP then, as Barry noted in his response to Dan, everybody could
    normatively reference this document.  I'm not really sure I buy the rationale of
    wanting to make this a BCP because everybody wants to normatively reference it
    (because DOWNREFs are easy), but if that is the case, then we ought to say so.
    
    Is there somebody outside the IETF that can't reference an informational RFC
    that wants to refer to this draft?

draft-ietf-mpls-loss-delay

  1. Ron Bonica: Comment [2011-06-28]:
    Please add text to section 2.9.10 stating that in the following conditions,
    delay measurement will be useless:
    
    - when the two router clocks differ by a significant portion of the round trip
    time
    - when probe processing contributes significantly to round trip time
  2. Wesley Eddy: Discuss [2011-06-30]:
        The computation of the throughput metric is only very loosely specified here.
    Since the counters exchanged can represent either a number of packets or a
    number of bytes, then the throughput can either be computed in packets/time or
    bytes/time depending on what units are used. 
        
  3. Adrian Farrel: Discuss [2011-06-23]:
        This is an administrative Discuss - I intend to move to move to a YES ballot.
    
    This document is in an administrative second IETF last call because of a late
    IPR disclosure. The IESG will hold its evaluation before this second last call
    completes. I will hold this Discuss until last call completes in case any issues
    are raised from the community. 
        
  4. Stephen Farrell: Discuss [2011-06-25]:
        
    This is just a discuss to check if the chat arising from Steve
    Kent's secdir review [1] reached closure. The discussion seemed 
    to tail off a bit and I'm not clear if it was done or not.
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02727.html 
        
  5. Stephen Farrell: Comment [2011-06-25]:
    (1) Section 2 as a whole is very wordy. While its fine to spell things
    out for clarity, this text perhaps demands too little from the reader,
    at the expense of clarity for the capable reader. (In other words, this
    seems just too long:-) Feel free to entirely ignore this comment
    though.
    
    (2) The "(B1,...,Bk)" notation isn't clear in 2.6 - are we measuring
    (A,B1) and (A,B2) etc. or are we measuring what happens on the path from
    A to Bk via B1,B2...etc.? Since the section is about unidirectional LSPs
    it may be easier to just deal with A and B here.
    
    (3) (2.9.3) Saying that the detailed measurement behavaiour "MUST be
    made clear to the user" seems wrong in two respects - a) a programmer
    won't know what'll be clear to all future users of their code, and b)
    there may be no (human) user that can see the direct mesurements, (the
    humans might only see derived statistics I guess). I also don't quite
    know how I'd test for that MUST. Maybe just loose the 2119 language
    there?
    
    (4) 2.9.5 assumes that intermediate nodes can reply to LM/DM messages,
    but that hasn't yet been stated.
    
    (5) Two timestamp formats are supported - would be good to include
    examples of each at the point where that's first mentioned in detail.
    
  6. Dan Romascanu: Discuss [2011-06-28]:
        This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise. 
    
    1. The document defines new protocols without making any reference to the IPPM
    OWAMP (RFC 4546) and TWAMP (RFC 5357) despite the bidirectional measurment
    described in section 2.1 being very similar to the latest, for example, If there
    are good reasons for which OWAMP and TWAMP are not suited in the MPLS
    environment I suggest that these need to be clearly explained.
    
    2. The applicability statement in section 1.1 risks to create confusion with the
    IPPM work. I would rather drop it.
    
       Although the procedures in this document are presented in the context
       of MPLS, they have no essential dependence on MPLS and generalize
       easily to other types of packet networks.  Such generalizations are,
       however, outside the scope of this document.
    
    3. In Section 2.2: 
    
       The foregoing discussion has assumed the counted objects are packets,
       but this need not be the case.  In particular, octets may be counted
       instead.  This will, of course, reduce the MaxLMInterval
       proportionately.
    
    Proportionately to what? Probably with the ratio between 1 and the number of
    octets in the minimal packet size on the respective media. Either be exact, or
    use some other more suitable term (accordingly?).
    
    4. What is the reason for not using the packet loss metrics definition from RFC
    2680? (while the delay metrics are referenced from 2679 and 2681 repectively).
    If that definition is not suitable I suggest that this is discussed if not
    please add the reference.
    
    5. I support Wesley's DISCUSS concerning the throuput metrics and discussion and
    I generally feel very unconfortable with the way it is dealt with in this
    document. Do we need reference to througput at all? after all the scope of the
    document focuses on loss and delay. If we do I would also suggest a serious
    rewrite starting from a proper definition of the metics or reference to existing
    definitions in other RFCs if appropriate.
    
    6. The PDV definition in section 2.5 is rather vague. I suggest to refer to
    section 4 in RFC 5481 which makes a clear distinction between PDV and IPDV.
    
    7. The document lacks proper manageability considerations: 
    
      section 2.9.7 
       This can be achieved in supporting
       implementations by, for example, configuring the querier, in the case
       of a bidirectional measurement session, to forward each response it
       receives to the post-processor via any convenient protocol.
    
       Post-processing devices may have the ability to store measurement
       data for an extended period and to generate a variety of useful
       statistics from them.
    
     section 4.1
       Measurement sessions are initiated at the discretion of the network
       operator and are terminated either at the operator's request or as
       the result of an error condition. 
    
    There is no mention about how to remotely configure this protocol (example: MIB
    or YANG module), how to retrieve the results, what are the storage requirements
    for the results and methods and periodicity of retreival of the results. There
    is no mention about the security implications of activating two new protocols
    that generate traffic in the network and what are the admissible levels of
    traffic that can be generated. 
        
  7. Sean Turner: Discuss [2011-06-30]:
        This is an updated discuss based on an exchange with an author.
    
    #1) Which of the 5 formats defined in Section 3.1 MUST be supported for an
    implementation to be considered compliant to this document?
    
    #2) Section 3.4 contains the following:
    
     The Type space is divided into Mandatory and Optional subspaces:
    
       Type Range     Semantics
       -------------- ---------
       0-127          Mandatory
       128-255        Optional
    
      Upon receipt of a query message including an unrecognized mandatory
       TLV object, the recipient MUST respond with an Unsupported Mandatory
       TLV Object error code.
    
    and Section 8.4 contains the following:
    
       IANA is also requested to indicate that Types 0-127 are classified as
       Mandatory, and that Types 128-255 are classified as Optional.
    
    Wouldn't it be more 2119-like if you used REQUIRED and OPTIONAL?  Isn't this
    kind of saying that the elements in the 0-127 range MUST be supported?
    
    Also later in 3.4 it includes:
    
    127            Experimental use
    
    You're requiring implementations to support the experimental TLV?  I would think
    that would be OPTIONAL.
    
    #3) Which of the four TLV objects in Section 3.5 MUST be supported for an
    implementation to be considered compliant to this document?  It says zero or
    more may be present but not which ones MUST be supported.  Are any of them a
    MUST?
    
    #4) cleared 
        
  8. Sean Turner: Comment [2011-06-28]:
    #1) Section 3.1 and 3.2 contains the following:
    
       TLV Block             Optional block of Type-Length-Value fields
    
    Should Optional be OPTIONAL to indicate support requirement?
    
    #2) Section 4.2.2 contains the following:
    
       When transmitting an LM Query over a channel, the Version field MUST
       be set to 0.
    
    Shouldn't "over a channel" be removed?  Isn't version always set to 0?
    
    #3) Section 4.2.2 contains the following:
    
       The Origin Timestamp field SHOULD be set to the time at which this
       message is transmitted, 
    
    hmmm so what other time would be put there?  The definition from earlier
    sections is:
    
       Origin Timestamp: Timestamp recording the transmit time of the query
       message.
    
    #4) Section 4.3.1 contains the following:
    
       When transmitting a DM Query over a channel,
    
    Shouldn't "over a channel" be removed?  Isn't version always set to 0?

draft-ietf-dkim-rfc4871bis

  1. Adrian Farrel: Comment [2011-06-29]:
    I note that in Section 1.2 of RFC 4871 (May 2007) it says "there are currently
    over 70 million domains." So while Section 1.3 of this I-D is not wrong to say
    "there are currently over 70 million domains," it may be a significant
    underestimate.
    
    I am not completely comfortable with the use of "normative" RFC 2119 language in
    ABNF comments. For example...
       dkim-safe-char        =  %x21-3A / %x3C / %x3E-
    7E
                                   ; '!' - ':', '<', '>' - '~'
    ; Characters not listed as "mail-safe" in
                                   ;
    [RFC2049] are also NOT RECOMMENDED.
    
    A terrible nit, but would you consider s/may/might/ in...
       o  The practical constraint that large (e.g., 4096 bit) keys may not
          fit within a 512-byte DNS UDP response packet
    
  2. Stephen Farrell: Comment [2011-06-24]:
    Good job.
    
    Other, than (6) & (8) below, which I'd ask that you check, I'm 
    entirely fine if you totally ignore these - they're just the notes I 
    made as I read the thing again (after not having had to do that 
    for a while:-) and are basically all nitty suggestions.
    
    (1) 2nd para of 2.6 refers to "i=" and "t=s" before those have
    been introduced. I wouldn't suggest defining them here, so I'm
    not sure what to change to make it better but maybe worth a look.
    Maybe you could get rid of the tags though for example by saying: 
    
      "Note that acceptable values for the AUID may be constrained via
       a flag in public key record. (See Section 3.6.1)"
    
    (2) end of p20, maybe s/are expected to/may/ since we're doing a
    new spec now but not changing the version number.
    
    (3) 2nd last para, p23: signing non-existent header fields does
    not "prevent" later insertion, it allows detection of that after
    the fact. Same issue with last para on p23 as well. The change is
    obvious I guess if you want to make it. 
    
    (4) p26, is "DNS TXT record" or "DNS TXT resource record" more
    correct? (And if so, do we care or not:-) If the latter then the
    same change would be needed in a few places.
    
    (5) Would it be useful for the reader and/or IANA to note that
    there are no new tags defined in section 7 compared to rfc4871?
    
    (6) Is 7.9 actually correct? That IANA registry references 4871 
    but should that be changed to this document or left alone? I've
    no idea.
    
    (7) Could/should appendix B.2.3 have an informative reference to
    dkim-mailinglists? Since that's now approved, it won't add any
    significant time for the RFC editor to do those together.  (I
    think.)
    
    (8) The last paragraph of appendix C is odd - maybe the reference
    in there should be to rfc4870?
    
  3. Russ Housley: Comment [2011-06-29]:
      Appendix E should probably include a pointer to the errata.
      Some documents have included a URL for this purpose.
  4. Pete Resnick: Discuss [2011-06-29]:
        1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING"
    and section 8.1):
    
          INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
          an attack in which an attacker modifies a message to include
          content that solely benefits the attacker.  It is possible for the
          appended content to completely replace the original content in the
          end recipient's eyes, such as via alterations to the MIME
          structure or exploiting lax HTML parsing in the MUA, and to defeat
          duplicate message detection algorithms.  To avoid this attack,
          signers should be wary of using this tag, and verifiers might wish
          to ignore the tag, perhaps based on other criteria.
    
    This is not an attack against DKIM. If the signer said, "I'm signing the first n
    bytes of the body of this message" and the verifier is able to verify that the
    signature is valid for n bytes of the body, the algorithm has succeeded. At
    most, this should lead to an admonition that unsigned data is not verified and
    therefore should not be trusted, but that seems obvious. There might be an
    attack on an MUA that does not verify the DKIM signature, but that is outside
    the scope of this document. Either way, 3.4.5 and 3.5 should have forward
    references to 8.1. This is a security consideration, not anything "informative".
    
    2. Section 6.1.3:
    
       verifiers might treat a message that contains bytes beyond the
       indicated body length with suspicion, such as by declaring the
       signature invalid (e.g., by returning PERMFAIL (unsigned content)),
       or conveying the partial verification to the policy module.
    
    Up to the word "suspicion", fine. After that, it is complete nonsense. The
    signature is not invalid. If what you mean is "and may choose to treat the
    signature as if it were invalid (e.g., by going into the PERMFAIL state)", then
    say that. And again, this is trying to wrap APIs and implementations choices
    into the protocol.
    
    3. Section 8.2: I don't see how this is DKIM specific. More importantly, this
    section doesn't explain how user private keys relate in any way to keys used in
    DKIM. Shouldn't this be a discussion about security of private keys in general
    (not just ones on user machines)?
    
    4. Section 8.5: I don't understand what the attack here is that has anything to
    do with DKIM. I especially don't see why the accomplice is an essential part of
    the example, unless all that is meant by "accomplice" is "relay". The attack
    sounds like, "people can spam signed messages", which is not an attack on DKIM.
    
    5. Section 8.14: This is a complete mischaracterization of the problem. This is
    absolutely not an attack vector. If a signer wishes to prevent additional
    *known* header fields from being verified, it can simply use the technique
    outlined in 8.15. If the signer chooses not to do that, it is expressing the
    intent that it considers messages valid that have additional header fields
    added. *That's* the security consideration: Signers should know that failing to
    include, e.g., "h=...:from:from:..." on messages with one "From:" header field
    are leaving themselves open to this attack. The attack is not on the verifier.
    Additionally:
    
       Note that the technique for using "h=...:from:from:...", described in
       Section 8.15 below, is of no effect in the case of an attacker that
       is also the signer.
    
    That sentence is utter nonsense. The signer *can't* be the attacker for purposes
    of DKIM when it comes to the header fields it's willing to sign. The
    Introduction (section 1) makes it absolutely clear that DKIM is about
    transmitting information from a signer to a verifier.
    
    Section 8.14 needs to be completely rewritten. It is nonsensical as it stands.
    
    6. Section 8.15:
    
       Implementers need to consider this possibility when designing their
       input handling functions.  Outright rejection of messages that
       violate the relevant standards such as [RFC5322], [RFC2045], etc.
       will interfere with delivery of legacy formats.  Instead, given such
       input, a signing module could return an error rather than generate a
       signature; a verifying module might return a syntax error code or
       arrange not to return a positive result even if the signature
       technically validates.
    
    DKIM can perfectly well deal with the obsolete syntax. The signer can sign as
    many "From:" fields as the message has when signed, and add a ":from" to the
    "h=" tag to insure that the right number of them are verified. As in 8.14, the
    attack is not on DKIM per se; it's on signers that don't properly use the "h="
    tag to sign those header fields that they don't want added to.
    
    Other malformed input might cause problems for a DKIM implementation, but
    multiple header fields where 5322 3.6 only allows one is not that sort of
    attack. 
        
  5. Pete Resnick: Comment [2011-06-29]:
    These first 15 comments are things that I think are potentially real problems,
    but I haven't heard enough back from the authors yet to know if they are worthy
    of a DISCUSSion.
    
    1. Section 2.7: I don't understand what the word "module" means in this context.
    It sounds like some sort of specific implementation, not part of a protocol. I
    don't know what it means to deliver values to a module.
    
    2. Section 3.5:
    
       v= Version (MUST be included).  This tag defines the version of this
          specification that applies to the signature record.  It MUST have
          the value "1".  Note that verifiers must do a string comparison on
          this value; for example, "1" is not the same as "1.0".
    
    What is the intention of "string comparison" here? There's no case sensitivity
    to worry about. There's no character encoding to worry about. Why not instead
    say, "Note that verifiers must (MUST?) ensure that the value is '1'; for exmaple
    '1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) What is this trying
    to convey.
    
    Also, the value is not listed as "plain-text".
    
    3. Section 3.5, "h=":
    
             INFORMATIVE EXPLANATION: By "signing" header fields that do not
             actually exist, a signer can allow a verifier to detect
             insertion of those header fields after signing.  However, since
             a signer cannot possibly know what header fields might be
             created in the future, and that some MUAs might present header
             fields that are embedded inside a message (e.g., as a message/
             rfc822 content type), the security of this solution is not
             total.
    
    a. I don't understand what MUAs presenting "header fields that are embedded
    inside a message" has to do with anything.
    
    b. I don't know what the words, "the security of this solution is not total" are
    supposed to mean.
    
    Don't you simply mean: "However, since a signer cannot possibly know what header
    fields might be defined in the future, this mechanism can't be used to prevent
    the addition of any possible unknown header fields."?
    
    4. Section 3.5, "h=":
    
             INFORMATIVE EXPLANATION: The exclusion of the header field name
             and colon as well as the header field value for non-existent
             header fields allows detection of an attacker that inserts an
             actual header field with a null value.
    
    I cannot parse that sentence. I have no idea what it means.
    
    5. Section 3.7: "content-hash" is not defined.
    
    6. Section 3.9:
    
    a. Neither TEMPFAIL nor PERMAFAIL is defined at this point.
    
    b. I have no idea what the "output of a DKIM verifier module" is supposed to
    mean.
    
    I suspect that section 3.9 is at least misplaced in this document, and probably
    completely unnecessary as it sounds like implementation details.
    
    7. Section 4.2, first INFORMATIVE NOTE: Why is this an informative note? It
    seems like good protocol adivce and therefore should say that signers SHOULD NOT
    sign exiting DKIM-Signauture fields.
    
    8. Section 4.2, last paragraph: PERMFAIL is still not defined to this point.
    
    I suspect sections 3.8 through all of section 4 belong after (or in) section 6.
    
    9. Section 5.1: I don't know what the term "signing address" means.
    
    10. Section 5.3:
    
       Therefore, a verifier
       SHOULD NOT validate a message that is not compliant with those
       specifications.
    
    This section is about signing, not verifying. What is that sentence doing in
    there?
    
    11. Section 5.4:
    
          INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits
          header fields to be reordered (with the exception of Received
          header fields)
    
    5322 does *not* permit header fields to be reordered. It says:
    
       ...header fields SHOULD NOT be reordered when a message is transported
       or transformed.  More importantly, the trace header fields and resent
       header fields MUST NOT be reordered, and SHOULD be kept in blocks
       prepended to the message.
    
    Suggest: "Despite the fact that [RFC5322] does not absolutely prohibit header
    fields to be reordered..."
    
    12. Section 6.1:
    
       A verifier SHOULD NOT treat a message that has one or more bad
       signatures and no good signatures differently from a message with no
       signature at all; such treatment is a matter of local policy and is
       beyond the scope of this document.
    
    The two clauses in that sentence seem contradictory. Is there an
    interoperability requirement that I not treat messages in a particular way, or
    is it a matter of local policy?
    
    13. Section 6.1 (and subsections): This section is playing some sort of game.
    The beginning of 6.1 describes some "statuses" and says things like, "The
    '(explanation)' is not normative text; it is provided solely for clarification."
    If it wanted to give an algorithm for Verfiers to follow, where there was a
    certain state machine with states of "PERMFAIL" and "TEMPFAIL", that would have
    been OK. But it is clear from the use of the phrasing, for example, "return
    PERMFAIL (signature syntax error)", the document is trying to sneak in some sort
    of actual APIs into the protocol spec. I think this is bogus and would much
    prefer that these sections be rewritten to say, "enters a PERMFAIL state",
    perhaps labeling each paragraph with the explanation. For example, the first
    paragraph of 6.1.1 could read:
    
       Signature syntax
       
       Implementers MUST meticulously validate the format and values in the
       DKIM-Signature header field; any inconsistency or unexpected values
       MUST cause the header field to be completely ignored and the verifier
       enters a PERMFAIL state.  Being "liberal in what you accept" is
       definitely a bad strategy in this security context.  Note however that
       this does not include the existence of unknown tags in a DKIM-Signature
       header field, which are explicitly permitted.
       
       Version compatibility
       
       Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature
       header field with a "v=" tag that is inconsistent with this
       specification.
    
    The current text is too cute by half, and I think it obfuscates the meaning.
    
    14. Section 6.1, first "INFORMATIVE NOTE" on attack by many bad sigs: This is a
    security consideration instead, not an informative note. Should be a forward
    reference to section 8.3
    
    15. Section 6.1.3: I don't understand the meaning of the note, "(note that this
    version does not actually need to be instantiated)".
    
    These last 10 comments are simply stylistic and editorial stuff. If they make
    sense to fix, great. If not, I'm not concerned.
    
    1. I find the use of the word "INFORMATIVE" throughout the document superfluous.
    No other word (e.g., NORMATIVE) is used in its place. I think they should all be
    removed. They serve no purpose.
    
    2. The ABNF "0*" construct is not normally used. Just "*" is sufficient.
    
    3. Section 3.4.4:
    
          INFORMATIVE NOTE: It should be noted that the relaxed body
          canonicalization algorithm may enable certain types of extremely
          crude "ASCII Art" attacks where a message may be conveyed by
          adjusting the spacing between words.  If this is a concern, the
          "simple" body canonicalization algorithm should be used instead.
    
    I think this MITM attack (the ability to insert and delete whitespace to send
    coded ASCII Art messages to the recipient) is so far fetched as to not be worthy
    of mention. If the WG really thinks it is worthy of mention, it should go in
    security considerations.
    
    4. Section 3.5: It would be nice to subsection each tag here. (e.g., "v=" could
    be 3.5.1, etc.)
    
    5. Section 3.5, "h=":
    
    It would be nice to add a sentence similar to the one in 5.4: "The field MAY
    contain multiple instances of a header field name; this means that multiple
    occurrences of the header field are being signed by the signing algorithm."
    
    6. Section 3.6.1: It would be nice to subsection each of the tags.
    
    7. Section 3.10: Is this not completely redundant with the text in 3.6.1
    regarding "t=s"?
    
    8. Section 4.1: The "INFORMATIVE EXAMPLES" don't need to be called out as such.
    The title of the section is "Example Scenarios". All of the text here is
    example, and as such it is all informative.
    
    9. Section 5.1, INFORMATIVE NOTE: Instead of saying "Signing modules may be
    incorporated into any", how about "A signer can be implemented as part of any"?
    
    10. Section 5.5: Though section 5.5 is titled "Recommended Signature Content",
    it is clear that the entire section is devoted to the topic of section 5.4:
    "Determine the Header Fields to Sign". These two sections should be combined,
    and might be subsections of a larger section. But it was very confusing to read
    these as separate.
  6. Peter Saint-Andre: Comment [2011-06-29]:
    1. It's good to see draft-ietf-dkim-implementation-report, which has 
    a thorough overview of the interoperability testing held in 2007.
    However, that I-D does not discuss interoperability regarding the 
    clarifications in RFC 5672. Are they covered here? Does the community 
    have enough experience with them to enable us to say that there are at
    least two interoperable implementations of RFC 5672?
    
    2. In Section 3.2, why not reference RFC 4648, perhaps with text about 
    line feeds (etc.), instead of Section 6.8 of RFC 2045?
    
    3. In Section 3.2, we might consider adding an informative reference to  
    RFC 3629 with regard to UTF-8.
    
    4. In Secton 3.6.2, we might consider adding a normative reference to  
    RFC 1464 with regard to DNS TXT RRs.
    
    5. In Section 6.1, we might consider adding an informative reference to
    RFC 4732 with regard to denial of service attacks. (Also Sections 8.3, 
    8.7, 8.12.)
    
    6. In Section 6.1.1, we might consider changing MAY to SHOULD. This
    seems like something we'd recommend, not describe as purely optional.
    
    7. In Section 7, "one has been obsoleted" makes it sound as if a new 
    tag has been defined to replace it (as in RFC 2026); we might consider
    changing it to "one has been designated as historic".

draft-ietf-soc-overload-design

  1. Adrian Farrel: Comment [2011-06-29]:
    In Section 1
    
       Overload can pose a serious problem for a network of SIP servers.
       During periods of overload, the throughput of a network of SIP
       servers can be significantly degraded.  In fact, overload may lead to
       a situation in which the throughput drops down to a small fraction of
       the original processing capacity.  This is often called congestion
       collapse.
    
    Reading (and re-reading) this paragraph, I could not extract from the 
    text whether the concern is the network throughput of SIP messages, or
    the impact on the data flows that are controlled by the SIP messages. 
    It seems to me that you need to make this clear up front, and that you
    should spend some time distinguishing the impact of SIP overload on
    existing data flows from the case you are describing.
    
    It may be that this is obvious to the informed reader, but it should be
    easy for you to explain, and that will make life easier for future
    readers.
  2. Stephen Farrell: Comment [2011-06-28]:
    Nice document, with good security considerations. 
    Thanks.
    
    One possible additional security consideration - if an
    attacker can convince senders that various other nodes 
    are overloaded, then it could cause traffic to be 
    directed towards attacker-chosen servers. That could 
    either be part of a DoS on the attacker-chosen servers,
    or, if the attacker-chosen servers are operated by or 
    for the attacker, then the attacker could monitor 
    possibly many more calls than otherwise. 
    
  3. Pete Resnick: Comment [2011-06-29]:
    This is a nice piece of architectural work. How did this end up in a WG instead
    of the IRTF? :-)
    
    One mostly editorial comment. From the Introduction:
    
       Overload can pose a serious problem for a network of SIP servers.
       During periods of overload, the throughput of a network of SIP
       servers can be significantly degraded.  In fact, overload may lead to
       a situation in which the throughput drops down to a small fraction of
       the original processing capacity.  This is often called congestion
       collapse.
    
    That's not congestion collapse. The first paragraph of section 2 talks about
    what *is* congestion collapse: congestion-related retransmissions themselves
    increasing congestion. Something's missing from the above paragraph.
  4. Dan Romascanu: Discuss [2011-06-29]:
        This is a very well written document. Before I turn my ballot into a YES I would
    like to DISCUSS one aspect of the SIP overload control which is related to
    manageability and specifically to observability. As I understand from the
    document and from the WG charter several methods of SIP overload control will be
    proposed and more than one may be supported by a SIP server. How can a network
    operator know what is supported on each device in the network? Also, for
    existing deployments, are there any mechanisms (alerts or status indication)
    that show whether one of the specific mechanism was triggered and activated? I
    believe that the design document needs to add some text refering to these
    operational aspects. 
        
  5. Peter Saint-Andre: Comment [2011-06-28]:
    This is a fine document. Please expand acronyms on first use (e.g., "UA", "UAC",
    "UAS", "RPH"). A reference to RFC 4732 ("Internet Denial-of-Service
    Considerations") might be appropriate.
  6. Robert Sparks: Comment [2011-06-23]:
    Please take these editorial suggestions into account:
    
    1) At "Introducing many such short-lived sybils" - I suggest s/sybils/servers.
    If you want to compare this to a sybil attack, an additional sentence
    would be
    better.
    
    2) I suggest s/affecting a reduce in the service/affecting a reduction in the
    service/
    
    3) At "keep the receiver window fill", I suggest s/fill/full/

draft-ietf-mpls-tp-loss-delay-profile

  1. Wesley Eddy: Comment [2011-06-30]:
    I'm changing from DISCUSS to No Objection, because I think it's sufficient to
    address any possible concerns with the throughput metrics via the draft-mpls-
    loss-delay document that this one refers to.
  2. Stephen Farrell: Comment [2011-06-28]:
    I dunno what security mechanisms are available 
    for use in an MPLS-TP environment, but if there
    are some that are not available outside that 
    environment, then it might be good to mention 
    those here.
    
  3. Russ Housley: Comment [2011-06-30]:
      The Gen-ART Review by Wassim Haddad on 29-Jun-2011 suggested one
      editorial improvement:
    
      Page 1: Abstract: remove _the_ efficient and accurate measurement
  4. Dan Romascanu: Discuss [2011-06-28]:
        1. I am a little puzzled by this Internet-Draft. Let me copy section 2: 
    
    > 2.  MPLS-TP Measurement Considerations
    
    >   Several of the considerations discussed in [I-D.ietf-mpls-loss-delay]
    >   can be disregarded in the more restrictive context of MPLS-TP:
    
    >   o  Equal Cost Multipath considerations (Section 2.7.3 of
    >      [I-D.ietf-mpls-loss-delay])
    
    >   o  Considerations for direct LM in the presence of Label Switched
    >      Paths constructed via the Label Distribution Protocol (LDP) or
    >      utilizing Penultimate Hop Popping (Section 2.7.6 of
    >      [I-D.ietf-mpls-loss-delay])
    
    First, the version  [I-D.ietf-mpls-loss-delay] is two versions back the latest
    one which is also on the agenda of the IESG telechat. The ECM considerations now
    belong to Section 2.9.3, and the direct LM considerations belong to section
    2.9.8.
    
    My principal question is however - are these the only two considerations that
    can be ignored from  [I-D.ietf-mpls-loss-delay] and everything else applies? If
    this is the case I would suggest to include clear text that says it.
    
    2. The measurement profiles defined in sections 3 and 4 define a restricted set
    of parameters and modes that need to be configured in a specific manner. Are
    these the only parameters that need to be configured in a different manner for
    MPLS-TP and all the rest of the parameters and modes defined in  [I-D.ietf-mpls-
    loss-delay] can be configured in any way the operator choses to? If this is the
    case I would suggest to include clear text that says it.
    
    3. As with  [I-D.ietf-mpls-loss-delay] I have reservations about the lack of
    manageability considerations. The only paragraph that deals with manageability
    is:
    
    > The assumption of this profile is that the devices involved in a
       measurement operation are configured for measurement by a means
       external to the measurement protocols themselves, for example via a
       Network Management System (NMS) or separate configuration protocol.
    
    This is too little. It tells nothing about any data model to be used (MIB or
    YANG module), or about how the results of the measurement are being retrieved
    from the routers/switches. Moreover, as such a protocol is not mentioned in [I-D
        
  5. .ietf-mpls-loss-delay] the security considerations section need to talk about the need for aunthenticated and privacy protected communications between the NMS and the routers/switches.
  6. Dan Romascanu: Comment [2011-06-28]:
    Please expand LM at first occurence. 
  7. Sean Turner: Discuss [2011-06-29]:
        This ought to be easy enough to answer and is tied up in a discuss on draft-
    ietf-mpls-loss-delay:
    
    It wasn't clear to me in draft-ietf-mpls-loss-delay that all of the "mandatory"
    TLV objects MUST be supported and if any of the "optional" TLV object should
    also be supported.  If they are, then this can go away.  If not, shouldn't this
    draft say which TLV objects are required?