IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Redaction of Potentially Sensitive Data from Mail Abuse Reports (Proposed Standard)
    draft-ietf-marf-redaction-05
    Token: Pete Resnick
    Discusses/comments (from ballot 3857):
    1. Stewart Bryant: Comment [2012-01-13]:
      I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there a plain text attack when encrypted material has a constant string included as seems to be the case here.
    2. Stephen Farrell: Discuss [2012-01-15]:
      (Updated-discuss - thought about it a bit more;-)
      (1) The construct here is output=H(redaction-key|sensitve-value). I don't think that's ok. I think you want HMAC() and not H().
      If I could supply a redactor with a zero length "private" string, e.g. message with a header field like "To: @example.org" then the redactor will send H(redaction-key) which can then allow (via hash-continuation) checking if any value matches a value from an output here.
      If the alphabet for sensitive values has N characters then I can also send "To: "+char[i]+"@example.org" for each i and then play the continuation game on that. Same for two character prefixes etc.
      (2) I can also use this to validate guesses of the redaction key value. I need to think about how one might avoid that or if its possible to avoid that.
    3. Stephen Farrell: Comment [2012-01-15]:
      - I don't get why this is not informational - where's the interop consequence?
      - While the idea of only listing JD is laudable, I think having a concactable author is best so I'd suggest Murray be kept as an author.
      - Last para of section 1 - such correlation is not theoretical, delete that word.
    4. Russ Housley: Comment [2012-01-18]:
      Please reference RFC 4648, Section 4 for [Base64]. More than one alphabet is available in RFC 4648.
    5. Dan Romascanu: Comment [2012-01-17]:
      This is a rather short and aparently straight-forward document, but it raised a couple of questions. None of them is that critical to deserve a blocking DISCUSS, but yet I would be glad if these were answered and clarified before approval and publication.
      1. It is not clear why this document is on standards track. I do not know how to establish interoperability of implementations and thus what the critieria would be for advancement from Proposed Standard to Standard. Moreover the Abstract describes the scope in a rather non-commital manner (suggests one method for ... the report generator ... to redact or elide the sensitive portions of the message) - so this looks like a recommendation about one (good way) to perform redaction, but not the <standard way> of doing it.
      2. I know too little about the operational model of configuring a report generator, so I was left wondering how are the first two recommendations implemented in practice:
      - 1. Select an arbitrary string that will be used by an Administrative Management Domain (ADMD) that generates reports. This string will not be changed except according to a key rotation policy or similar. Call this the "redaction key".
      - 2. Identify string(s) (such as local-parts of email addresses) in a message that need to be redacted. Call these strings the "private data".
      Some text that clarifies how this is supposed to be implemented and configured in practice would be useful.
    6. Peter Saint-Andre: Comment [2012-01-17]:
      I agree with other IESG members that this document seems informational, not standards track.
    7. Sean Turner: Comment [2012-01-18]:
      Updated (add the last two)
      I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.
      You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6194 for recent info on HMAC-MD5 and HMAC-SHA1. It would stop people from trying to do something over kill like HMAC-SHA256.
      If you're going to stick with the plain ole hash then pointing to 6151 and 6914 still is worth considering (i.e., MD5 bad).
      Probably worth a reference to RFC 4086 for the pseudo-random # issues.

    Telechat:

  2. Authentication Failure Reporting using the Abuse Report Format (Proposed Standard)
    draft-ietf-marf-authfailure-report-10
    Token: Pete Resnick
    Discusses/comments (from ballot 3923):
    1. Adrian Farrel: Comment [2012-01-02]:
      I have no objection to the publicaiton of this document as an RFC, but here are a few trivial nits...
    2. Stephen Farrell: Comment [2012-01-16]:
      - Section 2.4 (esp the title) is a bit odd, I'm sure its there for a reason but its not at all clear to this reader. (But I don't mind)
      - 3.1 - who's SOURCE-IP is meant here? Might be clear from ARP but not so clear from here - same for REPORTED-DOMAIN. Better to be crystal clear really.
      - 3.2.1 - the "policy" value is a bit vague, but that's ok I guess.
      - I'm not 100% clear about the rule for handling DKIM and redaction. Is it that the sender just chooses whether to send the unredacted possibly-DKIM-valid value or the redacted version with no DKIM info, or are you just supposed to never (as in MUST NOT) send a redacted message if the message had DKIM header fields? That might be there but I missed it if so.
    3. Peter Saint-Andre: Comment [2012-01-17]:
      Section 2.3 states: "base64 is defined in [MIME]."
      Well, base64 is also defined in RFC 4648. :) Perhaps it would be better to say:
      This specification mandates use of base64 as defined in [MIME].
      Section 3.1 states: "Delivery-Result: As specified in Section 3.2.2. This field is OPTIONAL, but MUST NOT appear more than once. If present, it SHOULD indicate the outcome of the message in some meaningful way, but MAY be redacted to "other" for local policy reasons."
      I think "redacted" is not right here (causes confusion with the redaction I-D). I suggest "set".
      Section 3.1 also states: "For privacy reasons, report generators might need to redact portions of a reported message such as the end user whose complaint action resulted in the report. A discussion of relevant issues and a suggested method for doing so can be found in [I-D.IETF-MARF-REDACTION]."
      I don't think you can redact an end user. :) I suggest "an identifier or address associated with the end user..."
      Section 6.2 states: "These reports may be forged" and "DKIM failure reports may produce reports". I suggest changing "may" to "can" and "might", respectively.
      Section 6.3 states: "Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information."
      Do you mean "MAY"?
      Section 6.5 states: "The use of this for "near-identical" incidents in particular causes a degradation in reporting quality, however. If for example a large number of pieces of spam arrive from one attacker, a reporting agent may decide only to send a report about a fraction of those messages. While this averts a flood of reports to a system administrator, the precise details of each incident are similarly not sent."
      Do you mean "MAY"?
    4. Sean Turner: Comment [2012-01-06]:
      I find it a little odd that the requirements language for what's optional/required in the different reports (s3.2.*) appear in the section titles but not in the text.

    Telechat:

  3. RADIUS Support for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netext-radius-pmip6-06
    Token: Jari Arkko
    Note: Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.
    Discusses/comments (from ballot 4004):
    1. Stephen Farrell: Discuss [2012-01-18]:
      The security considerations section refers to 2865, 2866 and 3579 which do have pretty good security considerations. However, this spec seems to me to introduce new things, such as sending the interface ID, which I think raises at least new privacy considerations. The ones that I think may be relevant here are the Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the PMIP6-Visited-Interface-ID, Calling-Station-Id and the Chargeable-User-Identity. Since I'm not quite sure how these are intended to be used, I'm also not sure what, if anything, needs to be said about them in security considerations, so I'd like to DISCUSS that.
    2. Stephen Farrell: Comment [2012-01-18]:
      How is the right policy store/profile selected? I suspect this is covered elsewhere (probably in 5213?) but it wasn't clear to me.
    3. Russ Housley: Discuss [2012-01-17]:
      The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern and several editorial suggestions. The authors and Elwyn seem to agree that the following text will resolve the concern, but it is not in the document yet:
      "When this bit is set the PMIP6_SUPPORTED flag MUST also be set, and the IP4_HOA_SUPPORTED flag MUST NOT be set."
    4. Pete Resnick: Discuss [2012-01-16]:
      4.3. Service-Selection: "The Service-Selection attribute (Type value TBD2) is of type UTF-8 text and contains the name of the service or the external network that the mobility service for the particular MN SHOULD be associated with [RFC5149]. The identifier MUST be unique within the PMIPv6 Domain."
      I've got a question about being "unique". My understanding is that UTF-8 text is normally used in Radius for "display to the user only" text and is not compared to other pieces of text. Here you say it "MUST be unique". How "unique" does it need to be? That is, if one identifier contains an "a" followed by a combining acute accent (U+0061 U+0301), and another identifier contains the a-with-acute-accent (U+00E1), are those "unique"? I guess the main question is: What are these things being used for and will the above make a difference? I think either way, some more information is needed in this paragraph to explain.
    5. Pete Resnick: Comment [2012-01-16]:
      (blank)
    6. Peter Saint-Andre: Comment [2012-01-17]:
      I concur with the DISCUSS position lodged by Pete Resnick.

    Telechat:

  4. Bulk Binding Update Support for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netext-bulk-re-registration-10
    Token: Jari Arkko
    Note: Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.
    Discusses/comments (from ballot 4007):
    1. Pete Resnick: Comment [2012-01-18]:
      There are several uses of 2119 language in section 5 and 6 that are inappropriate:
      5.1: I have no idea why "The following considerations MUST be applied by the mobile access gateway when supporting this specification" is at all useful. The entire sentence should be deleted.
      5.1.1: This is worded oddly. It's not that the data structure "MUST be extended", it's that the new fields MUST be included. I think what you probably mean is, "The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to include the following REQUIRED additional fields." Of course I assume that they are now "required for interoperation" [2119] or that not having them "has potential for causing harm". [2119] If not, then there shouldn't be 2119 language at all.
      5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the following considerations" adds. The requirements are in the paragraphs below. If you don't want to strike the sentence, sufficient would be, "The following are considerations for the mobile access gateway for requesting bulk binding update support for a mobility session."
      I think the "MAY" in the first bullet should be "can".
      In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise, what you're saying is "You MUST do everything in section 6.9.1 that says MUST", which seems silly and redundant.
      5.1.3: In the first and second bullet, s/MAY/can
      Also, the last sentence of the first and second bullets have the same problem as the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps instead, say something like "The requirement of section 5.3.3 of [RFC5213] is amended to allow a Mobile Node Group Identifier in place of the individual session identifiers."
      In the third bullet, the MUST seems useless. How could the gateway not "consider the request as a bulk revocation request"?
      5.2: Similar to 5.1.
      5.2.1: First sentence similar to 5.1.1.
      5.2.2: First sentence similar to 5.1.2. But I would simply move the first bullet up into that first sentence so it says:
      "5.2.2. Enabling Bulk Binding Update Support for a Mobility Session
      "The local mobility anchor will process a received Proxy Binding Update message as specified in [RFC5213]. However if the (B) flag in the received Proxy Binding Update message is set to a value of (1) and if it includes a Mobile Node Group Identifier option with sub-type value of (1) (bulk binding update group), the following processing takes place:"
      In sections 6.1 and 6.2, I am concerned about the statements containing "MUST allow the following variables to be configured by the system management" since that seems to go against 2119 where it says that the terms "must not be used to try to impose a particular method on implementors where the method is not required for interoperability." Is there an interoperability reason that these variables MUST be configurable?
      Also, the SHOULD and MUSTs in the definition of the variables doesn't seem right. These are not protocol requirements; they are descriptions of the meaning of the variables.
    2. Robert Sparks: Comment [2012-01-17]:
      Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request is rejected. One place to do this is 5.2.3 bullet 4, where you could say "for any reason (including administrative)" instead of "for any administrative reason".

    Telechat:

  5. OSPFv2 Multi-Instance Extensions (Proposed Standard)
    draft-ietf-ospf-multi-instance-09
    Token: Stewart Bryant
    Note: Manav Bhatia (manav.bhatia@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 4020):
    1. Ron Bonica: Comment [2012-01-16]:
      I agree whole-heartedly with Adrian's Discuss regarding redefining fields from another RFC rather than referencing them.
    2. Adrian Farrel: Discuss [2012-01-15]:
      I would be happy to ballot Yes on this document, but there are a couple of minor areas where I think the document needs work.
      I have a hot button about redrawing and redefining protocol fields. There is a risk in this duplication, and problems for future extensions. Your figure in Section 2 reproduces material from RFC 2328. How much of this is necessary? Is it helpful to sometimes say that a field is "as specified in [OSPFV2]" and sometimes write text that duplicates RFC 2328 without actually changing anything?
      I think you might get away with the figure and text that says:
      "All fields are as defined in [OSPFV2] except that the Instance ID field is new, and the AuType field is reduced to 8 bits from 16 bits without any change in meaning. The Insatnce ID fiels is interpreted as follows:"
      In Section 8 you need to inform IANA that you have reduced the available range of values for AuType. This changes the registry.
      The registry in Section 8 shows a number of instance ID value settings (namely "Base IPv4 Multicast", "Base IPv4 In-band Management Instance", and "Local Policy") without any discussion of the meaning in this document. That will not do! You must add description of the meaning of these settings somewhere in the body of the document.
      Section 8 describes the allocation policy for the range 3-127 as "Reserved for local policy assignment". There is no such allocation policy in RFC 5226. Do you mean "Private Use"? It is hard for me to guess given the total lack of description of this range of settings as noted in my previous point.
    3. Adrian Farrel: Comment [2012-01-15]:
      I have a few additional Comments that I think would improved the document and I hope you will consider incorporating them into a new revision.
      The Abstract is very dense. Nothing wrong with what you have written, but it's quite hard work. How about...
      "OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilise such a mechanism in order to support multiple routing domains on the same subnet.
      "This document defines the OSPFv2 instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 instance ID is reserved for identifying protocol instances.
      "This document updates RFC 2328."
      Note that I have left out of the Abstract the statement about how a different function is supported by a different protocol extension defined in a different document!
      You are inconsistent about whether to say "OSPF" or "OSPFv2" when refering to OSPFv2. Given that you keep comparing to OSPFv3, I think it would be helpful to always say "OSPFv2".
      You use phrases such as "OSPFv2 currently doesn't offer" which are, of course, correct before this becomes an RFC, whereupon they become wrong. If you can avoid this sort of thing by saying "This document defines..." then the draft is future-proofed.
      Can you please replace the future tense with the present tense. For example, Section 3
      "OSPF [OSPFV2] describes the conceptual interface data structure in section 9. The OSPF Interface Instance ID will be added to this structure. The OSPF Interface Instance ID will default to 0."
      Section 3.1: "When sending OSPF packets, if the OSPF Interface Instance ID has a non-zero value, it will be set in the OSPF packet header."
      Surely the zero value is also set in the packet header. That is, the field is not left uninitialised.
    4. Stephen Farrell: Comment [2012-01-19]:
      Yep, I agree with all the "what a hack" comments. OTOH, I do agree that its not likely that a 256th auth type will be needed here.
      I also agree that the abstract is very unclear and should be rewritten.
    5. Peter Saint-Andre: Comment [2012-01-17]:
      Although the authors appear to have documented the interoperability implications of reducing the AuType field from 2 octets to 1 octet, that still feels like a hack to me. However, I lack the context to judge whether the implications have been fully understood or documented. (Note also that this issue is not even mentioned in the shepherd writeup!)
    6. Robert Sparks: Comment [2012-01-16]:
      The abstract (identical to the introduction except for references) doesn't actually describe what this document does.
    7. Sean Turner: Comment [2012-01-18]:
      I'm with Peter on this draft - I too lack the background and ultimately trust that the AD is doing the right. But, I am curious why this wouldn't be a version # change especially if it affects all implementations.

    Telechat:

  6. A SASL and GSS-API Mechanism for SAML (Proposed Standard)
    draft-ietf-kitten-sasl-saml-08
    Token: Stephen Farrell
    Note: The document shepherd for this document is Shawn Emery (shawn.emery@oracle.com).
    Discusses/comments (from ballot 4029):
    1. Adrian Farrel: Comment [2012-01-16]:
      I cleared.
    2. Russ Housley: Discuss [2012-01-17]:
      The Gen-ART Review from Ben Campbell was updated on 13-Jan-2012. Ben provided a Gen-ART Review of -06 at Last Call, and this updated review covers -08. Version -08 is considerably improved, and it resolved most of Ben's comments. I would like to see responses to these four comments;
      1) section 3.2, last paragraph: "... needs to correlate the TCP session from the SASL client with the SAML authentication."
      Please elaborate on this correlation. The author added text, but the new text is about correlating response with request. The text that Ben mentioned was about correlating a TCP connection to a SAML authentication.
      2) section 4, 3rd and 4th paragraphs (paragraphs a and b) seem like protocol affecting differences. If so, they need elaboration, such as normative statements and formal definitions, or references to such.
      Ben did not see a response to this comment.
      3) section 5, general: The section seems to need further elaboration or references.
      Ben did not see a response to this comment.
      4) Also, this section compresses the interaction with the identity provider. Why not show the details for those steps like the others? (If you mean them to be out of scope, then why give as much detail as you do?)
      Ben did not see a response to this comment.
    3. Dan Romascanu: Comment [2012-01-17]:
      8.2. IANA OID: "The IANA is further requested to assign an OID for this GSS mechanism in the SMI numbers registry, with the prefix of iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to reference this specification in the registry."
      What the document is actually asking IANA is to assign a new entry in the sub-registry for SMI Security for Mechanism Codes whose prefix is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5)
    4. Peter Saint-Andre: Discuss [2012-01-17]:
      This is a valuable document and I support its publication. However, in addition to the comments provided below (some of which border on DISCUSS points), I'd like to chat about internationalization. Section 3.1 states:
      "Domain name is specified in [RFC1035]."
      Does this technology have no support for internationalized domain names (IDNs) as defined by RFC 5890 - RFC 5894?
    5. Peter Saint-Andre: Comment [2012-01-17]:
      (about 8 items)
    6. Sean Turner: Comment [2012-01-17]:
      f1, s2, and f2: If you're talking about the scheme isn't it HTTPS?
      r/HTTPs/HTTPS
      s6.1: If you're referring to 4648 then you need to specify which alphabet is to be used.

    Telechat:

  7. Subcodes for BGP Finite State Machine Error (Proposed Standard)
    draft-ietf-idr-fsm-subcode-02
    Token: Stewart Bryant
    Note: Susan Hares is the document shepherd  (Susan.Hares@huawei.com or shares@ndzh.com).
    Discusses/comments (from ballot 4031):
    1. Ron Bonica: Discuss [2012-01-16]:
      I intend to change this DISCUSS to a YES. However, I think that this draft should UPDATE RFC 4271.
    2. Adrian Farrel: Discuss [2012-01-15]:
      There was a last call comment from Ran Atkinson that said:
      I have read this short document and am familiar with its contents. I am not a BGP implementer, instead I am a BGP user (as are several of my clients).
      Summary: Security Considerations are missing
      The absence of any substantive "Security Considerations" is problematic and needs to be corrected prior to approval.
      As an example, creating these sub-codes will greatly facilitate active probing of remote routers for "OS fingerprinting" or "BGP fingerprinting", which might be used in future to determine the manufacturer, software-version, and possibly hardware model of the remote router.
      In turn, such fingerprinting can facilitate targeting attacks against security issues present in certain software versions or software+hardware combinations.
      I do not object to the principle of adding these sub-codes, but the practical operational security risks ought to be fully and clearly documented before this draft proceeds.
      Without agreeing or disagreeing with what Ran has said, I expect IETF last call comments to be resolved through discussion on the IETF list before te I-D is approved.
      I am unclear whether this document is intended to update RFC 4271. Is the plan that all future BGP implementations need to include this work, or is the inclusion optional? As currently presented, it is optional.
    3. Stephen Farrell: Comment [2012-01-18]:
      I also support Adrian's first discuss point.
    4. Peter Saint-Andre: Discuss [2012-01-17]:
      The IANA Considerations section states: "IANA is requested to create the registry "BGP Finite State Machine Error Subcodes", within the "BGP Error Subcodes" registry, with Registration Procedures "Standards Action process or the Early IANA Allocation process"."
      As far as I understand it, "Standards Action" is a registration process (per RFC 5226) but there is no such registration process as "Early IANA Allocation". It is true that RFC 4020 defines procedures for early allocation of code points, but that does not mean that early allocation is a registration process. Given that early allocation is always possible when the registration process is "Standards Action", it is proper to remove the text " or the Early IANA Allocation process" from the quoted paragraph. Alternatively, you could say something like this:
      "IANA is requested to create the registry "BGP Finite State Machine Error Subcodes", within the "BGP Error Subcodes" registry, with a Registration Procedure of "Standards Action" as defined in [RFC5226] (naturally, early allocation of such subcodes is allowed, in accordance with [RFC4020])."
    5. Sean Turner: Comment [2012-01-17]:
      I support Adrian's discuss.

    Telechat:

  8. Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS (Proposed Standard)
    draft-ietf-mile-rfc6046-bis-07
    Token: Sean Turner
    Note: Kathleen Moriarty (kathleen.moriarty@emc.com) is the document shepherd.
    Discusses/comments (from ballot 4046):
    1. Stephen Farrell: Comment [2012-01-18]:
      I wonder how easy it is to find a HTTP client implementation that won't follow 3xx response codes. I don't know, just wonder:-)
    2. Russ Housley: Discuss [2012-01-18]:
      he Gen-ART Review by Alexey Melnikov on 14-Jan-2012 led to a discussion with the authors. They seem to have settled on agreed changes to the document, but the changes have not been made yet.
    3. Peter Saint-Andre: Comment [2012-01-18]:
      First, thank you for addressing the comments that Julian Reschke provided on behalf of the Apps Directorate.
      Section 3 states: "RID systems MAY be configurable to listen on ports other than the well-known port; this configuration is out of band and out of scope for this specification."
      and: "When performing RID callback, a responding system MUST connect to the host at the network-layer address from which the original request was sent; there is no mechanism in RID for redirected callback. This callback SHOULD use TCP port 4590 unless configured out of band to use a different port."
      What does it mean to configure a RID system out of band? As far as I can see there is no *in-band* configuration method (i.e., a RID system cannot be configured via RID messages), so the use of "out of band" here is confusing. I suggest removing this terminology in both instances.
      The ABNF reference is old; please change [RFC2234] to [RFC5234].
      Section 3 states: "RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual authentication for confidentiality, identification, and authentication, as in [RFC2818], when transporting RID messages over HTTPS."
      The phrase "as in [RFC2818]" makes it sound as if the rules specified in RFC 2818 are the kind of rules that might be used, not that those rules must be followed. If the intent is that the identity-checking rules in RFC 2818 always apply to RID systems, I suggest changing the text to:
      "RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual authentication for confidentiality, identification, and authentication when transporting RID messages over HTTPS. RID systems MUST follow the rules specified in [RFC2818] regarding verification of endpoint identities."

    Telechat:

  9. Real-time Inter-network Defense (RID) (Proposed Standard)
    draft-ietf-mile-rfc6045-bis-06
    Token: Sean Turner
    Note: Brian Trammell (trammell@tik.ee.ethz.ch) is the document shepherd.
    Discusses/comments (from ballot 4048):
    1. Adrian Farrel: Comment [2012-01-16]:
      I found the first sentence of the Introduction confusing! "This document moves Real-time Inter-network Defense (RID) [RFC6045] to Historic status as it provides minor updates."
      While I can see that this document moves RFC6045 to Historic, I bet it is not your intention to say that RID is Historic.
      How about: "Real-time Inter-network Defense (RID) was previously defined in [RFC6045]. This document makes some minor updates to the RID specification and moves RID from an informational specification onto the standards track. This, this document obsoletes RFC 6045 and moves it to Historic status."
      (Maybe as a standalone paragraph and not running into the the main text?)
    2. Stephen Farrell: Discuss [2012-01-19]:
      I've a few things here that are easily fixable I hope after which I'll be happy to ballot yes.
      1) I'd like to understand why LawEnforcement is a good thing to include here and why its not some form of slippery slope that ends up going against IETF consensus as represented by rfc2804. This protocol would contain LawEnforcement and Tracing. I realise that's not wiretap, but its also not very different. It also doesn't seem to be technically necessary. Perhaps a better label might be "preserve evidence" or something which might also apply between CSIRTs. (Following on from the response to Robert's discuss.)
      2) LawEnforcement, OfficialBusiness and AccrossNationalBoundaries are odd. I'm not sure why an Internet protocol should distinguish between different things like this. Wouldn't it be silly if there were a value there for "DealingWithAGuySellingShoes" so I don't see why any bit of any government is any different for this protocol. What's done differently on the basis of these fields that cannot be (maybe better) done based on the identity of the peer and the transport endpoints used?
      3) There seem to be a bunch of 2119 terms misused in 9.5, e.g. "MUST be addressed" is too vague, ("Yeah, I thought about it, but I figured I'd do nothing much. Ok I've addressed that";-), "MUST be informed" is a little ambiguous (would page 99 of a legal agreement meet the requirement?), "MUST be considered" is too vague, "MUST ... adhere ... to goverment ... regulations" is funny since no one piece of code can do that, etc. etc. And while the sentiment behind "must ... not (be) used for ... censorship" is laudable, I don't see how that can be done. I think most or all of the 2119 terms in this section could be profitably revisisted to be made something with which an implementer or deployment could be made to conform. (I didn't notice the same problem in other sections but it might be worth a pass to check.)
    3. Stephen Farrell: Comment [2012-01-19]:
      - Expand CSIRT on first use (and maybe include a reference?)
      - The FBI is not a good example and not really needed. Precede it with United States or something if you keep it.
      - What is an "intermediate party" (p32) shouldn't stuff like that be explained up front? What's the model for multiple hops here - are requests and responses supposed to be passed on without any controls on the intermediary or not? If not, then what controls and how do those impact on the protocol?
      - Corner case security consideration - related to figure 8, if I can monitor the n/w connections of SP3, then when SP3 receives a message from SP2 and then replies to SP2 *and* SP1 then I get to know for whom SP2 was forwarding the request. Not sure if that's significant really but I guess it could alert a bad guy to stop doing stuff before the final tracing stage happens. I guess the only mitigation would be traffic padding of some sort if (as I suspect) traffic volunes here are small. (Does RID support traffic padding?) If you ever allowed an insecure transport then this might get worse, if the bad guy could flip a bit in the request and then see the ack to SP1 connection being attempted, then the bad guy gets his warning but SP3 hasn't got the message.
      - 9.3.2 is oddly titled, seems like you're really talking about a signature being verifiable at many veryifiers.
      - I don't get what "In some situations, all network traffic of a nation may be granted through a single SP. " means. (p73)
    4. Peter Saint-Andre: Discuss [2012-01-18]:
      First, I'd like to thank you for addressing the comments provided by Larry Masinter in his Apps Directorate review.
      There are a few topics I'd like to chat about.
      1. The document does not pass ID-nits! You might need to fix the document in order to address the following errors and warnings:
      == Missing Reference: 'XMLschema' is mentioned on line 3519, but not defined
      == Missing Reference: 'RFC5735' is mentioned on line 1811, but not defined
      == Unused Reference: 'CVRF' is defined on line 3720, but no explicit reference was found in the text
      ** Downref: Normative reference to an Informational RFC: RFC 3741
      ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)
      ** Downref: Normative reference to an Informational RFC: RFC 6046
      2. This document inherits the definition of Node from the NodeName class in RFC 5070. Although the IODEF specification defines a NodeName as a fully-qualified domain name, it does not provide a definition of that term and specifically does not say whether internationalized domain names (IDNs) are allowed. This is a significant oversight for a modern protocol.
      3. The definition of AcrossNationalBoundaries is confusing. First it says that this value must "MUST"?) be set if the message will cross national boundaries (and how exactly is the sender to determine whether the the message will in fact cross national boundaries?). Then it says that this value is ("MUST BE"?) used when additional handling and protection restrictions based on the data type and location, which is not the same thing as crossing national boundaries. Then it says that this value must be set if the security requirements of the message might not apply to all nations. Then it says that this value must be set if the traffic is of a type that may have different restrictions in other nations. This is such a muddle that I don't see how an SP could choose any value other than AcrossNationalBoundaries.
      4. In Section 7, some of the examples include XML comments. Are these allowed? Are any other aspects of XML disallowed (e.g., processing instructions and external DTD subsets)? Can conforming applications ignore or reject such data? I think the processing rules and security considerations are underspecified here. At the least, it would be helpful to cite RFC 3270 and RFC 3023 with regard to the use of XML in IETF application protocols.
    5. Peter Saint-Andre: Comment [2012-01-18]:
      (about ten items)
    6. Robert Sparks: Discuss [2012-01-17]:
      (Hit send too soon - sorry - there's an additional comment added at the end)
      What motivated the addition of the LawEnforcement PolicyRegion? The other PolicyRegion region definitions give some hint about how the mark might affect processing. It's not clear how this marking this region is required for (or helps) interoperability.
      Possibly related - the definition of the OfficialBusiness TrafficType (inherited from 6045) is vague. What an example of an "other official business request" that's not a government request? Is there an example of a request that should use this mark that's not related to a legal investigation?
      Can the document make it clearer how either of those enumerated values will be used (not just when a sender might set them)?
      As this is moving from Informational to Standards Track, should there be any policy captured in the document around adding values to PolicyRegion and TrafficType enumerations? (For example, someone may wish to mark messages moving across HEPA or FERPA controlled boundaries.)

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. LISP Map-Versioning (Experimental)
    draft-ietf-lisp-map-versioning-06
    Token: Jari Arkko
    Note: Terry Manderson (terry.manderson@icann.org) is the document shepherd.
    Discusses/comments (from ballot 3911):
    1. Ron Bonica: Discuss [2012-01-16]:
      Section 5.1, Bullet 2: Do you really want to drop this packet? Won't this condition occur whenever the following are true:
      - multiple ETRs serve the site
      - a mapping update is in progress
      - the ETR receiving the packet has not yet been updated
      - another ETR has been updated
      - the ITR received its mapping from the ETR that has been updated.
      Section 5.3, Bullet 3: Do you really want to drop this packet. Same argument as above, but viewed from the other side of the tunnel.
    2. Stewart Bryant: Discuss [2012-01-19]:
      This document should have an up front (Introduction) statement recording the issues stated in section 12, since without that statement the reader has the impression for most of the document that this is a fully baked solution.
      In particular the document seems to be saying that without the synchronization problem being solved their are significant issues with this mechanism. That would suggest that we ought to solve the synchronization mechanism at least in some rudimentary way before publishing this element of the LISP specification series.
    3. Stewart Bryant: Comment [2012-01-19]:
      There are many abbreviations that are used without expansion in the Introduction.
      Appendix A is confusing firstly because it is unclear as as to whether the 12 bits is right on the edge of acceptability, or is a realistic number that will be useful for the foreseeable future. Secondly it explains how wonderful it would be to have between 16 and 32 bits of version without providing any information on whether this is realistic to retrofit into the protocol.
    4. Ralph Droms: Discuss [2012-01-19]:
      In my opinion, draft-ietf-lisp-interworking should be a normative reference in this document. All of section 8.3 seems to depend on the details of the interworking mechanisms in draft-ietf-lisp-interworking.
      I've reviewed this document to the extent possible without reviewing draft-ietf-lisp-interworking, which has not yet come up for IESG review. This document will require additional review once draft-ietf-lisp-interworking has been reviewed, to ensure any changes in draft-ietf-lisp-interworking are reflected in this document.
    5. Adrian Farrel: Discuss [2012-01-12]:
      I am holding this Discuss until the resolution of my Discuss on the main LISP specification that is a normative reference.
      depending on how that is resolved, this document will need a pointer to the disclaimer text added to the base LISP spec.
      All other issues I raised on this document have been resolved.
    6. Adrian Farrel: Comment [2011-11-12]:
      (blank)
    7. Stephen Farrell: Comment [2011-09-20]:
      If there's conflict in normative text between this and base, which takes precedence? I think you need to say, even if you believe there is no such conflict, just in case it turns out that there's some hidden conflict or the base draft changes after this one is done.
    8. Pete Resnick: Comment [2011-10-06]:
      It's hard to imagine that anyone would treat values as other than big endian, but it might be worth being explicit in the document.
    9. Robert Sparks: Comment [2012-01-16]:
      (blank)

    Telechat:

  2. Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain (Informational)
    draft-ietf-pcn-signaling-requirements-07
    Token: David Harrington
    Note: Steven Blank (slblake@petri-meat.com) is the document shepherd.
    Discusses/comments (from ballot 3983):
    1. Stewart Bryant: Discuss [2012-01-17]:
      "The representation of a PCN-flow identifier depends on the surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. Examples of such PCN-flow identifier representations can be found in [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. "
      The above text implies that it is a simple matter to identify and represent an MPLS flow. I do not believe this to be the case. The authors should either specify how they propose to represent MPLS flows (as they do for IP) or note that this is a problem that needs to be solved.
    2. Adrian Farrel: Discuss [2012-01-18]:
      In Section 2 (and repeated in 3): "Signaling messages SHOULD have a higher priority than data packets to deliver them quickly and to avoid that they are dropped in case of overload."
      Unless I am mistaken, there is a difference between priority and drop precedence.
      Can you also clarify whether you mean all data packets, or justdata packets on the measured flow.
      I have a point that is very similar to Stewart's...
      "The representation of a PCN-flow identifier depends on the surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. Examples of such PCN-flow identifier representations can be found in [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804].
      I don't find any mentiong of PCN in those documents, so I think you mean "Identifiers for flows can be found in [foo]. These identifiers can be used in PCN to identify the flows that are measured and reported on."
      Thinking about it, the wider problem may be that the discussion in 2.1 is actually solution-oriented. The requirements are to be able to apply PCN to a specific set of flows, and that the flow about which PCN is being signaled should be unambiguously identified. Those requirements are worth stating. You might even say tat there is a requirement that the data packets not be encumbered by any additional fields used for flow identification, therefore all flow identifiers must utilize only fields already present in the data headers. [At this point you might also comment on how deep it is acceptable to look - e.g., can you look below a top MPLS label?]
      But the discussion of which identifiers are suitable is surely not a matter for a requirements document.
      Section 4: "[RFC5559] provides a general description of the security considerations for PCN. This memo does not introduce additional security considerations."
      I agree with the statement about RFC 5559. But surely this requirements document places security-related requirements on the PCN signaling. These should be noted in this section.
    3. Adrian Farrel: Comment [2012-01-18]:
      You should remove the citations from the Abstract.
    4. Stephen Farrell: Comment [2012-01-19]:
      I just note that 5559 which is referenced here says "The signalling between the PCN-boundary-nodes must be protected from attacks."
      So I'm counting on the eventual protocol document meeting that goal.
    5. Peter Saint-Andre: Comment [2012-01-17]:
      A question for the responsible AD...
      The PROTO writeup states: "The -03 version generated significant debate on the working group mailing list during WGLC. The editor addressed the comments to everyone's satisfaction. There are no vocal dissenters."
      Just curious: what were the topics that generated significant debate? It would be helpful to mention those in the ballot writeup.

    Telechat:

  3. DNS Extensions to Support IPv6 Address Aggregation and Renumbering (Historic)
    rfc2874
    Token: Ralph Droms

    Telechat:

3.1.2 Returning Items

  1. Locator/ID Separation Protocol (LISP) (Experimental)
    draft-ietf-lisp-19
    Token: Jari Arkko
    Note: Joel Halpern (jmh@joelhalpern.com) is the document shepherd.
    Discusses/comments (from ballot 3906):
    1. Jari Arkko: Discuss [2011-12-01]:
      Holding a DISCUSS until IANA provides a review, that has not arrived yet but should in a couple of days.
    2. Ron Bonica: Discuss [2012-01-18]:
      Success Criteria:
      Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.
      The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.
      Experiment Scoping:
      Joel points out that the DISCUSS item below is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending resolution of Adrian's.
      {Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).}
      IPv4 vs IPv6:
      Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.
    3. Stewart Bryant: Discuss [2011-12-01]:
      The document needs to be clearer on what happens when the traffic is a high volume UDP source that only transmits occasionally. Say (but not limited to) some form of remote IPFIX collector that is occasionally triggered.
      My concern is
      a) Do we see a large chunk of the flow dropped on the floor until the mapping is learned - the conflict is between DOS attack and degradation of service WRT the "legacy Internet".
      b) Do we see a miss ordering of packets during as the system swaps from probe to normal operation
      c) Do we see a repeat of this as a result of cache aging.
      I am also moving the following up to Discuss since it is related to the need for a clear description of the impact of the cache vs the existing behavior of the Internet.
      5.4.2. A Stateful Solution to MTU Handling
      SB> It looks like there needs to be some discussion about the state lifetime, and the issue of holding a stale MTU vs transienting a flow by flushing the cache.
      Note that in both cases I am not requesting a change to the protocol, just a clear explanation of the expected behavior.
    4. Stewart Bryant: Comment [2011-12-01]:
      (nine items)
    5. Ralph Droms: Discuss [2012-01-17]:
      Updated to refer to rev -19
      EIDs are defined to be "not routable on the public Internet." What are the global uniqueness properties required for EIDs, both among EIDs and between EIDs and globally routable IP addresses? How are EIDs with the appropriate properties chosen and coordinated among LISP sites?
    6. Ralph Droms: Comment [2012-01-17]:
      Updated to refer to rev -19
      I'd like to see a mention of the complementary observation that using a single ID-LOC avoids the necessity of a separate step to bind an identifier to its location and a database to manage those bindings. A mention of the scale of the binding database would be appropriate, too.
      As I understand LISP, the EIDs are still ID-LOCs, not pure identifiers, within a LISP site. Outside any LISP site, an EID is a pure identifier. Which begs the question: exactly what is LISP providing, since it isn't providing a pure ID/LOC separation. E.g., a node can't move within a site without changing its ID, nor can it move between sites without changing its ID. Of course, this hybrid ID/LOC architecture helps with the scaling of the ID/LOC binding database.
      In section 4: first bullet of "basic rules": is it the case that end-systems are aware of LISP at all?
      I would write the first phrase of the third paragraph of section 5 as "Because EIDs and RLOCs can be either IPv4 or IPv6 addresses, ..."
      I don't understand the deployment method described in section 5.5. I think I understand the scenario, but I don't understand how RFC 1918 prefixes can be used as EID prefixes. How is an EID that has an RFC 1918 prefix disambiguated to do the EID-RLOC mapping? This question is related to the Discuss issue asking for clarification of the global uniqueness requirements for EIDs.
      In section 6.3, how does an ITR determine the original destination of an encapsulated datagram that triggers an ICMP Network or Host Unreachable message, so it can construct a meaningful ICMP Unreachable message to send to the original source of the datagram?
      In section 10.2, I understand how LISP can help avoid site renumbering, as described in RFC 4192, but I don't understand how it helps with renumbering a single node that moves within or between sites. What is the impact of host renumbering on LISP forwarding? What is the citation of RFC 4984 at the end of section 10.2 in reference to?
      I see that Jari has a Discuss waiting for IANA review. I think section 14 needs clarification - e.g., while section 14 includes the text "There are two name spaces in LISP that require registration," there appear to be four registries requested in section 14.
      How is the statement from the definition of EID-prefix:
      "A globally routed address block MAY be used by its assignee as an EID block."
      compatible from this statement from sections 2 and 4, respectively:
      "[...] (EIDs), which are assigned independently from the network topology, [...] [...] an EID is only routable within the scope of a site."
      I think the issue is that some additional caveats are required if "a globally routed address block [is] used [...] as an EID block"; spec. those addresses from the globally routed address block used as EIDs must not be allowed to be actually routed directly over the Internet. Well, maybe, as we'll need to see how the transition mechanisms provide interoperability between LISP and non-LISP systems.
    7. Wesley Eddy: Discuss [2011-11-29]:
      If both the N bit and V bit MUST NOT be set in the same packet, then why would there be any rule defined for processing such a packet rather than to DROP it? It seems wrong to pretent that's okay and just treat it as if the V bit wasn't set. What is the advantage of this, and is there any risk?
      Section 5.4.1 is not clearly written, and seems fairly critical to proper performance. For instance, what does it mean when it says S is the maximum size of a packet that an ITR "would like to receive"? Is it the maximum that it *can* receive, the maximum that it can send on a next hop without fragmenting, etc.? From the description in the 2nd paragraph, the size would only be S/2 + H if the incoming packet were size S, in which case after adding H, it would be size L, NOT greater than L as the first sentence says. The definitions here really need to be tightened up and clarified.
      I believe the stateful solution in 5.4.2 is preferable to the stateless one which seems like it could have very bad effects if it really sets DF=1 and isn't keeping any state about whether smaller fragments need to be sent for a particular destination. The 5.4.1 algorithm doesn't solve this at all, and seems inadequate for providing a robust infrastructure.
      RLOC probing has an impact on the network capacity in-use and there is no way to sense when the overall rate of probing may simply be too great for some bottleneck to handle (due to some combination of the number of RLOCs being probed or the rate of probing). Losses can occur either of the probes or the map-replies. Even in cases where it isn't a significant source of congestion, the probing has to be implemented to avoid having bad things happen like accidentally causing synchronization of sending the probes such that this control traffic spikes periodically. Overall, unless the RLOC probing is better specified so that the risks and necessary precautions are well understood, this seems like a feature that could cause unexpected impact to data flows under some conditions.
    8. Wesley Eddy: Comment [2011-11-29]:
      In Section 5.3, UDP Checksum discussion, the reference to draft-eubanks-chimento-6man should probably be to draft-ietf-6man-udpzero instead.
      In section 5.4.1, what is "an architectural constant"? Should this just say "a constant"?
    9. Adrian Farrel: Discuss [2012-01-08]:
      I have updated my Discuss to remove the issues resolved in the -19 revision.
      I'm inclined to agree with Russ that this is well-enough specified for an experimental status document, but I have some concerns.
      I don't see any statement of the scope of the experiment or how it will be judged. Traditionally, experiments are not released into the Internet but are operated in a controlled way in walled gardens. It appears that the intention with this experiment is that it should be conducted in the Internet, and that makes it important to examine the risks and uncertaintes.
      As part of the Discuss resolution on other LISP documents, and in accordance with the LISP WG charter, we had agreed that this specification would countain an upfront and clear statement of the issues and concerns. To remind you, the charter says:
      "At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many."
      and "The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on"
      I do not consider that this draft has adhered to the WG charter, and I consider the active encouragement of "early deployments" to be both against the spirit and the letter of the charter. If you believe that the experiment needs to be conducted "in the wild" you need to spend a bit more text explaining why this is safe and how the experiment is contained.
      I have proposed text on the LISP mailing list to address this part of my Discuss.

      Section 2: "Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation)"
      I don't see that RLOCs are any more amenable to aggregation than today's IP addresses. That is, the allocation scheme for RLOCs could be run such that RLOCs are aggregatable, but could equally be run such that it is hard to aggregate.
      Maybe the points here are that:
      - network attachment points are not (currently) mobile
      - network attachment points are defined by the networks they attach to
      - network attachment points, by definition, impose an aggregation of end points.
      A way to solve this, if you wrote what you intended to write, would be a forward pointer to the section in the document that describes aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.
      Section 2: "One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]."
      Is the LISP working group undertaking controlled prototyping? Is the intention to state that "there are known protocotype implementations of [ALT]."
      Similarly, what does it mean to say "have been described but not implemented"? I guess: "At the time of writing, the authors are unaware of any implementations of..."
      Section 3: "When using multiple mapping database systems, care must be taken to not create reencapsulation loops."
      What is this "care"? What about loops caused by transient conditions (or errors) in a single LISP mapping database? Shouldn't the payload TTL at least be decremented by one for each tunnel?
      Note that reencapsulation is not the same as nested encapsulation. You are clear about avoiding the latter (although some form of DPI may be required to achieve it).
      Step 7 of Section 4.1 doesn't make it clear what has happened to the first packet in the flow. I had assumed that it was buffered pending the Map-Reply, but I now suspect it was discarded as soon as the Map-Request was constructed. Can you add a clarification.

    10. Adrian Farrel: Comment [2012-01-08]:
      I have updated my Comment to remove those points that you have addressed in revision -19 (thanks).
      The architectural overview in Section 4 would be enhanced by a picture.
      The example in 4.1 would similarly benefit.
      Section 5.3: I agree with Wes about the N and V bits.
      Section 5.3 LISP Nonce: "When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce."
      "is clear/set" in what? The original message sent, or the new message received?
    11. Stephen Farrell: Comment [2012-01-16]:
      This was a discuss, but on the basis that the lisp WG re-chartering will address the issue, I'm clearing.
      #12, It looks from 6.1.6 like a Map-Register can be replayed. That's not a good thing. There may be a similar replay issue with Map-Notify messages.
    12. Russ Housley: Comment [2011-11-29]:
      This is going for experimental, and I think it clears the bar for experimental. However, I think Section 6 could be much more clear.
    13. Pete Resnick: Comment [2011-11-29]:
      LISP sounds like a serious protocol experiment. I would have liked there to be more discussion in either the document or in the writeup about how that experiment is going to conclude. That is, though I see the things in section 15 that indicate what it would take to really move this to the standards track, it would be nice to see some discussion about how interoperability is going to be measured as the experiment progresses.
    14. Dan Romascanu: Comment [2012-01-18]:
      1. I support Pete's COMMENT and Adrian's DISCUSS about the need to make more clear the goals of the experiment, the criteria of success and the limits of deployment while the document stays Experimental.
      2. It would be more clear to split 14.1. into two sub-sections, especially as IANA is required to create a registry for LISP ACT if I understand correctly, while no action is required from IANA for the Flag Fields
      3. I support Stewart's DISCUSS. One of the sources of UDP traffic that transmit occasionally may be SNMP agents in the core. When sending unacknowledged notifications (a.k.a. traps) these could be dropped on the floor and then if the cache is flushed they will be lost forever. Altough traps are not supposed to be used in critical applications, systematic loss in what would not be a meltdown situation could badly impact the manageability of the routing environment,
    15. Peter Saint-Andre: Comment [2011-11-30]:
      Experiments are good. Although I share Pete's and Adrian's concerns about the scope of the experiment and the parameters for evaluating its success, I agree with Russ that the document is specified clearly enough to be implemented in an experimental fashion (modulo Ralph's question about global uniqueness).
    16. Robert Sparks: Comment [2011-12-01]:
      I'm clearing, trusting the shepherd and responsible AD to ensure that the informative references point to to appropriate places. In particular, please verify that it's possible to obtain [RPMD].
    17. Sean Turner: Comment [2012-01-19]:
      (blank)

    Telechat:

  2. LISP for Multicast Environments (Experimental)
    draft-ietf-lisp-multicast-12
    Token: Jari Arkko
    Note: Wassim Haddad <wassim.haddad@ericsson.com> is the document shepherd.
    Discusses/comments (from ballot 3910):
    1. Stewart Bryant: Discuss [2012-01-17]:
      This document defines a set of terms EID, RLOC etc which at first sight seem identical to the unicast terms. However the description of their operation seems to make them different objects, in which case they need different names. If the names are to be common, there needs to be a separation of the name from the mode of operation.
      Where the object is identical to the unicast term (LISP Header?) the object should not need to be redefined in this document since this invites issues of subtle difference between the competing definitions.
    2. Stewart Bryant: Comment [2012-01-17]:
      "By using the traffic engineering features of LISP" needs a ref.
      The subtleties of different m/c paths surely belongs after the basic description rather than as the first item
      The protocols in section 7 need references
      Mpriority seems to lack a definition
    3. Ralph Droms: Comment [2012-01-18]:
      Now that the base LISP protocol document has been published, I've cleared my Discuss on this document.
    4. Adrian Farrel: Discuss [2012-01-18]:
      I have no objection to the content of this document, and I thank you for spelling out (and calling out) the considerable complexity expecially in Section 9.
      As previously noted on other LISP documents, I would like a pointer to the generic caveat text being added to the main LISP spec.
      The answer to Ron Bonica's Discuss (now cleared) intimated that there are actually no changes to the multicast protocols since "it is LISP-Multicast that sends unicast PIM join and prune messages."
      I am trying to understand whether this document does or does not make any changes to (e.g.) PIM. In Section 2 I see bullet 3...
      3. What protocols are affected and what changes are required to such multicast protocols.
      Is this rhetoric ("I will show you which protocols are affected. None!") or is there some contradiction?
      Since Section 2 goes on to say...
      "This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi-protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no packet format changes to the protocols and no operational procedural changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled."
      It really sounds like no changes are needed to any of the protocols. It is just a question of how the individual routers use the protocols (i.e. how they supply information to and extract information from the protocols). Maybe this just needs a change in tone of the text to stop me repeatedly going into a panic about changes to protocols when I read
      "Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]."
      Section 7 (which really had me worried) appears to list each protocol and then say "no changes needed" for *nearly* all of them. But for PIM-SSM we have
      "In this case, there is a small modification to the operation of the PIM protocol. No modifications to any message format, but to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [RFC5135]."
      That is a change or not?
    5. Adrian Farrel: Comment [2012-01-18]:
      The title talks about "LISP for multicast environments" but the Abstract is specific to "inter-domain multicast routing". Should the document title be updated accordingly or is the Abstract wrong?
      It is possible that the confusion is at bullet 2 of Section 2 where it is implied that a "domain" is a LISP site such that "inter-domain" means between LISP sites. It would be helpful not to re-use "domain" in this way (we are used to it meaning inter-AS and inter-area).
      Since multicast between LISP sites is just a special case of multicast using LISP, you could strike the text from the Abstract.
      FWIW I found it premature to be reading about how to send a multicast packet from a LISP site to a non-LISP site (and vice versa) when I have not yet been told how to do this for unicast! There is nothing the authors can do about this, but it is yet another case of the LISP documents running through the system in the wrong order.
      I am pleased to see [INTWORK] as a normative reference since ts does help with the issue, and I wondered whether the LISP deployment I-D should not at least show as an informational reference (perhaps from Section 9.3).
      Section 7 needs some polish on the English to avoid doubts.
      "PIM-SSM No modifications to any message format, but to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary."
      "PIM-ASM The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites.
    6. Stephen Farrell: Comment [2011-12-13]:
      (blank)
    7. Russ Housley: Comment [2011-10-04]:
      Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 3-October-2011.
    8. Peter Saint-Andre: Comment [2011-10-05]:
      draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations", which provides a good start toward understanding the parameters of the experiment we're engaging in here, and perhaps some dimensions for measuring success. It would be helpful for this document to contain a similar section.
      The terminology section repeats definitions from the base LISP spec. This seems like a bad idea. It would be better to reference those definitions and here simply provide the extended information that applies only to multicast environments.
      The Security Considerations section seems rather sparse. Does the use of LISP in a multicast environment truly have no security implications whatsoever?

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling (Informational)
    draft-kompella-l2vpn-l2vpn-09
    Token: Stewart Bryant
    Note: Ross Callon (rcallon@juniper.net) is the document shepherd.
    IPR: Juniper's Statement of IPR related to draft-kompella-l2vpn-l2vpn-02
    Discusses/comments (from ballot 3889):
    1. Adrian Farrel: Comment [2012-01-15]:
      Nice documemnt, well positioned as complementary to the official IETF approach. Thanks.
      "PE" first appears in Section 1.1 without expansion.
    2. Stephen Farrell: Comment [2012-01-19]:
      A check that acronymns are expanded on 1st use would be good, e.g. DLCI was the one I noticed.
    3. Russ Housley: Comment [2012-01-18]:
      One non-blocking comment from the Gen-ART Review by Roni Even on 7-Sep-2011 has not been resolved. Please consider it:
      "Section 4.2 refers to section 4 but I am not sure where this mechanism in section 4 is."
    4. Dan Romascanu: Discuss [2012-01-16]:
      Benson Schliesser reviewed the document (version 07) for OPS-DIR and sent his review to the authors on 9/29. His review was never answered. Please address the following issues from Benson's review, or in case these were answered and addressed in the meantime provide the appropriate pointers:
      1) It is not clear to me whether L2-native end-to-end OAM mechanisms are supported. It seems that the IP-based interworking proposed by this document would be incompatible with native OAM. A discussion on whether this is true, when and how native OAM is supported, etc, would be useful.
      2) While there is a brief discussion of "adding" a new site, there is no discussion of "removing" sites.
      3) I'm also unclear about behavior during the transition timeframe. When label blocks are growing or shrinking, and PEs might have mismatched label block sizes, what is the correct behavior for label selection, dropping packets, etc? Is there an implementation mechanism for managing label space correctly, to ensure that blocks can grow? Are these behaviors something that should be configured correctly by the operator?
      4) The document doesn't clearly describe the AC-to-label-to-AC mapping, specifically how egress frames are mapped to an AC's local identifier (e.g. DLCI). The operator needs a way to know in advance and/or lookup the local/remote VC identifier mappings for each AC. It seems pretty obvious to me, but the text is not explicit on this point. (Section 3.2.1 talks about ingress DLCI-to-CE mappings; section 5 para 3 says the label is used to determine egress AC; section 6 reiterates these points, but says that the label identifies the CE rather than the AC. Perhaps I overlooked some other text; otherwise the egress mapping should be described explicitly.)
      5) Section 4 includes n-to-1 encapsulation types. Given my comments in #4 above regarding identifier mappings, it is even less clear how these types of circuits would work.
      6) On the ingress, what happens when the PE receives a frame addressed to itself? In other words, if CE-N sends a frame to the DLCI associated with the Nth index, does it get looped back? Is this a useful operational mechanism for testing connectivity etc?
      Supplementary to these please address the following:
    5. Dan Romascanu: Comment [2012-01-16]:
      1. In section 1: "It may be instructive to compare the approach in [RFC4447] and [RFC6074] (these are the IETF-approved technologies for the functions described in this document, albeit using two separate protocols) with the one described here. Devices implementing the solution described in this document must also implement the approach in [RFC4447] and [RFC6074]."
      This mislead me at first reading. I believe that it would be more clear if the non-capitalized 'must' is avoided completely, as [RFC4447] and [RFC6074] are supported as part of the L2VPN functionality and not as a reuirement for this document.
      2. Expand at first encountered instance: DLCI, VPI / VCI, NLRI.
      3. It makes sense to bring the Contributors and the Acknowledgments sections one near the other.
    6. Sean Turner: Comment [2012-01-18]:
      Where do the L2VPN TLVs go in the VPLS NLRI? Does the TLV(s) appear immediately after the VPKS NRLI when sent between the two PEs?

    Telechat:

  2. Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks (Experimental)
    draft-ash-gcac-algorithm-spec-03
    Token: Adrian Farrel
    Note: Young Lee (leeyoung@huawei.com) is the document shepherd.
    Discusses/comments (from ballot 3980):
    1. Jari Arkko: Comment [2012-01-19]:
      Agree with Robert's points in his discuss. I also found this document in general difficult to read, and hard to convince myself that it actually works as expected.
    2. Wesley Eddy: Comment [2012-01-18]:
      I concur with Robert's DISCUSS points
    3. Stephen Farrell: Comment [2012-01-18]:
      1) VARk = BWMck**2/VFck could be mis-read, suggest adding parenthesis or using another couple of lines like eq(2).
      2) Surely there's a DoS vector here too - couldn't someone in principle provide bad inputs so that the algorithm denies service? Not sure how best to note that, but I'd say its worth a mention in the security considerations.
    4. Peter Saint-Andre: Comment [2012-01-17]:
      As with all Experimental specifications, it would be nice to define some parameters for the experiment (success criteria, guidelines for those who implement and deploy the technology, etc.).
    5. Robert Sparks: Discuss [2012-01-18]:
      (Updated to add point 3 below)
      The document says that the algorithm might have negative effects on live deployments (by implication, up to and including failing to complete an emergenc call) but then says experimentation in production networks needs to be treated with caution. Was "experimentation in production networks is NOT RECOMMENDED", or even "experiments MUST NOT be performed on production networks" considered and rejected? If so, can the document explain why? (Related - can the document explain what experimenting "in a controlled manner" means?)
      The security consideration section's discussion of the risks of using possibly unprotected marks to identify emergency traffic should incorporate or reference the related discussion from ECRIT and (if I remember correctly) the RSVP document suite. This is much harder problem than the current text signals.
      Example A.2 needs to be updated to reflect that NSIS has concluded.
    6. Robert Sparks: Comment [2012-01-18]:
      The document calls out VOIP as an example of traffic that might be used as an input to this algorithm, but the current language implies it's the ONLY traffic that's expected, and that the only things generating that traffic will be IP/PBXs and SIP/RTP end devices. Please make it clear that this traffic is only a motivational example.
      The interoperability issue exposed at the top of page 11 deserves more discussion. What goes wrong when different administrative domains use different constraint models? Are there symptoms that can be observed to know that somethings going wrong? Can the document make a stronger statement about the appropriate configuration of a experimental test bed?
      This sentence needs clarification: "Let DBWi be the additional bandwidth capacity needed to carry the flow with aggregate bandwidth DBWi." As written it defines a term in terms of itself.
      I'm skeptical of the brevity of the security consideration section, but yield to the shepherd to double-check that there is nothing beyond the marking of emergency traffic to discuss.

    Telechat:

  3. Moving A6 to Historic Status (Informational)
    draft-jiang-a6-to-historic-00
    Token: Ralph Droms
    Note: Ralph Droms (rdroms@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 4043):
    1. Stewart Bryant: Discuss [2012-01-17]:
      As far as I can tell the purpose of this document is to obsolete RFC2874. However this is not called out in either the meta-data or the Abstract.
    2. Stewart Bryant: Comment [2012-01-17]:
      RFC2874 says that it is Standards Track, so it is surprising that this is not a WG draft.
    3. Ralph Droms: Comment [2012-01-16]:
      ID-nits flags:
      -- Obsolete informational reference (is this intentional?): RFC 1886 (Obsoleted by RFC 3596)
    4. Adrian Farrel: Discuss [2012-01-16]:
      Should the DNS record type 38 be deprecated (and marked so in the registry?
      This part of my Discuss is only for debate by the IESG and I will clear it on or before the Telechat. The authors do not need to take any action for this part of the Discuss.
      It is a source of confusion to me that when I look at RFC 2874 in the repository, all of the lovely metadata says "Experimental" but the RFC itself says "Standards Track". Now, I know that the RFC Editor does not like to make *any* change to the published RFC, but this has got be a source of confusion and, as this RFC moves to Historic, the confusion won't get any less
    5. Adrian Farrel: Comment [2012-01-16]:
      I would like it if the Abstract mentioned the RFC being moved to historic (viz. 2874)
    6. Sean Turner: Comment [2012-01-16]:
      Please make sure to incorporate the additional text agreed during the secdir review:

    Telechat:

  4. The 'disclosure' Link Relation Type (Informational)
    draft-yevstifeyev-disclosure-relation-02
    Token: Peter Saint-Andre
    Note: The IETF Last Call ends on January 6.
    Discusses/comments (from ballot 4053):
    1. Jari Arkko: Comment [2012-01-19]:
      I support the discusses, in particular the concern about pure patents vs. other general purpose IPR. The latter is the one that we use for IETF, for instance.
    2. Stewart Bryant: Comment [2012-01-17]:
      (blank)
    3. Wesley Eddy: Discuss [2012-01-02]:
      It is not clear to me why this is defined to indicate *only* patents (as it is currently) or to indicate intellectual property claims more generally (e.g. patent applications in-process are not patents).
    4. Adrian Farrel: Discuss [2012-01-02]:
      AFAICS, new IANA registrations require a specification (this document) and expert review. Have the experts looked at this request yet? I don't see anything in the Write-up.
      Last Call discussions seem to be still active, and I do not think we should approve this document until all issues have been successfully resolved.
      I suspect the shepherding AD should move this onto a later telechat.
    5. Stephen Farrell: Comment [2012-01-03]:
      Moved from discuss to no-objection since this will come around again and who needs a spare discuss;-)
      Former discuss:
      On Dec 26th the author suggested a substantive change [1] so I don't know whether what I've read is final or not. Maybe this is not ready?
      [1] http://www.ietf.org/mail-archive/web/ietf/current/msg71211.html
      Former comment text:
      This seems almost harmless. (It'd be totally harmless if it didn't add to the IPR industry in a very, very minor way;-) The writeup says that W3C feedback will be sought during IETF LC - did that happen and were they (as the ostensibile users of this) ok with it?
      Examples like patent.gov seem like a bad idea as do "almost" realistic patent numbers. Suggest either using example.org style stuff or else URIs for real but expired patents.
      There were a bunch of IETF LC mails on this (mostly suggested nits from Julian Reschke) that looked like they'd be worth fixing. (And the author appeared to agree too.)
    6. Russ Housley: Discuss [2012-01-18]:
      The Gen-ART Review by Martin Thomson on 17-Dec-2011 raised a serious question that deserves further discussion. He questions whether the IETF should publish the document at all.
      "The semantics of the relation type are quite clear, though the introduction does not make a particularly compelling case for an RFC. The registration requirements of RFC 5988 require little more than the creation of a specification; that specification could be created anywhere (say, in [W3C-PUBRULES]). I find the motivations described in the introduction to be not compelling."
      In response, the author suggests that an Informational RFC is the ideal way to meet the requirements in RFC 5988. Martin was not swayed by this suggestion.
    7. Pete Resnick: Comment [2012-01-18]:
      - I think the MUST in section 2 is superfluous. s/MUST represent/represents
      - Though I agree with Dan that some more discussion of applicability might be interesting, I do not think it is necessary to include. The document does not tightly define "patent disclosure" or "IPR disclosure", and I don't think it should. Any particular group using this construct may decide that pending patents or patent applications are things that they want to point to, and in the current document they are allowed to. The document can explicitly say that, but I don't think it needs to.
    8. Dan Romascanu: Discuss [2012-01-03]:
      This DISCUSS and COMMENT is based in part on the OPS-DIR review performed by Juergen Quittek.
      1. "Patent disclosure" is W3C terminology. The related term used in the IETF is "IPR disclosure". I would object the document to be published without a clear statement about the applicability of the new link relation type to IPR disclosures.
      2. This document is very short and most of the text deals with W3C document requirements and HTML examples. More important would be discussing the the applicability of the new link relation type in more detail: Is it applicable to granted patents only or to patent proposals (pending patents as well? What about other kinds of IPR, such as industrial design rights? I think they should all be covered. At least the document should be clear about these issues.
      3. The Introduction (section 1) exclusively discusses a single use case for the new link relation type: meeting W3C documentation requirements. This gives the impression that this draft is written for serving W3C purposes only. I don't think that this is the case, but there is not indication of other purposes in the draft. Please clarify that W3C documents are just an example use case and that there are many others. Mentioning a few other use cases is probably not a bad idea. One obvious use case may be links to IPR disclosures on IETF tools pages.
    9. Dan Romascanu: Comment [2012-01-03]:
      (eight items)

    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)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Locator/ID Separation Protocol (lisp)
    Token: Jari

    Telechat:

  2. Diameter Maintenance and Extensions (dime)
    Token: Dan

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Adding ONF to New-Work mail list (Russ Housley)

    Telechat:

  2. IANA expert for MANET registries (Adrian Farrel)

    Telechat:

  3. Designated Expert for RFC5797 (FTP Commands and Extensions) (Pete Resnick)

    Telechat:

  4. IAOC Candidate Conformation (Russ Housley)

    Telechat:

  5. Request for an IPv4 Option Number [IANA #459951] (Michelle Cotton)

    Telechat:

  6. Expert for Info Packages Registry [IANA #536670] (Michelle Cotton)

    Telechat:

  7. What is a recognized standards body? (Russ Housley)

    Telechat:

7. Agenda Working Group News

Item from the Secretariat

Item from the Secretariat

1344 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-01-19 07:30:04 PST)

draft-ietf-marf-redaction

  1. Stewart Bryant: Comment [2012-01-13]:
    I am not a crypto expert, and thus do not know the severity of the attack vector
    in this case, but isn't there a plain text attack when encrypted material has a
    constant string included as seems to be the case here.
  2. Stephen Farrell: Discuss [2012-01-15]:
        
    (Updated-discuss - thought about it a bit more;-)
    
    (1) The construct here is output=H(redaction-key|sensitve-value). 
    I don't think that's ok. I think you want HMAC() and not H().
    
    If I could supply a redactor with a zero length "private" string,
    e.g. message with a header field like "To: @example.org" then the
    redactor will send H(redaction-key) which can then allow (via
    hash-continuation) checking if any value matches a value from an
    output here.
    
    If the alphabet for sensitive values has N characters
    then I can also send "To: "+char[i]+"@example.org" for
    each i and then play the continuation game on that. 
    Same for two character prefixes etc. 
    
    (2) I can also use this to validate guesses of the redaction 
    key value. I need to think about how one might avoid that
    or if its possible to avoid that. 
        
  3. Stephen Farrell: Comment [2012-01-15]:
    - I don't get why this is not informational - where's the interop
    consequence?
    
    - While the idea of only listing JD is laudable, I think having a
    concactable author is best so I'd suggest Murray be kept as an
    author.
    
    - Last para of section 1 - such correlation is not theoretical,
    delete that word.
    
  4. Russ Housley: Comment [2012-01-18]:
      Please reference RFC 4648, Section 4 for [Base64].
      More than one alphabet is available in RFC 4648.
  5. Dan Romascanu: Comment [2012-01-17]:
    This is a rather short and aparently straight-forward document, but it raised a
    couple of questions. None of them is that critical to deserve a blocking
    DISCUSS, but yet I would be glad if these were answered and clarified before
    approval and publication.
    
    1. It is not clear why this document is on standards track. I do not know how to
    establish interoperability of implementations and thus what the critieria would
    be for advancement from Proposed Standard to Standard. Moreover the Abstract
    describes the scope in a rather non-commital manner (suggests one method for ...
    the report generator ... to redact or elide the sensitive portions of the
    message) - so this looks like a recommendation about one (good way) to perform
    redaction, but not the <standard way> of doing it.
    
    2. I know too little about the operational model of configuring a report
    generator, so I was left wondering how are the first two recommendations
    implemented in practice:
    
    > 1.  Select an arbitrary string that will be used by an Administrative
           Management Domain (ADMD) that generates reports.  This string
           will not be changed except according to a key rotation policy or
           similar.  Call this the "redaction key".
    >   2.  Identify string(s) (such as local-parts of email addresses) in a
           message that need to be redacted.  Call these strings the
           "private data".
    
    Some text that clarifies how this is supposed to be implemented and configured
    in practice would be useful.
  6. Peter Saint-Andre: Comment [2012-01-17]:
    I agree with other IESG members that this document seems informational, not
    standards track.
  7. Sean Turner: Comment [2012-01-18]:
    Updated (add the last two)
    
    I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.
    
    You probably don't need to specify an algorithm because it's not an
    interoperability issue, but it might be nice to point to RFC 6151 and 6194 for
    recent info on HMAC-MD5 and HMAC-SHA1.  It would stop people from trying to do
    something over kill like HMAC-SHA256.
    
    If you're going to stick with the plain ole hash then pointing to 6151 and 6914
    still is worth considering (i.e., MD5 bad).
    
    Probably worth a reference to RFC 4086 for the pseudo-random # issues.

draft-ietf-marf-authfailure-report

  1. Adrian Farrel: Comment [2012-01-02]:
    I have no objection to the publicaiton of this document as an RFC, but
    here are a few trivial nits.
    
    ---
    
    Please expand "AF" on first use in the Abstract, and show it as the
    abbreviation of "Abuse Report Format" on first use in the Introduction.
    
    ---
    
    Section 3.1
    
       Delivery-Result:  As specified in Section 3.2.2.  This field is
          OPTIONAL, but MUST NOT appear more than once.  If present, it
          SHOULD indicate the outcome of the message in some meaningful way,
          but might be redacted to "other" for local policy reasons.
    
    s/might/MAY/
    
    ---
    
    Section 3.2.2
    
    Please expand ADMD
    
    ---
    
    Section 3.2.3
    
    Please expand DKIM
    
    ---
    
    Section 3.2.5
    
    Please expand ADSP
    
    ---
    
    Section 3.2.6
    
    Please expand SPF
  2. Stephen Farrell: Comment [2012-01-16]:
    - Section 2.4 (esp the title) is a bit odd, I'm sure its
    there for a reason but its not at all clear to this reader.
    (But I don't mind)
    
    - 3.1 - who's SOURCE-IP is meant here? Might be clear from
    ARP but not so clear from here - same for REPORTED-DOMAIN.
    Better to be crystal clear really.
    
    - 3.2.1 - the "policy" value is a bit vague, but that's ok
    I guess.
    
    - I'm not 100% clear about the rule for handling DKIM and
    redaction. Is it that the sender just chooses whether to
    send the unredacted possibly-DKIM-valid value or the
    redacted version with no DKIM info, or are you just supposed
    to never (as in MUST NOT) send a redacted message if the
    message had DKIM header fields? That might be there but I
    missed it if so.
    
  3. Peter Saint-Andre: Comment [2012-01-17]:
    Section 2.3 states:
    
       base64 is defined in [MIME].
    
    Well, base64 is also defined in RFC 4648. :) Perhaps it would be better to say:
    
       This specification mandates use of base64 as defined in [MIME].
    
    Section 3.1 states:
    
       Delivery-Result:  As specified in Section 3.2.2.  This field is
          OPTIONAL, but MUST NOT appear more than once.  If present, it
          SHOULD indicate the outcome of the message in some meaningful way,
          but MAY be redacted to "other" for local policy reasons.
    
    I think "redacted" is not right here (causes confusion with the redaction I-D).
    I suggest "set".
    
    Section 3.1 also states:
    
       For privacy reasons, report generators might need to redact portions
       of a reported message such as the end user whose complaint action
       resulted in the report.  A discussion of relevant issues and a
       suggested method for doing so can be found in
       [I-D.IETF-MARF-REDACTION].
    
    I don't think you can redact an end user. :) I suggest "an identifier or address
    associated with the end user..."
    
    Section 6.2 states: "These reports may be forged" and "DKIM failure reports may
    produce reports". I suggest changing "may" to "can" and "might", respectively.
    
    Section 6.3 states:
    
       Limiting the rate of generation of these messages may be appropriate
       but threatens to inhibit the distribution of important and possibly
       time-sensitive information.
    
    Do you mean "MAY"?
    
    Section 6.5 states:
    
       The use of this for "near-identical" incidents in particular causes a
       degradation in reporting quality, however.  If for example a large
       number of pieces of spam arrive from one attacker, a reporting agent
       may decide only to send a report about a fraction of those messages.
       While this averts a flood of reports to a system administrator, the
       precise details of each incident are similarly not sent.
    
    Do you mean "MAY"?
  4. Sean Turner: Comment [2012-01-06]:
    I find it a little odd that the requirements language for what's
    optional/required in the different reports (s3.2.*) appear in the section titles
    but not in the text.

draft-ietf-netext-radius-pmip6

  1. Stephen Farrell: Discuss [2012-01-18]:
        
    The security considerations section refers to 2865, 2866 and 3579
    which do have pretty good security considerations.  However, this
    spec seems to me to introduce new things, such as sending the
    interface ID, which I think raises at least new privacy
    considerations. The ones that I think may be relevant here are the
    Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the
    PMIP6-Visited-Interface-ID, Calling-Station-Id and the
    Chargeable-User-Identity.  Since I'm not quite sure how these are
    intended to be used, I'm also not sure what, if anything, needs to
    be said about them in security considerations, so I'd like to
    DISCUSS that. 
        
  2. Stephen Farrell: Comment [2012-01-18]:
    How is the right policy store/profile selected? I suspect
    this is covered elsewhere (probably in 5213?) but it wasn't
    clear to me.
    
  3. Russ Housley: Discuss [2012-01-17]:
        
      The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern
      and several editorial suggestions.  The authors and Elwyn seem to
      agree that the following text will resolve the concern, but it is not
      in the document yet:
    
        When this bit is set the PMIP6_SUPPORTED flag MUST also be set,
    	and the IP4_HOA_SUPPORTED flag MUST NOT be set. 
        
  4. Pete Resnick: Discuss [2012-01-16]:
        4.3.  Service-Selection
    
       The Service-Selection attribute (Type value TBD2) is of type UTF-8
       text and contains the name of the service or the external network
       that the mobility service for the particular MN SHOULD be associated
       with [RFC5149].  The identifier MUST be unique within the PMIPv6
       Domain.
    
    I've got a question about being "unique". My understanding is that UTF-8 text is
    normally used in Radius for "display to the user only" text and is not compared
    to other pieces of text. Here you say it "MUST be unique". How "unique" does it
    need to be? That is, if one identifier contains an "a" followed by a combining
    acute accent (U+0061 U+0301), and another identifier contains the a-with-acute-
    accent (U+00E1), are those "unique"? I guess the main question is: What are
    these things being used for and will the above make a difference? I think either
    way, some more information is needed in this paragraph to explain. 
        
  5. Pete Resnick: Comment [2012-01-16]:
    
        
  6. Peter Saint-Andre: Comment [2012-01-17]:
    I concur with the DISCUSS position lodged by Pete Resnick.

draft-ietf-netext-bulk-re-registration

  1. Pete Resnick: Comment [2012-01-18]:
    There are several uses of 2119 language in section 5 and 6 that are
    inappropriate:
    
    5.1: I have no idea why "The following considerations MUST be applied by the
    mobile access gateway when supporting this specification" is at all useful. The
    entire sentence should be deleted.
    
    5.1.1: This is worded oddly. It's not that the data structure "MUST be
    extended", it's that the new fields MUST be included. I think what you probably
    mean is, "The conceptual Binding Update List entry data structure maintained by
    the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to
    include the following REQUIRED additional fields." Of course I assume that they
    are now "required for interoperation" [2119] or that not having them "has
    potential for causing harm". [2119] If not, then there shouldn't be 2119
    language at all.
    
    5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the
    following considerations" adds. The requirements are in the paragraphs below. If
    you don't want to strike the sentence, sufficient would be, "The following are
    considerations for the mobile access gateway for requesting bulk binding update
    support for a mobility session."
    
    I think the "MAY" in the first bullet should be "can".
    
    In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be
    applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise,
    what you're saying is "You MUST do everything in section 6.9.1 that says MUST",
    which seems silly and redundant.
    
    5.1.3: In the first and second bullet, s/MAY/can
    
    Also, the last sentence of the first and second bullets have the same problem as
    the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps
    instead, say something like "The requirement of section 5.3.3 of [RFC5213] is
    amended to allow a Mobile Node Group Identifier in place of the individual
    session identifiers."
    
    In the third bullet, the MUST seems useless. How could the gateway not
    "consider the request as a bulk revocation request"?
    
    5.2: Similar to 5.1.
    
    5.2.1: First sentence similar to 5.1.1.
    
    5.2.2: First sentence similar to 5.1.2. But I would simply move the first bullet
    up into that first sentence so it says:
    
       5.2.2. Enabling Bulk Binding Update Support for a Mobility Session
    
          The local mobility anchor will process a received Proxy Binding
          Update message as specified in [RFC5213]. However if the (B)
          flag in the received Proxy Binding Update message is set to a
          value of (1) and if it includes a Mobile Node Group Identifier
          option with sub-type value of (1) (bulk binding update group), the
          following processing takes place:
    
    In sections 6.1 and 6.2, I am concerned about the statements containing "MUST
    allow the following variables to be configured by the system management" since
    that seems to go against 2119 where it says that the terms "must not be used to
    try to impose a particular method on implementors where the method is not
    required for interoperability." Is there an interoperability reason that these
    variables MUST be configurable?
    
    Also, the SHOULD and MUSTs in the definition of the variables doesn't seem
    right. These are not protocol requirements; they are descriptions of the meaning
    of the variables.
  2. Robert Sparks: Comment [2012-01-17]:
    Consider making it even more clear that if _any_ circumstance arises in which a
    group operation might partially fail, the entire group request is rejected. One
    place to do this is 5.2.3 bullet 4, where you could say "for any reason
    (including administrative)" instead of "for any administrative reason".

draft-ietf-ospf-multi-instance

  1. Ron Bonica: Comment [2012-01-16]:
    I agree whole-heartedly with Adrian's Discuss regarding redefining fields from
    another RFC rather than referencing them.
  2. Adrian Farrel: Discuss [2012-01-15]:
        I would be happy to ballot Yes on this document, but there are a couple
    of minor areas where I think the document needs work.
    
    ---
    
    I have a hot button about redrawing and redefining protocol fields. 
    There is a risk in this duplicaton, and problems for future extensions. 
    Your figure in Section 2 reproduces material from RFC 2328. How much of 
    this is necessary? Is it helpful to sometimes say that a field is "as
    specified in [OSPFV2]" and sometimes write text that duplicates RFC 2328
    without actually changing anything?
    
    I think you might get away with the figure and text that says:
    
       All fields are as defined in [OSPFV2] except that the Instance ID
       field is new, and the AuType field is reduced to 8 bits from 16 bits
       without any change in meaning. The Insatnce ID fiels is interpreted as
       follows:
    
    ---
    
    In Section 8 you need to inform IANA that you have reduced the available
    range of values for AuType. This changes the registry.
    
    ---
                                                                            
    The registry in Section 8 shows a number of instance ID value settings
    (namely "Base IPv4 Multicast", "Base IPv4 In-band Management Instance",
    and "Local Policy") without any discussion of the meaning in this
    document. That will not do! You must add description of the meaning of
    these settings somewhere in the body of the document.
    
    ---
    
    Section 8 describes the allocation policy for the range 3-127 as
    "Reserved for local policy assignment". There is no such allocation
    policy in RFC 5226. Do you mean "Private Use"? It is hard for me to 
    guess given the totla lack of description of this range of settings as
    noted in my previous point. 
        
  3. Adrian Farrel: Comment [2012-01-15]:
    I have a few additional Comments that I think would improved the
    document and I hope you will consider incorporating them into a new
    revision.
    
    ---
    
    The Abstract is very dense. Nothing wrong with what you have written,
    but it's quite hard work. How about...
    
       OSPFv3 includes a mechanism to support multiple instances of the
       protocol running on the same interface.  OSPFv2 can utilise such a
       mechanism in order to support multiple routing domains on the same
       subnet.
    
       This document defines the OSPFv2 instance ID to enable separate
       OSPFv2 protocol instances on the same interface.  Unlike OSPFv3 where
       te instance ID can be used for multiple purposes, such as putting the
       same interface in multiple areas, the OSPFv2 instnce ID is reserved
       for identifying protocol instances.
    
       This document updates RFC 2328.
    
    Note that I have left out of the Abstract the statementabout how a
    different funciton is supported by a diffenent protocol extension defined
    in a different document!
    
    ---
    
    You are inconsistent about whether to say "OSPF" or "OSPFv2" when
    refering to OSPFv2. Given that you keep comparing to OSPFv3, I think it
    would be helful to always say "OSPFv2".
    
    ---
    
    You use phrases such as "OSPFv2 currently doesn't offer" which are, of
    course, correct before this becomes an RFC, whereupon they become wrong.
    If you can avoid this sortof thing by saying "This document defines..."
    then the draft is future-proofed.
    
    ---
    
    Can you please replace the future tense with the present tense. For
    example, Section 3
    
       OSPF [OSPFV2] describes the conceptual interface data structure in
       section 9.  The OSPF Interface Instance ID will be added to this
       structure.  The OSPF Interface Instance ID will default to 0.
    
    ---
    
    Section 3.1
    
       When sending OSPF packets, if the OSPF Interface Instance ID has a
       non-zero value, it will be set in the OSPF packet header.
    
    Surely the zero value is also set in the packet header. That is, the
    field is not left uninitialised.
  4. Stephen Farrell: Comment [2012-01-19]:
    Yep, I agree with all the "what a hack" comments. OTOH, I 
    do agree that its not likely that a 256th auth type will be
    needed here.
    
    I also agree that the abstract is very unclear and should be
    rewritten.
    
  5. Peter Saint-Andre: Comment [2012-01-17]:
    Although the authors appear to have documented the interoperability implications
    of reducing the AuType field from 2 octets to 1 octet, that still feels like a
    hack to me. However, I lack the context to judge whether the implications have
    been fully understood or documented. (Note also that this issue is not even
    mentioned in the shepherd writeup!)
  6. Robert Sparks: Comment [2012-01-16]:
    The abstract (identical to the introduction except for references) doesn't
    actually describe what this document does.
  7. Sean Turner: Comment [2012-01-18]:
    I'm with Peter on this draft - I too lack the background and ultimately trust
    that the AD is doing the right.  But, I am curious why this wouldn't be a
    version # change especially if it affects all implementations.

draft-ietf-kitten-sasl-saml

  1. Adrian Farrel: Comment [2012-01-16]:
    I cleared.
  2. Russ Housley: Discuss [2012-01-17]:
        
      The Gen-ART Review from Ben Campbell was updated on 13-Jan-2012.
      Ben provided a Gen-ART Review of -06 at Last Call, and this updated
      review covers -08.  Version -08 is considerably improved, and it
      resolved most of Ben's comments. I would like to see responses to
      these four comments;
    
      1) section 3.2, last paragraph:  "... needs to correlate the TCP
         session from the SASL client with the SAML authentication."
    
         Please elaborate on this correlation.  The author added text, but
         the new text is about correlating response with request.  The text
         that Ben mentioned was about correlating a TCP connection to a
         SAML authentication.
    
      2) section 4, 3rd and 4th paragraphs (paragraphs a and b) seem like
         protocol affecting differences. If so, they need elaboration, such
         as normative statements and formal definitions, or references to
         such.
    
         Ben did not see a response to this comment.
    
      3) section 5, general: The section seems to need further elaboration
         or references.
    
         Ben did not see a response to this comment.
    
      4) Also, this section compresses the interaction with the identity 
         provider. Why not show the details for those steps like the others?
         (If you mean them to be out of scope, then why give as much detail
         as you do?)
    
         Ben did not see a response to this comment. 
        
  3. Dan Romascanu: Comment [2012-01-17]:
    8.2.  IANA OID
    
       The IANA is further requested to assign an OID for this GSS mechanism
       in the SMI numbers registry, with the prefix of
       iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
       reference this specification in the registry.
    
    What the document is actually asking IANA is to assign a new entry in the sub-
    registry for SMI Security for Mechanism Codes whose prefix is
    iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5)
  4. Peter Saint-Andre: Discuss [2012-01-17]:
        This is a valuable document and I support its publication. However, in addition
    to the comments provided below (some of which border on DISCUSS points), I'd
    like to chat about internationalization. Section 3.1 states:
    
       Domain name is specified in [RFC1035].
    
    Does this technology have no support for internationalized domain names
    (IDNs) as defined by RFC 5890 - RFC 5894? 
        
  5. Peter Saint-Andre: Comment [2012-01-17]:
    Section 1...
    
    s/is a modular specification that//
    
    OLD
       As currently envisioned, this mechanism is to allow the interworking
       between SASL and SAML in order to assert identity and other
       attributes to relying parties.
    NEW
       The mechanism defined in this document enables interworking
       between SASL and SAML in order to assert identity and other
       attributes to relying parties.
    
    Question: in order for what to assert identity? An application? A client? A
    user?
    
    "This specification is appropriate for use when a browser is available."
    When is it not appropriate? What are its limitations?
    
    Section 1.2...
    
    In Section 1 we find:
    
       The mechanism assumes a security layer,
       such as Transport Layer Security (TLS [RFC5246]), will continue to be
       used.
    
    However, here we find:
    
       "the SAML mechanism MUST only be used over channels protected by TLS"
    
    Therefore is the "such as" in Section 1 correct? If so, then I think the
    text in Section 1.2 could be reworded as follows:
    
       Because this mechanism transports information that should not be
       controlled by an attacker, the SAML mechanism MUST only be used over
       channels protected by TLS, or over similar integrity protected and
       authenticated channels.  In addition, when TLS is used the client
       MUST successfully validate the server certificate.
    
    Section 2...
    
    This is hard to read:
    
       2.  The Relying Party redirects the browser via an HTTP redirect (as
           described in Section 10.3 of [RFC2616]) to the Identity Provider
           (IdP) or an IdP discovery service with as parameters an
           authentication request that contains the name of resource being
           requested, a browser cookie and a return URL as specified in
           Section 3.1 of the SAML profiles 2.0 specification
           [OASIS.saml-profiles-2.0-os].
    
    I suggest:
    
       2.  The Relying Party redirects the browser via an HTTP redirect (as
           described in Section 10.3 of [RFC2616]) to the Identity Provider
           (IdP) or an IdP discovery service.  When it does so, it includes
           the following parameters: (1) an authentication request that
           contains the name of resource being requested, (2) a browser
           cookie, and (3) a return URL as specified in Section 3.1 of the
           SAML profiles 2.0 specification [OASIS.saml-profiles-2.0-os].
    
    In the paragraph following that one (bullet point 3), what does it mean
    to "authorize the authentication to the Relying Party"? What entity is
    the user authorizing here? The IdP?
    
    s/Universal Resource Identifier/Uniform Resource Identifier/
    
    This is a bit terse:
    
       4.  The SASL client now sends an empty response, as authentication
           continues via the normal SAML flow.
    
    You might consider citing the following paragraph from RFC 4422:
    
       Where the mechanism specifies that the server is to return additional
       data to the client with a successful outcome and this field is
       unavailable or unused, the additional data is sent as a challenge
       whose response is empty.  After receiving this response, the server
       then indicates the successful outcome.
    
    (That is, in this case the server is waiting for information it will
    receive via the SAML flow before it can indicate the successful outcome.)
    
    We might want to expand a bit on this:
    
       6.  Next the client authenticates to the IdP.  The manner in which
           the end user is authenticated to the IdP and any policies
           surrounding such authentication is out of scope for SAML and
           hence for this draft.  This step happens out of band from SASL.
    
    For example, do any specifications provide guidance here (perhaps to use
    basic or digest HTTP authentication)? Also, why say "client" in the first
    sentence and "end user" in the second sentence? Does that difference have
    meaning?
    
    Section 3...
    
       The mechanism is capable of
       transferring an authorization identity (via the "gs2-header").
    
    Does this mean that an authorization identity can be communicated only
    when GS2 is used?
    
       The third mechanism message is from client to the server, and is the
       fixed message consisting of "=".
    
    You might append "(i.e., an empty response)".
    
       The SASL server now validates the response it received from the
       client via HTTP or HTTPS, as specified in the SAML specification
    
    That is a bit unclear -- are we assuming that the SASL exchange takes
    place over HTTP? The examples (IMAP, XMPP) belie such an assumption. Or
    do you mean that the SASL server (as SAML relying party) needs to make
    a connection between (1) its application-specific SASL exchange with the
    SASL client and (2) its HTTP-based SAML exchange with the IdP?
    
    Section 4...
    
    This is a bit underspecified:
    
       The mutual authentication property of this mechanism relies on
       successfully comparing the TLS server identity with the negotiated
       target name.  Since the TLS channel is managed by the application
       outside of the GSS-API mechanism, the mechanism itself is unable to
       confirm the name while the application is able to perform this
       comparison for the mechanism.  For this reason, applications MUST
       match the TLS server identity with the target name, as discussed in
       [RFC6125].
    
    In particular, see Section 13.7.1.2.1 of RFC 6120 for an example of
    the kind of thing you probably ought to specify.
    
    Section 5...
    
    At the least, citing RFC 5056 ("On the Use of Channel Bindings to Secure
    Channels") seems appropriate here.
    
    Section 6...
    
    In the XMPP flow, I would change <incorrect-encoding/> to
    <temporary-auth-failure/> for the error that occurs if no SAML
    Authentication Request can be constructed.
    
    Later in the flow, I would also change <temporary-auth-failure/> to
    <not-authorized/> (e.g., because the credentials are wrong).
    
    In the XMPP flow, I think you don't need Steps 8-11. That's post-auth
    stuff specific to XMPP.
    
    The IMAP example uses "xmpp.example.com" -- I assume you might want
    to change that to "imap.example.com" or "mail.example.com".
    
    Section 8...
    
    The registration does not include all the information requested from
    the template in Section 7.1.1 of RFC 4422 (e.g., intended usage).
    
  6. Sean Turner: Comment [2012-01-17]:
    f1, s2, and f2: If you're talking about the scheme isn't it HTTPS?
    r/HTTPs/HTTPS
    
    s6.1: If you're referring to 4648 then you need to specify which alphabet is to
    be used.

draft-ietf-idr-fsm-subcode

  1. Ron Bonica: Discuss [2012-01-16]:
        I intend to change this DISCUSS to a YES. However, I think that this draft
    should UPDATE RFC 4271. 
        
  2. Adrian Farrel: Discuss [2012-01-15]:
        There was a last call comment from Ran Atkinson that said:
    
       I have read this short document and am familiar with its
       contents.  I am not a BGP implementer, instead I am a BGP
       user (as are several of my clients).
    
       Summary:  Security Considerations are missing
    
       The absence of any substantive "Security Considerations"
       is problematic and needs to be corrected prior to approval.  
    
       As an example, creating these sub-codes will greatly facilitate 
       active probing of remote routers for "OS fingerprinting" or 
       "BGP fingerprinting", which might be used in future to determine
       the manufacturer, software-version, and possibly hardware model 
       of the remote router.  
    
       In turn, such fingerprinting can facilitate targeting attacks
       against security issues present in certain software versions
       or software+hardware combinations.
    
       I do not object to the principle of adding these sub-codes,
       but the practical operational security risks ought to be
       fully and clearly documented before this draft proceeds.  
    
    Without agreeing or disagreeing with what Ran has said, I expect IETF
    last call comments to be resolved through discussion on the IETF list
    before te I-D is approved.
    
    ---
    
    I am unclear whether this document is intended to update RFC 4271. Is
    the plan that all future BGP implementations need to include this work,
    or is the inclusion optional? As currently presented, it is optional. 
        
  3. Stephen Farrell: Comment [2012-01-18]:
    I also support Adrian's first discuss point.
  4. Peter Saint-Andre: Discuss [2012-01-17]:
        The IANA Considerations section states:
    
       IANA is requested to create the registry "BGP Finite State Machine
       Error Subcodes", within the "BGP Error Subcodes" registry, with
       Registration Procedures "Standards Action process or the Early IANA
       Allocation process".
    
    As far as I understand it, "Standards Action" is a registration process (per RFC
    5226) but there is no such registration process as "Early IANA Allocation". It
    is true that RFC 4020 defines procedures for early allocation of code points,
    but that does not mean that early allocation is a registration process. Given
    that early allocation is always possible when the registration process is
    "Standards Action", it is proper to remove the text " or the Early IANA
    Allocation process" from the quoted paragraph. Alternatively, you could say
    something like this:
    
       IANA is requested to create the registry "BGP Finite State Machine
       Error Subcodes", within the "BGP Error Subcodes" registry, with a
       Registration Procedure of "Standards Action" as defined in [RFC5226] 
       (naturally, early allocation of such subcodes is allowed, in accordance
       with [RFC4020]).
     
        
  5. Sean Turner: Comment [2012-01-17]:
    I support Adrian's discuss.

draft-ietf-mile-rfc6046-bis

  1. Stephen Farrell: Comment [2012-01-18]:
    I wonder how easy it is to find a HTTP client implementation
    that won't follow 3xx response codes. I don't know, just wonder:-)
  2. Russ Housley: Discuss [2012-01-18]:
        
      The Gen-ART Review by Alexey Melnikov on 14-Jan-2012 lead to a
      discussion with the authors.  They seem to have settled on agreed
      changes to the document, but the changes have not been made yet. 
        
  3. Peter Saint-Andre: Comment [2012-01-18]:
    First, thank you for addressing the comments that Julian Reschke provided on
    behalf of the Apps Directorate.
    
    Section 3 states:
    
       RID systems MAY be configurable to listen on
       ports other than the well-known port; this configuration is out of
       band and out of scope for this specification.
    
    and:
    
       When performing RID callback, a responding system MUST connect to the
       host at the network-layer address from which the original request was
       sent; there is no mechanism in RID for redirected callback.  This
       callback SHOULD use TCP port 4590 unless configured out of band to
       use a different port.
    
    What does it mean to configure a RID system out of band? As far as I can see
    there is no *in-band* configuration method (i.e., a RID system cannot be
    configured via RID messages), so the use of "out of band" here is confusing. I
    suggest removing this terminology in both instances.
    
    The ABNF reference is old; please change [RFC2234] to [RFC5234].
    
    Section 3 states:
    
       RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
       authentication for confidentiality, identification, and
       authentication, as in [RFC2818], when transporting RID messages over
       HTTPS.
    
    The phrase "as in [RFC2818]" makes it sound as if the rules specified in RFC
    2818 are the kind of rules that might be used, not that those rules must be
    followed. If the intent is that the identity-checking rules in RFC 2818 always
    apply to RID systems, I suggest changing the text to:
    
       RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
       authentication for confidentiality, identification, and authentication when
       transporting RID messages over HTTPS.  RID systems MUST follow the
       rules specified in [RFC2818] regarding verification of endpoint identities.
    

