IESG Narrative Minutes

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

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

Corrections from: (none)

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. The RPKI/Router Protocol (Proposed Standard)
    draft-ietf-sidr-rpki-rtr-25
    Token: Stewart Bryant
    Note: Document shepherd is Chris Morrow (morrowc@ops-netman.net).
    Discusses/comments (from ballot 4016):
    1. Jari Arkko: Comment [2012-02-01]:
      This is a well written and much needed document, thank you for writing it.
      (The only worry that I had was that there was a long list of different security mechanisms, perhaps too many for interoperability.)
    2. Stewart Bryant: Comment [2012-01-30]:
      I believe that the outstanding IETF LC comment has been addressed.
    3. Ralph Droms: Comment [2012-01-29]:
      Minor editorial suggestion - section 5.10 seems out of order and would have been more useful to me if it had appeared before the definitions of the PDU fields in section 5.
    4. Adrian Farrel: Comment [2012-01-31]:
      I am also concerned about the internationalisability of error strings, but otherwise have no objection to the publication of this document.
    5. Stephen Farrell: Comment [2012-01-29]:
      - "Formally" and "simple but reliable" in the abstract and intro seem to be marketing text.
      - I (still) don't like where it says you SHOULD do ACLs or something. (The text in the document uses "..." rather than "or something" but that's the meaning.) Just delete the elipsis or actually give a non-ACL example of what one might sensibly do.
      - I agree with the comments about the expansion of MITM but, like everyone else probably, don't care that much.
    6. Pete Resnick: Comment [2012-01-28]:
      In 5.9: "If error text is present, it SHOULD be a string in US-ASCII, for maximum portability; if non-US-ASCII characters are absolutely required, the error text MUST use UTF-8 encoding."
      I'm trying to suss out what "maximum portability" means. Is UTF-8 known to screw up some implementations (in which case the SHOULD is justified), or is it just that you're being super-conservative, or worse, that you're afraid some non-English might end up in the error log? :-) Unless there's a real worry for interoperability here, just define the thing as UTF-8 (which means that US-ASCII still looks like US-ASCII) and be done with it.
      A reference to RFC 3629 might be extra friendly.
    7. Dan Romascanu: Comment [2012-01-30]:
      1. It would be useful for the readability of the document to have acronyms expanded at the first occurence (starting with RPKI)
      2. In Section 5.9: "The diagnostic text is optional, if not present the Length of Error Text field SHOULD be zero."
      Why is this a SHOULD?
      3. Same: "If error text is present, it SHOULD be a string in US-ASCII, for maximum portability; if non-US-ASCII characters are absolutely required, the error text MUST use UTF-8 encoding."
      Pete already refered to this. RFC 2277 mandates implementing UTF-8, so what is the reason for recommending US-ASCII?
    8. Peter Saint-Andre: Discuss [2012-01-30]:
      There are two interrelated issues I'd like to chat about with respect to TLS transport.
      Section 7.2 states: "If such certificates are used, the CN field [RFC5280] MUST be used to denote the router's identity."
      What is meant by "identity" here? Is there a specific identifier that ought to be included in the CN (e.g., IP address or FQDN)? The term "identity" is nearly void for vagueness.
      Then: "Clients SHOULD verify the cache's certificate". It would be good to specify more clearly what is meant by certificate verification (e.g., using the rules from RFC 2818 or RFC 6125).
    9. Peter Saint-Andre: Comment [2012-01-30]:
      I second Pete's query about ASCII-only error text.
      The AppsDir review by Lisa Dusseault asks some questions that deserve a response:
      http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04230.html
      Section 2 states: "Serial Number: A 32-bit monotonically increasing unsigned integer which wraps from 2^32-1 to 0."
      Do you mean "strictly increasing" instead of "monotonically increasing"?
      Section 10 states: "This section contains a preliminary list of error codes. The authors expect additions to this section during development of the initial implementations."
      A forward reference to the IANA considerations would be friendly here.
      IDnits reports:
      ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

    Telechat:

