IESG Narrative Minutes

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

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

Corrections from: Pete, David

1 Administrivia

  1. Roll Call 1134 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. Conference Information Data Model for Centralized Conferencing (XCON) (Proposed Standard)
    draft-ietf-xcon-common-data-model-27
    Token: Robert Sparks
    Note: Alan Johnston (alan.b.johnston@gmail.com) is the Document Shepherd
    Discusses/comments (from ballot 3140):
    1. Jari Arkko: Comment [2011-05-24]:
      This was an overall OK document. I did have a few small question marks, however:
      I am wondering if <language> can contain multiple languages or appear multiple times. The text says nothing exact but seems to indicate just one language. Some of the schema definitions seems to say that multiple languages can appear. Please clarify and align.
      Then I had a question on this: "In order to facilitate the comparison of the XCON-USERID identifiers, all the components of the identifiers MUST be converted to lowercase. After normalizing the URI strings, the URIs comparison MUST applied a character-by-character basis as prescribed by RFC3986, Section 6.2.1."
      Question: is this sufficient to deal with internationalized user identifiers? I'm about as far as one can be from an i18n expert, but I thought there were situations were you'd have to map characters to other characters in order to do proper comparisons. Maybe that's not needed for user identifiers. Please check.
      Can notifications come after the end of the conference, too? The data type is integer, not NonNegativeInteger:... Please clarify and ensure you meant all integers.
      Are mixing start offsets really absolute time values? By their name, I was expecting an offset not an absolute value. Either approach is fine with me, of course, but perhaps the document needs to say explicitly that the offsets are actually absolute values and not differences to the start/end time.
    2. Stewart Bryant: Comment [2011-05-23]:
      On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.
    3. Adrian Farrel: Comment [2011-05-26]:
      There are enough detailed Discuss points from other people that I can't find much to add.
      Please note that you should not include references from the Abstract which is supposed to be stand-alone text.
      I was a little surprised that there isn't an Informative reference to draft-ietf-xcon-ccmp.
      Is http://www.relaxng.org/ the right reference to give for Relax NG given that it is published as an international standard by ISO?
    4. Stephen Farrell: Discuss [2011-05-24]:
      (1) I agree with the secdir reviewer (Tero Kivinen) [1] that passwords and personally identifying information do warrant specific protection in the DB. The security considerations seems to nearly, but not quite do this, when it says that the DB SHOULD be accessed via TLS or equivalent. However, I think you need two more things: a) to say when its ok to not follow the SHOULD but also b) you need to RECOMMEND that the (sensitive parts of the) DB be encrypted as stored in long term storage (i.e. disk) which is different from how its accessed via the network.
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html
      (2) I would think that conference object identifier URIs (and maybe also other URIs that are not typed by people) MUST or SHOULD be unguessable. The reason is that this provides a defence-in-depth for cases where e.g. TLS is not used when it ought be etc. Basically, if a URI is unlikely to be typed by a person, then it seems best to make sure they're unguessable and since this is something that implementations often get wrong this would seem like a good place for that statement.
      (5) 4.2.12 What does "set by an administrator" mean for a data model? How could I tell by looking? If it said "typically set..." that'd be fine but it currently reads like normative text.
      (7) Section 6 says "The IETF MAY extend the data model schema..." What does that mean? Why the 2119 MAY? Is a standards-track document needed, or informational, what about ISE/IRTF or other streams?
      (8) Security considerations: what does "There is no other encoding considerations for XCON-USERID or XCON-URI not discussed in RFC 3986 [RFC3986]." mean? I don't get it anyway.
    5. Stephen Farrell: Comment [2011-05-22]:
      (1) Typo: "the URIs comparison MUST applied a character-by-character basis"
      (2) In 3.2.2 if you don't want IP addresses to be used, then why not just say so? Maybe add text that says that xcon:foo@10.0.0.1 is not the same as xcon:foo@167772161 (but for one of the proper example IP addresses) if that's what is meant.
      (3) I think this (on p25) could do with rephrasing: "A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list (listed under the <allowed-users-list> element) with each participant being sufficiently (up to local policy) authenticated."
      (4) In 4.6.5, maybe s/authenticated user identities/authenticated user identifiers/ - a pet peeve of mine, but probably more correct as identifiers.
      (5) 4.6.5.3 seems a bit overstated - given that the highest level of protection still has non-anonymous identifiers for the user in the common model, calling if anonymous seems wrong and liable to give the wrong impression. I'd suggest changing the name of this to "<hide-name>". (This is not a discuss because I guess it could be that code depending on this name is out there already and its a small point.) If changing the name's not doable, then maybe add a sentence that implementations SHOULD make it clear to users that real anonymity is not being provided.
    6. Pete Resnick: Discuss [2011-05-25]:
      After getting most of the way though draft-ietf-xcon-ccmp and draft-ietf-xcon-examples-08, I have decided to move this to DISCUSS. These three documents repeat things from documents to which they normatively refer. Aside from increasing the overall length of what are already very long documents, I think this actually introduces a danger that the documents will "get out of sync": If the normative text happens to differ between the documents, it's unclear which is authoritative. If there's disagreement in even non-normative text, it introduces the potential for confusion. I really think the redundant text needs to be eliminated and the documents shortened.
      In this document: RFCs 3986, 4575, and 5239 are all normative references and are absolutely required reading to use this document. Therefore I don't see any reason for all of the redundancies in this document, and note the potential for problems above. So:
      Intro - Paragraphs 2, 3, 4 and figure are redundant and unneeded. Strike. (Indeed, figure 1 is subtly different from the ones in 5239. Maybe not in any important way, but why introduce the potential for confusion.)
      4.1 - Shorten:
      A conference object document begins with the root element <conference-info>, which is defined in [RFC4575]. The attributes 'state' and 'version' defined in [RFC4575] are not used for this element in this specification because these attributes only apply to notification mechanisms.
      This specification adds the child element <floor-information> to the <conference-info> element.
      4.2 - Shorten:
      The <conference-description> element, which is defined in [RFC4575], describes the conference as a whole. This specification adds the child elements <language>, <allow-sidebars>, <cloning-parent>, <sidebar-parent>, and <conference-time>. This specification also adds a new <conference-password> child element to the <entry> child element of the <conf-uris> child element, and adds the <mixing-mode>, <codecs>, and <controls> child elements to the <entry> child element of the <available-media> child element.
      Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5
      4.2.10 - Just define <conference-password> here.
      Strike 4.2.11, 4.2.12
      4.2.13 - Just define <mixing-mode>, <codecs>, and <controls> here.
      Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6
    7. Pete Resnick: Comment [2011-05-25]:
      ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also allows "---...", but I'm just checking. [Update 2011-05-24: The author claims this is desirable. I am willing to take his word for it, but leave this comment in just in case.]
      Editorial: Top of section 4 - The use of the word "operator" twice here is goofy. This is notation, not a formal operation. I say just strike it. [Update 2011-05-24: To be fixed.]
      Also, why is the figure specified as "non-normative". What could be taken as normative in there? [Update 2011-05-25: To be fixed.]
      4.2.1 - "defined in IANA [IANA-Lan]". That looks funny. [Update 2011-05-24: To be fixed.]
      4.2 - Why is "lang" on the <conference-description> rather than on its children? And why does it need to be called out normatively in this document? (Shouldn't all elements have a lang aatribute? Why is this one special?)
    8. Peter Saint-Andre: Discuss [2011-05-25]:
      First, my apologies for not reviewing this document earlier in the process, as requested by the RAI ADs.
      1. RFC 4575 says that a conference object MUST be encoded using UTF-8, yet this document says it SHOULD be encoded using UTF-8. Why the change? How would a UTF-16-encoded conference object be handled? I strongly suggest changing the SHOULD to MUST.
      2. Section 3.3 states: "When created within the conferencing system, the 'conference ID' has a 1:1 mapping to the unique conference object Identifier(XCON-URI)."
      However, Section 3.3.1 defines XCON-URI as: "XCON-URI = "xcon" ":" [conf-object-id "@"] host"
      Is there a 1:1 mapping between the "conference ID" and the full XCON-URI, or between the "conference ID" and the conf-object-id rule?
      3. Section 3.3.1 says that "the XCON-URI can not be resolved to addresses and/or ports". Does this mean that an application MUST NOT attempt to resolve an XCON-URI, or only that such URIs are not designed to be resolvable?
      4. Regarding Section 3.3.2, why not just reference Section 6 of RFC 3986?
      5. Please add a note that the XCON-URI construction does not directly support characters outside the ASCII range, but that such characters can be encoded (at least in the "host" portion) using the rules in RFC 3987.
      6. Section 4.1 states: "Note that the <conference-info> element does not have the attributes 'state' and 'version' defined in [RFC4575] for this element because these attributes only apply to notification mechanisms."
      What does it mean to say that the element "does not have" the attributes? Does it mean that for this usage, the attribute MUST NOT be included? If so then it appears that this document might be updating RFC 4575.
      (Similar text appears in Section 4.6, Section 4.6.5, etc.)
      7. Section 4.2 states: "The <conference-description> element, which is defined in [RFC4575], describes the conference as a whole. It SHOULD have an attribute 'lang' to specify the language used in the contents of this element."
      However, the 'lang' attribute is not specified in RFC 4575 schema. The RelaxNG definition in this document includes not 'lang' but 'xml:lang':
      "conference-description-type = element conference-description { attribute xml:lang { xsd:language }?"
      If you mean 'xml:lang' instead of 'lang' then please say so.
      8. A number of elements have boolean values, such as Section 4.2.6: "The <allow-sidebars> element represents a boolean value. If set to TRUE, the conference is allowed to create sidebar conferences. If absent, or set to FALSE, the conference can not create sidebar conferences."
      Please note that in W3C XML Schema Part 2 (Datatypes), there are two lexical representations for boolean values: "true"/"1" for the concept TRUE and "false"/"0" for the concept FALSE. You might want to add a general note about this somewhere in the text (or in each section say '"true" or "1"' instead of 'TRUE', '"false" or "0"' instead of 'FALSE').
      9. Given that the conference object is entirely defined in XML, why does the <base> child of the <conference-time> element contain the textual representation of an iCalendar object (RFC 5545) instead of the XML representation (draft-daboo-et-al-icalendar-in-xml, on the same telechat as this document)?
      10. Section 4.2.9 states the following about the <mixing-start-offset> element (same for <mixing-end-offset>): "The <mixing-start-offset> has the mandatory 'required-participant' attribute. This attribute contains one of the following values: "none", "administrator", "moderator", "user", "observer", and "participant". The roles' semantic definitions are out of the scope of this document and is subject to future policy documents. More values can be specified in the future."
      Not defining the attribute values seems problematic. Yes, we all have a common-sense idea of what administrators and moderators (etc.) are, but why leave the definitions to future policy documents? And given that more values can be specified in the future, is a registry in order?
      11. Section 4.6.3 states: "The <persistent-list> child element stores persistent information about users who are not actively part of an ongoing chatroom session. The <persistent-list> element stores the following information:
      "o user: The <user> element stores the name, nickname, the conference user identifier (XCON-USERID) and email address of a user. It has three attributes: 'name', 'nickname' and 'id' and an <email> element. Future extensions to this schema may define new elements for the <user> element."
      Why is it required to store email address? What are the privacy and security implications of storing email addresses (e.g., possible directory harvesting attacks)?
      12. Section 6 states: "The Conference Information Data Model defined in this document is meant to be extensible toward specific application domains. Such extensions are accomplished by defining elements, child elements and attributes that are specific to the desired application domain. The IETF MAY extend the data model schema with unqualified attributes or extension elements from the "urn:ietf:params:xml:ns:" "sub-namespace" in the future. Other instances are free to define extension elements or attributes under other namespaces."
      I see no reason to talk about the "urn:ietf:params:xml:ns:" tree here, although if you want to talk about it then the MAY seems out of place and it would be good to provide a pointer to RFC 3553. I would suggest: "The Conference Information Data Model defined in this document is meant to be extensible. Extensions are accomplished by defining elements or attributes qualified by namespaces other than "urn:ietf:params:xml:ns:conference-info" and "urn:ietf:params:xml:ns:xcon-conference-info" for use wherever the schema allows such extensions (i.e., where the RelaxNG definition specifies "anyAttribute" or "anyElement")."
    9. Peter Saint-Andre: Comment [2011-05-25]:
      1. Section 3.4 says: "Note that some of the elements described above such <conference-info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-val> are not defined in the data model in this specification but are defined in the data format of [RFC4575]. We describe them here because they are part of the basic structure of the data model."
      In fact *only* <floor-information/> is defined in this specification. It would be good to make that clear.
      2. In Section 4.2.13: "* The <mute> element is used in conjunction with an audio stream to cease transmission of any audio from the associated stream. That means that for the entire duration where mute is applicable, all current and future participants of the conference are muted and will not receive any audio."
      To be precise, muting applies to the sending of audio, not the receiving of audio.
      3. I haven't had time to complete detailed checking of the RelaxNG schema (compact or XML syntax), the W3C XML Schema document, or the examples. However, including the formal definition in three different representations might introduce the possibility that they are out of sync. The fact that only the compact syntax is normative helps. Finally, I merely note that the formal definition in RFC 4575 uses W3C XML Schema, whereas the formal definition in this document uses RelaxNG; the disconnect might make it difficult for implementers to compare and reuse the formal definition.
    10. Sean Turner: Discuss [2011-05-23]:
      #1) Mandatory is used a couple of times in the document to indicate support level for certain attributes (e.g., in Sec 4.2.9). I think these should be changed to use 2119 language.
      #2) Sec 4 include the following: "The operator "!" preceding an element indicates that the element is mandatory in the data model."
      Shouldn't mandatory be REQUIRED (i.e., use 2119 language).
      #3) I'm trying to reconcile the following statement from Sec 4.2.9 and Figure 3: "Every <entry> element contains the following child elements:"
      I read that to mean the child elements MUST be present. Is that the case?
      Same thing in 4.2.13: "Each <entry> element contains the following child elements:"
      #3) Sec 4.2, 4.3, 4.4, 4.6: Which of the sub-elements MUST be supported? E.g., is it allowable to have an empty <conference-state> or <users>? If so how's that handled?
      #4) Sec 4.5: Which of the four elements MUST be supported? Is <conference-ID> a MUST? What happens when <floor-request-handling> isn't included - is there default behavior like <allow-floor-events>?
      #5) Sec 4.5.4 includes the following: "The <conference-floor-policy> element has one or more <floor> child elements."
      Doesn't this mean "floor" is a MUST? Then, Figure 3 needs to be updated and this sentence should be reworded to clearly state it's a MUST support.
      #6) Sec 4.6.5.10 needs to indicate that it MUST be included in every <user>.
    11. Sean Turner: Comment [2011-05-23]:
      #1) I support Stephen's discuss.
      #2) Should this document indicate that it updates RFC 4575?
      #3) Sec 1 includes the following: "This core data set called the 'conference information data model' is defined in this document using an Extensible Markup Language (XML)-based."
      I think this sentence is missing some additional words.
      #4) Sec 4.5.4:
      r/is optional/is OPTIONAL
      r/The optional/The OPTIONAL

    Telechat:

  2. vCard Format Specification (Proposed Standard)
    draft-ietf-vcarddav-vcardrev-21
    Token: Peter Saint-Andre
    Note: The document shepherd is Alexey Melnikov.
    Discusses/comments (from ballot 3434):
    1. Adrian Farrel: Discuss [2011-05-25]:
      A fine piece of work, but one small issue need resolution before publication as an RFC.
      draft-ietf-vcarddav-vcardxml sets two requirements for extensions to this document:
      "It is expected that [...] vCard extensions will also specify extensions to the XML format"
      "New XML vCard property and parameter element names MUST be lower-case."
      I think you should include these two requirements in this document.
    2. Stephen Farrell: Comment [2011-05-23]:
      (1) I'm surprised that there is no security considerations text about the fact that you might run into trouble if you blindly follow URLs that are embedded in vCards. There's probably easily copied text somewhere on that.
      (2) Similar point about embedded images and audio - again security considerations about parsing/rendering these carefully would be good.
      (3) You can specify a key but no signature? That's a pity but I guess would be another spec entirely. Just wondering if anyone's developing that.
      (4) This allows a whole bunch of things to be included (e.g. PGP keys, URLs etc.) but there are no conformance requirements for what has to be supported. I guess that's in some other spec somewhere?
    3. David Harrington: Comment [2011-05-25]:
      1) in xCard,
      New XML vCard property and parameter element names MUST be lower-case. This is necessary to ensure that round-tripping between XML and plain-text vCard works correctly.
      in vCard,
      Based on experience with vCard 3 interoperability, it is RECOMMENDED that property and parameter names be upper-case on output.
      are these consistent?
      2) references need updating (see id-nits)
    4. Russ Housley: Comment [2011-05-24]:
      The discussion following the Gen-ART Review by Kathleen Moriarty on 8-Apr-2011 lead to the following proposed text:
      "vCards often carry information that can be sensitive (e.g. birthday, address, and phone information). Although vCards have no inherent authentication or privacy provisions, they can easily be carried by any security mechanism that transfers MIME objects to address authentication or privacy (e.g. S/MIME [RFC5751], OpenPGP [RFC4880]). In cases where the privacy or authenticity of information contained in vCard is a concern, the vCard SHOULD be transported using one of these secure mechanisms. The KEY property (Section 6.8.1) can be used to transport the public key used by these mechanisms."
      I would prefer the use of "confidentiality" instead of "privacy". That would better align with the definitions in RFC 2828.
    5. Pete Resnick: Comment [2011-05-24]:
      3.3 - NON-ASCII = %x80-FF ; Use is restricted by UTF-8
      Why not use UTF8-char and reference RFC 3629?
      4 - TEXT-CHAR = "\\" / "\," / "\n" / <any VALUE-CHAR except , or \> ; Backslashes, commas, and newlines must be encoded.
      Is it so bad to expand this out?
      TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII / %x21-2B / %x2D-5B / %x5D-7E ; Backslashes, commas, and newlines must be encoded.
      6.1.2/6.1.3 -
      BEGIN-param = 0dummy ; no parameter allowed
      END-param = 0dummy ; no parameter allowed
      BEGIN-param = 0" " ; no parameter allowed
      END-param = 0" " ; no parameter allowed
      That looks neater to me.
      6.5.1 - Is it worth an informative reference to draft-lear-iana-timezone-database (approved BCP)?
    6. Dan Romascanu: Comment [2011-05-24]:
      I support the issues raised by Stephen Farrell in his COMMENT.
    7. Robert Sparks: Discuss [2011-05-24]:
      Is this document deprecating text/directory? It obsoletes the RFC that defined it, but the only mention is in the media registration of text/vcard as "should be considered deprecated in favor of text/vcard". Why isn't this stated more clearly in the text (particularly the introduction) of the document?
    8. Robert Sparks: Comment [2011-05-24]:
      It would help to point to Appendix A earlier in the document, perhaps with a very high-level overview of what's been updated. An implementer will use Appendix A as a checklist of items to check against code - is it complete? There are changes called out in B (which will be deleted before being published) that don't seem to be reflected in A.
      Were there any changes to what 4770 specified?
    9. Sean Turner: Discuss [2011-05-24]:
      #1) Sorry to inflict an this on the authors, but I gotta ask: Do you want to move the obsoleted RFCs to Historic?
      #2) The last line in the abstract doesn't match up with the header. Is 2739 being updated or obsoleted?
      #3) Sec 3.1: What should happen if another charset is included?
    10. Sean Turner: Comment [2011-05-24]:
      #1) Section 5.2 & 5.3: r/parameter is optional/parameter is OPTIONAL
      #2) Sometimes the document uses ASCII and other it uses US-ASCII. Was this intentional?
      #3) Sec 6.8.1: lots of people use .cer or .pem for X.509 certificates can we change the example to:
      KEY:http://www.example.com/keys/jdoe.cer?

    Telechat:

  3. xCard: vCard XML Representation (Proposed Standard)
    draft-ietf-vcarddav-vcardxml-10
    Token: Peter Saint-Andre
    Note: The document shepherd is Alexey Melnikov.
    Discusses/comments (from ballot 3435):
    1. Adrian Farrel: Comment [2011-05-25]:
      The Relax NG specification really does need a reference that would help identify the correct base specification. I think you could use an OASIS URL, but I would prefer the ISO number.
    2. David Harrington: Comment [2011-05-25]:
      1) I did not validate Appendix A. Has this had independent validation by, say, the XML directorate?
    3. Russ Housley: Comment [2011-05-24]:
      The Security Considerations say: "All the security considerations applicable to plain vCard [I-D.ietf-vcarddav-vcardrev] are applicable to this document as well."
      This is completely correct; however, the use of XML digital signature and XML encryption are appropriate security mechanisms in this situation, while these mechanisms are not appropriate for a plain vCard. This seems worthy of mention.
    4. Dan Romascanu: Comment [2011-05-25]:
      5.1. Extensibility: "The original vCard format is extensible. New properties, parameters, data types and values (collectively known as vCard objects) can be registered with IANA. It is expected that these vCard extensions will also specify extensions to the XML format described in this document."
      I think that this paragraph refers to the procedure described in Section 10.2 of http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-21.txt for registering new vCard elements. I beleieve that an explicit reference would be useful. Also, why are the vCard extensions called 'objects' in this document and 'elements' in the other? Also just saying 'can be registered with IANA' is somehow mis-leading (especially in the absence of the reference) as this is no routine IANA registration, but a procedure that requires a standards-track RFC in some cases.

    Telechat:

  4. Centralized Conferencing Manipulation Protocol (Proposed Standard)
    draft-ietf-xcon-ccmp-13
    Token: Robert Sparks
    Note: Alan Johnston (alan.b.johnston@gmail.com) is the Document Shepherd.
    Discusses/comments (from ballot 3538):
    1. Stewart Bryant: Comment [2011-05-23]:
      On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.
    2. Ralph Droms: Comment [2011-05-25]:
      What is the scope of the uniqueness for an XCON-USERID? Is XCON-USERID intended to be used across multiple conferences or is it specific to a conference?
    3. Adrian Farrel: Discuss [2011-05-25]:
      A very weighty tome that I cannot pretend to have read in full detail. I am relying on the WG and responsible ADs for assurance of quality, but I noticed a few smaller issues that I believe need to be resolved before publication.
      Section 4: The specification recommends the use of HTTP as a transport solution, including CCMP requests in HTTP POST messages and CCMP responses in HTTP 200 OK replies. This implementation approach is further described in Section 4.4.
      Section 9: This section describes the use of HTTP [RFC2616] and HTTP Over TLS [RFC2818] as transport mechanisms for the CCMP protocol, which a conforming conference Server and Conferencing client MUST support.
      Section 10: 3. The protocol MUST support a confidentiality and integrity mechanism. As described in Section 9, implementations of CCMP MUST implement the HTTP transport over TLS [RFC2818].
      So it looks like Section 4 is under-egging the situation and you need
      s/recommends/requires/
      It is probable that Seciton 4.4 needs to be tightened in this regard as well.
      I think the 2119 language needs to be tightened up...
      Section 5.1: "conference-password: An optional parameter that MUST be inserted in all requests whose target conference object is password-protected (as per the <conference-password> element in [I-D.ietf-xcon-common-data-model])."
      This "MUST" implies that ommission would be treated as a malformed message, not a password failure (i.e. 400 not 401). Does it matter? But later I see you have defined 424 which is probably what you would use. Add some clarity?
      Shouldn't the sample phone number (uri="tel:+390817683823") be taken from one of the set of "unreal" phone numbers?
      Section 7: "This document proposes the use of DNS to locate the conferencing server."
      What is the upshot of this proposal? Does a conformant implementation get to choose? Is this language you can tighten as s/propose/specifies/
    4. Adrian Farrel: Comment [2011-05-25]:
      BTW, I appreciated the many examples, although they might have been moved to an appendix to clear the floor for the main meat of text (is that metaphor too horribly mixed?). I also wasn't convinced by including all of the schema fragments in-line as well as in Section 11, but this is probably a stlistic choice that is not important.
      Nit: 5.4. All CCMP response messages MUST include a ""response-code"".
      You probably don't need the quad-quotes.
    5. Stephen Farrell: Discuss [2011-05-25]:
      (1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be a mistake. Its more likely that HTTP authentication will be maintained in future (e.g. extended for oauth, saml, etc) than that CCMP will be. I would suggest getting rid of the "not required" in section 9 on that.
      (2) The response codes in 5.4 seem to be a subset of those from rfc 2616. I think it'd be better to not replicate the descriptive text about those, nor the codes themselves - how is the combination of HTTP response codes and CCMP response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one response then what? I could imagine coders getting this wrong, or having difficulty doing the right thing with libraries.
    6. Stephen Farrell: Comment [2011-05-25]:
      (1) This could do with being rephrased. "Their identifiers, respectively the conference XCON-URI and the conferencing client XCON-USERID, and their XML representations compliant with the XML Schema defined in the XCON data model are widely used for creating the CCMP requests and responses."
      (2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really followed the description and I wondered if it'd be easy to write code for this. I'd suggest maybe looking at that text again to see if there's a way to make it clearer for an implementer who hasn't been involved in the WG.
      (3) In 4.4, if a client's timer expires and it closes the connection, then what, if anything, is the server supposed to do? E.g. if the request was ok and the server has done an update but not yet sent the 200 response for some reason. I think the server doesn't have to do anything (e.g. try to unwind the update), but that'd be good to say.
      (4) What is the limit of the xPathFilter mechanism? Could I use it to select all the users or conferences with the password foo? Maybe there's some security considerations text needed for that?
    7. Pete Resnick: Discuss [2011-05-25]:
      As with draft-ietf-xcon-common-data-model, section 3 of this document repeats things from RFC 5239. I think this introduces a danger that the documents will "get out of sync": If the normative text happens to differ between the documents, it's unclear which is authoritative. If there's disagreement in even non-normative text, it introduces the potential for confusion. Strike all of section 3. Completely redundant with RFC 5239, which is a normative reference anyway.
      The intro to section 4 gives an implementation requirement without using 2119 language...
      4.3 needs a reference to the data model document.
      5.2 defines the "version" parameter as optional. However, there are clearly instances (specified in 4.2) where it is required. 5.2 should probably indicate that.
      5.3.1 - "A blueprintsRequest message REQUIRES no "confObjID" and "operation" parameters". Do you mean that they are OPTIONAL or that they MUST NOT be present? "REQUIRES no" is not appropriate.
    8. Pete Resnick: Comment [2011-05-25]:
      Intro to section 4: ...
      That's a bit fluffy. How about instead: ...
      4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced.
      4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two)
      can be reduced to: ...
      5.3 Overall - I wouldn't mind seeing all of the XML *not* repeated here. It's already in section 11.
      5.3 Intro - Move the discussion of optionsRequest/optionsResponse down to 5.3.12. No need to distinguish it here.
      6 - I think this should either be in an appendix or in draft-ietf-xcon-examples.
    9. Dan Romascanu: Comment [2011-05-26]:
      The OPS-DIR review performed by Juergen Quittek raised a few issues and made a number of suggestions. None of them are critical, but in case the document is open to fix other issues I suggest to consider these ones as well:
      1) Section 2: Terminology: "First-Party: A request issued by the client to manipulate their own conferencing data."
      "Third-Party: A request issued by a client to manipulate the conference data of another client."
      "First-Party" and "Third-Party" alone are not requests. At least the term is not used this way in the draft. Rather "third-party request" is used in the text for Referring to requests. I would suggest:
      NEW: "First-Party request: A request issued by the client to manipulate their own conferencing data."
      "Third-Party request: A request issued by a client to manipulate the conference data of another client."
      2) Section 3, third paragraph, 1st line:
      OLD: "Conference object and conference users do represent key elements"
      NEW: "Conference object and conference user objects do represent key elements"
      Implementation and operation of the protocol would become drastically simpler if the CCMP server would not be required anymore to create users. Just creating user objects would probably be sufficient already
      3) Section 3.2, 1st paragraph, lines 7-8
      OLD: "or a common administrator. The Conference Control Server creates individual users, assigning them a unique Conference User Identifier "
      NEW: "or a common administrator. The Conference Control Server creates individual user objects, assigning them a unique Conference User Identifier"
      4) Section 4.1, 2nd paragraph
      OLD: "create: for the creation of a conference, a conference user, a sidebar, or a blueprint."
      NEW: "create: for the creation of a conference object, a conference user object, a sidebar, or a blueprint."
      5) Section 4.3, item (b), line 2:
      OLD: "in the request has (have) been replaced by the newly created "
      NEW: "in the request have been replaced by the newly created"
      6) Section 5.3.4, paragraph after Figure 8, line 7: What is "the referenced conference document"? Is it the conference object?
      7) Section 5.3.5, 1st paragraph, Last two lines: Again "conference document", see issue 6)
      8) Section 5.2.12, first bullet item, line two: "ten standard message names" It would be helpful to add a reference to Table 1.
      9) Section 7, first lines: "If a conference control client is not pre-configured to use a specific conference control server for the requests, the client MUST first discover the conference control server before it can send any requests."
      Is this really a capital "MUST"? Would the client be able to send any request before discovering the server?
    10. Peter Saint-Andre: Discuss [2011-05-25]:
      1. Section 4.2 appears to assume that HTTP is the transport; for example: "If the modifications are all successfully applied, the server sends back to the client a "200" response which also carries information about the current server-side version of the modified object."
      If that is so, please either change SHOULD to MUST (i.e., make HTTP mandatory-to-implement as a baseline data transfer protocol) or at least add a note to the effect that HTTP is a SHOULD but all the examples use HTTP.
      This would also be consistent with Section 9, which states: "This section describes the use of HTTP [RFC2616] and HTTP Over TLS [RFC2818] as transport mechanisms for the CCMP protocol, which a conforming conference Server and Conferencing client MUST support."
      2. In Section 4.3: "The XCON data model identifies some elements/attributes as mandatory..."
      Instead of sending fake values, how about fixing the data model so that these elements and attributes are not mandatory?
      3. The CCMP namespace is "urn:ietf:params:xml:ns:xcon:ccmp". Why is it not "urn:ietf:params:xml:ns:xcon-ccmp"? On the meaning of ":" here please see Section 3 of RFC 3553...
      Declaration of structure: "The namespace is primarily opaque. The IANA, as operator...
      It appears that "urn:ietf:params:xml:ns:xcon" is not a valid name. Thus "urn:ietf:params:xml:ns:xcon-ccmp" seems better. Notice also that the XCON conference info URN is "urn:ietf:params:xml:ns:xcon-conference-info" not "urn:ietf:params:xml:ns:xcon:conference-info".
      4. Section 9 states: "a conferencing server may not be a fully compliant HTTP server"
      Do you mean "might" or "MAY"? I.e., is it OPTIONAL for a conferencing server to fully comply with HTTP?
    11. Peter Saint-Andre: Comment [2011-05-25]:
      1. Section 4 states: ...
      Change "must" to "MUST"?
      2. Also in Section 4: ...
      Change to the following?: Implementations SHOULD use HTTP as the transport...
      3. In Section 4.2:
      There is no "not REQUIRED" in RFC 2119. I suggest: The "version" parameter is OPTIONAL for requests...
      4. In Section 5, the terms "mandatory" and "optional" are used for the various parameters. Using RFC 2119 language, are these really "REQUIRED" and "OPTIONAL"?
      5. The table in Section 5.4 has bad line breaks...
      6. Various examples have "form the server" instead of "from the server".
      7. In schema snippet from Section 6.9, the example extension does not specify an XML namespace, implying that the extension is qualified by the base namespace. This would be wrong. The examples are right, here.
      8. Section 9 states: ...
      There is no "not required" in RFC 2119. Do you mean that it is OPTIONAL for a conferencing server to support RFC 2617 and RFC 6265?
      9. In Section 10.4, please add an informational reference to RFC 4732.
    12. Sean Turner: Discuss [2011-05-25]:
      This is an updated discuss... #5 and #6 are new.
      #5) I couldn't find an explicit statement that clients and server MUST support both the request and response. Do we need that or is it assumed?
      #6) In the CCMP Request there are 5 fields defined. All are optional. Doesn't at least one field need to be a MUST? If there's no required field - can an implementation that sends no fields in a CCMP Request considered compliant? I had the same kind of comment against the xcom-common-data-model: It seems odd to me that the protocol would specify sub-elements all of which are optional. Maybe this is done all the time in XML land and I'm just picking on this draft? In ASN.1-land, where I'm from, it's like having a CHOICE and not explaining which one of the choices is a MUST.
    13. Sean Turner: Comment [2011-05-25]:
      (five items, with author responses)

    Telechat:

  5. Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) (Proposed Standard)
    draft-ietf-avtext-multicast-acq-rtcp-xr-04
    Token: Gonzalo Camarillo
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3792):
    1. Adrian Farrel: Comment [2011-05-25]:
      It would have helped me as a reader to have had some idea of the range of potential sizes of the random acquisition delay. I suspect that it can be expressed in packets and extrapolated to a time interval based on line speeds, etc. Obviously (?) if the range is 0 to < 1ms we might conclude that this work is not very necessary. Can you add a short note to help scope the work?
      Section 3 says: "This document uses the following acronyms and definitions from [I-D.ietf-avt-rapid-acquisition-for-rtp]:"
      But the definitions presented are somewhat different from those in the referenced document. Although the intent may be the same, I don't think it is helpful to have different definitions and I recommend that you remove all but a list of terms and a pointer to the other I-D.
      Nit: Abstract: s/ore/or/
    2. Stephen Farrell: Comment [2011-05-25]:
      (1) s/one ore more/one or more/
      (C2 The constant 11 - I assume that's decimal - probably worth saying just in case someone interprets it as '11'H or 3 or whatever.
      (C3 I think you want to to s/this bit/this field/g below: "Rsvd. (16 bits): The RTP receiver MUST set this bit to zero." recipient MUST ignore this bit when received.
      (4) Suggest rephrasing this in 4.2.1 (how can a time measured locally be negative?) ...
    3. David Harrington: Comment [2011-05-25]:
      1) in 4.1, "Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The recipient MUST ignore this bit when received." - MUST ignore these bits or MUST ignore this field.
      2) in 7.1, do you want to replcae or supplement the existing RFC#?
      3) in 7.4, should 0, 255, and 128-254 be included in the registry with approrpiate notations?
    4. Pete Resnick: Comment [2011-05-24]:
      In 4: "It is better to send the MA report block after all the necessary information is collected and computed. Partial reporting is generally not useful as it cannot give the full picture of the multicast acquisition, and causes additional complexity in terms of report block matching and correlation. The MA report block is only sent as a part of an RTCP compound packet, and it is sent in the primary multicast session."
      Is there a reason 2119 language was not used here? (i.e., SHOULD send only after all information is collected, MUST send as part of an RTCP compound packet in the primary multicast session)
      In 4.2.1: "o SFGMP Join Time (32 bits): TLV element that denotes the greater of zero or the time difference (in ms) between the instant SFGMP Join message has been sent and the instant the first packet was received in the multicast session. If the multicast join was successful, this element MUST be included. If no multicast packet has been received, this element MUST NOT exist in the report block."
      and "o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element that denotes the greater of zero or the difference between the sequence number of the first multicast packet (received from the primary multicast stream) and the sequence number of the last burst packet minus 1 (considering the wrapping of the sequence numbers). If no burst packet has been received in the unicast session or no RTP packet has been received from the primary multicast stream, this element MUST NOT exist in the report block."
      When could the "greater of zero or" part kick in? That is, when can the difference possibly be negative?
    5. Dan Romascanu: Discuss [2011-05-26]:
      1. Some of the basic terms for the understanding of this document are being referenced from [I-D.ietf-avt-rapid-acquisition-for-rtp]. It looks to me that this document should be a Normative rather than Informational reference.
      2. The Specification Required policy defined in Section 7.5 makes the following recommendation.
      "The length of the Status field is two octets, allowing 65536 codes. However, the status codes have been registered to allow for an easier classification. For example, the values between (and including) 1 and 1000 are primarily used by the MA method of simple join. The values between (and including) 1001 and 2000 are used by the MA method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When registering new status codes for the existing MA methods or newly defined MA methods, a similar classification scheme is encouraged to be followed."
      However, there are currently 253 unassigned method values, so there is no room for an allocation of 1000 codes for each of them which creates a potential problem in the future. The language should be ammended (something else than 'similar classification scheme') and include some warning to IANA for caution on this issue.
    6. Robert Sparks: Comment [2011-05-24]:
      Additional text describing the assumptions around when you would use a status code of zero would help greatly. The expected use is that the sender of a report would only use that code when it knew from out-of-band methods that the receiver would understand the private TLVs in the report - one of those private TLVs, ostensibly, would replace semantics of the status code. Saying that explicitly would help avoid the situation where a client unintentionally throws away information like "multicast join was successful" by adding a private TLV that the server doesn't understand to a report that it would otherwise have used a status code of 1 on.
    7. Sean Turner: Discuss [2011-05-23]:
      Sec 4.1: Please use 2119 language to indicate support requirements. Mandatory is not 2119 language. Also, are block length and Rsvd optional?
    8. Sean Turner: Comment [2011-05-23]:
      Sec 4: r/The optional extensions that are/The OPTIONAL extensions that are
      Sec 4.2.1: r/Optional/OPTIONAL x 9. For Types 1 and 2 - are they optional too?

    Telechat:

  6. IANA Registry for Interactive Connectivity Establishment (ICE) Options (Proposed Standard)
    draft-ietf-mmusic-ice-options-registry-02
    Token: Gonzalo Camarillo
    Note: Flemming Andreasen (fandreas@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3803):
    1. Stephen Farrell: Comment [2011-05-18]:
      (1) s/these ICE options needs/these ICE options need/
      (2) Are there no existing ice-options that should be added to the registry? Looks like there aren't but just checking.

    Telechat:

  7. FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses (Proposed Standard)
    draft-ietf-savi-fcfs-09
    Token: Jari Arkko
    Note: Jean-Michel Combes (jeanmichel.combes@gmail.com) is the Document Shepherd
    Discusses/comments (from ballot 3808):
    1. Stewart Bryant: Comment [2011-05-25]:
      I support the discusses raised against this document.
    2. Ralph Droms: Discuss [2011-05-24]:
      1. The definitions of "source address validation", "address ownership" and the concept that a " source address [...] belongs to the originator of the packet" need to be clarified this paragraph:
      2.3. Address ownership proof: "The main function performed by FCFS SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. Since FCFS SAVI scope is limited to the local link, the originator of the packet is attached to the local link. In order to define a source address validation solution, we need to define some address ownership proof concept i.e. what it means that a given host owns a given address in the sense that the host is entitled to send packets with that source address."
      FCFS SAVI does not require that a host provide any sort of proof of "ownership" of an address before that address is registered in an FCFS SAVI function. A host merely needs to claim the address through traffic sent to the FCFS SAVI function. In contrast, a SAVI function implemented by bindings learned through manual configuration or through interactions with a DHCPv6 address assignment function can make a statement that an IP address belongs to a host.
      What FCFS SAVI does is prevent simultaneous use of a single IP address as a source address through multiple ports. There is no guarantee that the FCFS binding in any way reflects intended ownership of the bound address.
      2. There needs to be text in section 2.1 explaining why FCFS SAVI is applicable or inapplicable to addresses assigned through DHCPv6.
      3. What about links for which there are no prefixes that are advertised as on-link? Similarly, what about addresses that are assigned through DHCPv6 but are not taken from an on-link prefix?
      4. In section 3.2.2: "If the IP source address does not belong to one of the local prefixes of the receiving interface, this means that the data packet is transit traffic and the packet SHOULD be discarded.""
      s/SHOULD/MUST/
      How are the FCFS SAVI assumptions maintained and how is spoofed traffic discarded if the FCFS SAVI function decides to forward transit traffic?
      5. Section 3.2.4 must be worded more strongly to guarantee FCFS SAVI protection. Some of the items in the list are "MUST" or FCFS SAVI protection will not be provided:
      "o Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with spoofed source address."
      "o Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating ports. Not doing so will allow the host connected to any of these switches to send packets with spoofed source address."
      This requirement is a MUST. There are no alternatives to the given configurations that still provide FCFS SAVI protection.
      6. I agree with Stephen Farrell's DISCUSS points 3 and 4, but feel less strongly about a fix. Specifically, I agree that FCFS SAVI is inappropriate for a deployment in which an external router can pass transit traffic to an FCFS SAVI function. But that just means SAVI FCFS is inappropriate. There are other SAVI mechanisms that can work; for example, a DHCPv6-based mechanism in which the (non-FCFS) SAVI function is aware of the addresses and prefixes assigned through a binding anchor and, therefore, bound to that binding anchor.
      One way to address this issue some additional text describing how SAVI can be used to provide perimeter security, where that SAVI might be FCFS SAVI over part of the perimeter or some other kind of SAVI over the remainder of the perimeter.
      7. This paragraph from section 4 needs some clarification: "The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link."
      Random address selection makes it difficult for an attacker to hijack an address and deny legitimate use of an address. However, in deployments that use SLAAC, a host has a predictable global address (perhaps augmented by random privacy addresses) that can be hijacked.
      8. In TESTING_VP state, section 3.2.3: "If a data packet is received through a Trusted Port port that is other than port P, the state is moved to TESTING_TP-LT, and the packet MAY is discarded."
      Certainly it can't be just any packet received through a Trusted Port that triggers this action. And, if P is a validating port, won't traffic on any Trusted Port be "other than port P"? This bullet needs to be corrected.
      9. Throughout section 3.2.3, there are several occurrences of "If a DAD_NSOL" which need the qualification ""with target address set to IPAddr".
      10. In section 3.2.3, does "==" mean "is set to"? In the last bullet of TESTING_VP, does the FCFS SAVI function continue the TESTING_VP state and is the lifetime modified?
    3. Ralph Droms: Comment [2011-05-24]:
      1. What is the relationship between the contributors in section 6 and the contents of the document and the list of authors? A quick sentence about why the contributors are listed as such - rather than as authors or in the acknowledgments - would be helpful.
      2 I think it should be made clear whether the term "SAVI" refers to "FCFS SAVI" or, more generally, to any form of SAVI throughout the document. Section 2.6, for example, is unclear about the use of "SAVI". It's important to be clear in section 2.6 because in my opinion a SAVI perimeter could be composed out of various kinds of SAVI functions.
      3. What is the definition of a "realm"? It's important to define realm because, by using ND to confirm the correctness of SAVI bindings, the FCFS SAVI function only checks on the link to which it is attached, not across the entire FCFS SAVI perimeter.
      4. Also in section 3.2.3: NO_BIND: "Upon the reception through a Validating Port (VP) of a Neighbour Solicitation (NSOL) generated by the Duplicate Address Detection (DAD) procedure (hereafter named DAD_NSOL) containing Target Address IPAddr, the SAVI device MUST forward the NSOL and 250"
      In the last line, s/NSOL/DAD_NSOL/ How does the FCFS SAVI function differentiate between NSOLs generated by DAD and other NSOLs?
      5. In TENTATIVE state, section 3.2.3: "the state remains in TENTATIVE_DAD_NSOL,"
      s/TENTATIVE_DAD_NSOL/TENTATIVE/
    4. Wesley Eddy: Discuss [2011-05-24]:
      Some questions I think the authors should respond to:
      I believe the RetransTimer is configurable in RFC 4861, so why is 250 ms a magic number in Section 3.2.3 of this document? Are there scenarios where this value needs to be configured differently or is this really one size fits all? I didn't notice the motivation for this constant in the document, and it probably should be explained. It seems to be fixed rather than just a default, but the wording in this document is actually a little ambiguous about this.
      The same comment applies to TENT_LT (500 ms) and DEFAULT_LT (5 minutes). If these constants are special for some reason and not just defaults that can be tweaked to suit a deployment, it needs to be described why, otherwise the logic for setting them a certain way needs to be given.
    5. Wesley Eddy: Comment [2011-05-24]:
      Some comments that I don't think are very important and that the authors should feel free to either take or ignore:
      In section 2.1, second paragraph, it might make sense to be more clear that routers use their own MAC address, but the packets that they forward have an off-link source address that doesn't belong to them. However, I don't think anyone will really be confused either way, so this is just a suggestion.
      The definition of the term "binding anchor" is somewhat implicit in this document. It might be a good idea to make it more explicit with just a sentence or so more where it's first used in 2.3, and only one very brief example is given.
      In section 2.3, second paragraph, should "(e.g. the port in a switched LAN)" be "(e.g. the MAC address and/or port in a switched LAN)"?
    6. Adrian Farrel: Comment [2011-05-25]:
      There are plenty of Discuss points already raised with which I agree.
      Section 1: "The proposed mechanism..."
      It is no longer a proposal.
      The figure on page 9 has a misalignment.
      The writeup says: "There are existing implementations of a very similar feature for IPv4."
      This is fair enough, but I am surprised to see no reference to this in the document and no description of the differences.
    7. Stephen Farrell: Discuss [2011-05-23]:
      While this is quite long and maybe has some controversial things, it doesn't impact that much on details of the actual scheme so I hope it's less bad than it appears.
      (1) A general point about SAVI that also applies to SAVI FCFS: Since SAVI is only about spoofed source addresses and is not about monitoring hosts that never spoof anything, and since privacy is a concern for the (I assume) huge majority of non-spoofing hosts I would like to see this (and all SAVI standards track documents) say something like:
      "Compliant implementations MUST NOT log binding anchor information except where there is an identified reason (see section X for the list of reasons applying for FCFS-SAVI) why that information is likely to be involved in detection or prevention of actual source address spoofing. Information that is not logged MUST be deleted as soon as possible (see section Y for the conditions that make it safe to delete information). Information about the majority of hosts that never spoof SHOULD NOT be logged."
      The conditions for when logging is allowed and when each piece of state can be deleted need to be specifically called out. Those would be the putative sections X & Y in the above suggested paragraph above.
      I realise this may seem like a significant change (though not to the parts of the protocol that actually detect spoofing) but I think it is an important one.
      (2) Abstract - SAVI is not about the general "control of source addresses used" - it is chartered to help detect/prevent source address spoofing and that is all.
      (3) My phone can be a WiFi access point. How would that continue to work if SAVI-FCFS were deployed? I think the document needs to say how one can differentiate transit traffic from spoofed source addresses in that case or that SAVI FCFS MUST NOT be used in networks that should allow my phone to do its thing. 2.1 says that this technique only applies to local traffic so implementers will need to know how to do this.
      (4) I think SAVI FCFS needs a way to allow transit traffic and disallow spoofed source addresses but that is not trivial to fool by just pretending to be a router. If that is not possible, then this technique just seems broken. Its not clear to me whether the spec has this problem or not.
      (5) 2.4 - saying you "assume" that the binding anchor is a port on a switched network implies that SAVI-FCFS MUST NOT be used in any other case. You need to say that. On a related point, you need to clearly say that this is just for IPv6 if that is the case, (depending on rfc 4861 seems to make that the case). All text that implies that the binding anchor for SAVI FCFS can be anything other than a port number should also be excised since SAVI FCFS is only defined for the port number being the binding anchor as far as I can see. This could probably best be done via an applicability statement section at the front. (Probably just a short paragraph is all that's needed.)
      (6) 2.5 I totally disagree that its a good idea for SAVI to log all this information. I'd like to see the section removed. (And as in (1) above, replaced with a MUST NOT for "normal" traffic and binding anchor information.)
      (7) (If 2.5 ends up staying...) Where in the SAVI charter does it say that "a secondary goal is to assist in traceability.."? Is there IETF consensus for this goal? I don't believe there is. RFC 2804 would imply the opposite.
      (8) If I end up in the rough on point (1) above, I would like to discuss whether not not SAVI goals could be met while only dealing with an anonymized form of binding anchor information. If so, then maybe you should have a MUST for doing that where the binding anchor information could be personally identifying. While this is less relevant for SAVI-FCFS than perhaps other variants, (e.g. MAC address or NAI) even a port can be personally identifying in a some networks.
      (9) The SAVI DB content says "such as the layer-2 address" but you've gone to lengths to say that's not trustworthy so its presumably not useful for detection of source address spoofing and should not be included here. See also point (1) above - MAC addresses of non-spoofing users should not be retained casually like this. I'd like to see a statement that personally identifying data MUST NOT be included in the SAVI DB with the MAC address as the canonical example. (If packets do indicate attempted spoofing then I've no problem about logging the MAC address.)
      (10) The prefix in the prefix list is v6 only - right? If so maybe worth saying so.
      (11) 3.2.1 talks about what the SAVI device does when it boots - is that the only time it is supposed to update the prefix list for transit traffic? That seems wrong.
      (12) 3.2.2 uses the phrase "local prefixes" which doesn't seem to be defined - does that cover prefixes for routers or not?`
      (13) 3.2.2 seems to say that transit traffic received on validating ports is just dropped - that can't be right so maybe the text needs to be rephrased to make it clear what happens. This may be related to (12) above, but I find 3.2.2 just too hard to follow.
      (14) MLD is used without expansion and with no reference.
      (15) End of state machine, p17 - what does "P'==P''" mean here?
      (16) Why are the security considerations talking about the binding anchor being a MAC address when you've ruled that out? The spec needs to be clear about what binding anchor information can be used and not discuss other possible binding anchor information types.
      [The next 3 are from the secdir review by Juergen Schoenwaelder.]
      (17) [secdir#1] My first question was triggered by text on page 8: [...] Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it.
      Now, that sounded like it is easy to DoS new devices simply by generating fake NADV messages. Later in section 3, it seems you only accept NADV messages from trusted ports. If my reading is correct, then a better wording might be: [...] Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host _on a trusted port_ reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it.
      But then I am not sure whether it is really practical to assume that NADV messages always come from a trusted port.
      (18) [secdir#2] My second question concerns the construction of the prefix list. One option is to learn prefixes by listening to Router Advertisements. Is there a way to make SAVI do bad things by announcing bogus prefixes?
      (19) [secdir#3] My third question concerns this statement in the security considerations: The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link.
      The second sentence makes this sound like a non-issue but it seems to be correct only if devices uniformly pick random addresses out of the full 2^64 address space. If for whatever reason I can guess with a decent likelihood an address, it looks like SAVI becomes a tool to help me with denying service for such an address.
      (20) The "Security Logging" section should be changed significantly to say that only suspected spoofing should be logged and that for privacy reasons SAVI MUST NOT otherwise log normal use of the network.
    8. Stephen Farrell: Comment [2011-05-23]:
      (1) I don't understand the sentence at the end of 2.1 "Manually configured IPv6 addresses can be supported by FCFS SAVI, but manual configuration of the binding on the SAVI device provides higher security and seems compatible with manual address management."
      (2) 2.2 says that "non-compliant" packets can be dropped - there's no IESG write-up so I'm wondering if this is safe or if there's any evidence that this would be safe? Has this been implemented and if so have any results of its effects been published? (I know that's not a requirement for PS, but in this case, I think it would be very useful information.)
      (3) 2.3 "prove address ownership" is too strong and I think ownership is the wrong phrase in any case.
      (4) I don't understand "FCFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address." Seems like it needs re-phrasing - "contained the first packet" is the wrong bit.
      (5) The "it" in "CFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address" seems ambiguous. I'm fairly sure it refers to each SAVI instance rather than the set of instances in a SAVI perimeter but that should be made clear.
      (6) State machine ascii art - expanding T.O. to timeout (I guess) would be clearer.
      (7) "MLD considerations" - should you s/relay/rely/?
      (8) From section 4 on there are more English language errors that should be fixed, e.g "The attacks against the SAVI device basically consist on making the SAVI device to consume its resources until it runs out of them" has two (and maybe 3) errors. There are also some similar problems in Appendix A. (I have some marked up on paper so easiest will be if I try to list any that remain if you rev. the I-D.)
      (9) [secdir review nits] Editorial nits:
      - p10: s/because the connect/because they connect/ (twice)
      - p10: s/through validating port/through validating ports/
      - p11: s/prefixes.A/prefixes. A/
      - p13: s/may due/may be due/
      - p13: s/packets has been/packets have been/
      - p18: s/relay/rely/
      - p24: s/coalition/collision/
      - p26: s/case fixed/case of fixed/
    9. David Harrington: Discuss [2011-05-24]:
      There are many points in my DISCUSS, but most are requests to tighten the RFC2119 language, or explain in the text what the valid exceptions are to each SHOULD.
      1) this only deals with ipv6. The charter says ipv4 and ipv6 must be covered. Why doesn't this document also deal with ipv4, and is there another document that deals with ipv4?
      2) in 2.4, "For the rest of the document, we will assume that the binding anchors are ports of a switched network." Having this statement at the end of a paragraph in non-normative background text seems insufficient. To be compliant to this standard, the binding anchors MUST be ports of a switched network. I think this should be clearly specified in RFC2119 langauge in the normative section.
      3) in 2.5, "a secondary goal is to assist in traceability for determining who an improper actor is." I don't see this in the charter, and question whether this is an IETF-supported secondary goal. (I see that Stephen has raised a DISCUSS on this in more detail).
      4) in 3.2.2, "transit traffic and the packet SHOULD be discarded" why only SHOULD? what are the valid exceptions to this?
      5) in 3.2.3, "the SAVI device SHOULD execute the process of sending Neighbour Solicitation messages" s/SHOULD/MUST/
      6) "are NOT forwarded"
      s/are NOT/MUST NOT be/
      s/they are sent/they MUST be sent/
      s/are discarded/MUST be discarded/
      s/is discarded/MUST be discarded/
      s/packet is either stored or discarded/
      - why the choice? Please use RFC2119 language.
      ... the rest of the state table should be in RFC2119 terms.
      s/relay/rely/
      s/must join/MUST join/
      s/SHOULD join/MUST join/
      7) 3.2.4 "SHOULD be connected" - when is it valid to not be connected? should this be a MUST to ensure that transit traffic is not dropped?
      multiple SHOULDs here; why not MUSTs? If SHOULD, what are the valid exceptions?
      8) 3.2.5 "will behave as if
      " - MUST behave as if
      9) section 4, why 4 bindings? where did 4 come from?
      Doesn't this exhuast memory four times faster than an implementation that reserves memory for 1 binding per port? Isn't the reserved memory wasted if the port consistently has only one binding?
      10) "A SAVI device MUST limit the amount of memory" I think this should be a SHOULD. If an implemnter chooses to allocate unlimited memory, they should probably be allowed to. How will this being a SHOULD impact interoperability, as compared to its being a MUST?
      11) "The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link." I don't see how the 2^64 addresses available mitigates the ability of an attacker to create state that would block a valid address.
      12) "the SAVI device can be used as an amplifier by attackers. In order to limit this type of attack, it is RECOMMENDED that the SAVI device performs rate limiting "
      why not MUST?
    10. David Harrington: Comment [2011-05-24]:
      1) in 2.3, "SAVI checks would not be fulfilled by the transit traffic" I think fulfilled might be the wrong word here; do you mean performed?
      2) a stylistic point. The document often uses "This means". This is totally unnecessary. Just say what it means without the "this means phrase". This means don't use this means.
      3) in 2.6, summary, "A SAVI device only verifies packets coming through one interface connected to the untrusted part of the topology." why only ***one interface*** per SAVI device?
      4) in 2.6, "In particular, it is important to avoid that the same source address is bound to different binding anchors in different SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what SAVI is trying to prevent." Is this accurate? Does it necessarily imply there are two hosts?
    11. Pete Resnick: Comment [2011-05-24]:
      Section 2 title - I would prefer to strike "non-normative". I see no reason for it and the use of this expression is turning into an IETF fetish. Instead, you can add on to the the Introduction: "Section 2 gives the background and description of FCFS SAVI, and Section 3 specifies the FCFS SAVI protocol."
      Section 2.6: :Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. If no NADV message is received as a reply to the NSOL, then the local SAVI device will infer that no binding for that address exists in other SAVI device and will create the local SAVI binding for that address. (NOTE that the description included here is overly simplified to illustrate the mechanism used to preserve the coherency of the binding databases of the different SAVI devices. The actual SAVI mechanism normative specification as described in Section 3 varies in the fact that in some cases it is the SAVI device that generates the NSOL while in other cases it simply forwards the NSOL generated by the end host, and that the SAVI device will send multiple copies of the NSOL in order to improve the reliability of the message exchange, among other things).:
      Start with the words, "As a simplified example of how this might work:", and then strike the parenthetical NOTE entirely.
      Section 3 title - strike "normative"
    12. Dan Romascanu: Discuss [2011-05-26]:
      Section 3.2.5 speaks 'the case the SAVI device is a switch that supports VLANs'but provides no reference to what IEEE 802,1 specification it refers and what types of VLAN capable bridges (switches) are covered. Is the intent to cover all types of VLANs defined by IEEE 802.1? Clarification and proper references are required.
    13. Peter Saint-Andre: Comment [2011-05-23]:
      Please expand "DoS" on first use and add an informational reference to RFC 4732.

    Telechat:

  8. Transport Subsystem for the Simple Network Management Protocol (SNMP) (Draft)
    rfc5590
    Token: Sean Turner
    Discusses/comments (from ballot 3799):
    1. Stewart Bryant: Comment [2011-05-25]:
      (blank)

    Telechat:

  9. Transport Security Model for the Simple Network Management Protocol (SNMP) (Draft)
    rfc5591
    Token: Sean Turner
    Discusses/comments (from ballot 3800):
    1. (none)

    Telechat:

  10. Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) (Draft)
    rfc5953
    Token: Sean Turner
    Discusses/comments (from ballot 3801):
    1. Pete Resnick: Discuss [2011-05-23]:
      I'd like to understand this bit of text in the interop report:
      "Neither implementation claims to be a complete, bug-free production ready implementation, and occasional differences have been found noted between the implementations. To date, however, all the differences have fallen into one of these categories:
      - object not implemented yet
      - corner cases not handled yet
      - code needs to be refactored to meet requirement
      In other words, so far all issues are with a particular implementation, not with the specification."
      These are very general statements and I'm simply not clear on how it was determined that this wasn't a specification problem.
    2. Pete Resnick: Comment [2011-05-23]:
      (blank)
    3. Peter Saint-Andre: Discuss [2011-05-25]:
      Much as I would love to believe that changing a bit of text in Section 7 solves the problem of moving SNMP-over-TLS from IDNA2003 to IDNA2008 (and recognizing that I provided that bit of text to the responsible AD!), I fear that it does not. I realize that probably few if any implementations of RFC 5953 have been deployed with internationalized domain names, which might be why the implementation report does not mention IDNs. However, from the standpoint of both protocol development and technology deployment I think there's more work to be done here. I look forward to discussing this on the IESG telechat.
    4. Peter Saint-Andre: Comment [2011-05-25]:
      (blank)
    5. Robert Sparks: Discuss [2011-05-25]:
      1) There are several normative references in this document to RFCs that are not ready to progress to Draft Standard. It's not clear that the parts of those drafts that are used are stable. In particular, this RFC currently references RFC3490 - the RFC Editor note updates the reference to 5890, but did the interop testing cover implementations of this protocol using the techniques in 5890? Would any further changes to IDNA impact what's specified in this draft? Similarly, the draft references RFC5280, which has errata and a clarification draft in progress. Are the parts of 5280 this protocol uses stable?
      2) I believe asking the RFC Editor to issue a new RFC based on the existing RFC and a set of RFC Editor notes is likely to lead to unexpected trouble that could be avoided by processing this as a draft. At a minimum:
      - Is it clear what boilerplate the RFC Editor should use on the new RFC?
      - Who signs off on the new RFC in AUTH48?
    6. Robert Sparks: Comment [2011-05-25]:
      (blank)

    Telechat:

  11. Simple Network Management Protocol (SNMP) Context EngineID Discovery (Draft)
    rfc5343
    Token: Dan Romascanu
    Discusses/comments (from ballot 3802):
    1. (none)

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. xCal: The XML format for iCalendar (Proposed Standard)
    draft-daboo-et-al-icalendar-in-xml-09
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3528):
    1. Adrian Farrel: Comment [2011-05-25]:
      I have no objection to the publication of this document altough I raise a point below that seems to me to be a potntial issue.
      I'm not convinced that this document is completely future-proofed. I understand how future components, properties, and parameters will be converted into XML elements using a designated naming convention.
      But it seems to me that more complex entities (such as multi-valued properties) cannot be simply and automatically handled. Indeed, the need to present a schema in Appendix A (rather than simply define the rules for how it is automatically created) seems to imply that there is a little more work that will be needed when future extensions to iCalendar are made.
      In view of this, I think we need a section specifically discussing extensions to iCalendar. I think that the current Section 5 is a subset of this new section.
      Nit: Section 1: "semantic meaning"
      One of the words is redundant.
    2. Stephen Farrell: Comment [2011-05-26]:
      (1) In 3.6.5 can the date-time element value include TZ offsets? I think it'd be worth being explicit about this and adding a 2nd example with an offset if that's allowed. (It looks from the later examples like this is allowed.)
      (2) In 3.6.8 is INTEGER can be negative, then it'd be worth adding a 2nd example with a negative number.
      (3) In 3.6.11, if UTF8 characters are allowed, then it'd be good to add an example like that, or if that's hard in an RFC, then just say so and if they're not allowed, then just say that to make a coder's life easier.
      (4) In 4.2 when it says "IANA, non-standard, inline encoding..." should there be a reference to make it easier for an implementer to figure out what this means?
    3. Pete Resnick: Comment [2011-05-23]:
      - You claim that round-tripping is a design goal. I'm wondering about the base64 and folding round-tripping. The document clearly takes into account cases of iCalendar objects that have unnecessary base64. Is it at all problematic that this will not round-trip according to the rules you set out?
      - Instead of "the table is a non-normative reference", how about "the table gives examples of ...". The words "non-normative reference" have a specific meaning in RFCs and there is no "referencing" going on here. If you really need to call out that these tables are not normative, say something in section 2 like "The examples given in the tables throughout this document, along with the schema in Appendix A and examples in Appendix B, are not authoritative, and if there is a conflict between these and the definitions given in sections 3 and 4, the definitions in section 3 and 4 are to be taken as authoritative."
    4. Sean Turner: Discuss [2011-05-19]:
      #1) Sec 3.1: Do you need a normative reference to the Base64 RFC: http://datatracker.ietf.org/doc/rfc4648/? Also do you need to specify which alphabet you're using?
      #2) Sec 3.2: r/is an optional/is an OPTIONAL ?

    Telechat:

  2. Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) (Proposed Standard)
    draft-josefsson-gss-capsulate-05
    Token: Stephen Farrell
    Note: Alexey Melnikov (alexey.melnikov@isode.com) is the document shepherd.
    Discusses/comments (from ballot 3789):
    1. Russ Housley: Discuss [2011-05-24]:
      The introduction to this document says: "The intention is that text from this specification should be possible to use for implementation documentation, and for this reason this entire document should be considered a code component."
      Claiming that the whole document is a code component is inappropriate. However, I have no objection to claiming that Sections 3, 4, and 5 are code components.
    2. Pete Resnick: Comment [2011-05-23]:
      The writeup says that there are 3 implementations. Are they independent? Is there any sense in which the interoperate? The "interoperate" question is the really important one to me: I'm trying to figure out why a PS is being used for an API. Is there some way in which having the same API will make things interoperate better?
    3. Peter Saint-Andre: Comment [2011-05-23]:
      This document seems more Informational than Standards Track to me, but I have no objections to publishing it as a Proposed Standard.
    4. Robert Sparks: Comment [2011-05-25]:
      I agree with Russ' discuss regarding what portion of the document is a code component.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples (Informational)
    draft-ietf-xcon-examples-08
    Token: Robert Sparks
    Note: Alan Johnston (alan.b.johnston@gmail.com) is the Document Shepherd
    Discusses/comments (from ballot 3539):
    1. Adrian Farrel: Comment [2011-05-24]:
      I am ballotting "No Objection" after only a light skim of the document, mainly trusting the RAI ADs to have checked this document. However, I do wonder whether one sentence in the Abstract is open to misinterpretation. It says:
      "The objective is to provide a base reference for both protocol researchers and developers."
      That sounds like the flows in this document form part of the normative definition of the protocol. This is presumably not the intention of this Informational I-D. You can resolve this simply by moving that sentence from the Abstract to the Introduction and qualifying it by deferring to I-D.ietf-xcon-ccmp.
    2. Russ Housley: Comment [2011-05-24]:
      The Gen-ART Review by Francis Dupont on 5-Mar-2011 suggested several editorial changes. Please consider them.
    3. Pete Resnick: Discuss [2011-05-26]:
      It's not clear to me why RFCs 3261, 4579, 4597, 4575, 5567, and draft-ietf-xcon-common-data-model and draft-ietf-mediactrl-call-flows are not all normative references. As far as I can tell, these are all required reading to understand this document.
      [I will likely clear this next one immediately, but I'm leaving here because I want to discuss this in the context of the other two xcon documents] I'm again worried about text that is common between documents, especially section 4 of this document. In particular, the information in 4.2 looks like it should be in section 9 of draft-ietf-xcon-ccmp.
    4. Pete Resnick: Comment [2011-05-26]:
      (blank)
    5. Sean Turner: Discuss [2011-05-24]:
      Two issues related to passwords:
      a. Is it <password> or <conference-password>? It's <password> in 6.2 message 1? Where is that defined? It's not in 4575, or any of the other two xcon drafts on the telechat this week.
      b. Should these be exchanged over HTTPS!?
    6. Sean Turner: Comment [2011-05-24]:
      There's a couple of places where Alice's xcon-userid: is alice@example.com and not Alice@example.com. Not sure if you did this on purpose or not.

    Telechat:

  2. Use Cases and Requirements for SIP-based Media Recording (SIPREC) (Informational)
    draft-ietf-siprec-req-10
    Token: Gonzalo Camarillo
    Note: John Elwell (john.elwell@siemens-enterprise.com) is the document shepherd.
    Discusses/comments (from ballot 3753):
    1. Stephen Farrell: Discuss [2011-05-25]:
      I think this is a bunch of what should be fairly easily resolved things.
      (2) I don't understand REQ-025's statement about the "same or different" encryption keys, and I suspect that the requirement, as stated, might lead to bad designs, e.g. adding bad key export APIs to products. I think stating this in terms of keys is mistaken, it should probably be stated in terms of restricting access to the media (or something like that, not sure).
      (4) What non-repudiation requirements exist here? Put another way, who is expected to repudiate what, and how is that supposed to be prevented? Including NR might lead to significant complexity if not fairly tightly constrained. I'd suggest just dropping mention of NR, unless there are specific requirements known at this point.
      (5) The security considerations says: "Means for ensuring the integrity and correctness of media and metadata emitted by an SRC are outside the scope of this work. Other organizational and technical controls will need to be used to prevent tampering." That however, seems to conflict with REQ-029 at least. Perhaps something else was meant, or I'm just confused?
    2. Stephen Farrell: Comment [2011-05-25]:
      (1) "Furthermore, the scale and cost burdens vary widely, in all markets, where the different needs for solution capabilities such as media injection, transcoding, and security-related needs do not conform well to a one-size-fits-all model." That could do with being rephrased, I had to read it a few times before I got the message that one size doesn't easily fit all.
      (2) In figure 2, I assume that time runs from left to right but you might want to say that, e.g. add "t --->" at the bottom. If its meant to be something else, then you definitely want to say what.
      (3) REQ-005 - I think the "without loss of media" refers to the RS but not the CS - is that right? Maybe worth clarifying.
      (4) Just asking: REQ-019 is good, but was there any discussion about how much information to make available to a UA? E.g. whether or not card numbers won't be recorded.
    3. Peter Saint-Andre: Comment [2011-05-23]:
      REQ-012 refers to "the identities of parties involved". The term "identity" is vague. I suggest changing "identities" to "identifiers" or, even better, "SIP identifiers" or "SIP addresses".
      In REQ-024, what is "wall clock time"?
      Regarding terms such as "authentication", "confidentiality", "encryption", and "integrity" in REQ-025 through REQ-032, an informational reference to RFC 4949 seems appropriate.

    Telechat:

  3. MRT BGP routing information export format with geo-location extensions (Informational)
    draft-ietf-grow-geomrt-02
    Token: Ron Bonica
    Note: Christopher Morrow (christopher.morrow@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3763):
    1. Stewart Bryant: Comment [2011-05-23]:
      6. Security Considerations: "This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields that are of a descriptive nature and provide information that is useful in the analysis of routing systems. As such, the author believes that they do not constitute an additional security risk. It is recommended that the operators of the BGP collector and Peers consider their own privacy concerns before supplying geographical coordinates in MRT dumps."
      Comment: Isn't there also an enhanced threat in revealing to a physical attacker the precise geographical location of a strategic router?
    2. Ralph Droms: Comment [2011-05-26]:
      I agree with other points raised about revealing physical location, and I have a couple of additional questions:
      1. How does the BGP collector obtain the geolocation of its peers?
      2. From section 8: "It is recommended that the operators of the BGP collector and BGP peers consider their own privacy concerns before supplying geographical coordinates to BGP data collection systems."
      Depending on the answer to 1, how does the BGP peer control how its geographical coordinates are supplied to the BGP collector?
    3. Wesley Eddy: Comment [2011-05-24]:
      Support the other ADs DISCUSS positions on Informational vs. Standards Track
      Further, the security considerations should at least mention the fact that there's no way to prevent someone from lying about location data, yet would appear to have no bearing at all on BGP operation. It might totally mess up any later analysis someone is trying to use the MRT data for as they'd have little way to validate historic coordinates for a given router.
    4. Adrian Farrel: Discuss [2011-05-24]:
      draft-ietf-grow-mrt is Standard Track. I don't understand why this I-D (which defines further protocol extensions) is Informational.
      Given that "This document extends the Border Gateway Protocol (BGP) Multi-threaded Routing Toolkit (MRT)..." I don't see why there isn't an "Updates" statement in the header.
      draft-ietf-grow-mrt appears to create an IANA registry to track subtypes. Why does this document not include IANA actions for the new subtype that it defines?
      Note that the allocation procedures in draft-ietf-grow-mrt are "IETF Review" so you would be OK if this document does stay as Informational, but you would still need an IANA section.
    5. Adrian Farrel: Comment [2011-05-24]:
      I agree with Stewart's point about physical security, and suggest that you should highlight the point.
    6. Stephen Farrell: Comment [2011-05-23]:
      - MRT is not expanded.
      - Good luck with the PhD/hope it went well:-)
    7. Russ Housley: Discuss [2011-05-24]:
      The Gen-ART Review by Roni Even on 16-Apr-2011 included two questions. These questions were asked in a Last Call comment, but the questions were not answered. I would like to know the answers.
      1. Why not include it in draft-ietf-grow-mrt?
      2. Why is this Informational RFC and not standard-track like draft-ietf-grow-mrt?
    8. Russ Housley: Comment [2011-05-24]:
      Please expand MRT when first used.
    9. Pete Resnick: Discuss [2011-05-24]:
      This can either be Standards Track or Experimental. It's not Informational. It's extending a Standards Track protocol.

    Telechat:

  4. SAVI Threat Scope (Informational)
    draft-ietf-savi-threat-scope-05
    Token: Jari Arkko
    Note: Jean-Michel Combes (jeanmichel.combes@gmail.com) is the Document Shepherd.
    Discusses/comments (from ballot 3793):
    1. Stewart Bryant: Comment [2011-05-23]:
      A useful document which I enjoyed reading
    2. Ralph Droms: Discuss [2011-05-25]:
      I will raise a meta-discussion issue before listing several specific Discuss points. This issue may be just the suppressed pedantic ex-professor side of my personality expressing itself. My issue is that the contents of this document are useful and not incorrect. However, in my opinion the document would be more useful, especially to someone who reads this document without a lot of background in the type of threats described, with some additional detail. I could be persuaded that I am being overly pedantic, in which case I will clear my Discuss and move my points to Comments. I will be happy to send text if the authors would find it helpful.
      1. In section 1: "At the IP Network Layer, or Internet Layer, there is typically no required transactional state when communicating with other hosts on the network. Hosts generating packets for transmission have the opportunity to spoof (forge) the source address of packets which they transmit."
      I think this paragraph needs more detail to connect the first sentence with the last sentence.
      2. Next paragraph: "Source address verification is necessary in order to detect and reject spoofed packets and contribute to the overall security of IP networks. In particular, source address verification techniques enable detection and rejection of spoofed packets, and also implicitly provide some assurances that the source address in an IP packet is legitimately assigned to the system that generated the packet."
      "Source address verification" can be used or is necessary? You haven't told us what source address verification is, yet. The second sentence in this paragraph doesn't seem to add any new information. What would be more helpful would be a sentence or two foreshadowing the details in section 3. Why are packets with spoofed addresses dangerous?
      3. The attacks in section 3 fall, roughly, into two buckets: those that require spoofed source addresses and those that can use spoofed addresses to obfuscate the source of the attack. SAVI can eliminate the former but only deter, through threat of discovering the perpetrator, the latter. The difference is important to someone using this document to learn about how SAVI contributes to security in a network. Otherwise, a network administrator might expect to eliminate all of the listed attacks with SAVI.
      An improvement would be to explain the two types of attacks and indicate the type of the attacks in section 3.
      4. I found the second sentence of the first paragraph of section 4 very hard to parse and not entirely consistent with the title of the section. While most of the solutions in section 4 have to do with the network topology, the first bullet:
      "o The IP source address is appropriate for the lower layer address (they both identify the same system)"
      has nothing to do with network topology.
      The second bullet:
      "o The IP source address is appropriate for the device at the layer 2 switch port (the address was assigned to a, and perhaps the, system that uses that port)"
      does use network topology, but seems specific to wired networks; in fact, later in section 4, wireless networks are mentioned as using different techniques. Might be better to write:
      "o The IP source address is explicitly identified as appropriate for the physical topology; for example, the source address is appropriate for the layer 2 switch port through which the datagram was received"
      5. Section 4.1.1 changes in mid-section from checking the IP address against the Link Layer address to checking the IP address against the physical attachment point. Is Link Layer address checking ever implemented on switches or is it always IP address checking versus the physical attachment point?
      6. I suggest augmenting section 4.1.3 with a mention of IPv6 prefix checking, where the PE can be populated with the customer prefix through monitoring DHCPv6 prefix delegation.
      Also, the enterprise case can be augmented with prefix filtering based on the prefixes known by the ISP to be assigned to the customer.
      7. Sections 4.1.5 either needs more detail or pointers to references where more detail is available. In its current form, it has little or no content. The interesting parts of DOCSIS are the authentication and trust model, in which the ISP can control and trust the cable modem.
      8. Section 4.1.6 has more detail than section 4.1.5, but assumes some experience with DSL deployments and architectures. Both of these sections would benefit from some explanation of the accountability model in which packets can be traced to an accountable entity, regardless of the specific address or prefix in the source address of a packet.
      9. Section 4.2.3.2 might benefit from just a little more detail, or a pointer to more detail:
      switch uses IP address to port binding
      switch enforces restrictions that DHCP server traffic is only accepted from "upstream"
      switch monitors DHCP traffic to glean address-port bindings
      This technique works for both IPv4 and IPv6.
      And, the discussion of SLAAC brings up the issue of authenticated SAVI versus "ad hoc" SAVI. In the case of DHCP based SAVI, the switch can have authoritative information about the address/port binding, because it came from a reliable source (DHCP server). SLAAC-based SAVI can only identify claimed addresses, where the hose may not be authorized to use the claimed address.
      10. Are the techniques mentioned in 4.2.4 really SAVI?
      11. What is a "residual attack" and how does the text in section 4.2.5 describe a residual attack?
    3. Ralph Droms: Comment [2011-05-25]:
      1. Add DoS (yeah, I know DoS is pretty widely used already), "binding anchor" (and use "binding anchor" through the document), MITM, LAND, smurf attack, uRPF to section 2. Some of these also have first-use expansion, which might be OK ... this suggestion is just a Comment.
      2. Suggestion: it would be more useful to incorporate any issues specific to IPv6 in the body of the document.
      3. First sentence of section 4: "The first requirement is to eliminate datagrams with spoofed IP addresses from the Internet."
      First requirement for what? I thought this document was exactly about "eliminat[ing] datagrams with spoofed IP addresses from the Internet." I suggest dropping the sentence.
      4. At the end of section 4, the bullet list calls out "enterprise CPE Router" explicitly. Aren't residential CPE routers also a big opportunity? How are they different from enterprise CPE routers. In fact, perhaps "CPE" is not the best term? How about "Enterprise edge router" and add "subscriber home router"?
      5. At the end of section 1, have the strength of your convictions: "This document provides [...], and discusses [...]."
      6. For consistency, in sections 3.2.1 and 4.1.1 s/MAC address/Layer 2 address/
      7. Is "source address verification" equivalent to "Source Address Validation Improvement (SAVI)"? If so, for consistency use one phrase or acronym throughout.
    4. Wesley Eddy: Comment [2011-05-24]:
      The document looks good, I just have a few comments that the authors might think about:
      Section 3.1.7 is titled "other blind spoofing attacks" but talks about non-blind attacks just as much. The example given of a host on-link with routers is non-blind, for instance. However, seciton 3.2 is where non-blind attacks are supposed to be discussed, so this part of 3.1.7 seems rather odd.
      Why isn't the relationship to SeND discussed in this document?
      VPN gateways have similar considerations as the Mobile IP HA in sectino 5.2.6, but VPN gateways don't appear to be discussed in 5.2.
    5. Stephen Farrell: Discuss [2011-05-26]:
      (1) What's the difference between "validation" (abstract) and "verification" (overview, 3rd para) as used here? If there is none, then just use one. If this is a difference, then where are these defined? I think in either case, some definition is needed.
      (2) I expected this document to also analyse source-address spoofing threats after SAVI mechanisms are deployed. If some simple form(s) of source address spoofing will work regardless of which SAVI mechanism(s) are in place then one would have to wonder if SAVI is worth deploying or not. If this is not the right document to cover that then what is? The fact that the SAVI mechanisms will each be in separate documents would seem to mean that this question won't otherwise be answered by the WG, and I think we do need an answer somewhere. (The security considerations of the SAVI framework is currently one paragraph so that's not the place, at least not now.) Its probably worth noting that this issue is behind a number of cases below where I ask for evidence to justify what appear to be overly broad claims made.
      (3) What is the evidence that "Source address verification is necessary in order to detect and reject spoofed packets"? I'm asking why this is "necessary" as opposed to sufficient (if it is sufficient - see (2) above).
      (2) This presumably needs some form of qualification if not all packets with spoofed source addresses can be spotted: "source address verification techniques enable detection and rejection of spoofed packets." I'm not sure if "some spoofed packets" would be a good thing to say there but it does seem to be the case - a better qualification (or a forward reference to where that is described) would represent truth-in-advertising.
      (3) Where in the charter is "local traceability" in scope? The charter does say that "tracking other protocols is not in scope" so local traceability needs to be defined as something limited to/scoped to spoofed source addresses.
      (4) "For example, when an enterprise receives a report of an attack originating within that enterprise, the operational staff needs to be able to track from the IP address sourcing the attack to the particular machine within the enterprise that is the source." I don't think that's true in general - "needs" is wrong since there can be other ways to find a zombie.
      (5) Spoofing is defined to cover both IP and MAC address spoofing. SAVI does not address the latter I believe (right?). If so, then I think you need to separate these as otherwise confusion between them might lead to incorrect conclusions being stated. Spoofing is also defined as "forging" but that is not defined and could be considered to be synonymous with "spoofing" here which would make this a circular definition. I think the definition of spoofing needs to be more precise basically.
      (6) 3.1: " The result is that they have no access to legitimate source and target systems." I think that's wrong - are you trying to say that "The attacker in this case should have no legitimate access to source and target systems."
      (7) Does the ARP example in 3.2.1 really involve a spoofed IP source? If not, then you should note that its not in scope for SAVI. If it is, then say why its in scope.
      (8) I'd be interested in knowing if SAVI can help with 3.2.2 - if not then saying so would be right. If so, then saying when SAVI might help would be good.
      (9) If "The first requirement is to eliminate datagrams with spoofed IP addresses from the Internet." then SAVI would seem to be facing an impossible problem. The "can eliminate such datagrams" part also seems overstated - where's the evidence that that's true? s/eliminate/reduce/ would seem to be more correct.
      (10) Saying that "Internet devices can...confirm...that the IP address is appropriate for the lower layer address" is not true of all "Internet devices" only for some near the source, so that's also overstated and needs to be qualified. (It is later to be fair but the statement itself is wrong.)
      (11) I don't know the answer here, so this is just a question - what is the likelihood the uRPF check works well? (I didn't find the string uRPF in RFC 3704, so I'm not sure, but I didn't really read 3704;-) I guess the real question is whether a failure in uRPF might break anything for a non-spoofing host and whether a spoofing host could make it so that uRPF checks allow the packet with a spoofed address through (from e.g. the same subnet, or for certain guessable source addresses). I ask (in part) since 4.2.2 says that uRPF is a crude mechanism.
      (12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope for SAVI. Can you make that clear?
      (13) What does "unforgeable" mean in 4.2.3? Perhaps you need to define that term as well? It may be that the meaning differs for e.g. MAC addresses and other credentials (noting that passwords can be guessed or shared of course).
      (14) In 4.2.3 where is the evidence that "a large portion of the ...threat space...can be marginalized" - I think that needs some qualification.
      (15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically provide sufficient binding information" - is there evidence for that somewhere? Be good to reference it.
      (16) 802.1X determines the identity of a user, not a system I think.
      (17) I think 4.2.5 needs to better characterise the "residual threat" (not "residual attack") - for each of the various forms of SAVI. I had hoped this document would say what spoofing possibilities remain. Providing just one example doesn't seem sufficient.
      (18) Section 6 (at least) should also recognise that there are privacy considerations that apply and that more-or-less directly run counter to the ability to trace the source of problems.
      (19) Section 8 should note that circumstantial evidence linking a person to an IP address can be dangerous for the person. There have been cases where such tracking has mis-identified people responsible for some act. (I don't have a reference to hand sorry.)
      (20) If no set of deployed SAVI instances can prevent all spoofing from a given network then an attacker could probe the network to find out what spoofing works from where they are at, and then use that. Success in spoofing would then likely have more consequences for an innocent spoofed party. This would be a new threat caused by SAVI itself.
      (21) If binding anchors are personally identifying or stable over time or location then recording those creates new threats for tracking the user or host associated with the binding anchor. That needs to be noted.
    6. Stephen Farrell: Comment [2011-05-26]:
      (1) 2nd para of overview says that there is "typically no required transactional state when communicating with other hosts on the network." I think it'd be good to say why that's the case, via a reference to something. Not sure what reference is best exactly.)
      (2) What is a "better Internet participant"? It sounds like a scary thing.
      (3) s/This both that the information be useable/This requires both that the information be useable/
      (4) I expected to see some CVE references in section 3 but didn't see any. I'd encourage adding some of those for each of the threats covered since that should help motivate the work and would demonstrate that there are real threats to mitigate. (E.g. a quick search on "CVE spoofed source" throws up a bunch.) To take one example, 3.1.4 could do with such a reference.
      (5) Expand "LAND"
      (6) The DNS attack described around the top of page 9 isn't relevant to SAVI, right? Maybe the smurf attack is enough there.
      (7) Do 3.1.6 and 3.1.7 really fit in 3.1?
      (8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do.
      (9) Even IPsec doesn't unquestionably verify source address if load-balancing is in place with private key sharing.
    7. David Harrington: Comment [2011-05-23]:
      I found this document to be very informative about the problem space. I think this document could have been far more effective if the text didn't meander around the points it was trying to make; it could habve been far more succinct. Here are some suggestions that I think could improve the document.
      1) I find the following ambiguous, "the operational staff needs to be able to track from the IP address sourcing the attack to the particular machine within the enterprise that is the source. " I think the intention is that "the IP address sourcing the attack" means the spoofed address, and "that is the source" means the actual sending machine, but I'm not sure. This can be read as "the staff needs to track from the source to the source."
      2) This sentence doesn't parse properly, "This both that the information be useable ..." I think the sentence is missing "means" or "requires" or something.
      3) The glossary should include references to the defining documents.
      4) "or order to disrupt" -> "in order to disrupt"
      5) 3.1.3 doesn't describe what a poison attack is. It also refers to "the same kinds of poisonings as above", but above never spoke of poisoning attacks.
      6) the following seems a bit perverted logic - a malware attack is important because it is a justification for SAVI?
      "This attack is important both in terms of an attack vector that SAVI may help prevent, and also as a problem which SAVI can help track back to find infected systems. "
      Shouldn't you be arguing that savi is important for preventing these types of attacks?
      7) section 3.2.2 "Another example of sighted attack" - this is the first mention of "sighted attack". Please use consistent terminology.
      8) in section 3.2.2, "The use of spoofed addresses, while not necessary for this, can often provide additional information, and helps mask the traceability of the activity." would seem to be the conclusion of the paragraph, but this precedes the discussion of what the attack is.
      9) in scetion 4, "the first requirement" isn't followed by any further requirements. and is this section going to describe the requirements or the solutions?
      10) "The IP source address is appropriate for the lower layer address (they both identify the same system)". I find "is appropriate" too ambiguous, although the following parenthetical text explains it. I suggest this would be better written as "the IP source address and the lower layer address both identify the same system."
      11) "The IP source address is appropriate for the device at the layer 2 switch port" I find "is appropriate" too ambiguous.
      " (the address was assigned to a, and perhaps the, system that uses that port) " doesn't parse appropriately. I think this bullet needs a better description.
      12) section 4.1.1 "Port identification prevents transmission of malicious datagrams" Is this true? or is port identification one method that can be used to help prevent transmission?
      13) 4.1.3 "An obvious special case of the discussion is with an ISP PE router, " - what discussion? This section seems based on speculation about possible solutions, including contract negotiations. I think this would be much better if it actually focused on technical solutions for validating addresses for ISP edge routers.
      14) 4.1.4 again discusses business agreements between two conpanies. Please focus on ***technical*** solutions at this topological location.
      15) 4.1.4 "However, when it can be shown that spoofed addresses are present, the procedure can be applied. " what procedure?
      16) 4.2.5 is entitled residual attacks, but there is no discussion of residual attacks in the paragraph. The hand-waving contained in the paragraph doesn't seem worth documenting.
      17) why is 4.2.5, "residual attacks", included in section 4 "Current anti-spoofing solutions"?
      18) 5.2.6 what does "proper member" mean? where is this defined?
      19) 5.2.7 - doesn't this sum up the whole section 5? since it includes anything not covered in 5.1 or 5.2, shouldn't this be 5.3?
      20) is 5.3 about topological challenges? it seems to meander on about additioonal capabilites, rather than discussing the topological challenge to SAVI.
    8. Russ Housley: Discuss [2011-05-24]:
      The Gen-ART Review by David Black on 12-May-2011 lead to a discussion with one of the authors. At the end of the discussion, several changes to the document were agreed. However, those changes have not been made.
    9. Dan Romascanu: Comment [2011-05-25]:
      I find the document comprehensive but I share DBH's observation that it's a little too verbose and could use some fixes in the details.
      Beyond what he found I have a few more observations. None is critical for this informational document, but cleaning up all these text unclarities in a new version would be recommended;
      1. In the Glossary section: "NNI Router: Network to Network Interface Router. This router interface faces a similar system operated by another ISP or other large network."
      I think that the definition should read something like 'A router with interfaces facing a similar system ...'
      2. Section 4.2.3.3: "IEEE 802.1x is an authentication protocol that permits a network to determine the identity of a system seeking to join it and apply authorization rules to permit or deny the action. In and of themselves, such tools confirm only that the user is authorized to use the network, but do not enforce what IP address the user is allowed to use. It is worth noting that elements of 802.1x may well be useful as binding anchors for SAVI solutions."
      This is quite confusing. IEEE 802.1X is a port (in the sense of bridge or layer 2 switch) access control standard that controls the joining of devices to a layer 2 bridged network. The term 'tools' is not in place and there is nothing about the 'user' in the protocol itself but about the device - the standard uses the term 'supplicant' which is rather the device or the piece of software running on the device that presents credentials to an authenticator.
      3. In section 5.2 'hosts connected to switch ports that may have one or more IP addresses' is probably rather 'hosts that may have one or more IP addresses connected to (layer 2) switch ports'
    10. Peter Saint-Andre: Comment [2011-05-23]:
      Please expand "DoS" on first use and add an informational reference to RFC 4732.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC) (Informational)
    draft-giralt-schac-ns-05
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3255):
    1. Stephen Farrell: Comment [2011-05-21]:
      (1) Some examples would be nice.
      (2) https://urnreg.terena.org/ doesn't seem to currently have anything very human readable. Be good to fix that before the RFC issues.
    2. Sean Turner: Comment [2011-05-20]:
      #1) I followed the MACE link and got a 404 error. Maybe this one instead: http://middleware.internet2.edu/urn-mace/ or you could point to RFC 3613?
      #2) Sec 2: I compared the SCHAC-NSS and MACE-NSS. The only difference is as follows: "..."
      I assume they evaluate to the same thing?
      #3) A couple of nits on the last paragraph of Section 3: "..."
      Normally, I'd say point to RFC 2818 for HTTP over TLS (i.e., HTTPS), but I guess you might be trying to make people use TLS 1.2? What about the following: "..."
      Replace [11] with 2818 instead of 2616 because 2818 points to 2616.
      #4) Because of the MUST(s) in the last paragraph references [11] and [12] are now normative.

    Telechat:

  2. ForCES Implementation Experience Draft (Informational)
    draft-haleplidis-forces-implementation-experience-02
    Token: Adrian Farrel
    Note: AD Sponosred Submission for publication as an Informational RFC
    Discusses/comments (from ballot 3788):
    1. Jari Arkko: Comment [2011-05-26]:
      2. NAT issues. ForCES can be deployed everywhere and can run over SCTP/IP. In order for the FE and CE to work behind NATs you must ensure that the TML ports are forwarded and that the firewall allows SCTP through.
      This seems to be mixing NAT and firewall issues. Clearly, support NATs requires for those NATs to be capable of handling SCTP traffic to begin with. In addition, firewalls may have to be configured to let the traffic through.
      I found Section 3.3 very hard to understand for someone who is not closely familiar with the Forces technology.
      I don't understand why we need sections that talk about very generic topics, like 3.4.2 that describes how to decode a protocol message.
      And maybe more generally, I'm not sure what I learned from this document in terms of real forces implementation experience. Where are the difficult areas? Is the spec broken in places? Are there interoperability problems? Is further work needed in some issue?
    2. Stewart Bryant: Comment [2011-05-23]:
      "Developers of ForCES FEs and CEs should take the security considerations of the Forwarding and Control Element Separation Framework [RFC3746] and the Forwarding and Control Element Separation Protocol [RFC5810] into account."
      Why is this a should and not a must?
    3. Ralph Droms: Comment [2011-05-26]:
      In this text: 3.3. Model: "The model inherently is very dynamic."
      What "model"? The Forces data model?
      More generally, I agree with Jari's comment about the content of the document. I learned a little about potential issues in implementing the struct component (but no details). Are there any other major implementation issues aside from struct components and handling protocol messages?
    4. Stephen Farrell: Comment [2011-05-23]:
      s/difficulty lie/difficulty lies/
    5. Russ Housley: Comment [2011-05-24]:
      The Gen-ART Review by Francis Dupont on 9-May-2011 suggested several editorial changes. Please consider them.

    Telechat:

  3. Data Tracker States and Annotations for the IAB, IRTF, and Independent Submission Streams (Informational)
    draft-hoffman-alt-streams-tracker-14
    Token: Russ Housley
    Discusses/comments (from ballot 3805):
    1. Stewart Bryant: Discuss [2011-05-23]:
      The Independent stream need a rejected (sub)state.
      The "no longer in ISS" state as it stands seems to leave open the posibility of a DOS attack by resubmitting the same text.
      ISE "On hold" looks like it needs a sub state to deal with the case where it is desirable to sequence a WG document ahead of an ISE document but otherwise there is no objection
    2. Stewart Bryant: Comment [2011-05-23]:
      There should be a security note stateing that putting April 1st IDs in the tracker would be damaging to their purpose.
    3. Peter Saint-Andre: Discuss [2011-05-23]:
      I intend to ballot "Yes" on this document. However, as discussed within the IESG, this document needs some text making it clear that the IETF Data Tracker is not (or, upon approval of this document, will not be) limited to the IETF stream. I suggest adding the following note after the third paragraph of the Introduction.
      "Note: The term "IETF Data Tracker" is used as a generic name for the existing tool used to track state changes as Internet-Drafts are processed before hand-off to the RFC Editor. The word "IETF" in the name "IETF Data Tracker" is not meant to limit use of the tool to the IETF document stream; this document expands use of the tool to the other streams described in [RFC4844]."
    4. Robert Sparks: Discuss [2011-05-24]:
      Section 7 should be filed as a bug against the tracker and be removed from this draft before publication as an RFC.
      The intent of this document (and the other recent tracker requirements document) is to inform an initial development effort. I don't believe they were intended to stand as the requirements against a running tracker, being updated frequently and gathering errata. It would probably help to say that explicitly.
      Specifically, I don't think it's a good idea to have to update the RFC this becomes to change the Subject line or contents of a notification email. Further, I don't think updating this RFC (or the related ones) is the right tool to use to refine the states defined in the tracker as experience with them tells us we need new ones.
    5. Robert Sparks: Comment [2011-05-24]:
      It would help to explicitly state that a document can't be in more than one stream at the same time. In particular, it can't be in the Candidate/Submission received states of more than one stream at the same time. It would probably be useful to the implementer to call out this includes the streams not covered in this document.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