draft-ietf-mile-rfc6045-bis

  1. Adrian Farrel: Comment [2012-01-16]:
    I found the first sentence of the Introduction confusing!              
                                                                              
       This document moves Real-time Inter-network Defense (RID) [RFC6045]
       to Historic status as it provides minor updates.
    
    While I can see that this document moves RFC6045 to Historic, I bet it       
    is not your intention to say that RID is Historic.
    
    How about:
    
       Real-time Inter-network Defense (RID) was previously defined in
       [RFC6045]. This document makes some minor updates to the RID
       specification and moves RID from an informational specification
       onto the standards track. This, this document obsoletes RFC 6045
       and moves it to Historic status.
    
    (Maybe as a standalone paragraph and not running into the the main
    text?)
  2. Stephen Farrell: Discuss [2012-01-19]:
        I've a few things here that are easily fixable I hope after
    which I'll be happy to ballot yes.
    
    1) I'd like to understand why LawEnforcement is a good thing to
    include here and why its not some form of slippery slope that ends
    up going against IETF consensus as represented by rfc2804. This
    protocol would contain LawEnforcement and Tracing. I realise
    that's not wiretap, but its also not very different. It also
    doesn't seem to be technically necessary.  Perhaps a better label
    might be "preserve evidence" or something which might also apply
    between CSIRTs. (Following on from the response to Robert's
    discuss.) 
    
    2) LawEnforcement, OfficialBusiness and AccrossNationalBoundaries
    are odd. I'm not sure why an Internet protocol should distinguish
    between different things like this.  Wouldn't it be silly if there
    were a value there for "DealingWithAGuySellingShoes" so I don't
    see why any bit of any government is any different for this
    protocol. What's done differently on the basis of these fields
    that cannot be (maybe better) done based on the identity of the
    peer and the transport endpoints used?
    
    3) There seem to be a bunch of 2119 terms misused in 9.5, e.g.
    "MUST be addressed" is too vague, ("Yeah, I thought about it, but
    I figured I'd do nothing much. Ok I've addressed that";-), "MUST
    be informed" is a little ambiguous (would page 99 of a legal
    agreement meet the requirement?), "MUST be considered" is too
    vague,  "MUST ... adhere ... to goverment ... regulations" is
    funny since no one piece of code can do that, etc. etc.  And while
    the sentiment behind "must ... not (be) used for ... censorship"
    is laudable, I don't see how that can be done.  I think most or
    all of the 2119 terms in this section could be profitably
    revisisted to be made something with which an implementer or
    deployment could be made to conform. (I didn't notice the same
    problem in other sections but it might be worth a pass to check.)
     
        
  3. Stephen Farrell: Comment [2012-01-19]:
    - Expand CSIRT on first use (and maybe include a reference?)
    
    - The FBI is not a good example and not really needed. Precede it
    with United States or something if you keep it.
    
    - What is an "intermediate party" (p32) shouldn't stuff like that
    be explained up front? What's the model for multiple hops here -
    are requests and responses supposed to be passed on without any
    controls on the intermediary or not? If not, then what controls
    and how do those impact on the protocol?
    
    - Corner case security consideration - related to figure 8, if I
    can monitor the n/w connections of SP3, then when SP3 receives a
    message from SP2 and then replies to SP2 *and* SP1 then I get to
    know for whom SP2 was forwarding the request. Not sure if that's
    significant really but I guess it could alert a bad guy to stop
    doing stuff before the final tracing stage happens. I guess the
    only mitigation would be traffic padding of some sort if (as I
    suspect) traffic volunes here are small. (Does RID support traffic
    padding?) If you ever allowed an insecure transport then this
    might get worse, if the bad guy could flip a bit in the request
    and then see the ack to SP1 connection being attempted, then the
    bad guy gets his warning but SP3 hasn't got the message.
    
    - 9.3.2 is oddly titled, seems like you're really talking about
    a signature being verifiable at many veryifiers.
    
    - I don't get what "In some situations, all network traffic of a
    nation may be granted through a single SP.  " means. (p73)
    
  4. Peter Saint-Andre: Discuss [2012-01-18]:
        First, I'd like to thank you for addressing the comments provided by Larry
    Masinter in his Apps Directorate review.
    
    There are a few topics I'd like to chat about.
    
    1. The document does not pass ID-nits! You might need to fix the document in
    order to address the following errors and warnings:
    
      == Missing Reference: 'XMLschema' is mentioned on line 3519, but not defined
    
      == Missing Reference: 'RFC5735' is mentioned on line 1811, but not defined
    
      == Unused Reference: 'CVRF' is defined on line 3720, but no explicit
         reference was found in the text
    
      ** Downref: Normative reference to an Informational RFC: RFC 3741
    
      ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)
    
      ** Downref: Normative reference to an Informational RFC: RFC 6046
    
    2. This document inherits the definition of Node from the NodeName class in RFC
    5070. Although the IODEF specification defines a NodeName as a fully-qualified
    domain name, it does not provide a definition of that term and specifically does
    not say whether internationalized domain names (IDNs) are allowed. This is a
    significant oversight for a modern protocol.
    
    3. The definition of AcrossNationalBoundaries is confusing. First it says that
    this value must "MUST"?) be set if the message will cross national boundaries
    (and how exactly is the sender to determine whether the the message will in fact
    cross national boundaries?). Then it says that this value is ("MUST BE"?) used
    when additional handling and protection restrictions based on the data type and
    location, which is not the same thing as crossing national boundaries. Then it
    says that this value must be set if the security requirements of the message
    might not apply to all nations. Then it says that this value must be set if the
    traffic is of a type that may have different restrictions in other nations. This
    is such a muddle that I don't see how an SP could choose any value other than
    AcrossNationalBoundaries.
    
    4. In Section 7, some of the examples include XML comments. Are these allowed?
    Are any other aspects of XML disallowed (e.g., processing instructions and
    external DTD subsets)? Can conforming applications ignore or reject such data? I
    think the processing rules and security considerations are underspecified here.
    At the least, it would be helpful to cite RFC 3270 and RFC 3023 with regard to
    the use of XML in IETF application protocols. 
        
  5. Peter Saint-Andre: Comment [2012-01-18]:
    The Introduction would be easier to read if the summary of changes since RFC
    6045 were moved to an Appendix.
    
    Please expand "FBI" on first use, preferably via "U.S. Federal Bureau of
    Investigations (FBI)".
    
    Section 4.1.1 introduces the BOOLEAN data type, which is implemented as the
    xs:boolean type from W3C XML Schema. It would be helpful to note that there are
    two lexical representations of boolean in XML schema. I suggest changing the
    text as follows.
    
    OLD
       The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
       the schema.
    
    NEW
       The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
       the schema.  Note that there are two lexical representations for
       boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false'
       for FALSE.
    
    In Section 5, why is this document defining a 'lang' attribute when any XML data
    can include the 'xml:lang' attribute via inheritance from the core XML
    specificiation?
    
    The class definitions are inconsistent. I see several styles, such as:
    
       One.
       Zero or one.
       One or more.  REQUIRED.
       REQUIRED.  ENUM.
       One or many.  REQUIRED.
       Zero or One. URL.
       Zero to many.
    
    It would help to make those consistent. 
    
    Section 5.1 states:
    
       The RIDPolicy Class includes the ability to embed an IODEF or
       other XML schema document in the ReportSchema element.
    
    I don't think you're embedding XML schema documents, I think you're embedding
    XML documents that conform to schemas other than IODEF.
    
    Section 5.1 states:
    
       PolicyRegion
    
          One or more.  REQUIRED.  The values for the attribute "region" ....
    
    Is that supposed to be "PolicyRegion"?
    
    In Section 5.1.1, is "XMLDocumen" a typo?
    
    In Section 5.3, why is the IncidentSource restricted to FQDNs (Nodes)? It seems
    that the source of an incident might be an IP address, an email address, etc.
    
    This text in Section 5.4 is confusing:
    
       The RID schema declares a namespace of "iodef-rid-2.0" and registers
       it per [XMLNames].  Each IODEF-RID document MUST use the
       "iodef-rid-2.0" namespace in the top-level element RID-Document.
    
    In fact the namespace is not "iodef-rid-2.0" but "urn:ietf:params:xml:ns:iodef-
    rid-2.0". In addition, the "Namespaces in XML 1.0" specification says nothing
    about registration of XML namespaces; perhaps you meant to cite RFC 3688?
    
    In Section 5.5.1, do you really intend to include schemas, or documents defined
    by other schemes?
    
    The text in Section 6 is a bit misleading when it says that "The IODEF model
    MUST be fully implemented to ensure proper parsing of all RID messages." That's
    true only for RID messages that contain IODEF payloads, not RID messages that
    contain payloads defined by other schemas.
    
    In Section 8, the XML comment is quite distracting. Why not include this
    information in the xs:annotation element?
    
    Section 9.1 states:
    
       o  The originator of a Request MUST use a detached signature to sign
          at least one of the original elements contained in the RecordItem
          class to provide authentication to all upstream participants in
          the trace or those involved in the investigation.
    
    Is this required even in cases where channel encryption (e.g., TLS) is used
    between the parties to a PeerToPeer exchange that doesn't involve upstream
    participants? (By the way, it seems that some of the examples in the spec
    violate the rule from SEction 9.1.)
    
    In Section 9.1, do you mean "MAY" in the text "The IODEF/RID document may be
    encrypted"? The same question applies to "The action taken in the Result message
    may be encrypted". The difference between conformance and normal usage is
    especially confusing in a sentence like this:
    
       A Request, or any other message type that may be relayed through
       RID systems other than the intended destination as a result of
       trust relationships, may be encrypted for the intended recipient.
    
    I encourage you to check all the text in Section 9.1 (and elsewhere)  to make it
    clear whether you intend your guidelines to have conformance force.
    
    It's a bit confusing to say in Section 9.1 "See Section 9 for a discussion on
    public key infrastructure (PKI) and other security requirements." I think you
    mean Section 9.3. :)
    
    Section 9.2 states:
    
       The transport specifications are fully defined in a separate document
       [RFC6046-bis].
    
    I think you mean "A transport specification" because it seems that you are
    leaving the door open to defining other transport bindings in the future.
    
    Section 9.2 states:
    
       The RID protocol must be able to guarantee delivery and meet the
       necessary security requirements of a state-of-the-art protocol.  In
       order to guarantee delivery, TCP should be considered as the
       underlying protocol within the current network standard practices.
    
    There's a lot more to truly guaranteed delivery at the application layer than
    simply using TCP as the underlying transport. Do you mean at least once
    delivery, at most once, or something else? Do messages need to be persisted in
    case the messaging system crashes? And so on. You might consider dropping this
    paragraph, or clarifying what you really mean by guaranteed delivery.
    
    I find this a bit confusing:
    
       Consortiums may vary their selected transport mechanisms and thus
       decide upon a mutual protocol to use for transport when communicating
       with peers in a neighboring consortium using RID.  RID systems MUST
       implement and deploy HTTPS as defined in the transport document
       [RFC6046-bis] and optionally support other protocols such as the
       Blocks Extensible Exchange Protocol (BEEP) [RFC3080].
    
    If consortia are allowed to decide upon their own preferred transport bindings,
    why is HTTP/TLS a MUST-deploy technology?
    
    As to "optionally support other protocols", clearly someone would need to define
    bindings for those protocols (BEEP or XMPP or SIP or whatever) before they could
    be used -- it appears that one can't simply start sending RID documents over
    those protocols without some definition of the binding (as is already done for
    things like SOAP). So the current text is a bit misleading.
    
    Section 11 states:
    
          Registrant Contact: See the "Author's Address" section of this
          document.
    
    However, RFC 3688 states:
    
       In the case of IETF developed standards, the Registrant will be the IESG.
    
  6. Robert Sparks: Discuss [2012-01-17]:
        (Hit send too soon - sorry - there's an additional comment added at the end)
    
    What motivated the addition of the LawEnforcement PolicyRegion? The other
    PolicyRegion region definitions give some hint about how the mark might affect
    processing. It's not clear how this marking this region is required for (or
    helps) interoperability.
    
    Possibly related - the definition of the OfficialBusiness TrafficType (inherited
    from 6045) is vague. What an example of an "other official business request"
    that's not a government request? Is there an example of a request that should
    use this mark that's not related to a legal investigation?
    
    Can the document make it clearer how either of those enumerated values will be
    used (not just when a sender might
    set them)?
    
    As this is moving from Informational to Standards Track, should there be any
    policy captured in the document around adding values to PolicyRegion and
    TrafficType enumerations? (For example, someone may wish to mark messages
    moving
    across HEPA or FERPA controlled boundaries.) 
        