2.1.2 Returning Items

  1. Simple Authentication Schemes for the ALC and NORM Protocols (Proposed Standard)
    draft-ietf-rmt-simple-auth-for-alc-norm-06
    Token: David Harrington
    Note: Brian Adamson (adamson@itd.nrl.navy.mil) is the document shepherd.
    Discusses/comments (from ballot 3574):
    1. Stewart Bryant: Comment [2012-01-31]:
      The terms ALC and NORM need to be expanded on first use.
    2. Ralph Droms: Comment [2012-01-16]:
      I've cleared my Discuss.
    3. Adrian Farrel: Comment [2011-11-03]:
      I support Pete Resnick's Discuss
      Section 1: s/transfer reliably objects/reliably transfer objects/
      More precisely this document details the EXT_AUTH==1 header extension defined in [RFC5651].
      Should read
      More precisely this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
    4. Stephen Farrell: Comment [2011-12-09]:
      (blank)
    5. David Harrington: Discuss [2012-01-18]:
      This is a placeholder discuss. The authors need to take no action at this time. This is placed to allow the IETF LC for Proposed Standard status to complete 1/25. If no issues are raised, this document will be moved to approved.
    6. Russ Housley: Comment [2011-11-02]:
      Throughout the document, the use of "Signature Cryptographic Function" ought to be replaced by "One-way Hash Function" or "Message Digest Algorithm" (please pick just one).
    7. Peter Saint-Andre: Comment [2012-01-30]:
      Section 1.2 states: "Key sizes of length between 1024 and 2048 bits, inclusive, SHOULD be used. Key sizes of length strictly superior to 2048 MAY be used."
      It seems strange to prefer smaller keys to larger keys. Why not just say that keys should be larger than 1024? (By the way, this text is substantially repeated in Section 3.2; it would be better to provide it only once.)
      Section 3.4 states: "All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance because they do not support digital signatures."
      I think you mean "might" instead of "MAY", unless it is truly OPTIONAL to parse the content or support digital signatures. (This text recurs in Sections 4.4, 5.4, and 6.4.)
      Section 8.3 states: "This specification requires several parameters to be communicated to the receiver(s) via an out-of-band mechanism that is out of the scope of this document. This is in particular the case for the mapping between an ASID value and the associated authentication scheme (Section 1). Since this mapping is critical, this information SHOULD be carried in a secure way from the sender to the receiver(s)."
      Given the security implications, wouldn't it be prudent to at least suggest one or more out-of-band mechanisms for the sake of interoperability?
    8. Sean Turner: Comment [2011-12-11]:
      (blank)

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Additional HTTP Status Codes (Proposed Standard)
    draft-nottingham-http-new-status-03
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 4042):
    1. Stewart Bryant: Comment [2012-01-30]:
      The term substrate protocol is not a term I have seen in the lower layers of the net. Perhaps the authors should provide a reference to a definition of the term.
    2. Adrian Farrel: Comment [2012-01-31]:
      This Comment does not quite merit a Discuss, but I hope the authors will think about whether they can address it.
      I would have liked to see some discussion of backward compatibility. Obviously, legacy implementations may receive these new codes in the normal course of affairs. I am sure that default behavior for unknown codes is described somewhere, so one line of text with a reference will cover the default case. However, this document appears to define some mandatory behavior for nodes that see the new codes - it would be good to show how this is consistent with legacy implementations.
    3. Stephen Farrell: Comment [2012-01-29]:
      You might note that the 511 code doesn't help to avoid the problem of an intercepting proxy having to fake out the X.509 certificate of the user's target server. (I don't mind if you don't add that.)
      Please also continue the discussion started from Steve Hanna's secdir review. I believe some of those changes are agreed but not yet made, while others are still being discussed.
    4. Pete Resnick: Comment [2012-01-28]:
      Section 3: "Responses using this status code SHOULD explain how to resubmit the request successfully. For example:"
      The SHOULD seems a little overdone. There's no protocol interoperability issue here AFAICT. Perhaps just, "The body of the response is used for an explanation of how to resubmit the request successfully." Or just lowercase the should.
      Section 4: "The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request."
      Same issue as above, for both the SHOULD and the MAY. Also, I'm not sure I know what a "response representation" is. Term of art?
      Section 5: "...the response representation SHOULD specify which header field was too large."
      Same issue as above.
      Section 6: "The response representation SHOULD indicate how to do this; e.g., with an HTML form for submitting credentials."
      Similar issue to the above, however made a bit stranger by the text in 6.1:
      "Note that the 511 response can itself contain the login interface, but it may not be desirable to do so, because browsers would show the login interface as being associated with the originally requested URL, which may cause confusion."
      Those two seem to conflict.
    5. Dan Romascanu: Comment [2012-02-02]:
      Robert and Adrian made already the point in the COMMENTs - if backwards compatibility is not a prblem it would be good to be explicit why - i.e. describe or refer to text that describes what happens at the reception of an unknown status code.
    6. Robert Sparks: Comment [2012-01-31]:
      It would help to call out why these codes can be deployed into the existing base without disruption (existing implementations treat unknown messages in a class as the x00 in that class - RFC2616 6.1.1) and explain how the restrictions on not caching these responses are related to RFC2616 13.4.
      Given the potential consequence called out for including a login interface in a 511 at the end of section 6.1, I'm surprised this language is "may not be desirable". Why isn't this SHOULD NOT?
    7. Sean Turner: Comment [2012-02-01]:
      A total nit, should h1 match the title in s4?

      Too many Requests


      i.e., r/many/Many

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. A Discard Prefix for IPv6 (Informational)
    draft-ietf-v6ops-ipv6-discard-prefix-02
    Token: Ron Bonica
    Note: Joel Jaeggli, (joelja@bogus.com) v6ops co-chair, is the document shepherd.
    Discusses/comments (from ballot 4047):
    1. Stewart Bryant: Discuss [2012-01-31]:
      I agree with Pete's DISCUSS on the status of this document. I am similarly confused as to why the special addresses are not in the special purposes registry with this document adding to that registry.
      This document should surely just add a value to the registry and cite itself as the reference.
    2. Stewart Bryant: Comment [2012-01-31]:
      (blank)
    3. Ralph Droms: Discuss [2012-02-02]:
      I think the single sentence in the Security Considerations is pretty tightly focused on one specific situation, and the implications from the first phrase:
      "As the prefix specified in this document should not normally be transmitted or accepted over inter-domain BGP session"
      should be made explicit and expanded.
    4. Wesley Eddy: Comment [2012-01-30]:
      I think "militating" should be "mitigating" in the abstract.
    5. Adrian Farrel: Comment [2012-02-01]:
      A bit like Stephen's Comment...
      Section 3 contains to "SHOULD NOT" directives. This is an implication that these directives can be varied. Do you want to describe how and why, or do you want to change to "MUST NOT"?
      Obviously, these "SHOULD NOTs" also impact the security discussion.
    6. Stephen Farrell: Comment [2012-01-29]:
      I don't get why the 3rd party AS stuff is SHOULD NOT and not MUST NOT.
      I think it'd be better to s/should not/ought not/ in section 5 to avoid possible 2119 confusion.
    7. Pete Resnick: Discuss [2012-01-28]:
      I'd like to hear a lot more about the intended status of this document. As a formal IANA allocation for a specific purpose, it seems like this document should be at least a BCP. It could be argued that because this document is specifying how to use RTBH with a particular address, this is actually more appropriately Standards Track. There is certainly protocol in this document. (Of course 5635 is also Informational, but I don't really understand that either.) In addition, I find it telling that this document updates 5156. 5156 collects together special use IPv6 addresses from assorted other documents. Almost all of those documents (4193, 4291, 4380, etc.) are themselves Standards Track or Experimental. This seems to me further evidence that this document should be something more than Informational. (Of course, I would have thought 3330 and 4773 should have been BCP as well, but consistency does not seem to be our forte in this area.)
      It's not obvious what the correct status is, but I think this is worth a discussion.
    8. Pete Resnick: Comment [2012-01-28]:
      Though it is true that this document adds a new special use address, it does seem a bit odd to say that this document updates 5156. It seems to me that all of the special use addresses listed in 5156 would be better documented by listing them in the IANA special use registry. I wonder why they're not.

    Telechat:

  2. RFC3627 to Historic status (Informational)
    draft-ietf-6man-3627-historic-01
    Token: Jari Arkko
    Note: Brian Haberman (brian@innovationslab.net) is the document shepherd.
    Discusses/comments (from ballot 4070):
    1. Pete Resnick: Comment [2012-01-28]:
      Has there actually been confusion by people referring to and using 3627? This document says that it is moving 3627 to Historic to avoid such confusion, but never actually said that such confusions occurred. If they have occurred, it would be useful to say that. If they haven't occurred, I wonder why this document was necessary. (Note: Neither the shepherding writeup nor the IESG writeup were helpful in this regard as neither actually mentioned why the WG thought this was a useful document. It only had the standard one-liner saying, "there was consensus", which was not useful info.)

    Telechat:

  3. TLS encryption for RADIUS (Experimental)
    draft-ietf-radext-radsec-11
    Token: Dan Romascanu
    Note: Jouni Korhonen (jouni.korhonen@nsn.com) is the Document Shepherd.
    Discusses/comments (from ballot 4074):
    1. Stewart Bryant: Comment [2012-01-31]:
      This document needs a scrub to make sure that all TLAs other than those with a * in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt are expanded on first use and where the definition is contained in another document the term is provided with a reference on first use.
      radsec seems to have a lot of different spellings.
    2. Wesley Eddy: Discuss [2012-01-29]:
      (1) This may be easy to resolve: Do security issues with TCP which are not mitigated by TLS have any bearing on RADIUS, as they do for BGP, LDP, and some other applications? E.g. spoofing attacks discussed in RFC 4953.
      (2) Layering terminology should be tightened up in a few places to remove confusion between a RADIUS transport profile and what the underlying transport protocol itself actually is (it is not TLS, and the security in this document is not implemented in the transport layer, although it is in the transport profile). I believe it's clearest to say that this document "RADIUS/TLS" is a transport *profile* for RADIUS using TLS over TCP as the transport *protocol*. But it's definitely not correct to say that it's using security in the transport layer, as currently done in a few places:
      - abstract
      - introduction, paragraph 2
      - section 6, paragraph 3
      - appendix c, paragraph 2
    3. Adrian Farrel: Comment [2012-02-01]:
      Shouldn't there be some considerations of key management in line with RFC 4107?
    4. Stephen Farrell: Discuss [2012-01-29]:
      I've a few niggly but worth-fixing points here that should be easily addressed. A bunch of these overlap with the two reviews posted to the secdir list [1,2] so please resolve these comments along with those reviews.
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03073.html
      [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03074.html
      (1) You don't say what's the input to certificate fingerprint calculation. I think you want the DER encoded cert octets here, and not e.g. the subjectPublicKey, right?
      (2) You don't say what "acceptable certificate" means. It could mean "only accept these [EE's|CAs] no matter what the 5280 verification says" or (as I suspect) "always accept these EE's regardless of what the 5280 validation says" or something else. I'm (almost certainly) fine with it meaning whatever you currently want but it needs to be stated.
      (3) I think that saying you MUST do verification as per 5280 and at the same time saying that you SHOULD allow configuration of acceptable certificates (with the 2nd meaning above) is in conflict. I'd say the way to resolve that would be to say "SHOULD do 5280, except if the EE is on your acceptable list" and I'd be fine with doing that.
      (4) As with (2) you need to define what "acceptable subjectAltName:URI" is for.
      (5) I suspect you may be wrong in saying that "radsec" MUST be used for attribute encryption and MD5 since that means that if you only turn on TLS and don't modify your RADIUS code then you won't comply. It also means that if you have to turn off TLS for some reason for a while (e.g. one end's cert expired, forgot to have a new one ready beforehand, as happens quite commonly) then you probably have your trousers even further down than with current RADIUS if you start operating over UDP again temporarily and the value "radsec" is configured for RADIUS. (I just want to draw attention to this - I'll clear once I've seen a substantive response to this point, for pretty much all possible substantive resposes:-)
      (6) You don't say if TLS re-negotiation is REQUIRED to be supported or not. I think it'd be good to say and maybe to RECOMMEND something for what to do if a long-lived RADIUS/TLS session outliving a CRL re-issue or public key cert or maybe even the appropriate amount of data to encrypt with a given ciphersuite. I don't really mind which way you'd rather handle that, but I think saying something is needed so surprises don't happen. In fact, if you want to note the issue and not RECOMMEND anything that'd be ok too.
    5. Stephen Farrell: Comment [2012-01-29]:
      - I don't get why this is going for experimental rather than PS. I'd prefer the latter really.
      - You should define dynauth as a term or add a reference.
      - Seems odd to prefer a 3DES ciphersuite over an AES one. An explanation for that would be good. (Maybe its just existing code?)
      - Section 3, 1st bullet should I think talk about a list of trust points and say that that includes the CA public key and not just its name.
      - Please fix x.y.z, I doubt there's that section in 5246.
      - (Blatent self-promotion:-) Might it be useful to think about using draft-farrell-decade-ni as a(nother) way to represent certificate fingerprints?
      - Why only allow configuration of URIs for subjectAltName? I don't get why you don't include dNSName for example.
      - What does it mean to say the client is unique identified by the cert fingerprint? What happens when I get my certificate renewed?
      - I'm not sure why a reader in ten years will care that "Radiator is compliant to version 2 of RadSec..." (compliant to *this* protocol would be fine of course if those are the same but then why not say that?)
      - "(link to RFC once issued here)" is not really very finished text is is?
      - The mandatory TLS ciphersuites listed do not provide PFS.
    6. Russ Housley: Discuss [2012-01-31]:
      The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two concerns. Please respond to each of them.
      (1) Section 2.4: "In TLS-X.509 with PKI infrastructure, a client is uniquely identified by the serial number of the tuple (presented client certificate;Issuer)."
      SHOULD BE: "In TLS-X.509 with PKI infrastructure, a client is uniquely identified by the tuple (serial number of presented client certificate;Issuer)."
      (2) Because RADIUS supports the Disconnect Request (server-to-client) message, it seems that there is some requirement to keep the TLS session open for the duration of the access that was authorized. Otherwise, the server would not be able to send such a packet to the client without initiating its own TLS connection which may not be possible or desirable. Is this aspect of the specification inherited from the referenced TCP specification? It may be helpful to add a paragraph about this issue.
    7. Russ Housley: Comment [2012-01-31]:
      The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two editorial issues. Please consider them.
      (1) Section 2.3: "x.y.z"
      Did you mean to fill in a real section number here?
      (2) Note Section 3.4 (1) )
      Missing open paren?
    8. Peter Saint-Andre: Comment [2012-01-30]:
      Section 2.3 says the following with respect to use of TLS with PKIX certificates:
      "*"Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName: iPAddr has precedence over CN."
      It's good to specify the preference order, but you don't provide a precise definition of what it means to match the expected DNS name (IP address is more straightforward). You might find it helpful to cite RFC 6125 here.
      Section 4 states: "Ongoing work in the IETF defines multiple alternative transports to the classic UDP transport model as defined in [RFC2865], namely RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS."
      Is there a document that summarizes the experiment with these three technologies and that defines criteria for evaluating the success of each approach?
    9. Sean Turner: Comment [2012-02-02]:
      I agree with Stephen's discuss and Peter's comment positions. Based on the email exchanges it looks like their issues will be resolved in -12.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. DHCPv6 Prefix Delegation in Long Term Evolution (LTE) Networks (Informational)
    draft-sarikaya-v6ops-prefix-delegation-10
    Token: Jari Arkko
    Note: ISE Stream

    Telechat:

1204 EST no break

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. SPF Update (spfbis)
    Token: Pete

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. NETCONF Data Modeling Language (netmod)
    Token: Dan

    Telechat:

  2. Basic Level of Interoperability for SIP Services (bliss)
    Token: Robert

    Telechat:

  3. BiDirectional or Server-Initiated HTTP (hybi)
    Token: Peter

    Telechat:

4.2.2 Proposed for Approval

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

    Telechat:

    1242 EST break

    1248 EST back

5. IAB News We can use

6. Management Issues

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

    Telechat:

  2. Moving RFC 6045 to Historic (Sean Turner)

    Telechat:

  3. Moving RFC 6046 to Historic (Sean Turner)

    Telechat:

  4. Early RFC # allocation for draft-ietf-mile-rfc6045/6-bis (Sean Turner)

    Telechat:

  5. TCP Option Number Request [IANA #539780] (Michelle)

    Telechat:

7. Agenda Working Group News

Russ: retreat proposing Anapolis MD 3-4 May; considering half-day overlap with IAB retreat, perhaps beginning of that week (2-3 May)
David: we talked about making flight connections easier
Barry: surprised it would take two hops to reach Washington from Europe
Stewart: 2 May is holiday in England
Russ: continue to hold 3-4 May, while discussing overlap (seeming less likely)
Stewart: as separate series, we're due for US
Russ: new participants tend towards East coast; East coast seems to work; asked Secretariat to gather facts on possible venues

1341 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-02-02 07:31:17 PST)