no break

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Open Authentication Protocol (oauth)
    Token: Stephen

    Telechat:

  2. IPv6 Site Renumbering (6renum)
    Token: Ron

    Telechat:

4.1.2 Proposed for Approval

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

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Transport Layer Security (tls)
    Token: Sean

    Telechat:

  2. Transport Area Working Group (tsvwg)
    Token: David

    Telechat:

4.2.2 Proposed for Approval

  1. Softwires (softwire)
    Token: Ralph

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Request for designated expert for RFC5971 registry [IANA #397263] (Michelle Cotton)

    Telechat:

  2. Request for designated expert for RFC5308 registry [IANA #148437] (Michelle Cotton)

    Telechat:

  3. Lessons from draft-palanivelan-bfd-v2-gr (Adrian Farrel)

    Telechat:

  4. Request for assistance with character set requests (Michelle Cotton)

    Telechat:

  5. Late IPR related to draft-ietf-netext-redirect-07 (Russ Housley)

    Telechat:

  6. IENG statement on processing of RFC errata concerning RFC metadata (Stewart)

    Telechat:

7. Agenda Working Group News

1417 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-05-26 07:30:04 PDT)

draft-ietf-xcon-common-data-model

  1. Jari Arkko: Comment [2011-05-24]:
    This was an overall OK document. I did have a few small question marks, however:
    
    I am wondering if <language> can contain multiple languages or appear multiple
    times. The text says nothing exact but seems to indicate just one language. Some
    of the schema definitions seems to say that multiple languages can appear.
    Please clarify and align.
    
    Then I had a question on this:
       In order to facilitate the comparison of the XCON-USERID identifiers,
       all the components of the identifiers MUST be converted to lowercase.
       After normalizing the URI strings, the URIs comparison MUST applied a
       character-by-character basis as prescribed by RFC3986, Section 6.2.1.
    
    Question: is this sufficient to deal with internationalized user identifiers?
    I'm about as far as one can be from an i18n expert, but I thought there were
    situations were you'd have to map characters to other characters in order
    to do proper comparisons. Maybe that's not needed for user identifiers.
    Please check.
    
    Can notifications come after the end of the conference,  too? 
    The data type is integer, not NonNegativeInteger:
    
                  <xs:element name="notify-end-of-conference"
                    type="xs:integer" minOccurs="0"/>
    
    Please clarify and ensure you meant all integers.
    
    Are mixing start offsets really absolute time values? By their name, I was
    expecting an offset not an absolute value. Either approach is fine with me, of
    course, but perhaps the document needs to say explicitly that the offsets are
    actually absolute values and not differences to the start/end time.
    
           element xcon:mixing-start-offset {
             time-type,
             attribute required-participant { single-role-type },
             anyAttribute
           }?,
    
  2. Stewart Bryant: Comment [2011-05-23]:
    On the basis of trusting that others who have greater knowledge of this subject
    matter have reviewed this document I am voting no-objection.
  3. Adrian Farrel: Comment [2011-05-26]:
    There are enough detailed Discuss points from other people that I can't find
    much to add.
    
    Please note that you should not include references from the Abstract which is
    supposed to be stand-alone text.
    
    I was a little surprised that there isn't an Informative reference to draft-
    ietf-xcon-ccmp.
    
    Is http://www.relaxng.org/ the right reference to give for Relax NG given that
    it is published as an international standard by ISO?
  4. Stephen Farrell: Discuss [2011-05-24]:
        (1) I agree with the secdir reviewer (Tero Kivinen) [1] that passwords
    and personally identifying information do warrant specific protection
    in the DB. The security considerations seems to nearly, but not quite
    do this, when it says that the DB SHOULD be accessed via TLS or
    equivalent. However, I think you need two more things: a) to say when
    its ok to not follow the SHOULD but also b) you need to RECOMMEND that
    the (sensitive parts of the) DB be encrypted as stored in long term
    storage (i.e. disk) which is different from how its accessed via the
    network.
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html
    
    (2) I would think that conference object identifier URIs (and maybe
    also other URIs that are not typed by people) MUST or SHOULD be
    unguessable. The reason is that this provides a defence-in-depth for
    cases where e.g.  TLS is not used when it ought be etc. Basically, if
    a URI is unlikely to be typed by a person, then it seems best to make
    sure they're unguessable and since this is something that
    implementations often get wrong this would seem like a good place for
    that statement.
    
    (5) 4.2.12 What does "set by an administrator" mean for a data model?
    How could I tell by looking? If it said "typically set..." that'd be
    fine but it currently reads like normative text.
    
    (7) Section 6 says "The IETF MAY extend the data model schema..." What
    does that mean? Why the 2119 MAY? Is a standards-track document
    needed, or informational, what about ISE/IRTF or other streams?
    
    (8) Security considerations: what does "There is no other encoding
    considerations for XCON-USERID or XCON-URI not discussed in RFC 3986
    [RFC3986]." mean? I don't get it anyway. 
     
        
  5. Stephen Farrell: Comment [2011-05-22]:
    (1) Typo: "the URIs comparison MUST applied a character-by-character
    basis"
    
    (2) In 3.2.2 if you don't want IP addresses to be used, then why not
    just say so? Maybe add text that says that xcon:foo@10.0.0.1 is not
    the same as xcon:foo@167772161 (but for one of the proper example IP
    addresses) if that's what is meant.
    
    (3) I think this (on p25) could do with rephrasing: "A
    'closedAuthenticated' policy MUST have each conference participant in
    the allowed users list (listed under the <allowed-users-list> element)
    with each participant being sufficiently (up to local policy)
    authenticated."
    
    (4) In 4.6.5, maybe s/authenticated user identities/authenticated user
    identifiers/ - a pet peeve of mine, but probably more correct as
    identifiers.
    
    (5) 4.6.5.3 seems a bit overstated - given that the highest level of
    protection still has non-anonymous identifiers for the user in the
    common model, calling if anonymous seems wrong and liable to give the
    wrong impression. I'd suggest changing the name of this to
    "<hide-name>". (This is not a discuss because I guess it could be that
    code depending on this name is out there already and its a small
    point.) If changing the name's not doable, then maybe add a sentence
    that implementations SHOULD make it clear to users that real anonymity
    is not being provided.
    
  6. Pete Resnick: Discuss [2011-05-25]:
        After getting most of the way though draft-ietf-xcon-ccmp and draft-ietf-xcon-
    examples-08, I have decided to move this to DISCUSS. These three documents
    repeat things from documents to which they normatively refer. Aside from
    increasing the overall length of what are already very long documents, I think
    this actually introduces a danger that the documents will "get out of sync": If
    the normative text happens to differ between the documents, it's unclear which
    is authoritative. If there's disagreement in even non-normative text, it
    introduces the potential for confusion. I really think the redundant text needs
    to be eliminated and the documents shortened.
    
    In this document: RFCs 3986, 4575, and 5239 are all normative references and are
    absolutely required reading to use this document. Therefore I don't see any
    reason for all of the redundancies in this document, and note the potential for
    problems above. So:
    
    Intro - Paragraphs 2, 3, 4 and figure are redundant and unneeded. Strike.
    
    (Indeed, figure 1 is subtly different from the ones in 5239. Maybe not in any
    important way, but why introduce the potential for confusion.)
    
    4.1 - Shorten:
    
       A conference object document begins with the root element
       <conference-info>, which is defined in [RFC4575].  The
       attributes 'state' and 'version' defined in [RFC4575] are
       not used for this element in this specification because these
       attributes only apply to notification mechanisms.
    
       This specification adds the child element <floor-information>
       to the <conference-info> element.
    
    4.2 - Shorten:
    
       The <conference-description> element, which is defined in [RFC4575],
       describes the conference as a whole.  This specification adds the
       child elements <language>, <allow-sidebars>, <cloning-parent>, <sidebar-
       parent>, and <conference-time>. This specification also adds a new
       <conference-password> child element to the <entry> child element of the
       <conf-uris> child element, and adds the <mixing-mode>, <codecs>, and
       <controls> child elements to the <entry> child element of the
       <available-media> child element.
    
    Strike 4.2.2, 4.2.3, 4.2.4, 4.2.5
    
    4.2.10 - Just define <conference-password> here.
    
    Strike 4.2.11, 4.2.12
    
    4.2.13 - Just define <mixing-mode>, <codecs>, and <controls> here.
    
    Strike 4.3, 4.4.2, 4.4.3, 4.4.4, 4.6.5.1, 4.6.5.2, 4.6.5.5, 4.6.5.6 
        
  7. Pete Resnick: Comment [2011-05-25]:
    ABNF issue: In 3.3.1, conf-object-id is very liberal. Is everyone OK with the
    idea of a conf-object-id of "---...+++===///"? (I understand that 3986 also
    allows "---...", but I'm just checking. [Update 2011-05-24: The author claims
    this is desirable. I am willing to take his word for it, but leave this comment
    in just in case.]
    
    Editorial: Top of section 4 - The use of the word "operator" twice here is
    goofy. This is notation, not a formal operation. I say just strike it. [Update
    2011-05-24: To be fixed.]
    
    Also, why is the figure specified as "non-normative". What could be taken as
    normative in there? [Update 2011-05-25: To be fixed.]
    
    4.2.1 - "defined in IANA [IANA-Lan]". That looks funny. [Update 2011-05-24: To
    be fixed.]
    
    4.2 - Why is "lang" on the <conference-description> rather than on its children?
    And why does it need to be called out normatively in this document? (Shouldn't
    all elements have a lang aatribute? Why is this one special?)
  8. Peter Saint-Andre: Discuss [2011-05-25]:
        First, my apologies for not reviewing this document earlier in the
    process, as requested by the RAI ADs.
    
    1. RFC 4575 says that a conference object MUST be encoded using UTF-8,
    yet this document says it SHOULD be encoded using UTF-8. Why the change?
    How would a UTF-16-encoded conference object be handled? I strongly
    suggest changing the SHOULD to MUST.
    
    2. Section 3.3 states:
    
       When created within the
       conferencing system, the 'conference ID' has a 1:1 mapping to the
       unique conference object Identifier(XCON-URI).
    
    However, Section 3.3.1 defines XCON-URI as:
    
       XCON-URI = "xcon" ":" [conf-object-id "@"] host
    
    Is there a 1:1 mapping between the "conference ID" and the full 
    XCON-URI, or between the "conference ID" and the conf-object-id rule?
    
    3. Section 3.3.1 says that "the XCON-URI can not be resolved to 
    addresses and/or ports". Does this mean that an application MUST NOT
    attempt to resolve an XCON-URI, or only that such URIs are not designed 
    to be resolvable?
    
    4. Regarding Section 3.3.2, why not just reference Section 6 of RFC
    3986?
    
    5. Please add a note that the XCON-URI construction does not directly
    support characters outside the ASCII range, but that such characters can
    be encoded (at least in the "host" portion) using the rules in RFC 3987.
    
    6. Section 4.1 states:
    
       Note that the
       <conference-info> element does not have the attributes 'state' and
       'version' defined in [RFC4575] for this element because these
       attributes only apply to notification mechanisms.
    
    What does it mean to say that the element "does not have" the attributes?
    Does it mean that for this usage, the attribute MUST NOT be included? If
    so then it appears that this document might be updating RFC 4575. 
    
    (Similar text appears in Section 4.6, Section 4.6.5, etc.)
    
    7. Section 4.2 states:
    
       The <conference-description> element, which is defined in [RFC4575],
       describes the conference as a whole.  It SHOULD have an attribute
       'lang' to specify the language used in the contents of this element.
    
    However, the 'lang' attribute is not specified in RFC 4575 schema. The 
    RelaxNG definition in this document includes not 'lang' but 'xml:lang':
    
     conference-description-type =
       element conference-description {
         attribute xml:lang { xsd:language }?
    
    If you mean 'xml:lang' instead of 'lang' then please say so.
    
    8. A number of elements have boolean values, such as Section 4.2.6:
    
       The <allow-sidebars> element represents a boolean value.  If set to
       TRUE, the conference is allowed to create sidebar conferences.  If
       absent, or set to FALSE, the conference can not create sidebar
       conferences.
    
    Please note that in W3C XML Schema Part 2 (Datatypes), there are two 
    lexical representations for boolean values: "true"/"1" for the concept
    TRUE and "false"/"0" for the concept FALSE. You might want to add a
    general note about this somewhere in the text (or in each section say
    '"true" or "1"' instead of 'TRUE', '"false" or "0"' instead of 'FALSE').
    
    9. Given that the conference object is entirely defined in XML, why
    does the <base> child of the <conference-time> element contain the
    textual representation of an iCalendar object (RFC 5545) instead of
    the XML representation (draft-daboo-et-al-icalendar-in-xml, on the 
    same telechat as this document)?
    
    10. Section 4.2.9 states the following about the <mixing-start-offset>
    element (same for <mixing-end-offset>):
    
          The <mixing-start-offset> has the mandatory
          'required-participant' attribute.  This attribute contains one of
          the following values: "none", "administrator", "moderator",
          "user", "observer", and "participant".  The roles' semantic
          definitions are out of the scope of this document and is subject
          to future policy documents.  More values can be specified in the
          future.
    
    Not defining the attribute values seems problematic. Yes, we all have 
    a common-sense idea of what administrators and moderators (etc.) are,
    but why leave the definitions to future policy documents? And given
    that more values can be specified in the future, is a registry in
    order?
    
    11. Section 4.6.3 states:
    
       The <persistent-list> child element
       stores persistent information about users who are not actively part
       of an ongoing chatroom session.  The <persistent-list> element stores
       the following information:
    
       o  user: The <user> element stores the name, nickname, the conference
          user identifier (XCON-USERID) and email address of a user.  It has
          three attributes: 'name', 'nickname' and 'id' and an <email>
          element.  Future extensions to this schema may define new elements
          for the <user> element.
    
    Why is it required to store email address? What are the privacy and
    security implications of storing email addresses (e.g., possible
    directory harvesting attacks)?
    
    12. Section 6 states:
    
       The Conference Information Data Model defined in this document is
       meant to be extensible toward specific application domains.  Such
       extensions are accomplished by defining elements, child elements and
       attributes that are specific to the desired application domain.  The
       IETF MAY extend the data model schema with unqualified attributes or
       extension elements from the "urn:ietf:params:xml:ns:" "sub-namespace"
       in the future.  Other instances are free to define extension elements
       or attributes under other namespaces.
    
    I see no reason to talk about the "urn:ietf:params:xml:ns:" tree here,
    although if you want to talk about it then the MAY seems out of place
    and it would be good to provide a pointer to RFC 3553. I would suggest:
    
       The Conference Information Data Model defined in this document is
       meant to be extensible.  Extensions are accomplished by defining 
       elements or attributes qualified by namespaces other than
       "urn:ietf:params:xml:ns:conference-info" and
       "urn:ietf:params:xml:ns:xcon-conference-info" for use wherever
       the schema allows such extensions (i.e., where the RelaxNG
       definition specifies "anyAttribute" or "anyElement").
     
        
  9. Peter Saint-Andre: Comment [2011-05-25]:
    1. Section 3.4 says:
    
       Note that some of the elements described above such <conference-
       info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
       val> are not defined in the data model in this specification but are
       defined in the data format of [RFC4575].  We describe them here
       because they are part of the basic structure of the data model.
    
    In fact *only* <floor-information/> is defined in this specification. 
    It would be good to make that clear.
    
    2. In Section 4.2.13:
    
          *  The <mute> element is used in conjunction with an audio stream
             to cease transmission of any audio from the associated stream.
             That means that for the entire duration where mute is
             applicable, all current and future participants of the
             conference are muted and will not receive any audio.
    
    To be precise, muting applies to the sending of audio, not the receiving
    of audio.
    
    3. I haven't had time to complete detailed checking of the RelaxNG 
    schema (compact or XML syntax), the W3C XML Schema document, or the 
    examples. However, including the formal definition in three different
    representations might introduce the possibility that they are out of
    sync. The fact that only the compact syntax is normative helps. 
    Finally, I merely note that the formal definition in RFC 4575 uses 
    W3C XML Schema, whereas the formal definition in this document uses 
    RelaxNG; the disconnect might make it difficult for implementers to
    compare and reuse the formal definition.
    
  10. Sean Turner: Discuss [2011-05-23]:
        #1) Mandatory is used a couple of times in the document to indicate support
    level for certain attributes (e.g., in Sec 4.2.9).  I think these should be
    changed to use 2119 language.
    
    #2) Sec 4 include the following:
    
      The operator "!" preceding an element indicates
      that the element is mandatory in the data model.
    
    Shouldn't mandatory be REQUIRED (i.e., use 2119 language).
    
    #3) I'm trying to reconcile the following statement from Sec 4.2.9 and Figure 3:
    
      Every <entry> element contains the following child elements:
    
    I read that to mean the child elements MUST be present.  Is that the case?  
    
    Same thing in 4.2.13:
    
      Each <entry> element contains the following child elements:
    
    #3) Sec 4.2, 4.3, 4.4, 4.6: Which of the sub-elements MUST be supported?  E.g.,
    is it allowable to have an empty <conference-state> or <users>? If so how's that
    handled?
    
    #4) Sec 4.5: Which of the four elements MUST be supported?  Is <conference-ID> a
    MUST?  What happens when <floor-request-handling> isn't included - is there
    default behavior like <allow-floor-events>?
    
    #5) Sec 4.5.4 includes the following:
    
       The <conference-floor-policy> element has one or more <floor> child
       elements.
    
    Doesn't this mean "floor" is a MUST?  Then, Figure 3 needs to be updated and
    this sentence should be reworded to clearly state it's a MUST support.
    
    #6) Sec 4.6.5.10 needs to indicate that it MUST be included in every <user>. 
        
  11. Sean Turner: Comment [2011-05-23]:
    #1) I support Stephen's discuss.
    
    #2) Should this document indicate that it updates RFC 4575?
    
    #3) Sec 1 includes the following:
    
      This core data set called the 'conference information data model' is
      defined in this document using an Extensible Markup Language (XML)-
      based.
    
    I think this sentence is missing some additional words.
    
    #4) Sec 4.5.4:	 r/is optional/is OPTIONAL
    			r/The optional/The OPTIONAL

draft-ietf-vcarddav-vcardrev

  1. Adrian Farrel: Discuss [2011-05-25]:
        Updated Discuss in view of the RFC Editor Note
    
    A fine piece of work, but one small issue need resolution before
    publication as an RFC.
    
    ---
    
    draft-ietf-vcarddav-vcardxml sets two requirements for extensions to 
    this document:
    
       It is expected that [...] vCard extensions will also specify
       extensions to the XML format
    
       New XML vCard property and parameter element names MUST be lower-
       case.
    
    I think you should include these two requirements in this document. 
        
  2. Stephen Farrell: Comment [2011-05-23]:
    (1) I'm surprised that there is no security considerations text about
    the fact that you might run into trouble if you blindly follow URLs
    that are embedded in vCards. There's probably easily copied text
    somewhere on that.
    
    (2) Similar point about embedded images and audio - again security 
    considerations about parsing/rendering these carefully would be 
    good. 
    
    (3) You can specify a key but no signature? That's a pity but
    I guess would be another spec entirely. Just wondering if anyone's
    developing that.
    
    (4) This allows a whole bunch of things to be included (e.g.
    PGP keys, URLs etc.) but there are no conformance requirements
    for what has to be supported. I guess that's in some other 
    spec somewhere?
    
  3. David Harrington: Comment [2011-05-25]:
    1) in xCard,
    New XML vCard property and parameter element names MUST be lower-
    case. This is necessary to ensure that round-tripping between XML and plain-text
    vCard works correctly. 
    in vCard,
    Based on experience with vCard 3
    interoperability, it is RECOMMENDED that property and parameter names be upper-
    case on output. 
    are these consistent?
    2) references need updating (see id-nits)
  4. Russ Housley: Comment [2011-05-24]:
      The discussion following the Gen-ART Review by Kathleen Moriarty on
      8-Apr-2011 lead to the following proposed text:
      
      o  vCards often carry information that can be sensitive (e.g.
         birthday, address, and phone information).  Although vCards have no
         inherent authentication or privacy provisions, they can easily be
         carried by any security mechanism that transfers MIME objects to
         address authentication or privacy (e.g.  S/MIME [RFC5751], OpenPGP
         [RFC4880]).  In cases where the privacy or authenticity of
         information contained in vCard is a concern, the vCard SHOULD be
         transported using one of these secure mechanisms.  The KEY
         property (Section 6.8.1) can be used to transport the public key
         used by these mechanisms.
    
      I would prefer the use of "confidentiality" instead of "privacy".
      That would better align with the definitions in RFC 2828.
  5. Pete Resnick: Comment [2011-05-24]:
    3.3 -
         NON-ASCII = %x80-FF
            ; Use is restricted by UTF-8
            
    Why not use UTF8-char and reference RFC 3629?
         
    4 - 
         TEXT-CHAR = "\\" / "\," / "\n"
                   / <any VALUE-CHAR except , or \>
            ; Backslashes, commas, and newlines must be encoded.
    
    Is it so bad to expand this out?
    
         TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
                   / %x21-2B / %x2D-5B / %x5D-7E
            ; Backslashes, commas, and newlines must be encoded.
    
    6.1.2/6.1.3 - 
    
         BEGIN-param = 0dummy  ; no parameter allowed
         END-param = 0dummy  ; no parameter allowed
         
         BEGIN-param = 0" "  ; no parameter allowed
         END-param = 0" "  ; no parameter allowed
    
    That looks neater to me.
    
    6.5.1 - Is it worth an informative reference to
    draft-lear-iana-timezone-database (approved BCP)?
    
  6. Dan Romascanu: Comment [2011-05-24]:
    I support the issues raised by Stephen Farrell in his COMMENT.  
  7. Robert Sparks: Discuss [2011-05-24]:
        Is this document deprecating text/directory? It obsoletes the RFC that defined
    it, but the only mention is in the media registration of text/vcard as "should
    be considered deprecated in favor of text/vcard". Why isn't this stated more
    clearly in the text (particularly the introduction) of the document? 
        
  8. Robert Sparks: Comment [2011-05-24]:
    It would help to point to Appendix A earlier in the document, perhaps with a
    very high-level overview of what's been updated. An implementer will use
    Appendix A as a checklist of items to check against code - is it complete? There
    are changes called out in B (which will be deleted before being published) that
    don't seem to be reflected in A.
    
    Were there any changes to what 4770 specified?
  9. Sean Turner: Discuss [2011-05-24]:
        #1) Sorry to inflict an this on the authors, but I gotta ask:  Do you want to
    move the obsoleted RFCs to Historic?
    
    #2) The last line in the abstract doesn't match up with the header.  Is 2739
    being updated or obsoleted?
    
    #3) Sec 3.1: What should happen if another charset is included?  
        
  10. Sean Turner: Comment [2011-05-24]:
    #1) Section 5.2 & 5.3: r/parameter is optional/parameter is OPTIONAL
    
    #2) Sometimes the document uses ASCII and other it uses US-ASCII.  Was this
    intentional?
    
    #3) Sec 6.8.1: lots of people use .cer or .pem for X.509 certificates can we
    change the example to:
    
       KEY:http://www.example.com/keys/jdoe.cer?