draft-ietf-lisp-map-versioning

  1. Ron Bonica: Discuss [2012-01-16]:
        --------------------------------------------------------------------------------
    -
    
    Section 5.1, Bullet 2: Do you really want to drop this packet? Won't this
    condition occur whenever the following are true:
    
    - multiple ETRs serve the site
    - a mapping update is in progress
    - the ETR receiving the packet has not yet been updated
    - another ETR has been updated
    - the ITR received its mapping from the ETR that has been updated.
    
    --------------------------------------------------------------------------------
    --
    
    Section 5.3, Bullet 3: Do you really want to drop this packet. Same argument as
    above, but viewed from the other side of the tunnel.
    
    --------------------------------------------------------------------------------
    --- 
        
  2. Stewart Bryant: Discuss [2012-01-19]:
        This document should have an up front (Introduction) statement recording the
    issues stated in section 12, since without that statement the reader has the
    impression for most of the document that this is a fully baked solution.
    
    In particular the document seems to be saying that without the synchronization
    problem being solved their are significant issues with this mechanism. That
    would suggest that we ought to solve the synchronization mechanism at least in
    some rudimentary way before publishing this element of the LISP specification
    series. 
        
  3. Stewart Bryant: Comment [2012-01-19]:
    There are many abbreviations that are used without expansion in the
    Introduction.
    
    Appendix A is  confusing firstly because it is unclear as as to whether the 12
    bits is right on the edge of acceptability, or is a realistic number that will
    be useful for the foreseeable future. Secondly it explains how wonderful it
    would be to have between 16 and 32 bits of version without providing any
    information on whether this is realistic to retrofit into the protocol.
  4. Ralph Droms: Discuss [2012-01-19]:
        In my opinion, draft-ietf-lisp-interworking should
    be a normative reference in this document.  All
    of section 8.3 seems to depend on the details
    of the interworking mechanisms in draft-ietf-lisp-interworking.
    
    I've reviewed this document to the extent possible
    without reviewing draft-ietf-lisp-interworking, which
    has not yet come up for IESG review.  This document
    will require additional review once draft-ietf-lisp-interworking
    has been reviewed, to ensure any changes in
    draft-ietf-lisp-interworking are reflected in this document. 
        
  5. Adrian Farrel: Discuss [2012-01-12]:
        I am holding this Discuss until the resolution of my Discuss on the main LISP
    specification that is a normative reference.
    
    depending on how that is resolved, this document will need a pointer to the
    disclaimer text added to the base LISP spec.
    
    All other issues I raised on this document have been resolved. 
        
  6. Adrian Farrel: Comment [2011-11-12]:
    
        
  7. Stephen Farrell: Comment [2011-09-20]:
    If there's conflict in normative text between this and base,
    which takes precedence? I think you need to say, even if
    you believe there is no such conflict, just in case it turns out
    that there's some hidden conflict or the base draft changes
    after this one is done.
  8. Pete Resnick: Comment [2011-10-06]:
    It's hard to imagine that anyone would treat values as other than big endian,
    but it might be worth being explicit in the document.
  9. Robert Sparks: Comment [2012-01-16]:
    
      