draft-ietf-sidr-rpki-rtr

  1. Jari Arkko: Comment [2012-02-01]:
    This is a well written and much needed document, thank you for writing it.
    
    (The only worry that I had was that there was a long list of different security
    mechanisms, perhaps too many for interoperability.)
  2. Stewart Bryant: Comment [2012-01-30]:
    I believe that the outstanding IETF  LC comment has been addressed.
  3. Ralph Droms: Comment [2012-01-29]:
    Minor editorial suggestion - section 5.10 seems out of order
    and would have been more useful to me if it had appeared
    before the definitions of the PDU fields in section 5.
  4. Adrian Farrel: Comment [2012-01-31]:
    I am also concerned about the internationalisability of error strings, but
    otherwise have no objection to the publication of this document.
  5. Stephen Farrell: Comment [2012-01-29]:
    - "Formally" and "simple but reliable" in the abstract and intro
    seem to be marketing text.
    
    - I (still) don't like where it says you SHOULD do ACLs or
    something. (The text in the document uses "..." rather than "or
    something" but that's the meaning.)  Just delete the elipsis or
    actually give a non-ACL example of what one might sensibly do.
    
    - I agree with the comments about the expansion of MITM but,
    like everyone else probably, don't care that much.
    
  6. Pete Resnick: Comment [2012-01-28]:
    In 5.9:
    
       If error text is present, it SHOULD be a
       string in US-ASCII, for maximum portability; if non-US-ASCII
       characters are absolutely required, the error text MUST use UTF-8
       encoding.
    
    I'm trying to suss out what "maximum portability" means. Is UTF-8 known to screw
    up some implementations (in which case the SHOULD is justified), or is it just
    that you're being super-conservative, or worse, that you're afraid some non-
    English might end up in the error log? :-) Unless there's a real worry for
    interoperability here, just define the thing as UTF-8 (which means that US-ASCII
    still looks like US-ASCII) and be done with it.
    
    A reference to RFC 3629 might be extra friendly.
  7. Dan Romascanu: Comment [2012-01-30]:
    1. It would be useful for the readability of the document to have acronyms
    expanded at the first occurence (starting with RPKI)
    
    2. In Section 5.9:  
    
    > The diagnostic text is optional, if not present the Length of Error
       Text field SHOULD be zero. 
    
    Why is this a SHOULD? 
    
    3. Same: 
    
    > If error text is present, it SHOULD be a
       string in US-ASCII, for maximum portability; if non-US-ASCII
       characters are absolutely required, the error text MUST use UTF-8
       encoding.
    
    Pete already refered to this. RFC 2277 mandates implementing UTF-8, so what is
    the reason for recommending US-ASCII?
  8. Peter Saint-Andre: Discuss [2012-01-30]:
        There are two interrelated issues I'd like to chat about with respect to TLS
    transport.
    
    Section 7.2 states:
    
       If such certificates are used, the CN field [RFC5280]
       MUST be used to denote the router's identity.
    
    What is meant by "identity" here? Is there a specific identifier that ought to
    be included in the CN (e.g., IP address or FQDN)? The term "identity" is nearly
    void for vagueness.
    
    Then: "Clients SHOULD verify the cache's certificate". It would be good to
    specify more clearly what is meant by certificate verification (e.g., using the
    rules from RFC 2818 or RFC 6125). 
        
  9. Peter Saint-Andre: Comment [2012-01-30]:
    I second Pete's query about ASCII-only error text.
    
    The AppsDir review by Lisa Dusseault asks some questions that deserve a
    response:
    
    http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04230.html
    
    Section 2 states:
    
       Serial Number:  A 32-bit monotonically increasing unsigned integer
          which wraps from 2^32-1 to 0.
    
    Do you mean "strictly increasing" instead of "monotonically increasing"?
    
    Section 10 states:
    
       This section contains a preliminary list of error codes.  The authors
       expect additions to this section during development of the initial
       implementations.
    
    A forward reference to the IANA considerations would be friendly here.
    
    IDnits reports:
    
      ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)
    