draft-ietf-vcarddav-vcardxml

  1. Adrian Farrel: Comment [2011-05-25]:
    The Relax NG specification really does need a reference that would help
    identify the correct base specification. I think you could use an OASIS 
    URL, but I would prefer the ISO number.
  2. David Harrington: Comment [2011-05-25]:
    1) I did not validate Appendix A. Has this had independent validation by, say,
    the XML directorate?
  3. Russ Housley: Comment [2011-05-24]:
      The Security Considerations say:
    
        All the security considerations applicable to plain vCard
        [I-D.ietf-vcarddav-vcardrev] are applicable to this document
        as well.
    
      This is completely correct; however, the use of XML digital
      signature and XML encryption are appropriate security mechanisms
      in this situation, while these mechanisms are not appropriate for
      a plain vCard.  This seems worthy of mention.
    
  4. Dan Romascanu: Comment [2011-05-25]:
    5.1.  Extensibility
    
       The original vCard format is extensible.  New properties, parameters,
       data types and values (collectively known as vCard objects) can be
       registered with IANA.  It is expected that these vCard extensions
       will also specify extensions to the XML format described in this
       document.
    
    I think that this paragraph refers to the procedure described in Section 10.2 of
    http://www.ietf.org/id/draft-ietf-vcarddav-vcardrev-21.txt for registering new
    vCard elements. I beleieve that an explicit reference would be useful. Also, why
    are the vCard extensions called 'objects' in this document and 'elements' in the
    other? Also just saying 'can be registered with IANA' is somehow mis-leading
    (especially in the absence of the reference) as this is no routine IANA
    registration, but a procedure that requires a standards-track RFC in some cases.