draft-ietf-pcn-signaling-requirements

  1. Stewart Bryant: Discuss [2012-01-17]:
        "The representation of a PCN-flow identifier depends on the
     surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. 
     Examples of such PCN-flow identifier representations can be found in 
     [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. "
    
    The above text implies that it is a simple matter to identify 
    and represent an MPLS flow. I do not believe this to be the case.
    The authors should either specify how they propose to 
    represent MPLS flows (as they do for IP) or note that this
    is a problem that needs to be solved. 
        
  2. Adrian Farrel: Discuss [2012-01-18]:
        In Section 2 (and repeated in 3)
    
       Signaling messages SHOULD have a higher priority than data packets to
       deliver them quickly and to avoid that they are dropped in case of 
       overload.                                                                 
    
    Unless I am mistaken, there is a difference between priority and drop
    precedence.
    
    Can you also clarify whether you mean all data packets, or justdata 
    packets on the measured flow.
    
    ---
    
    I have a point that is very similar to Stewart's...
    
       The representation of a PCN-flow identifier depends on the
       surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. 
       Examples of such PCN-flow identifier representations can be found in 
       [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. 
    
    I don't find any mentiong of PCN in those documents, so I think you mean
    "Identifiers for flows can be found in [foo]. These identifiers can be
    used in PCN to identify the flows that are measured and reported on."
    
    Thinking about it, the wider problem may be that the discussion in 2.1 
    is actually solution-oriented. The requirements are to be able to apply
    PCN to a specific set of flows, and that the flow about which PCN is
    being signaled should be unambiguously identified. Those requirements
    are worth stating. You might even say tat there is a requirement that 
    the data packets not be encumbered by any additional fields used for 
    flow identification, therefore all flow identifiers must utilize only
    fields already present in the data headers. [At this point you might
    aslo comment on how deep it is acceptable to look - e.g., can you look
    below a top MPLS label?]
    
    But the discussion of which identifiers are suitable is surely not a
    matter for a requirements document.                                 
    
    ---
    
    Section 4
    
       [RFC5559] provides a general description of the security
       considerations for PCN. This memo does not introduce additional 
       security considerations.
    
    I agree with the statement about RFC 5559. But surely this requirements
    document places security-related requirements on the PCN signaling.
    These should be noted in this section. 
        
  3. Adrian Farrel: Comment [2012-01-18]:
    You should remove the citations from the Abstract.
  4. Stephen Farrell: Comment [2012-01-19]:
    I just note that 5559 which is referenced here says "The signalling 
    between the PCN-boundary-nodes must be protected from attacks."
    So I'm counting on the eventual protocol document meeting that
    goal.
  5. Peter Saint-Andre: Comment [2012-01-17]:
    A question for the responsible AD...
    
    The PROTO writeup states:
    
          The -03 version generated significant debate on the working group
          mailing list during WGLC.  The editor addressed the comments
          to everyone's satisfaction.  There are no vocal dissenters.
    
    Just curious: what were the topics that generated significant debate? It would
    be helpful to mention those in the ballot writeup.

rfc2874

draft-ietf-lisp

  1. Jari Arkko: Discuss [2011-12-01]:
        Holding a DISCUSS until IANA provides a review, that has not arrived yet but
    should in a couple of days. 
        
  2. Ron Bonica: Discuss [2012-01-18]:
        .
    
    Success Criteria
    ============
    Please be specific about success criteria for this
    experiment. What outcome must an experimenter observe in order to consider the
    experiment a success? Clearly, the experimenter must observe no significant
    decrease in network performance or availability. However, that alone is not
    enough to motivate the experiment.
    
    The Introduction suggests that the experiment is motivated by a desire to
    enhance the scaling characteristics of the global Internet. Having completed the
    experiment, how will you determine whether you have achieved that goal? One
    possibility is to make some predictions regarding the size of the global routing
    tables versus the size of the routing tables carried in LISP ALT at various
    points in the experiment (i.e., when only a few sites participate in LISP, when
    half of the Internet participates in LISP, when most of the Internet
    participates in LISP). The experiment could compare projected results to
    observations.
    
    Experiment Scoping
    ===============
    Joel points out that the DISCUSS item below
    is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending
    resolution of Adrian's.
    
    {Please scope the experiment. How many sites or prefixes must be carried by LISP
    in order to yield meaningful results? Given the remote possibility that LISP
    machinery may scale to a certain point and then fail dramatically, should the
    document provide any guidelines regarding experiment participation (e.g., non-
    mission critical).}
    
    IPv4 vs IPv6
    =========
    Please comment on how LISP will enhance the scaling
    capabilities of the IPv4 routing system, in which it is impossible to allocate a
    contiguous address block for EID use. 
        
  3. Stewart Bryant: Discuss [2012-01-19]:
        Having re-read the document and having reviewed some of the other LISP documents
    I am updating my discuss.
    
    The fundamental problem is understanding the LISP as presented in this base
    specification is that there is an implicit rather than explicit architecture.
    Understanding the architecture is important in understanding how the experiment
    is (or is not working) and understanding how to modify/correct/extend the
    protocol. Either this documents needs an architectural description up front
    showing how all the components fit together and which precedes the protocol
    definitions, or an architectural of framework document needs to be published
    first.
    
    In addition the definitions section really needs be split into a definitions
    section (with care being taken over the 
    generic definition of terms vs the
    unicast specific  definition), and a section describing the protocol 
    operations
    associated with those terms.
    
    The document needs to be clearer on what happens when the traffic is a high
    volume UDP source that only transmits occasionally. Say (but not limited to)
    some form of remote IPFIX collector that is occasionally triggered.
    
    My concern is 
    
    a) Do we see a large chunk of the flow dropped on the floor until the mapping is
    learned - the conflict is between DOS attack and degradation of service WRT the
    "legacy Internet".
    
    b) Do we see a miss ordering of packets during as the system swaps from probe to
    normal operation
    
    c) Do we see a repeat of this as a result of cache aging.
    
    ======== 
    
    I am also moving the following up to Discuss since it is related
    to the need for a clear description of the impact of the cache
    vs the existing behavior of the Internet.
    
    5.4.2.  A Stateful Solution to MTU Handling
    
    SB> It looks like there needs to be some discussion about
    SB> the state lifetime, and the issue of holding a stale
    SB> MTU vs transienting a flow by flushing the cache. 
    
    Note that in both cases I am not requesting a change to the protocol,
    just a clear explanation of the expected behavior. 
        
  4. Stewart Bryant: Comment [2012-01-19]:
    "Tunnel Router".  - should he in the definitions section as a generic type since
    you say it is a fundamental component.
    
    ==========
    
    5.1.  LISP IPv4-in-IPv4 Header Format
    
    SB> It would be helpful to the reader to put a forward ref to
    SB> the definition of terms in 5.3 - same in 5.2.
    
    ==========
    
       UDP Checksum:  The UDP checksum field SHOULD be transmitted as zero
          by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
          [UDP-TUNNELS].  When a packet with a zero UDP checksum is received
    
    SB> UDP-TUNNELS seems to be a normative reference to an expired
    SB> individual draft. That seems to risk this (LISP) document going
    SB> into limbo. The following text suggests that the reference 
    SB> should be changed to informative anyway.
    
          .... The handling of UDP
          checksums for all tunneling protocols, including LISP, is under
          active discussion within the IETF.  When that discussion
          concludes, any necessary changes will be made to align LISP with
          the outcome of the broader discussion.
    
    =========
    
         0 x 0 1 x x x x
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 Instance ID/Locator Status Bits               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    SB> I cannot see a definition in this section of the terms 
    SB> Source Map-Version and Dest Map-Version
    
       I: The I bit is the Instance ID bit.  See Section 5.5 for more
          details.  When this bit is set to 1, the Locator Status Bits field
          is reduced to 8-bits and the high-order 24-bits are used as an
          Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
          are transmitted as zero and ignored on receipt.  The format of the
          LISP header would look like:
    
         x x x x 1 x x x
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |N|L|E|V|I|flags|            Nonce/Map-Version                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 Instance ID                   |     LSBs      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    SB> s/LISP header would look like:/LISP header in this case is:/
    SB> More importantly it is slightly confusing putting the 0 case
    SB> rider before the format, since at first glance it looks like
    SB> the format is only like this when L = 0.
    
    =========
    
       o  The outer header Type of Service field (or the Traffic Class
          field, in the case of IPv6) SHOULD be copied from the inner header
          Type of Service field (with one caveat, see below).
    
    SB> Given that you have separated the host domain from the 
    SB> ISP domain, I am not sure why this is a SHOULD.
    
    ==========
    
       When doing ETR/PETR decapsulation:
    
       o  The inner header Time to Live field (or Hop Limit field, in case
          of IPv6) SHOULD be copied from the outer header Time to Live
          field, when the Time to Live field of the outer header is less
          than the Time to Live of the inner header.  Failing to perform
          this check can cause the Time to Live of the inner header to
          increment across encapsulation/decapsulation cycle.  This check is
          also performed when doing initial encapsulation when a packet
          comes to an ITR or PITR destined for a LISP site.
    
    SB> What LISP is doing is very similar in many respects to
    SB> MPLS does, and MPLS found that it needed both copy TTL and
    SB> not copy TTL. I am surprised that you did not follow that model.
    
    ========
    
    6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats
    
       The following UDP packet formats are used by the LISP control-plane.
    
    SB> They are not UDP pkt formats, they are UDP/IP packet formats.
    
    ========
    
    6.1.1.  LISP Packet Type Allocations
    
       This section will be the authoritative source for allocating LISP
       Type values.  Current allocations are:
    
    SB> Surely the section *is* the authoritative source?
    SB> Are you sure you do not need a registry for this?
    
    =======
    
    9.2.  IPv4 Traceroute
    
       The solution we propose to solve this problem is to cache traceroute
       IPv4 headers in the ITR and to match them up with corresponding IPv4
       Time Exceeded messages received from core routers and the ETR. 
    
    SB> This sounds like quite a complicated mechanism. Did the authors
    SB> consider having the ITR do proxy traceroute?
  5. Ralph Droms: Discuss [2012-01-17]:
        Updated to refer to rev -19
    
    EIDs are defined to be "not routable on the public
    Internet."  What are the global uniqueness properties
    required for EIDs, both among EIDs and between
    EIDs and globally routable IP addresses?  How
    are EIDs with the appropriate properties chosen
    and coordinated among LISP sites? 
        
  6. Ralph Droms: Comment [2012-01-17]:
    Updated to refer to rev -19
    
    I'd like to see a mention of the complementary observation that
    using a single ID-LOC avoids the necessity of a separate step to
    bind an identifier to its location and a database to manage those
    bindings.  A mention of the scale of the binding database would be
    appropriate, too.
    
    As I understand LISP, the EIDs are still ID-LOCs, not pure
    identifiers, within a LISP site.  Outside any LISP site, an EID is a
    pure identifier.  Which begs the question: exactly what is LISP
    providing, since it isn't providing a pure ID/LOC separation.  E.g., a
    node can't move within a site without changing its ID, nor can it move
    between sites without changing its ID.  Of course, this hybrid ID/LOC
    architecture helps with the scaling of the ID/LOC binding database. 
    
    In section 4: first bullet of "basic rules": is it the case that
    end-systems are aware of LISP at all?
    
    I would write the first phrase of the third paragraph of section 5 as
    "Because EIDs and RLOCs can be either IPv4 or IPv6 addresses, ..."
    
    I don't understand the deployment method described in section 5.5.  I
    think I understand the scenario, but I don't understand how RFC 1918
    prefixes can be used as EID prefixes.  How is an EID that has an RFC
    1918 prefix disambiguated to do the EID-RLOC mapping?  This
    question is related to the Discuss issue asking for clarification
    of the global uniqueness requirements for EIDs.
    
    In section 6.3, how does an ITR determine the original destination of
    an encapsulated datagram that triggers an ICMP Network or Host
    Unreachable message, so it can construct a meaningful ICMP Unreachable
    message to send to the original source of the datagram?
    
    In section 10.2, I understand how LISP can help avoid site
    renumbering, as described in RFC 4192, but I don't understand how it
    helps with renumbering a single node that moves
    within or between sites.  What is the impact of host renumbering on
    LISP forwarding?  What is the citation of RFC 4984 at the end of
    section 10.2 in reference to?
    
    I see that Jari has a Discuss waiting for IANA review.  I think
    section 14 needs clarification - e.g., while section 14 includes
    the text "There are two name spaces in LISP that require registration,"
    there appear to be four registries requested in section 14.
    
    How is the statement from the definition of EID-prefix:
    
       A globally routed
       address block MAY be used by its assignee as an EID block.
    
    compatible from this statement from sections 2 and 4, respectively:
    
       [...] (EIDs), which are assigned independently from
       the network topology, [...]
    
       [...] an EID is only routable within the scope of a site.
    
    I think the issue is that some additional caveats are required if "a
    globally routed address block [is] used [...] as an EID block";
    spec. those addresses from the globally routed address block used as
    EIDs must not be allowed to be actually routed directly over the
    Internet.  Well, maybe, as we'll need to see how the transition
    mechanisms provide interoperability between LISP and
    non-LISP systems.
    
  7. Wesley Eddy: Discuss [2011-11-29]:
        If both the N bit and V bit MUST NOT be set in the same packet, then why would
    there be any rule defined for processing such a packet rather than to DROP it?
    It seems wrong to pretent that's okay and just treat it as if the V bit wasn't
    set.  What is the advantage of this, and is there any risk?
    
    Section 5.4.1 is not clearly written, and seems fairly critical to proper
    performance.  For instance, what does it mean when it says S is the maximum size
    of a packet that an ITR "would like to receive"?  Is it the maximum that it
    *can* receive, the maximum that it can send on a next hop without fragmenting,
    etc.?  From the description in the 2nd paragraph, the size would only be S/2 + H
    if the incoming packet were size S, in which case after adding H, it would be
    size L, NOT greater than L as the first sentence says.  The definitions here
    really need to be tightened up and clarified.
    
    I believe the stateful solution in 5.4.2 is preferable to the stateless one
    which seems like it could have very bad effects if it really sets DF=1 and isn't
    keeping any state about whether smaller fragments need to be sent for a
    particular destination.  The 5.4.1 algorithm doesn't solve this at all, and
    seems inadequate for providing a robust infrastructure.
    
    RLOC probing has an impact on the network capacity in-use and there is no way to
    sense when the overall rate of probing may simply be too great for some
    bottleneck to handle (due to some combination of the number of RLOCs being
    probed or the rate of probing).  Losses can occur either of the probes or the
    map-replies.  Even in cases where it isn't a significant source of congestion,
    the probing has to be implemented to avoid having bad things happen like
    accidentally causing synchronization of sending the probes such that this
    control traffic spikes periodically.  Overall, unless the RLOC probing is better
    specified so that the risks and necessary precautions are well understood, this
    seems like a feature that could cause unexpected impact to data flows under some
    conditions. 
        
  8. Wesley Eddy: Comment [2011-11-29]:
    In Section 5.3, UDP Checksum discussion, the reference to draft-eubanks-
    chimento-6man should probably be to draft-ietf-6man-udpzero instead.
    
    In section 5.4.1, what is "an architectural constant"?  Should this just say "a
    constant"?
  9. Adrian Farrel: Discuss [2012-01-08]:
        I have updated my Discuss to remove the issues resolved in the -19
    revision. 
    
    ---
    
    I'm inclined to agree with Russ that this is well-enough specified for
    an experimental status document, but I have some concerns.
    
    ---
    
    I don't see any statement of the scope of the experiment or how it will
    be judged. Traditionally, experiments are not released into the Internet
    but are operated in a controlled way in walled gardens. It appears that
    the intention with this experiment is that it should be conducted in the
    Internet, and that makes it important to examine the risks and
    uncertaintes.
    
    As part of the Discuss resolution on other LISP documents, and in
    accordance with the LISP WG charter, we had agreed that this
    specification would countain an upfront and clear statement of the
    issues and concerns. To remind you, the charter says:
    
     At this time, these proposals are at an early stage. All proposals
     (including LISP) have potentially harmful side-effects to Internet
     traffic carried by the involved routers, have parts where deployment
     incentives may be lacking, and are NOT RECOMMENDED for deployment beyond
     experimental situations at this stage. Many of the proposals have
     components (such as the identifier to locator mapping system) where it
     is not yet known what kind of design alternative is the best one among
     many.
    
    and
    
     The LISP WG is NOT chartered to develop the final
     or standard solution for solving the routing scalability problem. Its
     specifications are Experimental and labeled with accurate disclaimers
     about their limitations and not fully understood implications for
     Internet traffic. In addition, as these issues are understood, the
     working group will analyze and document the implications of LISP on
     Internet traffic, applications, routers, and security. This analysis
     will explain what role LISP can play in scalable routing. The analysis
     should also look at scalability and levels of state required for
     encapsulation, decapsulation, liveness, and so on
    
    I do not consider that this draft has adhered to the WG charter, and I
    consider the active encouragement of "early deployments" to be both
    against the spirit and the letter of the charter. If you believe that
    the experiment needs to be conducted "in the wild" you need to spend a
    bit more text explaining why this is safe and how the experiment is
    contained.
    
    I have proposed text on the LISP mailing list to address this part of my
    Discuss.
    
    ---
    
    Section 2
    
       Routing Locators (RLOCs), which are topologically assigned to network
       attachment points (and are therefore amenable to aggregation)
    
    I don't see that RLOCs are any more amenable to aggregation than today's
    IP addresses. That is, the allocation scheme for RLOCs could be run such
    that RLOCs are aggregatable, but could equally be run such that it is
    hard to aggregate.
    
    Maybe the points here are that:
    - network attachment points are not (currently) mobile
    - network attachment points are defined by the networks they attach to
    - network attachment points, by definition, impose an aggregation of
      end points.
    
    A way to solve this, if you wrote what you intended to write, would be a
    forward pointer to the section in the document that describes
    aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.
    
    ---
    
    Section 2
    
       One database design that is being developed
       and prototyped as part of the LISP working group work is [ALT].
       Others that have been described but not implemented include [CONS],
       [EMACS], [RPMD], [NERD].
    
    Is the LISP working group undertaking controlled prototyping?
    Is the intention to state that "there are known protocotype
    implementations of [ALT]."
    
    Similarly, what does it mean to say "have been described but not
    implemented"? I guess: "At the time of writing, the authors are unaware
    of any implementations of..."
    
    ---
    
    Section 3
    
          When using multiple mapping database
          systems, care must be taken to not create reencapsulation loops.
    
    What is this "care"?
    What about loops caused by transient conditions (or errors) in a single
    LISP mapping database?
    Shouldn't the payload TTL at least be decremented by one for each
    tunnel?
    
    Note that reencapsulation is not the same as nested encapsulation.
    You are clear about avoiding the latter (although some form of DPI
    may be required to achieve it).
    
    ---
    
    Step 7 of Section 4.1 doesn't make it clear what has happened to the
    first packet in the flow. I had assumed that it was buffered pending
    the Map-Reply, but I now suspect it was discarded as soon as the
    Map-Request was constructed. Can you add a clarification. 
        
  10. Adrian Farrel: Comment [2012-01-08]:
    I have updated my Comment to remove those points that you have addressed
    in revision -19 (thanks).
    
    ---
    
    The architectural overview in Section 4 would be enhanced by a picture.
    
    The example in 4.1 would similarly benefit.
    
    ---
    Section 5.3
    
    I agree with Wes about the N and V bits.
    
    ---
    
    Section 5.3 LISP Nonce
    
          When the E-bit is clear but the N-bit is
          set, a remote ITR is either echoing a previously requested echo-
          nonce or providing a random nonce.
    
    "is clear/set" in what?
    The original message sent, or the new message received?
    
  11. Stephen Farrell: Comment [2012-01-16]:
    This was a discuss, but on the basis that the lisp WG re-chartering
    will address the issue, I'm clearing.
    
    #12, It looks from 6.1.6 like a Map-Register can be replayed. That's
    not a good thing. There may be a similar replay 
    issue with Map-Notify messages.
  12. Russ Housley: Comment [2011-11-29]:
      This is going for experimental, and I think it clears the bar for
      experimental.  However, I think Section 6 could be much more clear.
  13. Pete Resnick: Comment [2011-11-29]:
    LISP sounds like a serious protocol experiment. I would have liked there to be
    more discussion in either the document or in the writeup about how that
    experiment is going to conclude. That is, though I see the things in section 15
    that indicate what it would take to really move this to the standards track, it
    would be nice to see some discussion about how interoperability is going to be
    measured as the experiment progresses.
  14. Dan Romascanu: Comment [2012-01-18]:
    1. I support Pete's COMMENT and Adrian's DISCUSS about the need to make more
    clear the goals of the experiment, the criteria of success and the limits of
    deployment while the document stays Experimental.
    
    2. It would be more clear to split 14.1. into two sub-sections, especially as
    IANA is required to create a registry for LISP ACT if I understand correctly,
    while no action is required from IANA for the Flag Fields
    
    3. I support Stewart's DISCUSS. One of the sources of UDP traffic that transmit
    occasionally may be SNMP agents in the core. When sending unaknowledged
    notifications (a.k.a. traps) these could be dropped on the floor and then if the
    cache is flushed they will be lost forever. Altough traps are not supposed to be
    used in critical applications, systematic loss in what would not be a meltdown
    situation could badly impact the manageability of the routing environment,
  15. Peter Saint-Andre: Comment [2011-11-30]:
    Experiments are good. Although I share Pete's and Adrian's concerns about the
    scope of the experiment and the parameters for evaluating its success, I agree
    with Russ that the document is specified clearly enough to be implemented in an
    experimental fashion (modulo Ralph's question about global uniqueness).
  16. Robert Sparks: Comment [2011-12-01]:
    I'm clearing, trusting the shepherd and responsible AD to ensure that the
    informative references point to to appropriate places. In particular, please
    verify that it's possible to obtain [RPMD].
  17. Sean Turner: Comment [2012-01-19]:
    
      

draft-ietf-lisp-multicast

  1. Stewart Bryant: Discuss [2012-01-17]:
        This document defines a set of terms EID, RLOC etc which at first sight seem
    identical to the unicast terms. However the description of their operation seems
    to make them different objects, in which case they need different names. If the
    names are to be common, there needs to be a separation of the name from the mode
    of operation.
    
    Where the object is identical to the unicast term (LISP Header?) the object
    should not need to be redefined in this document since this invites issues of
    subtle difference between the competing definitions. 
        
  2. Stewart Bryant: Comment [2012-01-17]:
    "By using the traffic engineering features of LISP" needs a ref.
    
    The subtleties of different m/c paths surely belongs after the basic description
    rather than as the first item
    
    The protocols in section 7 need references
    
    Mpriority seems to lack a definition
  3. Ralph Droms: Comment [2012-01-18]:
    Now that the base LISP protocol document has been published, I've cleared my
    Discuss on this document.
  4. Adrian Farrel: Discuss [2012-01-18]:
        I have no objection to the content of this document, and I thank you 
    for spelling out (and calling out) the considerable complexity 
    expecially in Section 9.
    
    ---
    
    As previously noted on other LISP documents, I would like a pointer
    to the generic caveat text being added to the main LISP spec.
    
    ---
    
    The answer to Ron Bonica's Discuss (now cleared) intimated that there
    are actually no changes to the multicast protocols since "it is LISP-
    Multicast that sends unicast PIM join and prune messages."
    
    I am trying to understand whether this document does or does not make 
    any changes to (e.g.) PIM. In Section 2 I see bullet 3...
                                                                          
       3.  What protocols are affected and what changes are required to such
           multicast protocols.
    
    Is this rhetoric ("I will show you which protocols are affected. None!")
    or is there some contradiction?
    
    Since Section 2 goes on to say...
    
       This specification focuses on what changes are needed to the
       multicast routing protocols to support LISP-Multicast as well as
       other protocols used for inter-domain multicast, such as Multi-
       protocol BGP (MBGP) [RFC4760].  The approach proposed in this
       specification requires no packet format changes to the protocols and
       no operational procedural changes to the multicast infrastructure
       inside of a site when all sources and receivers reside in that site,
       even when the site is LISP enabled.  That is, internal operation of
       multicast is unchanged regardless of whether or not the site is LISP
       enabled or whether or not receivers exist in other sites which are
       LISP-enabled.
    
    It really sounds like no changes are needed to any of the protocols. It
    is just a question of how the individual routers use the protocols (i.e.
    how they supply information to and extract information from the 
    protocols). Maybe this just needs a change in tone of the text to stop 
    me repeatedly going into a panic about changes to protocols when I read
    
       Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
       and PIM-SSM [RFC4607].
    
    Section 7 (which really had me worried) appears to list each protocl and
    then say "no changes needed" for *nearly* all of them. But for PIM-SSM 
    we have
    
          In this case, there is a small
          modification to the operation of the PIM protocol.  No
          modifications to any message format, but to support taking a Join/
          Prune message originated inside of a LISP site with embedded
          addresses from the EID namespace and converting them to addresses
          from the RLOC namespace when the Join/Prune message crosses a site
          boundary.  This is similar to the requirements documented in
          [RFC5135].
    
    That is a change or not? 
        
  5. Adrian Farrel: Comment [2012-01-18]:
    The title talks about "LISP for multicast environments" but the Abstract
    is specific to "inter-domain multicast routing". Should the document
    title be updated accordingly or is the Abstract wrong?
    
    It is possible that the confusion is at bullet 2 of Section 2 where it
    is implied that a "domain" is a LISP site such that "inter-domain" means
    between LISP sites. It would be helpful not to re-use "domain" in ths
    way (we are used to it meaning inter-AS and inter-area).  
    
    Since multicast between LISP sites is just a special case of multicast
    using LISP, you could stike te text from the Abstract.
    
    ---
    
    FWIW I found it premature to be reading about how to send a multicast
    packet from a LISP site to a non-LISP site (and vice versa) when I have
    not yet been told how to do this for unicast! There is nothing the 
    authors can do about this, butit is yet another case of the LISP 
    documents running through the system in the wrong order.
    
    I am pleased to see [INTWORK] as a normative reference since ts does
    help with the issue, and I wondered whether the LISP deployment I-D
    should not at least show as an informational reference (perhaps from
    Section 9.3).
    
    ---
    
    Section 7 needs some polish on the English to avoid doubts.
    
    PIM-SSM
          No
          modifications to any message format, but to support taking a Join/
          Prune message originated inside of a LISP site with embedded
          addresses from the EID namespace and converting them to addresses
          from the RLOC namespace when the Join/Prune message crosses a site
          boundary.
    
    PIM-ASM
          The ASM mode of PIM, the most popular form of PIM, is
          deployed in the Internet today is by having shared-trees within a
          site and using source-trees across sites.
  6. Stephen Farrell: Comment [2011-12-13]:
    
        
  7. Russ Housley: Comment [2011-10-04]:
      Please consider the editorial comments in the Gen-ART Review by
      Kathleen Moriarty on 3-October-2011.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06774.html
  8. Peter Saint-Andre: Comment [2011-10-05]:
    draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations",
    which provides a good start toward understanding the parameters of the
    experiment we're engaging in here, and perhaps some dimensions for measuring
    success. It would be helpful for this document to contain a similar section.
    
    The terminology section repeats definitions from the base LISP spec. This seems
    like a bad idea. It would be better to reference those definitions and here
    simply provide the extended information that applies only to multicast
    environments.
    
    The Security Considerations section seems rather sparse. Does the use of LISP in
    a multicast environment truly have no security implications whatsoever?

draft-kompella-l2vpn-l2vpn

  1. Adrian Farrel: Comment [2012-01-15]:
    Nice documemnt, well positioned as complementary to the official IETF
    approach. Thanks.
    
    ---
    
    "PE" first appears in Section 1.1 without expansion.
  2. Stephen Farrell: Comment [2012-01-19]:
    A check that acronymns are expanded on 1st use would be good,
    e.g. DLCI was the one I noticed.
    
  3. Russ Housley: Comment [2012-01-18]:
      One non-blocking comment from the Gen-ART Review by Roni Even on
      7-Sep-2011 has not been resolved.  Please consider it:
      >
      > Section 4.2 refers to section 4 but I am not sure where this
      > mechanism in section 4 is.
  4. Dan Romascanu: Discuss [2012-01-16]:
        Benson Schliesser reviewed the document (version 07) for OPS-DIR and sent hos
    review to the authors on 9/29. His review was never answered. Please address the
    following issues from Benson's review, or in case these were answered and
    addressed in the meantime provide the appropriate pointers:
    
    1) It is not clear to me whether L2-native end-to-end OAM mechanisms are
    supported. It seems that the IP-based interworking proposed by this document
    would be incompatible with native OAM. A discussion on whether this is true,
    when and how native OAM is supported, etc, would be useful.
    
    2) While there is a brief discussion of "adding" a new site, there is no
    discussion of "removing" sites.
    
    3) I'm also unclear about behavior during the transition timeframe. When label
    blocks are growing or shrinking, and PEs might have mismatched label block
    sizes, what is the correct behavior for label selection, dropping packets, etc?
    Is there an implementation mechanism for managing label space correctly, to
    ensure that blocks can grow? Are these behaviors something that should be
    configured correctly by the operator?
    
    4) The document doesn't clearly describe the AC-to-label-to-AC mapping,
    specifically how egress frames are mapped to an AC's local identifier (e.g.
    DLCI). The operator needs a way to know in advance and/or lookup the
    local/remote VC identifier mappings for each AC. It seems pretty obvious to me,
    but the text is not explicit on this point. (Section 3.2.1 talks about ingress
    DLCI-to-CE mappings; section 5 para 3 says the label is used to determine egress
    AC; section 6 reiterates these points, but says that the label identifies the CE
    rather than the AC. Perhaps I overlooked some other text; otherwise the egress
    mapping should be described explicitly.)
    
    5) Section 4 includes n-to-1 encapsulation types. Given my comments in #4 above
    regarding identifier mappings, it is even less clear how these types of circuits
    would work.
    
    6) On the ingress, what happens when the PE receives a frame addressed to
    itself? In other words, if CE-N sends a frame to the DLCI associated with the
    Nth index, does it get looped back? Is this a useful operational mechanism for
    testing connectivity etc?
    
    Supplementary to these please address the following:  
        
  5. Dan Romascanu: Comment [2012-01-16]:
    1. In section 1:
    
    > It may be instructive to compare the approach in [RFC4447] and
       [RFC6074] (these are the IETF-approved technologies for the functions
       described in this document, albeit using two separate protocols) with
       the one described here.  Devices implementing the solution described
       in this document must also implement the approach in [RFC4447] and
       [RFC6074].
    
    This mislead me at first reading. I believe that it would be more clear if the
    non-capitalized 'must' is avoided completely, as [RFC4447] and  [RFC6074] are
    supported as part of the L2VPN functionality and not as a reuirement for this
    document.
    
    2. Expand at first encountered instance: DLCI, VPI / VCI, NLRI. 
    
    3. It makes sense to bring the Contributors and the Acknowledgments sections one
    near the other.
    
     
  6. Sean Turner: Comment [2012-01-18]:
    Where do the L2VPN TLVs go in the VPLS NLRI?  Does the TLV(s) appear immediately
    after the VPKS NRLI when sent between the two PEs?