draft-ietf-rmt-simple-auth-for-alc-norm

  1. Stewart Bryant: Comment [2012-01-31]:
    The terms ALC and NORM need to be expanded on first use.
  2. Ralph Droms: Comment [2012-01-16]:
    I've cleared my Discuss.
  3. Adrian Farrel: Comment [2011-11-03]:
    I support Pete Resnick's Discuss
    
    ---
    
    Section 1
    
    s/transfer reliably objects/reliably transfer objects/
    
    --
    
       More precisely this document details the EXT_AUTH==1 header extension
       defined in [RFC5651].
    
    Should read
    
       More precisely this document details the HET=1 (EXT_AUTH) header 
       extension defined in [RFC5651].
  4. Stephen Farrell: Comment [2011-12-09]:
    
        
  5. David Harrington: Discuss [2012-01-18]:
        This is a placeholder discuss. The authors need to take no action at this time.
    This is placed to allow the IETF LC for Proposed Standard status to complete
    1/25.
    If no issues are raised, this document will be moved to approved. 
        
  6. Russ Housley: Comment [2011-11-02]:
      Throughout the document, the use of "Signature Cryptographic Function"
      ought to be replaced by "One-way Hash Function" or "Message Digest
      Algorithm" (please pick just one).
  7. Peter Saint-Andre: Comment [2012-01-30]:
    Section 1.2 states:
    
          Key sizes of length between 1024 and 2048
          bits, inclusive, SHOULD be used.  Key sizes of length strictly
          superior to 2048 MAY be used.
    
    It seems strange to prefer smaller keys to larger keys. Why not just say that
    keys should be larger than 1024? (By the way, this text is substantially
    repeated in Section 3.2; it would be better to provide it only once.)
    
    Section 3.4 states:
    
       All receivers MUST recognize EXT_AUTH but MAY not be able to parse
       its content, for instance because they do not support digital
       signatures.
    
    I think you mean "might" instead of "MAY", unless it is truly OPTIONAL to parse
    the content or support digital signatures. (This text recurs in Sections 4.4,
    5.4, and 6.4.)
    
    Section 8.3 states:
    
       This specification requires several parameters to be communicated to
       the receiver(s) via an out-of-band mechanism that is out of the scope
       of this document.  This is in particular the case for the mapping
       between an ASID value and the associated authentication scheme
       (Section 1).  Since this mapping is critical, this information SHOULD
       be carried in a secure way from the sender to the receiver(s).
    
    Given the security implications, wouldn't it be prudent to at least suggest one
    or more out-of-band mechanisms for the sake of interoperability?
  8. Sean Turner: Comment [2011-12-11]:
    
      