draft-ietf-xcon-ccmp

  1. Stewart Bryant: Comment [2011-05-23]:
    On the basis of trusting that others who have greater knowledge of this subject
    matter have reviewed this document I am voting no-objection.
  2. Ralph Droms: Comment [2011-05-25]:
    What is the scope of the uniqueness for an XCON-USERID?  Is
    XCON-USERID intended to be used across multiple conferences or is it
    specific to a conference?
  3. Adrian Farrel: Discuss [2011-05-25]:
        A very weighty tome that I cannot pretend to have read in full detail. 
    I am relying on the WG and responsible ADs for assurance of quality,
    but I noticed a few smaller issues that I believe need to be resolved
    before publication.
    
    ---
    
    Section 4
    
       The specification recommends the use of HTTP as
       a transport solution, including CCMP requests in HTTP POST messages
       and CCMP responses in HTTP 200 OK replies.  This implementation
       approach is further described in Section 4.4.
    
    Section 9
    
       This section describes the use of HTTP [RFC2616] and HTTP Over TLS
       [RFC2818] as transport mechanisms for the CCMP protocol, which a
       conforming conference Server and Conferencing client MUST support.
    
    Section 10  
    
       3.  The protocol MUST support a confidentiality and integrity
           mechanism.  As described in Section 9, implementations of CCMP
           MUST implement the HTTP transport over TLS [RFC2818].
    
    So it looks like Section 4 is under-egging the situation and you need
    s/recommends/requires/
    
    It is probable that Seciton 4.4 needs to be tightened in this regard as 
    well.
    
    ---
    
    I think the 2119 language needs to be tightened up. As a completely
    random example:
    
    Section 5.1
    
       operation:  An optional parameter refining the type of specialized
          request message.  The "operation" parameter is REQUIRED in all
          requests except for the "blueprintsRequest" and "confsRequest"
          specialized messages.
    
    Why "optional" in lowercase but "REQUIRED" in uppercase? 
    
    I think the only sure way to sort this will be to grep all the lowercase
    versions of the 2119 words and think about them carefully.
    
    ---
    
    Section 5.1
    
       conference-password:  An optional parameter that MUST be inserted in
          all requests whose target conference object is password-protected
          (as per the <conference-password> element in
          [I-D.ietf-xcon-common-data-model]).
    
    This "MUST" implies that ommission would be treated as a malformed 
    message, not a password failure (i.e. 400 not 401). Does it matter?
    But later I see you have defined 424 which is probably what you would
    use. Add some clarity?
    
    ---
    
    Shouldn't the sample phone number (uri="tel:+390817683823") be taken
    from one of the set of "unreal" phone numbers?
    
    ---
    
    Section 7
    
       This document proposes the use of DNS to locate the conferencing
       server.
    
    What is the upshot of this proposal? Does a conformant implementation
    get to choose? Is this language you can tighten as s/propose/specifies/ 
        
  4. Adrian Farrel: Comment [2011-05-25]:
    BTW, I appreciated the many examples, although they might have been 
    moved to an appendix to clear the floor for the main meat of text
    (is that metaphor too horribly mixed?). I also wasn't convinced by
    including all of the schema fragments in-line as well as in Section 11,
    but this is probably a stlistic choice that is not important.
    
    ---
    
    Nit
    
    5.4. 
    
       All CCMP response messages MUST include a ""response-code"".  The
    
    You probably don't need the quad-quotes.
  5. Stephen Farrell: Discuss [2011-05-25]:
        (1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be
    a mistake. Its more likely that HTTP authentication will be maintained in
    future (e.g. extended for oauth, saml, etc) than that CCMP will be.  I would
    suggest getting rid of the "not required" in section 9 on that.
    
    (2) The response codes in 5.4 seem to be a subset of those from rfc 2616.  I
    think it'd be better to not replicate the descriptive text about those, nor the
    codes themselves - how is the combination of HTTP response codes and CCMP
    response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one
    response then what? I could imagine coders getting this wrong, or having
    difficulty doing the right thing with libraries. 
        
  6. Stephen Farrell: Comment [2011-05-25]:
    (1) This could do with being rephrased. "Their identifiers, respectively the
    conference XCON-URI and the conferencing client XCON-USERID, and their XML
    representations compliant with the XML Schema defined in the XCON data model
    are widely used for creating the CCMP requests and responses."
    
    (2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really
    followed the description and I wondered if it'd be easy to write code for this.
    I'd suggest maybe looking at that text again to see if there's a way to make it
    clearer for an implementer who hasn't been involved in the WG. 
    
    (3) In 4.4, if a client's timer expires and it closes the connection, then
    what, if anything, is the server supposed to do? E.g. if the request was ok and
    the server has done an update but not yet sent the 200 response for some
    reason. I think the server doesn't have to do anything (e.g. try to unwind the
    update), but that'd be good to say.
    
    (4) What is the limit of the xPathFilter mechanism? Could I use it to select
    all the users or conferences with the password foo? Maybe there's some security
    considerations text needed for that?
    
  7. Pete Resnick: Discuss [2011-05-25]:
        As with draft-ietf-xcon-common-data-model, section 3 of this document repeats
    things from RFC 5239. I think this introduces a danger that the documents will
    "get out of sync": If the normative text happens to differ between the
    documents, it's unclear which is authoritative. If there's disagreement in even
    non-normative text, it introduces the potential for confusion. Strike all of
    section 3. Completely redundant with RFC 5239, which is a normative reference
    anyway.
    
    The intro to section 4 gives an implementation requirement without using 2119
    language:
    
       Each operation in the protocol model, as summarized in Section 4.1 is
       atomic and either succeeds or fails as a whole.  The conference
       server must ensure that the operations are atomic in that the
       operation invoked by a specific conference client completes prior to
       another client's operation on the same conference object.
    
    4.3 needs a reference to the data model document.
    
    5.2 defines the "version" parameter as optional. However, there are clearly
    instances (specified in 4.2) where it is required. 5.2 should probably indicate
    that.
    
    5.3.1 - "A blueprintsRequest message REQUIRES no "confObjID" and "operation"
    parameters". Do you mean that they are OPTIONAL or that they MUST NOT be
    present? "REQUIRES no" is not appropriate. 
        
  8. Pete Resnick: Comment [2011-05-25]:
    Intro to section 4:
    
       CCMP is a client-server, XML-based protocol, which has been
       specifically conceived to provide users with the necessary means for
       the creation, retrieval, modification and deletion of conference
       objects.  CCMP is also state-less, which means implementations can
       safely handle transactions independently from each other.
       Conference-related information is encapsulated into CCMP messages in
       the form of XML documents or XML document fragments compliant with
       the XCON data model representation.
    
    That's a bit fluffy. How about instead:
    
       CCMP is a client-server, XML-based protocol for user creation,
       retrieval,
    modification and deletion of conference objects.  CCMP
       is a stateless
    protocol, such that implementations can safely
       handle transactions
    independently from each other.  CCMP messages 
       are XML documents or XML
    document fragments compliant with the
       XCON data model representation. [REF?]
    See also use of the word "conceived" in the intro to 4 and in 5.3.1. Could
    tighten up the language there.
    
    4.2 would be much easier to read if you stated the requirement (that responses
    with documents MUST have a version) first and then gave the explanation.
    Implementers don't need dramatic build-up. Get to the point. Then most of the
    explanation can be reduced.
    
    4.4 first paragraph (or two; I can't tell if what spans the page break is 1
    paragraph or two)
    can be reduced to:
    
       CCMP is implemented using HTTP, placing the CCMP request messages into
       the body of an HTTP POST operation and placing the CCMP responses into
       the body of the HTTP response messages. For information as to why this
       implementation method was chosen, refer to Appendix A.
    
    Then trim the second to last paragraph of 4.4 to get rid of redundancies.
    
    5.3 Overall - I wouldn't mind seeing all of the XML *not* repeated here. It's
    already in section 11.
    
    5.3 Intro - Move the discussion of optionsRequest/optionsResponse down to
    5.3.12. No need to distinguish it here.
    
    6 - I think this should either be in an appendix or in draft-ietf-xcon-examples.
    
  9. Dan Romascanu: Comment [2011-05-26]:
    The OPS-DIR review performed by Juergen Quittek raised a few issues and made a
    number of suggestions. None of them are critical, but in case the document is
    open to fix other issues I suggest to consider these ones as well:
    
    1) Section 2: Terminology
    >    First-Party:   A request issued by the client to manipulate their own
    >       conferencing data.
    > 
    >    Third-Party:   A request issued by a client to manipulate the
    >       conference data of another client.
    
    "First-Party" and "Third-Party" alone are not requests.
    At least the term is not used this way in the draft.
    Rather "third-party request" is used in the text for Referring to requests.
    I would suggest:
    
    NEW
       First-Party request:   A request issued by the client to
          manipulate their own conferencing data.
    
       Third-Party request:   A request issued by a client to
          manipulate the conference data of another client.
    
    2) Section 3, third paragraph, 1st line:
    
    OLD
       Conference object and conference users do represent key elements 
    
    NEW
       Conference object and conference user objects do represent key elements
    
    Implementation and operation of the protocol would become drastically simpler if
    the CCMP server would not be required anymore to create users. Just creating
    user objects would probably be sufficient already
    
    3) Section 3.2, 1st paragraph, lines 7-8 
    
    OLD
       or a common administrator.  The Conference Control Server creates
       individual users, assigning them a unique Conference User Identifier 
    
    NEW
       or a common administrator.  The Conference Control Server creates
       individual user objects, assigning them a unique Conference User
       Identifier
    
    4) Section 4.1, 2nd paragraph
    
    OLD
       create:  for the creation of a conference, a conference user, a
          sidebar, or a blueprint.
    
    NEW
       create:  for the creation of a conference object, a conference
          user object, a sidebar, or a blueprint.
    
    5) Section 4.3, item (b), line 2:
    
    OLD
            in the request has (have) been replaced by the newly created 
    
    NEW
            in the request have been replaced by the newly created
    
    6) Section 5.3.4, paragraph after Figure 8, line 7:
    What is "the referenced conference document"?
    Is it the conference object?
    
    7) Section 5.3.5, 1st paragraph, Last two lines:
    Again "conference document", see issue 6)
    
    8) Section 5.2.12, first bullet item, line two:
    "ten standard message names"
    It would be helpful to add a reference to Table 1.
    
    9) Section 7, first lines:
    >    If a conference control client is not pre-
    configured to use a
    >    specific conference control server for the requests,
    the client MUST
    >    first discover the conference control server before it can
    send any
    >    requests.
    Is this really a capital "MUST"? Would the client be
    able to send any request before discovering the server?
  10. Peter Saint-Andre: Discuss [2011-05-25]:
        1. Section 4.2 appears to assume that HTTP is the transport; for
    example:
    
       If the
       modifications are all successfully applied, the server sends back to
       the client a "200" response which also carries information about the
       current server-side version of the modified object.
    
    If that is so, please either change SHOULD to MUST (i.e., make HTTP
    mandatory-to-implement as a baseline data transfer protocol) or at
    least add a note to the effect that HTTP is a SHOULD but all the 
    examples use HTTP.
    
    This would also be consistent with Section 9, which states:
    
       This section describes the use of HTTP [RFC2616] and HTTP Over TLS
       [RFC2818] as transport mechanisms for the CCMP protocol, which a
       conforming conference Server and Conferencing client MUST support.
    
    2. In Section 4.3:
    
       The XCON data model identifies some elements/attributes as mandatory.
       Since the XML documents carried in the CCMP need to be compliant with
       the XCON data model, there can be a problem in cases of client-
       initiated operations, like the creation/update of conference objects.
       In such cases, not all of the mandatory data can be known in advance
       to the client issuing a CCMP request.  As an example, a client has no
       means to know, at the time it issues a conference creation request,
       the XCON-URI that the server will assign to the yet-to-be-created
       conference and hence it is not able to appropriately fill with that
       value the mandatory "entity" attribute of the conference document
       contained in the request.  To solve this issue, the CCMP client fills
       all mandatory data model fields, for which no value is available at
       the time the request is constructed, with fake values in the form of
       a wildcard string, AUTO_GENERATE_X (all uppercase), with X being a
       unique numeric index for each data model field for which the value is
       unknown.
    
    Instead of sending fake values, how about fixing the data model so that
    these elements and attributes are not mandatory?
    
    3. The CCMP namespace is "urn:ietf:params:xml:ns:xcon:ccmp". Why is it 
    not "urn:ietf:params:xml:ns:xcon-ccmp"? On the meaning of ":" here
    please see Section 3 of RFC 3553...
    
       Declaration of structure:
    
          The namespace is primarily opaque.  The IANA, as operator of the
          registry, may take suggestions for names to assign but they
          reserve the right to assign whatever name they desire, within
          guidelines set by the IESG.  The colon character (":") is used to
          denote a very limited concept of hierarchy.  If a colon is present
          then the items on both sides of it are valid names.  In general,
          if a name has a colon then the item on the left hand side
          represents a class of those items that would contain other items
          of that class.  For example, a name can be assigned to the entire
          list of DNS resource record type codes as well as for each
          individual code.  The URN for the list might look like this:
    
                urn:ietf:params:dns:rr-type-codes
    
          while the URN for the SOA records type code might look like this:
    
                urn:ietf:params:dns:rr-type-codes:soa
    
    It appears that "urn:ietf:params:xml:ns:xcon" is not a valid name. Thus
    "urn:ietf:params:xml:ns:xcon-ccmp" seems better. Notice also that the 
    XCON conference info URN is "urn:ietf:params:xml:ns:xcon-conference-info"
    not "urn:ietf:params:xml:ns:xcon:conference-info".
    
    4. Section 9 states:
    
       a conferencing server may not be a fully compliant HTTP server
    
    Do you mean "might" or "MAY"? I.e., is it OPTIONAL for a conferencing
    server to fully comply with HTTP? 
        
  11. Peter Saint-Andre: Comment [2011-05-25]:
    1. Section 4 states:
    
       The conference
       server must ensure that the operations are atomic in that the
       operation invoked by a specific conference client completes prior to
       another client's operation on the same conference object.
    
    Change "must" to "MUST"?
    
    2. Also in Section 4:
    
       The specification recommends the use of HTTP as
       a transport solution...
    
    Change to the following?
    
       Implementations SHOULD use HTTP as the transport...
    
    3. In Section 4.2:
    
       The "version" parameter is not REQUIRED for requests...
    
    There is no "not REQUIRED" in RFC 2119. I suggest:
    
       The "version" parameter is OPTIONAL for requests...
    
    4. In Section 5, the terms "mandatory" and "optional" are used for the
    various parameters. Using RFC 2119 language, are these really "REQUIRED"
    and "OPTIONAL"?
    
    5. The table in Section 5.4 has bad line breaks. I suggest changing this:
    
       +---------------+------------+------------+------------+------------+
       | Response code | Create     | Retrieve   | Update     | Delete     |
       +---------------+------------+------------+------------+------------+
    
    to this:
    
       +----------+-------------+-------------+-------------+-------------+
       | Response | Create      | Retrieve    | Update      | Delete      |
       | Code     |             |             |             |             |
       +----------+-------------+-------------+-------------+-------------+
    
    or even to this:
    
       +------+--------------+--------------+--------------+--------------+
       | Code | Create       | Retrieve     | Update       | Delete       |
       +------+--------------+--------------+--------------+--------------+
    
    That will give you more room in each column.
    
    6. Various examples have "form the server" instead of "from the server".
    
    7. In schema snippet from Section 6.9, the example extension does not 
    specify an XML namespace, implying that the extension is qualified by 
    the base namespace. This would be wrong. The examples are right, here.
    
    8. Section 9 states:
    
       A conferencing client that conforms to this specification is not
       required to support HTTP authentication [RFC2617] or cookies
       [RFC6265].
    
    There is no "not required" in RFC 2119. Do you mean that it is OPTIONAL 
    for a conferencing server to support RFC 2617 and RFC 6265?
    
    9. In Section 10.4, please add an informational reference to RFC 4732.
  12. Sean Turner: Discuss [2011-05-25]:
        This is an updated discuss.  I've included the authors responses to the first 4
    between [MB] and [/MB].  #5 and #6 are new.
    
    #1) This document sometimes uses optional and mandatory to indicate support
    requirements.  These should be changed to use 2119 language.  E.g., in 5.1, 5.2,
    and 5.3.12.
    
    [MB] Agreed. [/MB] 
    
    #2) Sec 4 includes the following:
    
     The specification recommends the use of HTTP as
     a transport solution, including CCMP requests in HTTP POST messages
     and CCMP responses in HTTP 200 OK replies.
    
    Should it be "RECOMMEND"?  There were musts earlier but I think they were
    specified in other RFCs.
    
    [MB] Definitely yes. [/MB] 
    
    #3) Sec 4.4 includes the following:
    
     In addition, to mitigate
     the situation clients MUST NOT wait indefinitely for a response and
     MUST implement a timer (in the range of seconds) such that when it
     expires, the client MUST close the connection
    
    Is there some recommendation you could give about how long to wait?  1 minute, 5
    minutes?
    
    [MB] It should be in 10s of seconds.  I think 60 secs would be an upper range.
    I'm inclined to suggest 30 secs as the default. [/MB]
    
    #4) Sec 5.3.5 includes the following:
    
       Through a "usersRequest" message the CCMP client manipulates the XML
       <users> element of the conference document associated with the
       conference identified by the "confObjID" parameter complusory
       included in the request.
    
    Is "complusory" supposed to mean it's mandatory?  It would be better to just use
    the 2119 language.
    
    [MB] Yes. [/MB] 
    
    #5) I couldn't find an explicit statement that clients and server MUST support
    both the request and response.  Do we need that or is it assumed?
    
    #6) In the CCMP Request there are 5 fields defined.  All are optional.  Doesn't
    at least one field need to be a MUST? If there's no required field - can an
    implementation that sends no fields in a CCMP Request considered compliant?  I
    had the same kind of comment against the xcom-common-data-model: It seems odd to
    me that the protocol would specify sub-elements all of which are optional.
    Maybe this is done all the time in XML land and I'm just picking on this draft?
    In ASN.1-land, where I'm from, it's like having a CHOICE and not explaining
    which one of the choices is a MUST. 
        
  13. Sean Turner: Comment [2011-05-25]:
    #1) Section 5.1 subject references AAA, a reference is needed - it kind of came
    out of the blue.
    
    [MB] Okay. [/MB] 
    
    #2) Sec 6 message 1 has:
    
    <confUserID>xcon-userid:alice@example.com</confUserID>
    
    shouldn't it be:
    
    <confUserID>xcon-userid:Alice@example.com</confUserID>
    
    [MB] Yes, this needs to be corrected. [/MB] 
    
    #3) Sec 9 - "REQUIRED" is not 2119 language.
    
    [MB] "REQUIRED" is in the 2119 template that we used and is specified in  RFC
    2119 in the following context:
    
    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.
    
    [/MB] 
    
    [spt] duh - homer simpson moment. [/spt]
    
    #4) Sec 10.1: r/the client must be
       able to validate the certificate./the client MUST be
       able to validate the certificate.
    
    [MB] Okay. [/MB]
    
    #5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is
    properly checked.
    
    [MB] Are you suggesting that we change the following sentence to something like
    the following?
     OLD: 
       Note that in order for the
       presented certificate to
    be valid at the client, the client must be
       able to validate the certificate.
    NEW:
       Note that in order for the
       presented certificate to be valid at the
    client, the client must be
       able to validate the certificate, using a
    mechansim such as that specified in RFC 6125.
    [/MB]
    
    [spt] this or a pointer to 2818.