draft-ash-gcac-algorithm-spec

  1. Jari Arkko: Comment [2012-01-19]:
    Agree with Robert's points in his discuss. I also found this document in general
    difficult to read, and hard to convince myself that it actually works as
    expected.
  2. Wesley Eddy: Comment [2012-01-18]:
    I concur with Robert's DISCUSS points
  3. Stephen Farrell: Comment [2012-01-18]:
    1) VARk = BWMck**2/VFck could be mis-read, suggest adding 
    parenthesis or using another couple of lines like eq(2).
    
    2) Surely there's a DoS vector here too - couldn't someone in
    principle provide bad inputs so that the algorithm denies service?
    Not sure how best to note that, but I'd say its worth a mention in
    the security considerations.
    
  4. Peter Saint-Andre: Comment [2012-01-17]:
    As with all Experimental specifications, it would be nice to define some
    parameters for the experiment (success criteria, guidelines for those who
    implement and deploy the technology, etc.).
  5. Robert Sparks: Discuss [2012-01-18]:
        (Updated to add point 3 below)
    
    The document says that the algorithm might have negative effects on live
    deployments (by implication, up to and including failing to complete an
    emergenc call) but then says experimentation in production networks needs
    to be treated with caution. Was "experimentation in production networks
    is NOT RECOMMENDED", or even "expereiments MUST NOT be performed on production
    networks" considered and rejected? If so, can the document explain why? 
    (Related - can the document explain what experimenting "in a controlled
    manner" means?)
    
    The security consideration section's discussion of the risks of using
    possibly unprotected marks to identify emergency traffic should 
    incorporate or reference the related discussion from ECRIT and (if I 
    remember correctly) the RSVP document suite. This is much harder
    problem than the current text signals.
    
    Example A.2 needs to be updated to reflect that NSIS has concluded. 
        
  6. Robert Sparks: Comment [2012-01-18]:
    The document calls out VOIP as an example of traffic that might be used
    as an input to this algorithm, but the current language implies it's the
    ONLY traffic that's expected, and that the only things generating that
    traffic will be IP/PBXs and SIP/RTP end devices. Please make it clear
    that this traffic is only a motivational example.
    
    The interoperability issue exposed at the top of page 11 deserves more
    discussion. What goes wrong when different administrative domains use
    different constraint models? Are there symptoms that can be observed
    to know that somethings going wrong? Can the document make a stronger
    statement about the appropriate configuration of a experimental test bed?
    
    This sentence needs clarification: "Let DBWi be the additional bandwidth
    capacity needed to carry the flow with aggregate bandwidth DBWi." As written
    it defines a term in terms of itself.
    
    I'm skeptical of the brevity of the security consideration section, but yield
    to the shepherd to double-check that there is nothing beyond the marking of
    emergency traffic to discuss.

draft-jiang-a6-to-historic

  1. Stewart Bryant: Discuss [2012-01-17]:
        As far as I can tell the purpose of this document is to obsolete RFC2874.
    However this is not called out in either the meta-data or the Abstract.
    
        
  2. Stewart Bryant: Comment [2012-01-17]:
    RFC2874 says that it is Standards Track, so it is surprising that this is not a
    WG draft.
  3. Ralph Droms: Comment [2012-01-16]:
    ID-nits flags:
    
      -- Obsolete informational reference (is this intentional?): RFC 1886
         (Obsoleted by RFC 3596)
  4. Adrian Farrel: Discuss [2012-01-16]:
        Should the DNS record type 38 be deprecated (and marked so in the
    registry?
    
    ---
    
    This part of my Discuss is only for debate by the IESG and I will
    clear it on or before the Telechat. The authors do not need to 
    take any action for this part of the Discuss.
    
    It is a source of confusion to me that when I look at RFC 2874 in 
    the
    repository, all of the lovely metadata says "Experimental" but
    the RFC itself
    says "Standards Track". Now, I know that the RFC                      
    Editor
    does not like tmake *any* change to the published RFC, but
    this has got be a
    source of confusion and, as this RFC moves to
    Historic, the confusion won't get
    any less 
        
  5. Adrian Farrel: Comment [2012-01-16]:
    I would like it if the Abstract mentioned the RFC being moved to
    historic (viz. 2874)
  6. Sean Turner: Comment [2012-01-16]:
    Please make sure to incorporate the additional text agreed during the secdir
    review:
    
    http://www.ietf.org/mail-archive/web/secdir/current/msg03051.html

draft-yevstifeyev-disclosure-relation

  1. Jari Arkko: Comment [2012-01-19]:
    I support the discusses, in particular the concern about pure patents vs. other
    general purpose IPR. The latter is the one that we use for IETF, for instance.
  2. Stewart Bryant: Comment [2012-01-17]:
    
        
  3. Wesley Eddy: Discuss [2012-01-02]:
        It is not clear to me why this is defined to indicate *only* patents (as it is
    currently) or to indicate intellectual property claims more generally (e.g.
    patent applications in-process are not patents). 
        
  4. Adrian Farrel: Discuss [2012-01-02]:
        AFAICS, new IANA registrations require a specification (this document)
    and expert review. Have the experts looked at this request yet? I don't
    see anything in the Write-up.
     
    ---
    
    Last Call discussions seem to be still active, and I do not think we 
    should approve this document until all issues have been successfully
    resolved.
    
    I suspect the shepherding AD should move this onto a later telechat. 
        
  5. Stephen Farrell: Comment [2012-01-03]:
    Moved from discuss to no-objection since this will come around
    again and who needs a spare discuss;-)
    
    Former discuss:
    
    On Dec 26th the author suggested a substantive change [1] so I
    don't know whether what I've read is final or not. Maybe this is
    not ready?
    
       [1] http://www.ietf.org/mail-archive/web/ietf/current/msg71211.html
    
    Former comment text:
    
    This seems almost harmless. (It'd be totally harmless if it didn't
    add to the IPR industry in a very, very minor way;-)  The writeup
    says that W3C feedback will be sought during IETF LC - did that
    happen and were they (as the ostensbile users of this) ok with it?
    
    Examples like patent.gov seem like a bad idea as do "almost"
    realistic patent numbers.  Suggest either using example.org style
    stuff or else URIs for real but expired patents.
    
    There were a bunch of IETF LC mails on this (mostly suggested nits
    from Julian Reschke) that looked like they'd be worth fixing. (And
    the author appeared to agree too.)
    
  6. Russ Housley: Discuss [2012-01-18]:
        
      The Gen-ART Review by Martin Thomson on 17-Dec-2011 raised a
      serious question that deserves further discussion.  He questions
      whether the IETF should publish the document at all.
      >
      > The semantics of the relation type are quite clear, though the
      > introduction does not make a particularly compelling case for an RFC.
      > The registration requirements of RFC 5988 require little more than the
      > creation of a specification; that specification could be created
      > anywhere (say, in [W3C-PUBRULES]).  I find the motivations described
      > in the introduction to be not compelling.
      >
      In response, the author suggests that an Informational RFC is the
      ideal way to meet the requirements in RFC 5988.  Martin was not
      swayed by this suggestion. 
        
  7. Pete Resnick: Comment [2012-01-18]:
    - I think the MUST in section 2 is superfluous. s/MUST represent/represents
    
    - Though I agree with Dan that some more discussion of applicability might be
    interesting, I do not think it is necessary to include. The document does not
    tightly define "patent disclosure" or "IPR disclosure", and I don't think it
    should. Any particular group using this construct may decide that pending
    patents or patent applications are things that they want to point to, and in the
    current document they are allowed to. The document can explicitly say that, but
    I don't think it needs to.
  8. Dan Romascanu: Discuss [2012-01-03]:
        This DISCUSS and COMMENT is based in part on the  OPS-DIR review performed by
    Juergen Quittek.
    
    1.  "Patent disclosure" is W3C terminology. The related term used in the IETF is
    "IPR disclosure".  I would object the document to be published without a clear
    statement about the applicability of the new link relation type to IPR
    disclosures.
    
    2. This document is very short and most of the text deals with W3C document
    requirements and HTML examples.  More important would be discussing the the
    applicability of the new link relation type in more detail:  Is it applicable to
    granted patents only or to patent proposals (pending patents as well? What about
    other kinds of IPR, such as industrial design rights?  I think they should all
    be covered. At least the document should be clear about these issues.
    
    3. The Introduction (section 1) exclusively discusses a single use case for the
    new link relation type: meeting W3C documentation requirements. This gives the
    impression that this draft is written for serving W3C purposes only.  I don't
    think that this is the case, but there is not indication of other purposes in
    the draft.  Please clarify that W3C documents are just an example use case and
    that there are many others. Mentioning a few other use cases is probably not a
    bad idea.  One obvious use case may be links to IPR disclosures on IETF tools
    pages. 
        
  9. Dan Romascanu: Comment [2012-01-03]:
    1. The purpose of the draft is defining a the semantics of a new link
    relationship type.  This is done in section 2. But the four lines of text that
    should serve this purpose rather confuse me:
    
    > 2. 'disclosure' Link Relation Type
    > 
    >    Whenever the 'disclosure' relation is defined, the target IRI MUST
    >    either
    
    What does precisely mean "Whenever the disclosure relation is defined"?
    It is
    defined in this document.  The sentence should rather state something like
    "Whenever the relation type attribute is used with value 'disclosure'".
    
    >    (1) designate a list of patent disclosures, or
    > 
    >    (2) refer to a particular patent disclosure made with respect to the
    >        material being referenced by context IRI.
    
    Why does (1) designate and (2) refer to?  Why is there a difference?
    Where is
    the difference explained?  What are the semantics of "designating a list of
    patent disclosures".
    
    2. In the IANA Consideration section please be explicit that the registry to be
    extended is the Link Relation Type registry.
    
    3. Abstract: 
    >    This document specifies the 'disclosure' Link Relation Type.  It
    >    designates a list of patent disclosures or a particular patent
    >    disclosure itself made with respect to material for which such
    >    relation type is specified.
    
    I had to read this two times until I could parse the second sentence correctly.
    Less cryptic wording would be appreciated, particularly
    
    in the abstract that should readers allow to quickly get an idea of the content.
    
    I would suggest removing "itself" from the abstract, but I'm not a native
    speaker.
    
    The first sentence says "this document specifies the new type".
    The last line says "for which the type is specified".  This is confusing.
    In both cases the "type" is "specified" but with different meanings.
    In the first case it is indeed the specification of the type.
    In the second case the type is assigned to (not specified for) "material".
    Suggestion: replace "specified" in last line.
    
    4. Section 1 (Introduction), first sentence: see comments on abstract
    
    5.  Section 1 (Introduction), second paragraph, line 1:
    "Active use of 'disclosure' relation type has been identified."
      - What is "active use" compared to just "use"?
      - Why "identified"? What is "identification of use"?
        You may want to replace "identified" by "observed" or something similar.
    
    6.  Section 1 (Introduction), line 4:
    Suggestion: "defines" -> "mandates"
    
    7.  Section 1 (Introduction), last line:
    "separate" -> "multiple"
    
    8. Section 3 (examples), last example:
    This example uses potentially real
    domain names:
    patent.gov, ipr.su, ftp.legal.va.  They should be replaced with
    domain names reserved for examples such as example.com, example.net, and
    example.org, see RFC 2606.