draft-nottingham-http-new-status

  1. Stewart Bryant: Comment [2012-01-30]:
    The term substrate protocol is not a term I have seen in the lower layers of the
    net. Perhaps the authors should provide a reference to a definition of the term.
  2. Adrian Farrel: Comment [2012-01-31]:
    This Comment does not quite merit a Discuss, but I hope the authors will think
    about whether they can address it.
    
    I would have liked to see some discussion of backward compatibility. Obviously,
    legacy implementations may receive these new codes in the normal course of
    affairs. I am sure that default behavior for unknown codes is described
    somewhere, so one line of text with a reference will cover the default case.
    However, this document appears to define some mandatory behavior for nodes that
    see the new codes -  it would be good to show how this is consistent with legacy
    implementations.
  3. Stephen Farrell: Comment [2012-01-29]:
    You might note that the 511 code doesn't help to avoid the
    problem of an intercepting proxy having to fake out the
    X.509 certificate of the user's target server. (I don't mind
    if you don't add that.)
    
    Please also continue the discussion started from Steve
    Hanna's secdir review. [1] I believe some of those changes
    are agreed but not yet made, while others are still being
    discussed.
    
       [1]
    https://www.ietf.org/ibin/c5i?mid=6&rid=48&gid=0&k1=933&k3=10932&tid=1327720307
  4. Pete Resnick: Comment [2012-01-28]:
    Section 3:
    
       Responses using this status code SHOULD explain how to resubmit the
       request successfully.  For example:
    
    The SHOULD seems a little overdone. There's no protocol interoperability issue
    here AFAICT. Perhaps just, "The body of the response is used for an explanation
    of how to resubmit the request successfully." Or just lowercase the should.
    
    Section 4:
    
       The response representations SHOULD include details explaining the
       condition, and MAY include a Retry-After header indicating how long
       to wait before making a new request.
    
    Same issue as above, for both the SHOULD and the MAY. Also, I'm not sure I know
    what a "response representation" is. Term of art?
    
    Section 5:
    
       ...the response representation SHOULD specify which header
       field was too large.
    
    Same issue as above.
    
    Section 6:
    
       The response representation SHOULD indicate how to do this; e.g.,
       with an HTML form for submitting credentials.
    
    Similar issue to the above, however made a bit stranger by the text in 6.1:
    
       Note that the 511 response can itself contain the login interface,
       but it may not be desirable to do so, because browsers would show the
       login interface as being associated with the originally requested
       URL, which may cause confusion.
    
    Those two seem to conflict.
  5. Dan Romascanu: Comment [2012-02-02]:
    Robert and Adrian made already the point in the COMMENTs - if backwards
    compatibility is not a prblem it would be good to be explicit why - i.e.
    describe or refer to text that describes what happens at the reception of an
    unknown status code.
  6. Robert Sparks: Comment [2012-01-31]:
    It would help to call out why these codes can be deployed into the existing base
    without disruption (existing implementations treat unknown messages in a class
    as the x00 in that class - RFC2616 6.1.1) and explain how the restrictions on
    not caching these responses are related to RFC2616 13.4.
    
    Given the potential consequence called out for including a login interface in a
    511 at the end of section 6.1, I'm surprised this language is "may not be
    desirable". Why isn't this SHOULD NOT?
  7. Sean Turner: Comment [2012-02-01]:
    A total nit, should h1 match the title in s4?
    
    <h1>Too many Requests</h1>
    
    i.e., r/many/Many