draft-ietf-avtext-multicast-acq-rtcp-xr

  1. Adrian Farrel: Comment [2011-05-25]:
    It would have helped me as a reader to have had some idea of the range
    of potential sizes of the random acquisition delay. I suspect that it
    can be expressed in packets and extrapolated to a time interval based
    on line speeds, etc. Obviously (?) if the range is 0 to < 1ms we might
    conclude that this work is not very necessary.
    
    Can you add a short note to help scope the work?
    
    ---
    
    Section 3 says:
    
       This document uses the following acronyms and definitions from
       [I-D.ietf-avt-rapid-acquisition-for-rtp]:
    
    But the definitions presented are somewhat different from those in 
    the referenced document. Although the intent may be the same, I don't
    think it is helpful to have different definitions and I recommend that
    you remove all but a list of terms and a pointer to the other I-D.
    
    ---
    
    Nit
    Abstract                   
    s/ore/or/
  2. Stephen Farrell: Comment [2011-05-25]:
    (1) s/one ore more/one or more/
    
    (C2 The constant 11 - I assume that's decimal - probably worth
    saying just in case someone interprets it as '11'H or 3 or
    whatever.
    
    (C3 I think you want to to s/this bit/this field/g below.  
    
          o  Rsvd. (16 bits):  The RTP receiver MUST set this bit to zero.  The
          recipient MUST ignore this bit when received.
    
    (4) Suggest rephrasing this in 4.2.1 (how can a time measured
    locally be negative?)
    
    OLD
    
      o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
          of zero or the time difference (in ms) between the instant SFGMP
          Join message has been sent and the instant the first packet was
          received in the multicast session. 
    
    NEW
      o  SFGMP Join Time (32 bits):  TLV element 
          with the time difference (in ms) between the instant the SFGMP
          Join message was sent and the instant the first packet was
          received in the multicast session. 
  3. David Harrington: Comment [2011-05-25]:
    1) in 4.1, "Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The
    recipient MUST ignore this bit when received." - MUST ignore these bits or MUST
    ignore this field.
    2) in 7.1, do you want to replcae or supplement the existing
    RFC#?
    3) in 7.4, should 0, 255, and 128-254 be included in the registry with
    approrpiate notations?
  4. Pete Resnick: Comment [2011-05-24]:
    In 4:
    
       It is better to send the MA report block after all the necessary
       information is collected and computed.  Partial reporting is
       generally not useful as it cannot give the full picture of the
       multicast acquisition, and causes additional complexity in terms of
       report block matching and correlation.  The MA report block is only
       sent as a part of an RTCP compound packet, and it is sent in the
       primary multicast session.
    
    Is there a reason 2119 language was not used here? (i.e., SHOULD send
    only after all information is collected, MUST send as part of an RTCP
    compound packet in the primary multicast session)
    
    In 4.2.1:
    
       o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
          of zero or the time difference (in ms) between the instant SFGMP
          Join message has been sent and the instant the first packet was
          received in the multicast session.  If the multicast join was
          successful, this element MUST be included.  If no multicast packet
          has been received, this element MUST NOT exist in the report
          block.
    
    and
    
       o  Size of Burst-to-Multicast Gap (32 bits):  Optional TLV element
          that denotes the greater of zero or the difference between the
          sequence number of the first multicast packet (received from the
          primary multicast stream) and the sequence number of the last
          burst packet minus 1 (considering the wrapping of the sequence
          numbers).  If no burst packet has been received in the unicast
          session or no RTP packet has been received from the primary
          multicast stream, this element MUST NOT exist in the report block.
    
    When could the "greater of zero or" part kick in? That is, when can the
    difference possibly be negative?
    
  5. Dan Romascanu: Discuss [2011-05-26]:
        1. Some of the basic terms for the understanding of this document are being
    referenced from [I-D.ietf-avt-rapid-acquisition-for-rtp]. It looks to me that
    this document should be a Normative rather than Informational reference.
    
    2. The Specification Required policy defined in Section 7.5 makes the following
    recommendation.
    
      The length of the Status field is two octets, allowing 65536 codes.
       However, the status codes have been registered to allow for an easier
       classification.  For example, the values between (and including) 1
       and 1000 are primarily used by the MA method of simple join.  The
       values between (and including) 1001 and 2000 are used by the MA
       method described in [I-D.ietf-avt-rapid-acquisition-for-rtp].  When
       registering new status codes for the existing MA methods or newly
       defined MA methods, a similar classification scheme is encouraged to
       be followed.
    
    However, there are currently 253 unassigned method values, so there is no room
    for an allocation of 1000 codes for each of them which creates a potential
    problem in the future. The language should be ammended (something else than
    'similar classification scheme') and include some warning to IANA for caution on
    this issue. 
        
  6. Robert Sparks: Comment [2011-05-24]:
    Additional text describing the assumptions around when you would use a status
    code of zero would help greatly. The expected use is that the sender of a report
    would only use that code when it knew from out-of-band methods that the receiver
    would understand the private TLVs in the report - one of those private TLVs,
    ostensibly, would replace semantics of the status code. Saying that explicitly
    would help avoid the situation where a client unintentionally throws away
    information like "multicast join was successful" by adding a private TLV that
    the server doesn't understand to a report that it would otherwise have used a
    status code of 1 on.
  7. Sean Turner: Discuss [2011-05-23]:
        Sec 4.1: Please use 2119 language to indicate support requirements.  Mandatory
    is not 2119 language. Also, are block length and Rsvd optional? 
        
  8. Sean Turner: Comment [2011-05-23]:
    Sec 4: r/The optional extensions that are/The OPTIONAL extensions that are 
    
    Sec 4.2.1: r/Optional/OPTIONAL  x 9. For Types 1 and 2 - are they optional too?

draft-ietf-mmusic-ice-options-registry

  1. Stephen Farrell: Comment [2011-05-18]:
    (1) s/these ICE options needs/these ICE options need/
    
    (2) Are there no existing ice-options that should be added to the registry?
    Looks like there aren't but just checking.

draft-ietf-savi-fcfs

  1. Stewart Bryant: Comment [2011-05-25]:
    I support the discusses raised against this document.
  2. Ralph Droms: Discuss [2011-05-24]:
        1. The definitions of "source address validation", "address ownership"
    and the concept that a " source address [...] belongs to the
    originator of the packet" need to be clarified this paragraph:
    
    2.3.  Address ownership proof
    
       The main function performed by FCFS SAVI is to verify that the source
       address used in data packets actually belongs to the originator of
       the packet.  Since FCFS SAVI scope is limited to the local link, the
       originator of the packet is attached to the local link.  In order to
       define a source address validation solution, we need to define some
       address ownership proof concept i.e. what it means that a given host
       owns a given address in the sense that the host is entitled to send
       packets with that source address.
    
    FCFS SAVI does not require that a host provide any sort of proof of
    "ownership" of an address before that address is registered in an FCFS
    SAVI function.  A host merely needs to claim the address through
    traffic sent to the FCFS SAVI function.  In contrast, a SAVI function
    implemented by bindings learned through manual configuration or
    through interactions with a DHCPv6 address assignment function can
    make a statement that an IP address belongs to a host.
    
    What FCFS SAVI does is prevent simultaneous use of a single IP address
    as a source address through multiple ports.  There is no guarantee
    that the FCFS binding in any way reflects intended ownership of the
    bound address.
    
    2. There needs to be text in section 2.1 explaining why FCFS SAVI is
    applicable or inapplicable to addresses assigned through DHCPv6.
    
    3. What about links for which there are no prefixes that are
    advertised as on-link?  Similarly, what about addresses that are
    assigned through DHCPv6 but are not taken from an on-link prefix?
    
    4. In section 3.2.2:
    
          *  If the IP source address does not belong to one of the local
             prefixes of the receiving interface, this means that the data
             packet is transit traffic and the packet SHOULD be discarded.
    
    s/SHOULD/MUST/
    
    How are the FCFS SAVI assumptions maintained and how is
    spoofed traffic discarded if the FCFS SAVI function decides to forward
    transit traffic?
    
    5. Section 3.2.4 must be worded more strongly to guarantee FCFS SAVI
    protection.  Some of the items in the list are "MUST" or FCFS SAVI
    protection will not be provided:
    
       o  Ports connected to hosts SHOULD be configured as Validating ports.
          Not doing so will allow the host connected to that port to send
          packets with spoofed source address.
       o  Ports connected to a chain of one or more legacy switches that
          have hosts connected SHOULD be configured as Validating ports.
          Not doing so will allow the host connected to any of these
          switches to send packets with spoofed source address.
    
    This requirement is a MUST.  There are no alternatives to the given
    configurations that still provide FCFS SAVI protection.
    
    6. I agree with Stephen Farrell's DISCUSS points 3 and 4, but feel
    less strongly about a fix.  Specifically, I agree that FCFS SAVI is
    inappropriate for a deployment in which an external router can pass
    transit traffic to an FCFS SAVI function.  But that just means SAVI
    FCFS is inappropriate.  There are other SAVI mechanisms that can work;
    for example, a DHCPv6-based mechanism in which the (non-FCFS) SAVI
    function is aware of the addresses and prefixes assigned through a
    binding anchor and, therefore, bound to that binding anchor.
    
    One way to address this issue some additional text describing how SAVI
    can be used to provide perimeter security, where that SAVI might be
    FCFS SAVI over part of the perimeter or some other kind of SAVI over
    the remainder of the perimeter.
    
    7. This paragraph from section 4 needs some clarification:
    
       The other type of attack is when an attacker manages to create state
       in the SAVI device that will result in blocking the data packets sent
       by the legitimate owner of the address.  In IPv6 these attacks are
       not an issue thanks to the 2^64 addresses available in each link.
    
    Random address selection makes it difficult for an attacker to hijack
    an address and deny legitimate use of an address.  However, in
    deployments that use SLAAC, a host has a predictable global address
    (perhaps augmented by random privacy addresses) that can be hijacked.
    
    8. In TESTING_VP state, section 3.2.3:
    
       o  If a data packet is received through a Trusted Port port that is
          other than port P, the state is moved to TESTING_TP-LT, and the
          packet MAY is discarded.
    
    Certainly it can't be just any packet received through a Trusted Port
    that triggers this action.  And, if P is a validating port, won't
    traffic on any Trusted Port be "other than port P"?  This bullet needs
    to be corrected.
    
    9. Throughout section 3.2.3, there are several occurrences of "If a
    DAD_NSOL" which need the qualification ""with target address set to
    IPAddr".
    
    10. In section 3.2.3, does "==" mean "is set to"?  In the last bullet
    of TESTING_VP, does the FCFS SAVI function continue the TESTING_VP
    state and is the lifetime modified?
     
        
  3. Ralph Droms: Comment [2011-05-24]:
    1. What is the relationship between the contributors in section 6 and
    the contents of the document and the list of authors?  A quick
    sentence about why the contributors are listed as such - rather than
    as authors or in the acknowledgments - would be helpful.
    
    2 I think it should be made clear whether the term "SAVI" refers to
    "FCFS SAVI" or, more generally, to any form of SAVI throughout the
    document.  Section 2.6, for example, is unclear about the use of
    "SAVI".  It's important to be clear in section 2.6 because in my
    opinion a SAVI perimeter could be composed out of various kinds of
    SAVI functions.
    
    3. What is the definition of a "realm"?  It's important to define
    realm because, by using ND to confirm the correctness of SAVI
    bindings, the FCFS SAVI function only checks on the link to which it
    is attached, not across the entire FCFS SAVI perimeter.
    
    4. Also in section 3.2.3:
    
       NO_BIND
    
       o  Upon the reception through a Validating Port (VP) of a Neighbour
          Solicitation (NSOL) generated by the Duplicate Address Detection
          (DAD) procedure (hereafter named DAD_NSOL) containing Target
          Address IPAddr, the SAVI device MUST forward the NSOL and 250
    
    In the last line, s/NSOL/DAD_NSOL/  How does the FCFS SAVI function
    differentiate between NSOLs generated by DAD and other NSOLs?
    
    5. In TENTATIVE state, section 3.2.3:
    
          the state remains in
          TENTATIVE_DAD_NSOL,
    
    s/TENTATIVE_DAD_NSOL/TENTATIVE/
    
    
  4. Wesley Eddy: Discuss [2011-05-24]:
        Some questions I think the authors should respond to:
    
    I believe the RetransTimer is configurable in RFC 4861, so why is 250 ms a magic
    number in Section 3.2.3 of this document?  Are there scenarios where this value
    needs to be configured differently or is this really one size fits all?  I
    didn't notice the motivation for this constant in the document, and it probably
    should be explained.  It seems to be fixed rather than just a default, but the
    wording in this document is actually a little ambiguous about this.
    
    The same comment applies to TENT_LT (500 ms) and DEFAULT_LT (5 minutes).  If
    these constants are special for some reason and not just defaults that can be
    tweaked to suit a deployment, it needs to be described why, otherwise the logic
    for setting them a certain way needs to be given. 
        
  5. Wesley Eddy: Comment [2011-05-24]:
    Some comments that I don't think are very important and that the authors should
    feel free to either take or ignore:
    
    In section 2.1, second paragraph, it might make sense to be more clear that
    routers use their own MAC address, but the packets that they forward have an
    off-link source address that doesn't belong to them.  However, I don't think
    anyone will really be confused either way, so this is just a suggestion.
    
    The definition of the term "binding anchor" is somewhat implicit in this
    document.  It might be a good idea to make it more explicit with just a sentence
    or so more where it's first used in 2.3, and only one very brief example is
    given.
    
    In section 2.3, second paragraph, should "(e.g. the port in a switched LAN)" be
    "(e.g. the MAC address and/or port in a switched LAN)"?
  6. Adrian Farrel: Comment [2011-05-25]:
    There are plenty of Discuss points already raised with which I agree.
    
    ---
    
    Section 1
    "The proposed mechanism..."
    It is no longer a proposal.
    
    ---
    
    The figure on page 9 has a misalignment.
    
    ---
    
    The writeup says:
       There are existing implementations of a very similar feature for
       IPv4.
    This is fair enough, but I am surprised to see no reference to this in
    the document and no description of the differences.
  7. Stephen Farrell: Discuss [2011-05-23]:
        
    While this is quite long and maybe has some controversial things, it
    doesn't impact that much on details of the actual scheme so I hope
    it's less bad than it appears.
    
    (1) A general point about SAVI that also applies to SAVI FCFS: Since
    SAVI is only about spoofed source addresses and is not about
    monitoring hosts that never spoof anything, and since privacy is a
    concern for the (I assume) huge majority of non-spoofing hosts I
    would like to see this (and all SAVI standards track documents) say
    something like: 
    
    "Compliant implementations MUST NOT log binding anchor information
    except where there is an identified reason (see section X for the
    list of reasons applying for FCFS-SAVI) why that information is
    likely to be involved in detection or prevention of actual source
    address spoofing.  Information that is not logged MUST be deleted as
    soon as possible (see section Y for the conditions that make it safe
    to delete information). Information about the majority of hosts that 
    never spoof SHOULD NOT be logged."
    
    The conditions for when logging is allowed and when each piece of
    state can be deleted need to be specifically called out.  Those would
    be the putative sections X & Y in the above suggested paragraph above.
    
    I realise this may seem like a significant change (though not to the
    parts of the protocol that actually detect spoofing) but I think it is
    an important one.
    
    (2) Abstract - SAVI is not about the general "control of source
    addresses used" - it is chartered to help detect/prevent source
    address spoofing and that is all. 
    
    (3) My phone can be a WiFi access point. How would that continue to
    work if SAVI-FCFS were deployed? I think the document needs to say how
    one can differentiate transit traffic from spoofed source addresses in
    that case or that SAVI FCFS MUST NOT be used in networks that should
    allow my phone to do its thing.  2.1 says that this technique only
    applies to local traffic so implementers will need to know how to do
    this. 
    
    (4) I think SAVI FCFS needs a way to allow transit traffic and
    disallow spoofed source addresses but that is not trivial to fool by
    just pretending to be a router. If that is not possible, then this
    technique just seems broken. Its not clear to me whether the spec has
    this problem or not.   
    
    (5) 2.4 - saying you "assume" that the binding anchor is a port on a
    switched network implies that SAVI-FCFS MUST NOT be used in any other
    case. You need to say that. On a related point, you need to clearly
    say that this is just for IPv6 if that is the case, (depending on rfc
    4861 seems to make that the case). All text that implies that the
    binding anchor for SAVI FCFS can be anything other than a port number
    should also be excised since SAVI FCFS is only defined for the port
    number being the binding anchor as far as I can see. This could
    probably best be done via an applicability statement section at the
    front. (Probably just a short paragraph is all that's needed.)
    
    (6) 2.5 I totally disagree that its a good idea for SAVI to log all
    this information. I'd like to see the section removed. (And as in (1)
    above, replaced with a MUST NOT for "normal" traffic and binding
    anchor information.)
    
    (7) (If 2.5 ends up staying...) Where in the SAVI charter does it say
    that "a secondary goal is to assist in traceability.."? Is there IETF
    consensus for this goal? I don't believe there is. RFC 2804 would
    imply the opposite.
    
    (8) If I end up in the rough on point (1) above, I would like to
    discuss whether not not SAVI goals could be met while only dealing
    with an anonymized form of binding anchor information. If so, then
    maybe you should have a MUST for doing that where the binding anchor
    information could be personally identifying.  While this is less
    relevant for SAVI-FCFS than perhaps other variants, (e.g. MAC address
    or NAI) even a port can be personally identifying in a some networks. 
    
    (9) The SAVI DB content says "such as the layer-2 address" but you've
    gone to lengths to say that's not trustworthy so its presumably not
    useful for detection of source address spoofing and should not be
    included here. See also point (1) above - MAC addresses of
    non-spoofing users should not be retained casually like this. I'd like
    to see a statement that personally identifying data MUST NOT be
    included in the SAVI DB with the MAC address as the canonical example.
    (If packets do indicate attempted spoofing then I've no problem about
    logging the MAC address.)
    
    (10) The prefix in the prefix list is v6 only - right? If so maybe
    worth saying so.
    
    (11) 3.2.1 talks about what the SAVI device does when it boots - is
    that the only time it is supposed to update the prefix list for
    transit traffic? That seems wrong.
    
    (12) 3.2.2 uses the phrase "local prefixes" which doesn't seem to be
    defined - does that cover prefixes for routers or not?`
    
    (13) 3.2.2 seems to say that transit traffic received on validating
    ports is just dropped - that can't be right so maybe the text needs to
    be rephrased to make it clear what happens. This may be related to
    (12) above, but I find 3.2.2 just too hard to follow.
    
    (14) MLD is used without expansion and with no reference.
    
    (15) End of state machine, p17 - what does "P'==P''" mean here?
    
    (16) Why are the security considerations talking about the binding
    anchor being a MAC address when you've ruled that out?  The spec needs
    to be clear about what binding anchor information can be used and not
    discuss other possible binding anchor information types.
    
    [The next 3 are from the secdir review by Juergen Schoenwaelder.]
    
    (17) [secdir#1] 
    
    My first question was triggered by text on page 8:
     
       [...] Before creating a SAVI binding in the local SAVI database,
    the SAVI device will send a NSOL message querying for the address
    involved.  Should any host reply to that message with a NADV message,
    the SAVI device that sent the NSOL will infer that a binding for that
    address exists in another SAVI device and will not create a local
    binding for it.
    
    Now, that sounded like it is easy to DoS new devices simply by
    generating fake NADV messages. Later in section 3, it seems you only
    accept NADV messages from trusted ports. If my reading is correct,
    then a better wording might be:
    
       [...] Before creating a SAVI binding in the local SAVI database,
    the SAVI device will send a NSOL message querying for the address
    involved.  Should any host _on a trusted port_ reply to that message
    with a NADV message, the SAVI device that sent the NSOL will infer
    that a binding for that address exists in another SAVI device and will
    not create a local binding for it.
    
    But then I am not sure whether it is really practical to assume that
    NADV messages always come from a trusted port.
    
    (18) [secdir#2]
    
    My second question concerns the construction of the prefix list. One
    option is to learn prefixes by listening to Router Advertisements. Is
    there a way to make SAVI do bad things by announcing bogus prefixes?
    
    (19) [secdir#3]
    
    My third question concerns this statement in the security
    considerations:
    
       The other type of attack is when an attacker manages to create
    state in the SAVI device that will result in blocking the data packets
    sent by the legitimate owner of the address.  In IPv6 these attacks
    are not an issue thanks to the 2^64 addresses available in each link.
    
    The second sentence makes this sound like a non-issue but it seems to
    be correct only if devices uniformly pick random addresses out of the
    full 2^64 address space. If for whatever reason I can guess with a
    decent likelihood an address, it looks like SAVI becomes a tool to
    help me with denying service for such an address.
    
    (20) The "Security Logging" section should be changed significantly to
    say that only suspected spoofing should be logged and that for privacy
    reasons SAVI MUST NOT otherwise log normal use of the network.
     
        
  8. Stephen Farrell: Comment [2011-05-23]:
    (1) I don't understand the sentence at the end of 2.1 " Manually
    configured IPv6 addresses can be supported by FCFS SAVI, but manual
    configuration of the binding on the SAVI device provides higher
    security and seems compatible with manual address management."
    
    (2) 2.2 says that "non-compliant" packets can be dropped - there's no
    IESG write-up so I'm wondering if this is safe or if there's any
    evidence that this would be safe? Has this been implemented and if so
    have any results of its effects been published? (I know that's not a
    requirement for PS, but in this case, I think it would be very useful
    information.)
    
    (3) 2.3 "prove address ownership" is too strong and I think ownership
    is the wrong phrase in any case.
    
    (4) I don't understand "FCFS SAVI function relies on state information
    binding the source address used in data packets to the binding anchor
    that contained the first packet that used that source IP address."
    Seems like it needs re-phrasing - "contained the first packet" is the
    wrong bit.
    
    (5) The "it" in "CFS SAVI function relies on state information binding
    the source address used in data packets to the binding anchor that
    contained the first packet that used that source IP address" seems
    ambiguous. I'm fairly sure it refers to each SAVI instance rather than
    the set of instances in a SAVI perimeter but that should be made
    clear.
    
    (6) State machine ascii art - expanding T.O. to timeout (I guess)
    would be clearer.
    
    (7) "MLD considerations" - should you s/relay/rely/?
    
    (8) From section 4 on there are more English language errors that
    should be fixed, e.g "The attacks against the SAVI device basically
    consist on making the SAVI device to consume its resources until it
    runs out of them" has two (and maybe 3) errors.  There are also some
    similar problems in Appendix A. (I have some marked up on paper so
    easiest will be if I try to list any that remain if you rev. the I-D.)
    
    (9) [secdir review nits]
    Editorial nits:
    
    - p10: s/because the connect/because they connect/  (twice)
    - p10: s/through validating port/through validating ports/
    - p11: s/prefixes.A/prefixes. A/
    - p13: s/may due/may be due/
    - p13: s/packets has been/packets have been/
    - p18: s/relay/rely/
    - p24: s/coalition/collision/
    - p26: s/case fixed/case of fixed/
  9. David Harrington: Discuss [2011-05-24]:
        There are many points in my DISCUSS, but most are requests to tighten the
    RFC2119 language, or explain in the text what the valid exceptions are to each
    SHOULD.
    
    1) this only deals with ipv6. The charter says ipv4 and ipv6 must be covered.
    Why doesn't this document also deal with ipv4, and is there another document
    that deals with ipv4?
    
    2) in 2.4, "For the rest of the document, we will assume that the binding
    anchors are ports of a switched network." Having this statement at the end of a
    paragraph in non-normative background text seems insufficient. To be compliant
    to this standard, the binding anchors MUST be ports of a switched network. I
    think this should be clearly specified in RFC2119 langauge in the normative
    section.
    
    3) in 2.5, "a secondary goal is to assist in traceability for determining who an
    improper actor is." I don't see this in the charter, and question whether this
    is an IETF-supported secondary goal. (I see that Stephen has raised a DISCUSS on
    this in more detail).
    
    4) in 3.2.2, "transit traffic and the packet SHOULD be discarded" why only
    SHOULD? what are the valid exceptions to this?
    5) in 3.2.3, "the SAVI device
    SHOULD execute the process of sending Neighbour Solicitation messages"
    s/SHOULD/MUST/
    6) "are NOT forwarded" s/are NOT/MUST NOT be/
    s/they are
    sent/they MUST be sent/
    s/are discarded/MUST be discarded/
    s/is discarded/MUST
    be discarded/
    s/packet is either stored or discarded/ - why the choice? Please
    use RFC2119 language.
    ... the rest o fthe state table shoul dbe in RFC2119
    terms.
    s/relay/rely/
    s/must join/MUST join/
    s/SHOULD join/MUST join/
    7) 3.2.4
    "SHOULD be connected" - when is ti valid to not be connected? should thi sbe a
    MUST to ensure that transit traffic is not dropped?
    multiple SHOULDs here; why
    not MUSTs? If SHOULD, what are the valid exceptions?
    8) 3.2.5 "will behave as if
    " - MUST behave as if
    9) section 4, why 4 bindings? where did 4 come from?
    Doesn't this exhuast memory four times faster than an implementation that
    reserves memory for 1 binding per port? Isn't the reserved memory wasted if the
    port consistently has only one binding?
    10) "A SAVI device MUST limit the amount
    of memory" I think this should be a SHOULD. If an implemnter chooses to allocate
    unlimited memory, they should probably be allowed to. How will thi sbeing a
    SHOULD impact interoperability, as compared to its being a MUST?
    11) "The other
    type of attack is when an attacker manages to create state in the SAVI device
    that will result in blocking the data packets sent by the legitimate owner of
    the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses
    available in each link." I don't see how the 2^64 addresses available mitigates
    the ability of an attacker to create state that would block a valid address.
    12)
    "the SAVI device can be used as an amplifier by attackers. In order to limit
    this type of attack, it is RECOMMENDED that the SAVI device performs rate
    limiting " why not MUST? 
        
  10. David Harrington: Comment [2011-05-24]:
    1)  in 2.3, "SAVI checks would not be fulfilled by the transit traffic" I think
    fulfilled might be the wrong word here; do you mean performed?
    
    2) a stylistiuc point. The document often uses "This means". This is totally
    unnecessary. Just say what it means without the "this means phrase". This means
    don't use this means.
    
    3) in 2.6, summary, "A SAVI device only verifies packets coming through one
    interface connected to the untrusted part of the topology." why only ***one
    interface*** per SAVI device?
    
    4) in 2.6, "In particular, it is important to avoid that the same source address
    is bound to different binding anchors in different SAVI devices. Should that
    occur, then it would mean that two hosts are allowed to send packets with the
    same source address, which is what SAVI is trying to prevent." Is this accurate?
    Does it necessarily imply there are two hosts?
  11. Pete Resnick: Comment [2011-05-24]:
    Section 2 title - I would prefer to strike "non-normative". I see
    no reason for it and the use of this expression is turning into an
    IETF fetish. Instead, you can add on to the the Introduction:
    "Section 2 gives the background and description of FCFS SAVI,
    and Section 3 specifies the FCFS SAVI protocol."
    
    Section 2.6:
    
       Before creating a SAVI
       binding in the local SAVI database, the SAVI device will send a NSOL
       message querying for the address involved.  Should any host reply to
       that message with a NADV message, the SAVI device that sent the NSOL
       will infer that a binding for that address exists in another SAVI
       device and will not create a local binding for it.  If no NADV
       message is received as a reply to the NSOL, then the local SAVI
       device will infer that no binding for that address exists in other
       SAVI device and will create the local SAVI binding for that address.
       (NOTE that the description included here is overly simplified to
       illustrate the mechanism used to preserve the coherency of the
       binding databases of the different SAVI devices.  The actual SAVI
       mechanism normative specification as described in Section 3 varies in
       the fact that in some cases it is the SAVI device that generates the
       NSOL while in other cases it simply forwards the NSOL generated by
       the end host, and that the SAVI device will send multiple copies of
       the NSOL in order to improve the reliability of the message exchange,
       among other things).
    
    Start with the words, "As a simplified example of how this might work:",
    and then strike the parenthetical NOTE entirely.
    
    Section 3 title - strike "normative"
  12. Dan Romascanu: Discuss [2011-05-26]:
        Section 3.2.5 speaks 'the case the SAVI device is a switch that supports
    VLANs'but provides no reference to what IEEE 802,1 specification it refers and
    what types of VLAN capable bridges (switches) are covered. Is the intent to
    cover all types of VLANs defined by IEEE 802.1? Clarification and proper
    references are required. 
        
  13. Peter Saint-Andre: Comment [2011-05-23]:
    Please expand "DoS" on first use and add an informational reference to RFC 4732.

rfc5590

  1. Stewart Bryant: Comment [2011-05-25]:
    
      

rfc5591

  1. (none)

rfc5953

  1. Pete Resnick: Discuss [2011-05-23]:
        I'd like to understand this bit of text in the interop report:
    
            Neither implementation claims to be a complete, bug-free
            production ready implementation, and occasional differences have
            been found noted between the implementations. To date, however,
            all the differences have fallen into one of these categories:
    
              - object not implemented yet
              - corner cases not handled yet
              - code needs to be refactored to meet requirement
    
            In other words, so far all issues are with a particular
            implementation, not with the specification.
    
    These are very general statements and I'm simply not clear on how it
    was determined that this wasn't a specification problem. 
        
  2. Pete Resnick: Comment [2011-05-23]:
    
        
  3. Peter Saint-Andre: Discuss [2011-05-25]:
        Much as I would love to believe that changing a bit of text in Section 7 solves
    the problem of moving SNMP-over-TLS from IDNA2003 to IDNA2008 (and recognizing
    that I provided that bit of text to the responsible AD!), I fear that it does
    not. I realize that probably few if any implementations of RFC 5953 have been
    deployed with internationalized domain names, which might be why the
    implementation report does not mention IDNs. However, from the standpoint of
    both protocol development and technology deployment I think there's more work to
    be done here. I look forward to discussing this on the IESG telechat. 
        
  4. Peter Saint-Andre: Comment [2011-05-25]:
    
        
  5. Robert Sparks: Discuss [2011-05-25]:
        1) There are several normative references in this document to RFCs that are not
    ready to progress to Draft Standard. It's not clear that the parts of those
    drafts that are used are stable. In particular, this RFC currently references
    RFC3490 - the RFC Editor note updates the reference to 5890, but did the interop
    testing cover implementations of this protocol using the techniques in 5890?
    Would any further changes to IDNA impact what's specified in this draft?
    Similarly, the draft references RFC5280, which has errata and a clarification
    draft in progress. Are the parts of 5280 this protocol uses stable?
    
    2) I believe asking the RFC Editor to issue a new RFC based on the existing RFC
    and a set of RFC Editor notes is likely to lead to unexpected trouble that could
    be avoided by processing this as a draft. At a minimum:
      - Is it clear what
    boilerplate the RFC Editor should use on the new RFC?
      - Who signs off on the
    new RFC in AUTH48? 
        
  6. Robert Sparks: Comment [2011-05-25]:
    
      

rfc5343

  1. (none)

draft-daboo-et-al-icalendar-in-xml

  1. Adrian Farrel: Comment [2011-05-25]:
    I have no objection to the publication of this document altough I
    raise a point below that seems to me to be a potntial issue.
    
    ---
    
    I'm not convinced that this document is completely future-proofed. I
    understand how future components, properties, and parameters will be
    converted into XML elements using a designated naming convention.
    
    But it seems to me that more complex entities (such as multi-valued
    properties) cannot be simply and automatically handled. Indeed, the
    need to present a schema in Appendix A (rather than simply define the 
    rules for how it is automatically created) seems to imply that there
    is a little more work that will be needed when future extensions to
    iCalendar are made.
    
    In view of this, I think we need a section specifically discussing
    extensions to iCalendar. I think that the current Section 5 is a
    subset of this new section.
    
    ---
    
    Nit
    
    Section 1
    "semantic meaning" 
    One of the words is redundant.
  2. Stephen Farrell: Comment [2011-05-26]:
    (1) In 3.6.5 can the date-time element value include TZ offsets? I think
    it'd be worth being explicit about this and adding a 2nd example with
    an offset if that's allowed. (It looks from the later examples like this
    is allowed.)
    
    (2) In 3.6.8 is INTEGER can be negative, then it'd be worth adding a
    2nd example with a negative number.
    
    (3) In 3.6.11, if UTF8 characters are allowed, then it'd be good to
    add an example like that, or if that's hard in an RFC, then just say
    so and if they're not allowed, then just say that to make a coder's
    life easier.
    
    (4) In 4.2 when it says "IANA, non-standard, inline encoding..." should
    there be a reference to make it easier for an implementer to figure out
    what this means? 
    
  3. Pete Resnick: Comment [2011-05-23]:
    - You claim that round-tripping is a design goal. I'm wondering about the base64
    and folding round-tripping. The document clearly takes into account cases of
    iCalendar objects that have unnecessary base64. Is it at all problematic that
    this will not round-trip according to the rules you set out?
    
    - Instead of "the table is a non-normative reference", how about "the table
    gives examples of ...". The words "non-normative reference" have a specific
    meaning in RFCs and there is no "referencing" going on here. If you really need
    to call out that these tables are not normative, say something in section 2 like
    "The examples given in the tables throughout this document, along with the
    schema in Appendix A and examples in Appendix B, are not authoritative, and if
    there is a conflict between these and the definitions given in sections 3 and 4,
    the definitions in section 3 and 4 are to be taken as authoritative."
  4. Sean Turner: Discuss [2011-05-19]:
        #1) Sec 3.1: Do you need a normative reference to the Base64 RFC:
    http://datatracker.ietf.org/doc/rfc4648/?  Also do you need to specify which
    alphabet you're using?
    
    #2) Sec 3.2: r/is an optional/is an OPTIONAL ?
     
        

draft-josefsson-gss-capsulate

  1. Russ Housley: Discuss [2011-05-24]:
        
      The introduction to this document says:
    
       The intention is that text from this specification should be possible
       to use for implementation documentation, and for this reason this
       entire document should be considered a code component.
    
      Claiming that the whole document is a code component is inappropriate.
      However, I have no objection to claiming that Sections 3, 4, and 5 are
      code components. 
        
  2. Pete Resnick: Comment [2011-05-23]:
    The writeup says that there are 3 implementations. Are they independent? Is
    there any sense in which the interoperate? The "interoperate" question is the
    really important one to me: I'm trying to figure out why a PS is being used for
    an API. Is there some way in which having the same API will make things
    interoperate better?
  3. Peter Saint-Andre: Comment [2011-05-23]:
    This document seems more Informational than Standards Track to me, but I have no
    objections to publishing it as a Proposed Standard.
  4. Robert Sparks: Comment [2011-05-25]:
    I agree with Russ' discuss regarding what portion of the document is a code
    component.

draft-ietf-xcon-examples

  1. Adrian Farrel: Comment [2011-05-24]:
    I am ballotting "No Objection" after only a light skim of the document, mainly
    trusting the RAI ADs to have checked this document. However, I do wonder whether
    one sentence in the Abstract is open to misinterpretation. It says:
    
       The
       objective is to provide a base reference for both protocol
       researchers and developers.
    
    That sounds like the flows in this document form part of the normative
    definition of the protocol. This is presumably not the intention of this
    Informational I-D. You can resolve this simply by moving that sentence from the
    Abstract to the Introduction and qualifying it by deferring to I-D.ietf-xcon-
    ccmp.
  2. Russ Housley: Comment [2011-05-24]:
      The Gen-ART Review by Francis Dupont on 5-Mar-2011 suggested several
      editorial changes.  Please consider them.
  3. Pete Resnick: Discuss [2011-05-26]:
        It's not clear to me why RFCs 3261, 4579, 4597, 4575, 5567, and draft-ietf-xcon-
    common-data-model and draft-ietf-mediactrl-call-flows are not all normative
    references. As far as I can tell, these are all required reading to understand
    this document.
    
    [I will likely clear this next one immediately, but I'm leaving here because I
    want to discuss this in the context of the other two xcon documents] I'm again
    worried about text that is common between documents, especially section 4 of
    this document. In particular, the information in 4.2 looks like it should be in
    section 9 of draft-ietf-xcon-ccmp. 
        
  4. Pete Resnick: Comment [2011-05-26]:
    
        
  5. Sean Turner: Discuss [2011-05-24]:
        Two issues related to passwords:
    
    a. Is it <password> or <conference-password>?  It's <password> in 6.2 message 1?
    Where is that defined?  It's not in 4575, or any of the other two xcon drafts on
    the telechat this week.
    
    b. Should these be exchanged over HTTPS!? 
        
  6. Sean Turner: Comment [2011-05-24]:
    There's a couple of places where Alice's xcon-userid: is alice@example.com and
    not Alice@example.com.  Not sure if you did this on purpose or not.

draft-ietf-siprec-req

  1. Stephen Farrell: Discuss [2011-05-25]:
        I think this is a bunch of what should be fairly easily resolved
    things.
    
    (2) I don't understand REQ-025's statement about the "same or
    different" encryption keys, and I suspect that the requirement, as
    stated,  might lead to bad designs, e.g. adding bad key export APIs
    to products. I think stating this in terms of keys is mistaken, it
    should probably be stated in terms of restricting access to the media
    (or something like that, not sure).
    
    (4) What non-repudiation requirements exist here? Put another way,
    who is expected to repudiate what, and how is that supposed to be
    prevented? Including NR might lead to significant complexity if not
    fairly tightly constrained.  I'd suggest just dropping mention of NR,
    unless there are specific requirements known at this point.
    
    (5) The security considerations says: "Means for ensuring the
    integrity and correctness of media and metadata emitted by an SRC are
    outside the scope of this work.  Other organizational and technical
    controls will need to be used to prevent tampering." That however,
    seems to conflict with REQ-029 at least.  Perhaps something else was
    meant, or I'm just confused?  
        
  2. Stephen Farrell: Comment [2011-05-25]:
    (1) "Furthermore, the scale and cost burdens vary widely, in all
    markets, where the different needs for solution capabilities such as
    media injection, transcoding, and security-related needs do not
    conform well to a one-size-fits-all model." That could do with being
    rephrased, I had to read it a few times before I got the message that
    one size doesn't easily fit all.
    
    (2) In figure 2, I assume that time runs from left to right but you
    might want to say that, e.g. add "t --->" at the bottom. If its meant
    to be something else, then you definitely want to say what.
    
    (3) REQ-005 - I think the "without loss of media" refers to the RS
    but not the CS - is that right? Maybe worth clarifying.
    
    (4) Just asking: REQ-019 is good, but was there any discussion about
    how much information to make available to a UA? E.g. whether or not
    card numbers won't be recorded. 
  3. Peter Saint-Andre: Comment [2011-05-23]:
    REQ-012 refers to "the identities of parties involved". The term "identity" is
    vague. I suggest changing "identities" to "identifiers" or, even better, "SIP
    identifiers" or "SIP addresses".
    
    In REQ-024, what is "wall clock time"?
    
    Regarding terms such as "authentication", "confidentiality", "encryption", and
    "integrity" in REQ-025 through REQ-032, an informational reference to RFC 4949
    seems appropriate.

draft-ietf-grow-geomrt

  1. Stewart Bryant: Comment [2011-05-23]:
    6.  Security Considerations
    
       This extension to the "MRT format" [I-D.ietf-grow-mrt] defines fields
       that are of a descriptive nature and provide information that is
       useful in the analysis of routing systems.  As such, the author
       believes that they do not constitute an additional security risk.  It
       is recommended that the operators of the BGP collector and Peers
       consider their own privacy concerns before supplying geographical
       coordinates in MRT dumps.
    
    Comment:
    
    Isn't there also an enhanced threat in revealing to a physical attacker the
    precise geographical location of a strategic router?
  2. Ralph Droms: Comment [2011-05-26]:
    I agree with other points raised about revealing physical location,
    and I have a couple of additional questions: 
    
    1. How does the BGP collector obtain the geolocation of its peers?
    
    2. From section 8:
    
       It
       is recommended that the operators of the BGP collector and BGP peers
       consider their own privacy concerns before supplying geographical
       coordinates to BGP data collection systems.
    
    Depending on the answer to 1, how does the BGP peer control how its
    geographical coordinates are supplied to the BGP collector?
    
  3. Wesley Eddy: Comment [2011-05-24]:
    Support the other ADs DISCUSS positions on Informational vs. Standards Track
    
    Further, the security considerations should at least mention the fact that
    there's no way to prevent someone from lying about location data, yet would
    appear to have no bearing at all on BGP operation.  It might totally mess up any
    later analysis someone is trying to use the MRT data for as they'd have little
    way to validate historic coordinates for a given router.
  4. Adrian Farrel: Discuss [2011-05-24]:
        draft-ietf-grow-mrt is Standard Track. I don't understand why this 
    I-D (which defines further protocol extensions) is Informational.
    
    Given that "This document extends the Border Gateway Protocol (BGP)
    Multi-threaded Routing Toolkit (MRT)..." I don't see why there isn't
    an "Updates" statement in the header.
    
    ---
    
    draft-ietf-grow-mrt appears to create an IANA registry to track 
    subtypes. Why does this document not include IANA actions for the new
    subtype that it defines?
    
    Note that the allocation procedures in draft-ietf-grow-mrt are "IETF
    Review" so you would be OK if this document does stay as Informational,
    but you would still need an IANA section. 
        
  5. Adrian Farrel: Comment [2011-05-24]:
    I agree with Stewart's point about physical security, and suggest that
    you should highlight the point.
  6. Stephen Farrell: Comment [2011-05-23]:
    - MRT is not expanded.
    - Good luck with the PhD/hope it went well:-)
  7. Russ Housley: Discuss [2011-05-24]:
        
      The Gen-ART Review by Roni Even on 16-Apr-2011 included two questions.
      These questions were asked in a Last Call comment, but the questions
      were not answered.  I would like to know the answers.
      
      1. Why not include it in draft-ietf-grow-mrt?
    
      2. Why is this Informational RFC and not standard-track like
         draft-ietf-grow-mrt? 
        
  8. Russ Housley: Comment [2011-05-24]:
      Please expand MRT when first used.
  9. Pete Resnick: Discuss [2011-05-24]:
        This can either be Standards Track or Experimental. It's not Informational. It's
    extending a Standards Track protocol. 
        

draft-ietf-savi-threat-scope

  1. Stewart Bryant: Comment [2011-05-23]:
    A useful document which I enjoyed reading
    
  2. Ralph Droms: Discuss [2011-05-25]:
        
    I will raise a meta-discussion issue before listing several specific
    Discuss points.  This issue may be just the suppressed pedantic
    ex-professor side of my personality expressing itself.  My issue is
    that the contents of this document are useful and not incorrect.
    However, in my opinion the document would be more useful, especially
    to someone who reads this document without a lot of background in the
    type of threats described, with some additional detail.  I could be
    persuaded that I am being overly pedantic, in which case I will clear
    my Discuss and move my points to Comments.  I will be happy to send
    text if the authors would find it helpful.
    
    1. In section 1:
    
       At the IP Network Layer, or Internet Layer, there is typically no
       required transactional state when communicating with other hosts on
       the network.  Hosts generating packets for transmission have the
       opportunity to spoof (forge) the source address of packets which they
       transmit.
    
    I think this paragraph needs more detail to connect the first sentence
    with the last sentence.
    
    2. Next paragraph:
    
       Source address verification is necessary in order to detect and
       reject spoofed packets and contribute to the overall security of IP
       networks.  In particular, source address verification techniques
       enable detection and rejection of spoofed packets, and also
       implicitly provide some assurances that the source address in an IP
       packet is legitimately assigned to the system that generated the
       packet.
    
    "Source address verification" can be used or is necessary?  You
    haven't told us what source address verification is, yet.  The second
    sentence in this paragraph doesn't seem to add any new information.
    What would be more helpful would be a sentence or two foreshadowing
    the details in section 3.  Why are packets with spoofed addresses
    dangerous?
    
    3. The attacks in section 3 fall, roughly, into two buckets: those that
    require spoofed source addresses and those that can use spoofed
    addresses to obfuscate the source of the attack.  SAVI can eliminate
    the former but only deter, through threat of discovering the
    perpetrator, the latter.  The difference is important to someone using
    this document to learn about how SAVI contributes to security in a
    network.  Otherwise, a network administrator might expect to eliminate
    all of the listed attacks with SAVI.
    
    An improvement would be to explain the two types of attacks and
    indicate the type of the attacks in section 3.
    
    4. I found the second sentence of the first paragraph of section 4
    very hard to parse and not entirely consistent with the title of the
    section.  While most of the solutions in section 4 have to do with the
    network topology, the first bullet:
    
       o  The IP source address is appropriate for the lower layer address
          (they both identify the same system)
    
    has nothing to do with network topology.
    
    The second bullet:
    
       o  The IP source address is appropriate for the device at the layer 2
          switch port (the address was assigned to a, and perhaps the,
          system that uses that port)
    
    does use network topology, but seems specific to wired networks; in
    fact, later in section 4, wireless networks are mentioned as using
    different techniques.  Might be better to write:
    
       o  The IP source address is explicitly identified as appropriate
          for the physical topology; for example, the source address
          is appropriate for the layer 2 switch port through which the
          datagram was received
    
    5. Section 4.1.1 changes in mid-section from checking the IP address
    against the Link Layer address to checking the IP address against the
    physical attachment point.  Is Link Layer address checking ever
    implemented on switches or is it always IP address checking versus the
    physical attachment point? 
    
    6. I suggest augmenting section 4.1.3 with a mention of IPv6 prefix
    checking, where the PE can be populated with the customer prefix
    through monitoring DHCPv6 prefix delegation.
    
    Also, the enterprise case can be augmented with prefix filtering based
    on the prefixes known by the ISP to be assigned to the customer.
    
    7. Sections 4.1.5 either needs more detail or pointers to references
    where more detail is available.  In its current form, it has little
    or no content.  The interesting parts of DOCSIS are the authentication
    and trust model, in which the ISP can control and trust the cable
    modem.
    
    8. Section 4.1.6 has more detail than section 4.1.5, but assumes some
    experience with DSL deployments and architectures.  Both of these
    sections would benefit from some explanation of the accountability
    model in which packets can be traced to an accountable entity,
    regardless of the specific address or prefix in the source address of
    a packet.
    
    9. Section 4.2.3.2 might benefit from just a little more detail, or a
    pointer to more detail:
    
      switch uses IP address to port binding
      switch enforces restrictions that DHCP server traffic is only
        accepted from "upstream"
      switch monitors DHCP traffic to glean address-port bindings
    
    This technique works for both IPv4 and IPv6.
    
    And, the discussion of SLAAC brings up the issue of authenticated SAVI
    versus "ad hoc" SAVI.  In the case of DHCP based SAVI, the switch can
    have authoritative information about the address/port binding, because
    it came from a reliable source (DHCP server).  SLAAC-based SAVI can
    only identify claimed addresses, where the hose may not be authorized
    to use the claimed address.
    
    10. Are the techniques mentioned in 4.2.4 really SAVI?
    
    11. What is a "residual attack" and how does the text in section 4.2.5
    describe a residual attack?
     
        
  3. Ralph Droms: Comment [2011-05-25]:
    1. Add DoS (yeah, I know DoS is pretty widely used already), "binding
    anchor" (and use "binding anchor" through the document), MITM, LAND,
    smurf attack, uRPF to section 2.  Some of these also have first-use
    expansion, which might be OK ... this suggestion is just a Comment.
    
    2. Suggestion: it would be more useful to incorporate any issues
    specific to IPv6 in the body of the document.
    
    3. First sentence of section 4:
    
       The first requirement is to eliminate datagrams with spoofed IP
       addresses from the Internet.
    
    First requirement for what?  I thought this document was exactly about
    "eliminat[ing] datagrams with spoofed IP addresses from the Internet."
    I suggest dropping the sentence.
    
    4. At the end of section 4, the bullet list calls out "enterprise CPE
    Router" explicitly.  Aren't residential CPE routers also a big
    opportunity?  How are they different from enterprise CPE routers.  In
    fact, perhaps "CPE" is not the best term?  How about "Enterprise edge
    router" and add "subscriber home router"?
    
    5. At the end of section 1, have the strength of your convictions:
    
       This document provides [...], and discusses [...].
    
    6. For consistency, in sections 3.2.1 and 4.1.1
    s/MAC address/Layer 2 address/ 
    
    7. Is "source address verification" equivalent to "Source Address
    Validation Improvement (SAVI)"?  If so, for consistency use one phrase
    or acronym throughout.
  4. Wesley Eddy: Comment [2011-05-24]:
    The document looks good, I just have a few comments that the authors might think
    about:
    
    Section 3.1.7 is titled "other blind spoofing attacks" but talks about non-blind
    attacks just as much.  The example given of a host on-link with routers is non-
    blind, for instance.  However, seciton 3.2 is where non-blind attacks are
    supposed to be discussed, so this part of 3.1.7 seems rather odd.
    
    Why isn't the relationship to SeND discussed in this document?
    
    VPN gateways have similar considerations as the Mobile IP HA in sectino 5.2.6,
    but VPN gateways don't appear to be discussed in 5.2.
  5. Stephen Farrell: Discuss [2011-05-26]:
        (1) What's the difference between "validation" (abstract) and
    "verification" (overview, 3rd para) as used here?  If there is
    none, then just use one. If this is a difference, then where are
    these defined?  I think in either case, some definition is needed.
    
    (2) I expected this document to also analyse source-address
    spoofing threats after SAVI mechanisms are deployed. If some simple
    form(s) of source address spoofing will work regardless of which
    SAVI mechanism(s) are in place then one would have to wonder if
    SAVI is worth deploying or not. If this is not the right document
    to cover that then what is? The fact that the SAVI mechanisms will
    each be in separate documents would seem to mean that this question
    won't otherwise be answered by the WG, and I think we do need an
    answer somewhere.  (The security considerations of the SAVI
    framework is currently one paragraph so that's not the place, at
    least not now.) Its probably worth noting that this issue is behind
    a number of cases below where I ask for evidence to justify what
    appear to be overly broad claims made.
    
    (3) What is the evidence that "Source address verification is
    necessary in order to detect and reject spoofed packets"? I'm
    asking why this is "necessary"as opposed to sufficient (if it is
    sufficient - see (2) above).
    
    (2) This presumably needs some form of qualification if not all
    packets with spoofed source addresses can be spotted: "source
    address verification techniques enable detection and rejection of
    spoofed packets." I'm not sure if "some spoofed packets" would be a
    good thing to say there but it does seem to be the case - a better
    qualification (or a forward reference to where that is described)
    would represent truth-in-advertising. 
    
    (3) Where in the charter is "local traceability" in scope? The
    charter does say that "tracking other protocols is not in scope" so
    local traceability needs to be defined as something limited
    to/scoped to spoofed source addresses.
    
    (4) "For example, when an enterprise receives a report of an attack
    originating within that enterprise, the operational staff needs to
    be able to track from the IP address sourcing the attack to the
    particular machine within the enterprise that is the source." I
    don't think that's true in general - "needs" is wrong since there
    can be other ways to find a zombie.
    
    (5) Spoofing is defined to cover both IP and MAC address spoofing.
    SAVI does not address the latter I believe (right?). If so, then I
    think you need to separate these as otherwise confusion between
    them might lead to incorrect conclusions being stated. Spoofing is
    also defined as "forging" but that is not defined and could be
    considered to be synonymous with "spoofing" here which would make
    this a circular definition. I think the definition of spoofing
    needs to be more precise basically.
    
    (6) 3.1: " The result is that they have no access to legitimate
    source and target systems." I think that's wrong - are you trying
    to say that "The attacker in this case should have no legitimate
    access to source and target systems." 
    
    (7) Does the ARP example in 3.2.1 really involve a spoofed IP
    source?  If not, then you should note that its not in scope for
    SAVI. If it is, then say why its in scope.
    
    (8) I'd be interested in knowing if SAVI can help with 3.2.2 - if
    not then saying so would be right. If so, then saying when SAVI
    might help would be good.
    
    (9) If "The first requirement is to eliminate datagrams with
    spoofed IP addresses from the Internet." then SAVI would seem to be
    facing an impossible problem. The "can eliminate such datagrams"
    part also seems overstated - where's the evidence that that's true?
    s/eliminate/reduce/ would seem to be more correct. 
    
    (10) Saying that "Internet devices can...confirm...that the IP
    address is appropriate for the lower layer address" is not true of
    all "Internet devices" only for some near the source, so that's
    also overstated and needs to be qualified. (It is later to be fair
    but the statement itself is wrong.)
    
    (11) I don't know the answer here, so this is just a question -
    what is the likelihood the uRPF check works well? (I didn't find
    the string uRPF in RFC 3704, so I'm not sure, but I didn't really
    read 3704;-) I guess the real question is whether a failure in uRPF
    might break anything for a non-spoofing host and whether a spoofing
    host could make it so that uRPF checks allow the packet with a
    spoofed address through (from e.g. the same subnet, or for certain
    guessable source addresses). I ask (in part) since 4.2.2 says that
    uRPF is a crude mechanism.
    
    (12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope
    for SAVI.  Can you make that clear?
    
    (13) What does "unforgeable" mean in 4.2.3? Perhaps you need to
    define that term as well? It may be that the meaning differs for
    e.g. MAC addresses and other credentials (noting that passwords can
    be guessed or shared of course). 
    
    (14) In 4.2.3 where is the evidence that "a large portion of the
    ...threat space...can be marginalized" - I think that needs some
    qualification.
    
    (15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically
    provide sufficient binding information" - is there evidence for
    that somewhere?  Be good to reference it.
    
    (16) 802.1X determines the identity of a user, not a system I
    think.
    
    (17) I think 4.2.5 needs to better characterise the "residual
    threat" (not "residual attack") - for each of the various forms of
    SAVI. I had hoped this document would say what spoofing
    possibilities remain.  Providing just one example doesn't seem
    sufficient.
    
    (18) Section 6 (at least) should also recognise that there are
    privacy considerations that apply and that more-or-less directly
    run counter to the ability to trace the source of problems.
    
    (19) Section 8 should note that circumstantial evidence linking a
    person to an IP address can be dangerous for the person. There have
    been cases where such tracking has mis-identified people
    responsible for some act. (I don't have a reference to hand sorry.)
    
    (20) If no set of deployed SAVI instances can prevent all spoofing
    from a given network then an attacker could probe the network to
    find out what spoofing works from where they are at, and then use
    that. Success in spoofing would then likely have more consequences
    for an innocent spoofed party. This would be a new threat caused by
    SAVI itself.
    
    (21) If binding anchors are personally identifying or stable over
    time or location then recording those creates new threats for tracking 
    the user or host associated with the binding anchor. That needs to 
    be noted.
     
        
  6. Stephen Farrell: Comment [2011-05-26]:
    (1) 2nd para of overview says that there is "typically no required
    transactional state when communicating with other hosts on the
    network." I think it'd be good to say why that's the case, via a
    reference to something.  (Not sure what reference is best exactly.)
    
    (2) What is a "better Internet participant"? It sounds like a scary
    thing.
    
    (3) s/This both that the information be useable/This requires both
    that the information be useable/
    
    (4) I expected to see some CVE references in section 3 but didn't
    see any. I'd encourage adding some of those for each of the threats
    covered since that should help motivate the work and would
    demonstrate that there are real threats to mitigate. (E.g. a quick
    search on "CVE spoofed source" throws up a bunch.) To take one
    example, 3.1.4 could do with such a reference.
    
    (5) Expand "LAND"
    
    (6) The DNS attack described around the top of page 9 isn't
    relevant to SAVI, right? Maybe the smurf attack is enough there.
    
    (7) Do 3.1.6 and 3.1.7 really fit in 3.1? 
    
    (8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do.
    
    (9) Even IPsec doesn't unquestionably verify source address if
    load-balancing is in place with private key sharing.
  7. David Harrington: Comment [2011-05-23]:
    I found this document to be very informative about the problem space.
    I think
    this document could have been far more effective if the text didn't meander
    around the points it was trying to make; it could habve been far more succinct.
    Here are some suggestions that I think could improve the document.
    
    1) I find the following ambiguous, "the operational staff needs to be able to
    track from the IP address sourcing the attack to the particular machine within
    the enterprise that is the source. " I think the intention is that "the IP
    address sourcing the attack" means the spoofed address, and "that is the source"
    means the actual sending machine, but I'm not sure. This can be read as "the
    staff needs to track from the source to the source."
    2) This sentence doesn't
    parse properly, "This both that the information be useable ..." I think the
    sentence is missing "means" or "requires" or something.
    3)  The glossary should
    include references to the defining documents.
    4) "or order to disrupt" -> "in
    order to disrupt"
    5) 3.1.3 doesn't describe what a poison attack is. It also
    refers to "the same kinds of poisonings as above", but above never spoke of
    poisoning attacks.
    6) the following seems a bit perverted logic - a malware
    attack is important because it is a justification for SAVI?
    "This attack is
    important both in terms of an attack vector that SAVI may help prevent, and also
    as a problem which SAVI can help track back to find infected systems. "
    Shouldn't you be arguing that savi is important for preventing these types of
    attacks? 
    7) section 3.2.2 "Another example of sighted attack" - this is the
    first mention of "sighted attack". Please use consistent terminology.
    8) in
    section 3.2.2, "The use of spoofed addresses, while not necessary for this, can
    often provide additional information, and helps mask the traceability of the
    activity." would seem to be the conclusion of the paragraph, but this precedes
    the discussion of what the attack is.
    9) in scetion 4, "the first requirement"
    isn't followed by any further requirements. and is this section going to
    describe the requirements or the solutions?
    10) "The IP source address is
    appropriate for the lower layer address (they both identify the same system)".
    I find "is appropriate" too ambiguous, although the following parethetical text
    explains it. I suggest this would be better written as "the IP source address
    and the lower layer address both identify the same system."
    11) "The IP source
    address is appropriate for the device at the layer 2 switch port" I find "is
    appropriate" too ambiguous.  
    " (the address was assigned to a, and perhaps the,
    system that uses that port) " doesn't parse appropriately. I think this bullet
    needs a better description.
    12) section 4.1.1 "Port identification prevents
    transmission of malicious datagrams" Is thistrue? or is port identification one
    method that can be used to help prevent transmission? 
    13) 4.1.3 "An obvious
    special case of the discussion is with an ISP PE router, " - what discussion?
    This section seems based on speculation about possible solutions, including
    contract negotiations. I think this would be much better if it actually focused
    on technical solutions for validating addresses for ISP edge routers.
    14) 4.1.4
    again discusses business agreements between two conpanies. Please focus on
    ***technical*** solutions at this topological location.
    15) 4.1.4 "However, when
    it can be shown that spoofed addresses are present, the procedure can be
    applied. " what procedure?
    16) 4.2.5 is entitled residual attacks, but there is
    no discussion of residual attacks in the paragraph. The hand-waving contained in
    the paragraph doesn't seem worth documenting.
    17) why is 4.2.5, "residual
    attacks", included in section 4 "Current anti-spoofing solutions"?
    18) 5.2.6
    what does "proper member" mean? where is this defined?
    19) 5.2.7 - doesn't this
    sum up the whole section 5? since it includes anything not covered in 5.1 or
    5.2, shouldn't this be 5.3?
    20) is 5.3 about topological challenges? it seems to
    meander on about additioonal capabilites, rather than discussing the topological
    challenge to SAVI.
  8. Russ Housley: Discuss [2011-05-24]:
        
      The Gen-ART Review by David Black on 12-May-2011 lead to a discussion
      with one of the authors.  At the end of the discussion, several
      changes to the document were agreed.  However, those changes have
      not been made. 
        
  9. Dan Romascanu: Comment [2011-05-25]:
    I find the document comprehensive but I share DBH's observation that it's a
    little too verbose and could use some fixes in the details.
    
    Beyond what he found I have a few more observations. None is critical for this
    informational document, but cleaning up all these text unclarities in a new
    version would be recommended;
    
    1. In the Glossary section
    
    NNI Router:  Network to Network Interface Router.  This router
          interface faces a similar system operated by another ISP or other
          large network.
    
    I think that the definition should read something like 'A router with interfaces
    facing a similar system ...'
    
    2.  Section 4.2.3.3
    
       IEEE 802.1x is an authentication protocol that permits a network to
       determine the identity of a system seeking to join it and apply
       authorization rules to permit or deny the action.  In and of
       themselves, such tools confirm only that the user is authorized to
       use the network, but do not enforce what IP address the user is
       allowed to use.  It is worth noting that elements of 802.1x may well
       be useful as binding anchors for SAVI solutions.
    
    This is quite confusing. IEEE 802.1X is a port (in the sense of bridge or layer
    2 switch) access control standard that controls the joining of devices to a
    layer 2 bridged network. The term 'tools' is not in place and there is nothing
    about the 'user' in the protocol itself but about the device - the standard uses
    the term 'supplicant' which is rather the device or the piece of software
    running on the device that presents credentials to an authenticator.
    
    3. In section 5.2 'hosts connected to switch ports that may have one or more IP
    addresses' is probably rather 'hosts that may have one or more IP addresses
    connected to (layer 2) switch ports'
  10. Peter Saint-Andre: Comment [2011-05-23]:
    Please expand "DoS" on first use and add an informational reference to RFC 4732.

draft-giralt-schac-ns

  1. Stephen Farrell: Comment [2011-05-21]:
    (1) Some examples would be nice.
    
    (2) https://urnreg.terena.org/ doesn't seem to currently have anything very
    human readable.
    Be good to fix that before the RFC issues.
  2. Sean Turner: Comment [2011-05-20]:
    #1) I followed the MACE link and got a 404 error.  Maybe this one instead:
    http://middleware.internet2.edu/urn-mace/
    or you could point to RFC 3613?
    
    #2) Sec 2:  I compared the SCHAC-NSS and MACE-NSS.  The only difference is as
    follows:
    
    MACE-NSS        =   1*(subStChar) 0*(":" 1*(subStChar))
    
    SCHAC-NSS    =   1*subStChar *( ":" 1*subStChar )
    
    I assume they evaluate to the same thing?
    
    #3) A couple of nits on the last paragraph of Section 3:
    
       ... sites offering credentials signed by a community recognised
                                                 ^ SCHAC-community
       Certificate Authority (CA) and that WILL require the latest secure
                 ^ion                      ^^^^will
       methods for accessing a web site, that currently being HTTP [11] over
       the latest version of TLS [12].
    
    Normally, I'd say point to RFC 2818 for HTTP over TLS (i.e., HTTPS), but I guess
    you might be trying to make people use TLS 1.2?  What about the following:
    
       In order to guarantee the validity and origin of SCHAC-NSS URN
       values, they MUST be published over https links [11].  The https links
       MUST be secured by sites offering credentials signed by a SHAC-community
       recognised Certification Authority (CA) using the latest secure
       methods for accessing a web site, that currently being the latest
       version of TLS [12].
    
    Replace [11] with 2818 instead of 2616 because 2818 points to 2616.
    
    #4) Because of the MUST(s) in the last paragraph references [11] and [12] are
    now normative.

draft-haleplidis-forces-implementation-experience

  1. Jari Arkko: Comment [2011-05-26]:
       2.  NAT issues.  ForCES can be deployed everywhere and can run over
           SCTP/IP.  In order for the FE and CE to work behind NATs you must
           ensure that the TML ports are forwarded and that the firewall
           allows SCTP through.
    
    This seems to be mixing NAT and firewall issues. Clearly, support NATs
    requires for those NATs to be capable of handling SCTP traffic to begin
    with. In addition, firewalls may have to be configured to let the traffic
    through.
    
    I found Section 3.3 very hard to understand for someone who is not
    closely familiar with the Forces technology.
    
    I don't understand why we need sections that talk about very generic topics,
    like 3.4.2 that describes how to decode a protocol message.
    
    And maybe more generally, I'm not sure what I learned from this document
    in terms of real forces implementation experience. Where are the difficult
    areas? Is the spec broken in places? Are there interoperability problems?
    Is further work needed in some issue?
    
  2. Stewart Bryant: Comment [2011-05-23]:
       Developers of ForCES FEs and CEs should take the security
       considerations of the Forwarding and Control Element Separation
       Framework [RFC3746] and the Forwarding and Control Element Separation
       Protocol [RFC5810] into account.
    
    Why is this a should and not a must?
  3. Ralph Droms: Comment [2011-05-26]:
    In this text:
    
    3.3.  Model
    
       The model inherently is very dynamic.
    
    What "model"?  The Forces data model?
    
    More generally, I agree with Jari's comment about the content of the document.
    I learned a little about potential issues in implementing the struct component
    (but no details).  Are there any other major implementation issues aside from
    struct components and handling protocol messages?
  4. Stephen Farrell: Comment [2011-05-23]:
    s/difficulty lie/difficulty lies/
  5. Russ Housley: Comment [2011-05-24]:
      The Gen-ART Review by Francis Dupont on 9-May-2011 suggested several
      editorial changes.  Please consider them.

draft-hoffman-alt-streams-tracker

  1. Stewart Bryant: Discuss [2011-05-23]:
        The Independent stream need a rejected (sub)state.
    
    The "no longer in ISS" state as it stands seems to leave open the posibility of
    a DOS attack by resubmitting the same text.
    
    ISE "On hold" looks like it needs a sub state to deal with the case where it is
    desirable to sequence a WG document ahead of an ISE document but otherwise there
    is no objection. 
        
  2. Stewart Bryant: Comment [2011-05-23]:
    There should be a security note stateing that putting April 1st IDs in the
    tracker would be damaging to their purpose.
  3. Peter Saint-Andre: Discuss [2011-05-23]:
        I intend to ballot "Yes" on this document. However, as discussed within the
    IESG, this document needs some text making it clear that the IETF Data Tracker
    is not (or, upon approval of this document, will not be) limited to the IETF
    stream. I suggest adding the following note after the third paragraph of the
    Introduction.
    
       Note:  The term "IETF Data Tracker" is used as a generic name for
       the existing tool used to track state changes as Internet-Drafts are
       processed before hand-off to the RFC Editor.  The word "IETF" in
       the name "IETF Data Tracker" is not meant to limit use of the tool
       to the IETF document stream; this document expands use of the
       tool to the other streams described in [RFC4844].
     
        
  4. Robert Sparks: Discuss [2011-05-24]:
        Section 7 should be filed as a bug against the tracker and be removed from this
    draft before publication as an RFC.
    
    The intent of this document (and the other recent tracker requirements document)
    is to inform an initial development effort. I don't believe they were intended
    to stand as the requirements against a running tracker, being updated frequently
    and gathering errata. It would probably help to say that explicitly.
    
    Specifically, I don't think it's a good idea to have to update the RFC this
    becomes to change the Subject line or contents of a notification email. Further,
    I don't think updating this RFC (or the related ones) is the right tool to use
    to refine the states defined in the tracker as experience with them tells us we
    need new ones. 
        
  5. Robert Sparks: Comment [2011-05-24]:
    It would help to explicitly state that a document can't be in more than one
    stream at the same time. In particular, it can't be in the Candidate/Submission
    received states of more than one stream at the same time. It would probably be
    useful to the implementer to call out this includes the streams not covered in
    this document.