draft-ietf-v6ops-ipv6-discard-prefix

  1. Stewart Bryant: Discuss [2012-01-31]:
        I agree with Pete's DISCUSS on the status of this document. I am similarly
    confused as to why the special addresses are not in the special purposes
    registry with this document adding to that registry.
    
    This document should surely just add a value to the registry and cite itself as
    the reference.
    
        
  2. Stewart Bryant: Comment [2012-01-31]:
    
        
  3. Ralph Droms: Discuss [2012-02-02]:
        I think the single sentence in the Security Considerations
    is pretty tightly focused on one specific situation, and the
    implications from the first phrase:
    
       As the prefix specified in this document should not normally be
       transmitted or accepted over inter-domain BGP session
    
    should be made explicit and expanded. 
        
  4. Wesley Eddy: Comment [2012-01-30]:
    I think "militating" should be "mitigating" in the abstract.
  5. Adrian Farrel: Comment [2012-02-01]:
    A bit like Stephen's Comment...
    
    Section 3 contains to "SHOULD NOT" directives. This is an implication
    that these directives can be varied. Do you want to describe how and
    why, or do you want to change to "MUST NOT"?
    
    Obviously, these "SHOULD NOTs" also impact the security discussion.
  6. Stephen Farrell: Comment [2012-01-29]:
    Hi Nick,
    
    I don't get why the 3rd party AS stuff is SHOULD NOT and not 
    MUST NOT. 
    
    I think it'd be better to s/should not/ought not/ in section 5 to
    avoid possible 2119 confusion.
    
    S
  7. Pete Resnick: Discuss [2012-01-28]:
        I'd like to hear a lot more about the intended status of this document. As a
    formal IANA allocation for a specific purpose, it seems like this document
    should be at least a BCP. It could be argued that because this document is
    specifying how to use RTBH with a particular address, this is actually more
    appropriately Standards Track. There is certainly protocol in this document. (Of
    course 5635 is also Informational, but I don't really understand that either.)
    In addition, I find it telling that this document updates 5156. 5156 collects
    together special use IPv6 addresses from assorted other documents. Almost all of
    those documents (4193, 4291, 4380, etc.) are themselves Standards Track or
    Experimental. This seems to me further evidence that this document should be
    something more than Informational. (Of course, I would have thought 3330 and
    4773 should have been BCP as well, but consistency does not seem to be our forte
    in this area.)
    
    It's not obvious what the correct status is, but I think this is worth a
    discussion. 
        
  8. Pete Resnick: Comment [2012-01-28]:
    Though it is true that this document adds a new special use address, it does
    seem a bit odd to say that this document updates 5156. It seems to me that all
    of the special use addresses listed in 5156 would be better documented by
    listing them in the IANA special use registry. I wonder why they're not.

draft-ietf-6man-3627-historic

  1. Pete Resnick: Comment [2012-01-28]:
    Has there actually been confusion by people referring to and using 3627? This
    document says that it is moving 3627 to Historic to avoid such confusion, but
    never actually said that such confusions occurred. If they have occurred, it
    would be useful to say that. If they haven't occurred, I wonder why this
    document was necessary. (Note: Neither the shepherding writeup nor the IESG
    writeup were helpful in this regard as neither actually mentioned why the WG
    thought this was a useful document. It only had the standard one-liner saying,
    "there was consensus", which was not useful info.)

draft-ietf-radext-radsec

  1. Stewart Bryant: Comment [2012-01-31]:
    This document needs a scrub to make sure that all TLAs other than those with a *
    in the list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
    are expanded on first use and where the definition is contained in another
    document the term is provided with a reference on first use.
    
    radsec seems to have a lot of different spellings.
  2. Wesley Eddy: Discuss [2012-01-29]:
        (1)  This may be easy to resolve: Do security issues with TCP which are not
    mitigated by TLS have any bearing on RADIUS, as they do for BGP, LDP, and some
    other applications?  E.g. spoofing attacks discussed in RFC 4953.
    
    (2)  Layering terminology should be tightened up in a few places to remove
    confusion between a RADIUS transport profile and what the underlying transport
    protocol itself actually is (it is not TLS, and the security in this document is
    not implemented in the transport layer, although it is in the transport
    profile).  I believe it's clearest to say that this document "RADIUS/TLS" is a
    transport *profile* for RADIUS using TLS over TCP as the transport *protocol*.
    But it's definitely not correct to say that it's using security in the transport
    layer, as currently done in a few places:
    - abstract
    - introduction, paragraph 2
    - section 6, paragraph 3
    - appendix c, paragraph 2 
        
  3. Adrian Farrel: Comment [2012-02-01]:
    Shouldn't there be some considerations of key management in line with RFC 4107?
  4. Stephen Farrell: Discuss [2012-01-29]:
        
    I've a few niggly but worth-fixing points here that should
    be easily addressed. A bunch of these overlap with the
    two reviews posted to the secdir list [1,2] so please resolve
    these comments along with those reviews.
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03073.html
       [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03074.html
    
    (1) You don't say what's the input to certificate fingerprint
    calculation. I think you want the DER encoded cert octets here,
    and not e.g. the subjectPublicKey, right? 
    
    (2) You don't say what "acceptable certificate" means. It could
    mean "only accept these [EE's|CAs] no matter what the 5280
    verification says" or (as I suspect) "always accept these EE's
    regardless of what the 5280 validation says" or something else.
    I'm (almost certainly) fine with it meaning whatever you
    currently want but it needs to be stated.
    
    (3) I think that saying you MUST do verification as per 5280 and
    at the same time saying that you SHOULD allow configuration of
    acceptable certificates (with the 2nd meaning above) is in
    conflict. I'd say the way to resolve that would be to say "SHOULD
    do 5280, except if the EE is on your acceptable list" and I'd be
    fine with doing that.
    
    (4) As with (2) you need to define what "acceptable
    subjectAltName:URI" is for.
    
    (5) I suspect you may be wrong in saying that "radsec" MUST be
    used for attribute encryption and MD5 since that means that if
    you only turn on TLS and don't modify your RADIUS code then you
    won't comply. It also means that if you have to turn off TLS for
    some reason for a while (e.g. one end's cert expired, forgot to
    have a new one ready beforehand, as happens quite commonly) then
    you probably have your trousers even further down than with
    current RADIUS if you start operating over UDP again temporarily
    and the value "radsec" is configured for RADIUS.  (I just want to
    draw attention to this - I'll clear once I've seen a substantive
    response to this point, for pretty much all possible substantive
    resposes:-)
    
    (6) You don't say if TLS re-negotiation is REQUIRED to be
    supported or not. I think it'd be good to say and maybe to
    RECOMMEND something for what to do if a long-lived RADIUS/TLS
    session outliving a CRL re-issue or public key cert or maybe even
    the appropriate amount of data to encrypt with a given
    ciphersuite. I don't really mind which way you'd rather handle
    that, but I think saying something is needed so surprises don't
    happen. In fact, if you want to note the issue and not RECOMMEND
    anything that'd be ok too.
     
        
  5. Stephen Farrell: Comment [2012-01-29]:
    - I don't get why this is going for experimental rather than PS.
    I'd prefer the latter really. 
    
    - You should define dynauth as a term or add a reference.
    
    - Seems odd to prefer a 3DES ciphersuite over an AES one. An
    explaination for that would be good. (Maybe its just existing
    code?)
    
    - Section 3, 1st bullet should I think talk about a list of trust
    points and say that that includes the CA public key and not just
    its name.
    
    - Please fix x.y.z, I doubt there's that section in 5246.
    
    - (Blatent self-promotion:-) Might it be useful to think about
    using draft-farrell-decade-ni as a(nother) way to represent
    certificate fingerprints?
    
    - Why only allow configuration of URIs for subjectAltName? I
    don't get why you don't include dNSName for example.
    
    - What does it mean to say the client is unique identified
    by the cert fingerprint? What happens when I get my certificate
    renewed?
    
    - I'm not sure why a reader in ten years will care that "Radiator
    is compliant to version 2 of RadSec..." (compliant to *this*
    protocol would be fine of course if those are the same but then
    why not say that?)
    
    - "(link to RFC once issued here)" is not really very finished
    text is is?
    
    - The mandatory TLS ciphersuites listed do not provide PFS.
    
  6. Russ Housley: Discuss [2012-01-31]:
        
      The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two
      concerns.  Please respond to each of them.
    
      (1) Section 2.4:
           In TLS-X.509 with PKI infrastructure, a client is uniquely
           identified by the serial number of the tuple (presented client
           certificate;Issuer).
          SHOULD BE:
           In TLS-X.509 with PKI infrastructure, a client is uniquely
           identified by the tuple (serial number of presented client
           certificate;Issuer).
    
      (2) Because RADIUS supports the Disconnect Request (server-to-client)
          message, it seems that there is some requirement to keep the TLS
          session open for the duration of the access that was authorized.
          Otherwise, the server would not be able to send such a packet to
          the client without initiating its own TLS connection which may not
          be possible or desirable.  Is this aspect of the specification
          inherited from the referenced TCP specification?  It may be
          helpful to add a paragraph about this issue. 
        
  7. Russ Housley: Comment [2012-01-31]:
      The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two editorial
      issues.  Please consider them.
    
      (1) Section 2.3:
           x.y.z
          Did you mean to fill in a real section number here?
    
      (2) Note Section 3.4 (1) )
          Missing open paren?
  8. Peter Saint-Andre: Comment [2012-01-30]:
    Section 2.3 says the following with respect to use of TLS with PKIX
    certificates:
    
           *  Peer validation always includes a check on whether the locally
              configured expected DNS name or IP address of the server that
              is contacted matches its presented certificate.  DNS names and
              IP addresses can be contained in the Common Name (CN) or
              subjectAltName entries.  For verification, only one of these
              entries is to be considered.  The following precedence
              applies: for DNS name validation, subjectAltName:DNS has
              precedence over CN; for IP address validation, subjectAltName:
              iPAddr has precedence over CN.
    
    It's good to specify the preference order, but you don't provide a precise
    definition of what it means to match the expected DNS name (IP address is more
    straightforward). You might find it helpful to cite RFC 6125 here.
    
    Section 4 states:
    
       Ongoing work in the IETF defines multiple alternative transports to
       the classic UDP transport model as defined in [RFC2865], namely
       RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS
       [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS.
    
    Is there a document that summarizes the experiment with these three technologies
    and that defines criteria for evaluating the success of each approach?
  9. Sean Turner: Comment [2012-02-02]:
    I agree with Stephen's discuss and Peter's comment positions.  Based on the
    email exchanges it looks like their issues will be resolved in -12.

draft-sarikaya-v6ops-prefix-delegation