IESG Narrative Minutes

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

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

Corrections from: (none)

1 Administrivia

1. Roll Call 1135 EDT Amy:
   • Bernard Aboba---
   • Richard Barnes--- likely regrets
   • Ron Bonica--- y
   • Stewart Bryant--- y
   • Gonzalo Camarillo--- y
   • Benoit Claise--- y
   • Michelle Cotton--- y
   • Ralph Droms--- y
   • Wesley Eddy--- in WebEx
   • Adrian Farrel--- y
   • Stephen Farrell--- y
   • Heather Flanagan--- y
   • Sandy Ginoza--- Alice for Sandy
   • Brian Haberman--- y
   • Joel Halpern--- y
   • Susan Hares--- regrets
   • Russ Housley--- y
   • Barry Leiba--- y
   • John Leslie--- y
   • Cindy Morgan--- y
   • Ray Pelletier--- regrets
   • Pete Resnick--- y
   • Robert Sparks--- y
   • Martin Stiemerling--- y
   • Sean Turner--- y
   • Amy Vezza--- y
2. Bash the Agenda
   • Amy: any new? four eai together, any other changes?
3. Approval of the Minutes of the past telechat
   • September 13 minutes--- approved
   • September 13 narrative minutes--- approved
4. Review of Action Items from last Telechat
   • Ron Bonica to write a draft moving RFC 5156 to Historic.
     Ron: submitted yesterday
     Russ: who will shepherd?
     Ron: I vote for Ralph
     Ralph: I'll be happy to sponsor it

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

• POP3 Support for UTF-8 (Proposed Standard)
  draft-ietf-eai-rfc5721bis [txt]
  Token: Pete Resnick (app area)
  Discusses/comments [ballot]:
  • Russ Housley: Comment [2012-09-23 14:45]:
    The abstract should mention that this document obsoletes RFC 5721.
  • Adrian Farrel: Comment [2012-09-27 04:41]:
    Please ask the RFC editor to remove section 8 before publication.
    When a new document obsoletes an old one, it is really nice to include a short section stating the changes. I think it is unfortunate that this document doesn't include such a section.
  • Stephen Farrell: Comment [2012-09-25 06:13]:
    (Sorry, ignore the previous mail, I attached the wrong comment to the wrong document.)
    I checked the diff with 5721 but its not that useful since there are a lot of changes. Apologies in advance if I comment on something that's unchanged from there and feel free to ignore such comments.
    - 2.1: Why mustn't clients issue the STLS command after UTF8? I don't get that.
  • Ralph Droms: Comment [2012-09-27 05:26]:
    Barry tells me the working group considered and rejected marking this document as 'updates RFC 2449'. I'd like the working group to reconsider that decision, considering this text from the IANA considerations:
    "Section 2 and 3 of this specification update two capabilities ('UTF8' and 'LANG') to the POP3 capability registry [RFC2449]."
    "Section 5 of this specification also adds one new response code ('UTF8') to the POP3 response codes registry [RFC2449]."
    It seems to me anyone implementing POP3 from scratch or updating an existing implementation should read this document as part of that implementation.
  • Pete Resnick: Comment [2012-09-21 13:45]:
    In section 3.1: "The character encoding format of maildrops may not be UTF-8 or ASCII."
    That sentence is wrong. Please correct.
  • Sean Turner: Comment [2012-09-25 16:59]:
    Along the same lines as Stephen's suggestion in response to Chris:
    s7: A bit more precise ?:
    OLD: A mechanism to protect the integrity of the session, such as Transport Layer Security (TLS) [RFC2595] can be used to defeat such attacks.
    NEW: A mechanism to protect the integrity of the session can be used to defeat such attacks, e.g., issuing the STLS [RFC2595] command before issuing the LANG command.

  Telechat:

  • Amy: no open; no discusses, hearing no objection, approved
  • Pete: understand we may have to return to this; point-raised
• IMAP Support for UTF-8 (Proposed Standard)
  draft-ietf-eai-5738bis [txt]
  Token: Barry Leiba (app area)
  Discusses/comments [ballot]:
  • Russ Housley: Discuss [2012-09-23 17:16]:
    5721bis is clear that support for downgrade is optional. As I read 5721bis, it says that one can downgrade, and if one does so, it must downgrade according to Section 7 of this document. However, there is no normative language in Section 7 of this document.
    "This document informatively references the downgrade drafts as examples, and the downgrade drafts are targeting the standards track."
    What specification MUST be followed to implement downgrade?
  • Adrian Farrel: Comment [2012-09-27 04:32]:
    Section 4: "IMAP servers that advertise support for 'UTF8=ACCEPT' or 'UTF8=ONLY' MUST reject an APPEND command that includes any 8-bit in the message headers with a 'NO' response, when IMAP clients do not issue 'ENABLE UTF8=ACCEPT' or 'ENABLE UTF8=ONLY'."
    This looks like errata 2075 has not been applied. http://www.rfc-editor.org/errata_search.php?rfc=5738
    When a new document obsoletes an old one, it is really nice to include a short section stating the changes. I think it is unfortunate that this document doesn't include such a section.
  • Stephen Farrell: Comment [2012-09-25 06:13]:
    I checked the diff with 5738 but its not that useful since there are a lot of changes. Apologies in advance if I comment on something that's unchanged from there and feel free to ignore such comments.
    - section 1:'Most of this specification' is an odd phrase. It'd be nicer if you could be more precise, or maybe just better to s/Most of this/This/
    - p4, 3rd last para says that the 'server MUST NOT send UTF-8 in quoted strings to the client unless the client has indicated support using the'ENABLE UTF8=ACCEPT' command.'
    Earlier you said that the 'UTF8=ONLY' capability implies this, so I guess that this MUST NOT also doesn't apply in that case. But is that clear enough? Maybe s/using the 'ENABLE UTF8=ACCEPT' command/using the 'ENABLE UTF8=ACCEPT' command or 'UTF8=ONLY' capability/ would be better?
    - section 7 says that signatures might 'not be applicable' to the variant version, which reads oddly to me. I think it'd be better to say that signatures may not longer be verifiable with the variant message.
    (The next two questions maybe apply to all four documents in this set, but I'll ask'em here anyway.)
    - I have a security question, the answer to which isn't clear to me, but maybe you can help. Is there any situation where a mailbox name or a user id might contain non-ascii characters and where the IMAP server will treat those as equivalent to some mapping to ascii? For example if joerg can use an umlaut or not, but has only set up one of the two, is there ever a threat that I could get access to joerg's mail by setting up an account with the one he's not using? I guess I'm wondering if it might be worth adding a warning about that kind of mapping. I don't know if that belongs here or not, or is already somewhere else, since its really like the general problem of 'cousin' domains in phishing (paypa1 etc), but I guess some discussion somewhere would be good.
    - Can EAI make it more likely that a sender would encrypt a message for the wrong recipient? If so, is that worth noting? Not sure where'd be right for that, but I wondered.
  • Ralph Droms: Comment [2012-09-27 05:22]:
    Barry tells me the working group considered and rejected marking this document as 'updates RFC 3501'. I'd like the working group to reconsider that decision, considering this text from the IANA considerations:
    "This document redefines two capabilities ('UTF8=ACCEPT' and 'UTF8=ONLY') in the IMAP 4 Capabilities registry [RFC3501]. Three other capabilities that were described in the experimental predecessor to this document (UTF8=ALL, UTF8=APPEND, UTF8=USER) are now made OBSOLETE."
    It seems to me anyone implementing IMAP from scratch or updating an existing implementation should read this document as part of that implementation.
  • Pete Resnick: Comment [2012-09-21 15:07]:
    I really didn't work on this version of the document, but they seemed determined to leave my name on it, so I shall Recuse.
  • Benoit Claise: Comment [2012-09-24 14:32]:
    No objection to the publication of this document. However, please fix the following issue.
    http://tools.ietf.org/html/draft-ietf-eai-5738bis-09#section-9. 'The reference making them obsolete would be good to include', quoting my discussion with Michelle Cotton
  • Barry Leiba: Comment [2012-09-21 12:42]:
    For the IESG, I'll note the following from the ballot text, in case anyone misses it. All four documents will be on the 27 Sept telechat.
    [Please note: This document is one a set of four interdependent documents:
    draft-ietf-eai-5738bis
    draft-ietf-eai-popimap-downgrade
    draft-ietf-eai-rfc5721bis
    draft-ietf-eai-simpledowngrade
    These documents should be reviewed, evaluated, and understood together.]
  • Sean Turner: Comment [2012-09-27 05:27]:
    I took tripped over the same sentence Stephen did. Please consider the following changes proposed by Barry: ...
    [see link]

  Telechat:

  • Amy: one discuss
  • Barry: general downgrade situation... main issue whether POP and IMAP should normatively refer; ongoing conversation with Russ
  • Pete: I think normative reference issue is separate...
  • Russ: there would be a dependency if there is a MUST
  • Pete: we don't want a MUST
  • Barry?: if you use, should use a vetted technique, these are the standard ways of downgrading
  • Russ: that's not what the revised text says
  • Pete: let me look at 21 again
  • Russ: text: downgrading is optional, if you do it there's guidance, neither is a must
  • Barry: don't think we said you could use your own homebrew... should be clear advice in both documents: using an approved mechanism if you do downgrade is important
  • Pete: I suspect we're not talking precisely enough... neither PGP or SMIME is a MUST for email; you'll screw it up if you don't use an approve encryption; if you're going to downgrade, you'd best use one of the standardized versions
  • Russ: "MUST use a standardized technology"... I'd clear, and accept informative references
  • Barry: think we can get that by the WG; AD followup
  • Benoit: IMAP and POP3 documents... just examples
  • Barry: need to change it to make clear these are the two standardized mechanisms
  • Benout: disconnect between the writeup and the text
  • Robert: do you know if change in 5738 boilerplate... did need for pre-1968 boilerplate disappear?
  • Barry: will check; AD-followup
• Post-delivery Message Downgrading for Internationalized Email Messages (Proposed Standard)
  draft-ietf-eai-popimap-downgrade [txt]
  Token: Pete Resnick (app area)
  Discusses/comments [ballot]:
  • Russ Housley: Discuss [2012-09-27 06:30]:
    Why is this document on the standards track? I would expect the standards track if the other documents in this cluster required this document to be followed if the optional downgrade capability is implemented. However, that is not the situation. Benoit Claise seems to have the same concern.
  • Stephen Farrell: Comment [2012-09-25 06:14]:
    - Should the security considerations here have a MUST or SHOULD statement calling for the server to strip existing Downgraded-* header fields? If not, why not?
    - Would it be worthwhile having a PDF version of this document that contained examples that show actual non-ASCII characters in appendix A? If so, then pointing to that in the ASCII appendix A would be a good thing too.
  • Benoit Claise: Discuss [2012-09-24 14:43]:
    The writeup mentions: "Consequently the base IMAP and POP3 documents are no longer dependent on particular downgrading choices and that two methods presented are, to a considerable extent, just examples."
    If these are just examples, why are they standards tracks? They should be informational.
    From RFC 2026:
    4.2.2 Informational
    An 'Informational' specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
    Along the same lines, quoting Barry:
    The only good answer to this issue (having a client that doesn't support EAI using a server that does and has an 'EAI message' to present to the client) is to get the client upgraded. *Anything* else (see Pete's parenthesized list above) is bad in some regard, and the decision of how to handle the situation until an upgrade can happen simply has to be at the discretion of the server
    Please mention in the draft (maybe in section 1.3, after the first paragraph), something such as: While this document is a specification, the only good solution is to upgrade the client [RFC5721bis] [RFC5738bis]
    My justification is the following: yes, this is a spec, but we don't want to promote it, we just want the clients to be upgraded.
    Note: this is done in https://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/
    "This document specifies a way to present such messages to the client. It values simplicity of implementation over fidelity of representation, since implementing a high-fidelity downgrade algorithm is likely more work than implementing proper support for [RFC5721] and/or [RFC5738]."
    Btw, should be RFC 5738bis and RFC5721bis.

  Telechat:

  • Amy: couple of discusses
  • Pete: think they're the same, Russ? Benoit
  • Russ: yes
  • Benoit: want to be sure it's covered
  • Michelle: also need changes in IANA for registration procedures
  • Pete: Russ and Benoit, are you ready to clear
  • Russ: I can clear all three when I see the text
  • Benoit: want changes in text for all four
  • Pete: do you think there are changes needed in the downgrade documents
  • Benoit: I have a pile of notes, prefer to review all four together
  • Pete: AD-followup, please
• HTTP Strict Transport Security (HSTS) (Proposed Standard)
  draft-ietf-websec-strict-transport-sec [txt]
  Token: Barry Leiba (app area)
  Discusses/comments [ballot]:
  • Stephen Farrell: Comment [2012-09-26 05:28]:
    This is a very well written document. Thanks!
    Only comment I have is that 6.1 says that directives are optional or required according to their definitions. Is it actually possible to define a new required directive without breaking interop with this spec? If not then I think saying that would be good.
  • Robert Sparks: Discuss [2012-09-25 13:19]:
    I have two points that to discuss that I think will be easy to address.
    1) Consider the case where a policy maker or example.edu configures the server to enforce STS, and to include the 'includeSubDomains' directive in the STS header field that server returns. This policy maker may think they've set policy for all the servers inside example.edu at this point, which is clearly not the case. A browser that only accessed a departmental server, say math.example.edu, would never see (so would never cache from) the response that contains the policy. Was this case discussed in the WG? Could some text be added to the document to make it more likely that the server administrator for example.edu would understand that configuring just the top level server will only cause browsers that actually access that top-level server to use STS on subdomains?
    2) The document does a great job of discussing how to handle the expiration time on cached entries when setting or updating those entries (that is, when processing a response). I'm not finding any text that says an implementation should check the expiration time before _using_ a cache entry (preparing a new request). I expected to see something in 8.3 (or perhaps 8.2) calling out that expired cache entries must not be used.
  • Robert Sparks: Comment [2012-09-25 13:19]:
    In section 14.4's first bullet, where you note 'the web application will be rendered unusable for the UA's user', consider calling out this as a reason for clients to consider providing a way for users to remove entries from the cache.
    Nit: In section 7.1 second paragraph 'may be accomplished over the HTTP protocol' could be read to mean over an unsecure transport.
  • Sean Turner: Comment [2012-09-26 16:30]:
    I was going to say 'Well written indeed' and leave it at that but I thought s14 was outstanding.
    In s11.2: Maybe make this a SHOULD:
    "Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems."
    or say:
    "Additionally, it is RECOMMENDED that server implementers employ a default max-age value of zero in their deployment configuration systems."

  Telechat:

  • Amy: a discuss
  • Barry: sorted out, revised-ID needed
• Simplified POP/IMAP Downgrading for Internationalized Email (Proposed Standard)
  draft-ietf-eai-simpledowngrade [txt]
  Token: Pete Resnick (app area)
  Discusses/comments [ballot]:
  • Russ Housley: Discuss [2012-09-27 06:28]:
    It appears that one open issue has not been resolved. The 'Open Issues' section includes this question:
    "Should Kazunori Fujiwara's downgrade document also mention DOWNGRADED?"
    5721bis is clear that support for downgrade is optional. It points to Section 7 of 5738bis for guidance on downgrade if it is implemented, which in turn points to this document was an informational reference.
    Why is this document on the standards track? I would expect the standards track if the other documents required this document to be followed if the optional capability is implemented. However, that is not the situation. Benoit Claise seems to have the same concern.
  • Adrian Farrel: Comment [2012-09-26 14:44]:
    It is petty of me and you may ignore this Comment at your discretion,
    but...
    "This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients."
    1. Those would be 'email clients' or 'IMAP or POP clients' I guess
    2. What is convention these days?
    Would '...to email clients that do not include internationalization support' be better?
    Section 1 para 1: s/attempt/attempts/
    Section 5: "Some POP or IMAP clients, such as Fetchmail, download messages and delete the version on the server. This may lead to permanent loss of information when the only remaining version of a message is the synthetic message."
    This seems to suggest that the mechanisms described in this document might not always be what the user wants the server to do (i.e., they would prefer the message was hidden on the conventional MUA and found by the internationalized MUA, rather than downgraded for the conventional MUA and deleted from the server).
    That seems to suggest that the behavior of the server must be configurable per account with the default to hide.
  • Stephen Farrell: Comment [2012-09-25 06:14]:
    - The reference on page 2 to 5738 should presumably be to 5738bis?
    - Examples would be good here, and as with the other downgrade approach, it'd be nice if there were a PDF version that showed actual non-ASCII.
  • Benoit Claise: Discuss [2012-09-24 14:46]:
    Same DISCUSS as https://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/ballot/#benoit-claise, with one difference for this document: mentions [RFC5721bis] and [RFC5738bis].
  • Stewart Bryant: Comment [2012-09-24 23:05]:
    The most often cited originator of rule 12 was William of Ocam (b1285) though scollars who know more about these things than I think that it does back much further. I am most interested in the nature of the help that William was able to provide the Apps Area on this work.

  Telechat:

  • Amy: is this also AD-followup
  • Pete: yes; I'll add note about IANA issue
• Guidelines for Authors and Reviewers of IPFIX Information Elements (Best Current Practice)
  draft-ietf-ipfix-ie-doctors [txt]
  Token: Ronald Bonica (ops area)
  Note: Juergen Quittek (Quittek@neclab.eu) is the document shepherd.
  Discusses/comments [ballot]:
  • Adrian Farrel: Discuss [2012-09-27 07:21]:
    Updated first point of the Discuss after conversation with Ron Bonica.
    I found rather a number of issues. I have tried to split them between my Discuss and Comment according to their magnitude. Inevitably I will have got this wrong, so please debate them with me.
    This document appears to update RFC 5102. That RFC defined the registry and sets up the guidelines for expert review of allocation requests.This document is changing those guidelines.
    Not quite sure how that will fit in when you come to publish I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D has a normative reference to that I-D so they will pop out together.
    A way to fix this would be to yank all of the IANA stuff and put it in 5102bis. Then this document simply instruct the IE-doctors to ensure the IANA allocation requests match the rules.
    Section 4: "o The Information Element MUST be unique within the registry. Its description MUST represent a substantially different meaning from that of any existing Information Element. A proposed Information Element which is a substantial duplicate of an existing Information Element is to be represented using the existing Information Element."
    Surely this is too subjective. What does 'substantially different' actually mean? I tried to rewrite this for you in terms of data type, units, and range, but I think that is probably only a part of what you are talking about. For re-use of an existing Information Element you presumably need those three parameters to be the same, *and* some other quality has to be the same.
    Depending on the description being similar seems really doubtful. Can you clarify this?
    Section 4: "o The Information Element SHOULD contain minimal internal structure;"
    Do you mean 'minimal'. I suppose you use this in the meaning 'the least possible'.
    Given the existence of parallel export and Structured Data, is there any reason not to interpret this statement as: you must only use a single Abstract Data Type.
    Of course, you may be attempting to also control the definition of new Abstract Data Types, but if so, you probably ought to call that out.
    Section 4: "o The Information Element SHOULD be generally applicable to the application at hand, which SHOULD be of general interest to the community."
    I find this a bit worrying. What are you saying about proposals from outside the IETF? How is the 'general interest to the community' to be measured? Are the designated experts called upon to call consensus?
    Section 4.3 defines rules for IANA Allocation of code points. Including notes on the ranges. Is it your intention that the registry is updated to point to this document? If so, you should make that statement in the IANA considerations section.
    On the other hand, this seems to be a restatement of what is already in the registry, so I wonder whether the section can be left out.
    Doesn't Section 11 give rise to some additional rules that are not captured in the body of the document and (importantly) not in the checklists of Section 7?
    Section 12: Do you need to tell IANA how to populate the Revision and Date fields in the IE registry for IEs that have already been defined?
  • Adrian Farrel: Comment [2012-09-26 16:22]:
    Just to let the shepherding AD know that it isn't very nice to find:
    "Capitalized terms used in this document that are defined in the Terminology section of [I-D.ietf-ipfix-protocol-rfc5101bis] are to be interpreted as defined there."
    when the referenced I-D is not yet stable enough to receive a publication request. Nothing the authors can do except realise that any change to the referenced document may break this document.
    The use of 2119 language seems entirely inappropriate to me. There is nothing to be implemented and no bits on the wire. The designated experts are humans not machines - speak to them in English!
    Section 3, while providing a useful refresher on IPFIX seems to be out of scope for the document. It could be entirely removed without harming the document.
    Section 4.1: "o Names of Information Elements SHOULD be descriptive."
    Why on earth do you want to allow non-descriptive names?
    Section 4.2:
    "Information Elements of type string or octetArray which have length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their description.
    "The type of an Information Element MUST match the type of the data it represents. More specifically, information that could be represented as a string, but which better matches one of the other data types (e.g. an integral type for a number or enumerated type, an address type for an address) MUST be represented by the best-matching type, even if the data was represented using a different type in the source. In other words, an IPFIX application that exports Options Template Records mapping IP addresses to additional information about each host from an external database MUST use Information Elements of an address type to represent the addresses, even if the source database represented these as strings."
    Do you need to say that strings and octetArrays must not be used to encode data that would be more properly encoded in other data types perhaps using multiple information elements with a forward pointer to Section 4.5?
    Section 4.3: "In general, when adding newly registered Information Elements to the IANA IE registry, IANA SHOULD assign the lowest available Information Element identifier (the value column in [iana-ipfix-assignments]) in the range 128-32767."
    What does 'in general' mean and how is IANA to interpret it?
    Section 4.9: "However, for reasons of history, there are several Information Elements within the IANA IE registry which do not follow best practices in Information Element design. These Information Elements are not necessarily so flawed so as to require deprecation, but they should be explicitly ignored when looking for guidance as to whether a new Information Element should be added."
    Now, I know the experts are experts, and it is completely obvious to them which IEs don't follow best practices, but the poor fool building a new spec is being asked for a rock. Can you not list the IEs that should be ignored?
    Section 6: "Due to the limited number space of Information Elements in the IANA IE registry, avoiding redundancy and clutter in the registry is important in defining new applications."
    Nah! I agree that avoiding redundancy and clutter are a good idea, but you cannot say that the IE has such limited space that this is the reason. Look, you have assigned fewer than 375 out of 32767 identifiers. If it fills up in the next 20 years I will buy you a bottle.
  • Pete Resnick: Comment [2012-09-26 17:27]:
    The abstract tries to jam everything into a single convoluted sentence, and I think it ends up being completely unclear. I make a suggestion here, but I'm not sure I've captured what needs to be captured. The WG needs to check this:
    "This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations."
    I'll leave it to the authors to rewrite section 1 along the same lines. In section 1.1, I think you specifically need to mention people who write new IEs and *not* talk about 'extending the applicability of IPFIX', as that confused the issue. I also find the use of the word 'application' a bit odd here, and I've substituted 'use case', but if 'application' is understood in this community, that is fine. So, maybe something like:
    "This document is meant for two separate audiences. For those wishing to write new Information Element specifications, it provides guidelines for how to decide which Information Elements are necessary for a given existing or new use case, instructions for writing the Information Element specification to be registered, and information on the kinds of documentation that will be required for the use case (up to and including publication of a new RFC). For the IPFIX experts..."
    2. Regarding 2119: I agree with Adrian that the use of 2119 language in this document is wrong, and verges on downright silly. This document is not talking about protocol requirements, or even documentation requirements that need to be followed for interoperability purposes. So for instance, section 4.1 says, 'Information Element Names should be defined in accordance with section 2.3 of [I-D.ietf-ipfix-information-model-rfc5102bis]' and then goes on to give some conventions as MUSTs and SHOULDs. But if we look at ietf-ipfix-information-model-rfc5102bis, we find:
    "The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions."
    So even the MUSTs are not requirements, but recommended naming conventions for extensions. I really think you should get rid of all of the 2119 language.
    That said, you'll note that this is in a COMMENT. I think for the most part, while useless and silly (it sounds like you are trying to be protocol police), using 2119 in this document is generally not harmful. I am most worried about the use of 2119 to control IANA actions (e.g., 4.3), but even there, disaster is unlikely. So I do beg with you to revisit your decision to use 2119 in this document; I think it adds nothing and detracts from the understanding of 2119 in other documents. But I will not insist on DISCUSSing this with the IESG.
  • Barry Leiba: Comment [2012-09-26 16:09]:
    The beginning of the document, through the beginning of Section 3 (end of page 5), very strongly smells like an Applicability Statement, which should be on Standards Track. Completion of review and further discussion supports BCP, but it will help to clarify the text up to page 5. Pete has promised specific comments for that, so I'll leave them to him, but I'm happy to help with it as well.
  • Stewart Bryant: Comment [2012-09-26 07:54]:
    Thank you for addressing my concerns.

  Telechat:

  • Amy: no open, a discuss
  • Ron: author on call
  • Michelle: IANA would like to review the most recent version, can someone hold for IANA
  • Benoit: in there already under Adrian
  • Adrian: I'm behind with my email
  • Benoit: removal of 2119 keywords, I believe that's right; two documents, normative reference in both directions, extra set of rules in the BCP
  • Adrian: between the two drafts, you are replacing 5102... I propose you take IANA stuff out of this document, and put it in 5102bis
  • Benoit: that's one way... expect to update perhaps every five years, could lead to need to update two documents
  • Adrian: I think you need rules for IANA management in a single place, preferably standards-track; IANA management details hidden in...
  • Benoit: which one do you read first, should we have BCP simply say, refer to 5102bis?
  • Benoit: two audiences
  • Adrian: if that's what you want, don't write document with this title
  • Benoit: IANA issue is valid
  • Adrian: need to read emails, hoping I'm ready to clear, will check with IANA before clearing
  • Ron: revised-ID needed
• IS-IS Multi-Instance (Proposed Standard)
  draft-ietf-isis-mi [txt]
  Token: Adrian Farrel (rtg area)
  Note: Chris Hopps (chopps@rawdofmt.org) is the document shepherd.
  Discusses/comments [ballot]:
  • Pete Resnick: Comment [2012-09-23 08:51]:
    +1 to Barry's comment: Good usage of 2119. Just one comment along those lines:
    2.4: "The following sub-sections describe the additional rules an MI-RTR MUST follow when establishing adjacencies."
    I think this might be confusing to implementers. The next subsections contain one 'SHOULD NOT' and some other guidance, but it's not clear what protocol requirement (i.e., 'MUST') an implementer is REQUIRED to follow. I suggest replacing the sentence with:
    "The following sub-sections describe additional procedures to follow when an MI-RTR establishes adjacencies."
    There are a few instances of your caps-lock key getting stuck. :-)
    In 2.1, change 'BE' to 'be' in two places.
    In 2.6.2, change 'NOT' to 'not' in two places.
  • Barry Leiba: Comment [2012-09-18 06:04]:
    A couple of non-blocking comments, which I'd like the authors to please consider (and chat with me about if it helps):
    You have isis-genapp as a normative reference, but the only citation of it is as an example use case in the introduction. Why is it normative? If it is, shouldn't there be a citation when the normative bit comes up later?
    -- Section 2 -- "This MAY also imply IID/ITID specific routing calculations and IID/ITID specific routing and forwarding tables. However, this aspect is outside the scope of this specification."
    I think this is not a 2119 'MAY' (one huge clue is the second sentence). I suggest changing it to 'might'. Kudos on what seems to be very crisp use of 2119 language in the rest of the document.
    And, finally a totally trivial point: the last paragraph of the introduction says this:
    "The above are examples of how MI-IS-IS might be used. The specification of uses of MI-IS-IS is outside the scope of this document."
    That seems self-contradictory. How about 'Full specification of uses...'?
  • Sean Turner: Discuss [2012-09-26 17:11]:
    s2.3: I'm curious if authentication is used on one ITID MUST it be used on all? I could read the last sentence as:
    "If authentication is used then all ITID MUST also use authentication, but different authentication methods can used on the ITIDs but it's never no authentication."
    or
    "Different ITIDs can have different authentication mechanisms (i.e., some have none some use 5304)."

  Telechat:

  • Amy: no open, a discuss
  • Adrian: briefly, Sean, email exchange, sounds like your point has been answered, but you asked, why do you want to
  • Sean: ought to be security considerations, if one fails, do you kick the other out... a little more needs to be said
  • Adrian: AD-followup
  • Michelle: latest version added ethernet items, should they be reviewed by expert
  • Adrian: I'll make sure that happens; If I need help, I'll ask you
• Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals (Proposed Standard)
  draft-ietf-krb-wg-kerberos-referrals [txt]
  Token: Stephen Farrell (sec area)
  Note: The Document Shepherd for this document is Jeffrey Hutzelman (jhutz@cmu.edu).
  Discusses/comments [ballot]:
  • Sean Turner: Comment [2012-09-27 07:29]:
    FAST is SHOULD in s6 but MUST in s11? Which is it?
    s6: as noted by Tom, please add SIZE() around the (1..MAX).
    s11: I know you know EncKDCRepPart is defined in 4120 and I found it there too, but a pointer there would be nice.
    App A: To what version does current refer: "In Microsoft's current implementation through the use of global catalogs any domain in one forest is reachable from any other domain in the same forest or another trusted forest with 3 or less referrals."

  Telechat:

  • Amy: no open, no active discusses, hearing no objection, approved
  • Stephen: RFCed notes, couple of comments pending, point-raised please

2.1.2 Returning Items

• (none)

2.2 Individual Submissions

2.2.1 New Items

• (none)

2.2.2 Returning Items

• (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

• Camellia Encryption for Kerberos 5 (Informational)
  draft-ietf-krb-wg-camellia-cts [txt]
  Token: Stephen Farrell (sec area)
  Note: The Document Shepherd for this document is Jeffrey Hutzelman (jhutz@cmu.edu).
  IPR: Stephen Farrell's Statement about IPR related to draft-ietf-krb-wg-camellia-cts-01 belonging to Nippon Telegraph and Telephone Company and Mitsubishi Electric Corporation
  Discusses/comments [ballot]:
  • Russ Housley: Comment [2012-09-23 15:14]:
    The Gen-ART Review by Joel Halpern on 13-Sept-2012 makes two suggestions to improve the document:
    1. The document seems to use 'random2key' (in section 3) and 'random-to-key' (in section 4) to represent the same thing, apparently meaning the 'random-to-key' function of section 6.
    2. Section 6 defines Ki in a different way than section 4. Section 4 apparently uses K0 and Ki to mean K(0) and K(i) for the iteration. (And then in the next line uses K1, K2, ... Kn for these, without parens.) But section 6, Ki is for a specific value in the encrypt/decrypt functions. The simple solution would seem to be to consistently use parenthesis in section 4.
  • Adrian Farrel: Comment [2012-09-27 04:15]:
    I've cleared my Discuss after reading email from Ken Raeburn as designated expert.
    However, Ken made a number of comments (captured below) that you may want to consider for a revised version...
    [see link[
  • Sean Turner: Comment [2012-09-27 07:26]:
    From the secdir review:
    As noted by Russ: is it random-to-key or random2key in s3/4?
    In s4, please reference section 6 for random-to-key and RFC 3961 for k-truncate as well
    In s3, what's the format for the string-to-key.
    Encryption and decryption description in section 6 seems a little incomplete. In particular the setting of newstate seems to be missing in the encryption. In the decryption perhaps you should define how newIV is determined.

  Telechat:

  • Amy: no discusses, hearing no objection, approved
  • Stephen: some comments I want to check, point-raised please
• NEA Asokan Attack Analysis (Informational)
  draft-ietf-nea-asokan [txt]
  Token: Stephen Farrell (sec area)
  Note: Susan Thomson (sethomso@cisco.com) is the Document Shepherd.
  Discusses/comments [ballot]:
  • Adrian Farrel: Comment [2012-09-26 14:21]:
    The third sentence of the Introduction is an apparent non sequitur. It would be nice if some context was given to the statement.
    Section 5: "1. Protocols should make use of cryptographic binding, however binding identities of the tunnel endpoints in the EMA may be useful."
    This is hard to parse. Is there an 'also' missing from the second clause?
  • Martin Stiemerling: Comment [2012-09-25 06:11]:
    I have one point requiring clarification:
    Section 2, paragraph 1: "The NEA Asokan Attack is a variation on an attack described in a 2002 paper written by Asokan, Niemi, and Nyberg [1]. Figure 1 depicts one version of the original Asokan attack. This attack involves tricking an authorized user into authenticating to a decoy AAA server, which forwards the authentication protocol from one tunnel to another, tricking a AAA server into believing these messages came from the attacker and granting access to him."
    Shouldn't it read that the 'believe that messages came from the user, but granting access to the attacker'?
  • Stewart Bryant: Comment [2012-09-25 05:59]:
    I had no idea what a Network Endpoint Assessment was, until I stumbled on the reference to RFC5209. It would be a good idea to move the reference up to the first line of the Introduction.
    I kept meeting PT, but has no idea what that was until I found it in RFC5209. A sentence earlier in the text would be useful.

  Telechat:

  • Amy: no discusses, hearing no objection, approved
  • Stephen: point-raised please, one comment to check

3.1.2 Returning Items

• (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

• (none)

3.2.2 Returning Items

• (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

• (none)

3.3.2 Returning Items

• (none)

1212 EDT 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. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

1. Operations and Management Area Working Group (opsawg)

   Telechat:

   • Amy: no blocking comment; does it need external review
   • Benoit: it deserves external review
   • Amy: approved for external review

4.2.2 Proposed for Approval

1. Hypertext Transfer Protocol Bis (httpbis)
   Token: Barry

   Telechat:

   • Amy: one blocking comment
   • Barry: no real need to discuss, I see your text and will add, and some comments I need to check
   • Pete: that's fine
   • Barry: Amy, we'll let you know
   • Amy: we need guidance: does this go back on the agenda, or does this go to approved when the block clears
   • Pete: do you want me to clear, so it's more like point-raised... clear my block
   • Amy: approved pending edits

5. IAB News We can use

• Joel: two items, IAB decided on technical plenary, measurement issues in the large-scale Internet; other issue, ongoing discussion with ICANN, RSSAC wants to publish a replacement pointing to an RSSAC document
• Russ: we would clearly be involved in any discussion about obsoleting such a document; suggest we discuss in Atlanta, will put it on agenda for Atlanta lunch

6. Management Issues

1. Approval of the IESG Statement regarding Ethertype assignments (Russ Housley)

   Telechat:

   • Russ: I contacted Glenn re early allocation, not ready to approve, push to next agenda
   • Amy: on agenda for October 11

2. Expert Non-Responsiveness - Transport Layer Security (TLS) Parameters (Michelle Cotton)

   Telechat:

   • Michelle: Sean has taken the token, may be due to old email
   • Benoit: he found them, will get to them next week

3. Experts for IS-IS Multi-Topology framework [IANA #561932] (Michelle Cotton)

   Telechat:

   • Michelle: confirm (name + name), any objection?
   • Adrian: sounds fine, will Amy send ticket to IANA
   • Amy: approved two names, we will send official note to IANA

4. Experts for Level of Assurance (LoA) Registry (Sean Turner)

   Telechat:

   • Sean: RFC 6711, approve pool of experts, any objection to five names?
   • Russ: look fine
   • Sean: reminder to IANA to get email set up
   • Amy: approved five names, can you make sure we get the right email addresses?

5. TCP Option Kind Numbers [IANA #601713] (Michelle Cotton)

   Telechat:

   • Michelle: received request, either IESG or standards; can you review and approve?
   • Russ: expect transport ADs to lead on this
   • Barry: think Wes' reply this morning will satisfy
   • Pete: 10:25 last night
   • Russ: refer to WG or write standards-track
   • Michelle: how do we close the ticket?
   • Amy: I don't think we need to do that, we'll just close the ticket

7. Agenda Working Group News

• Pete Resnick (Apps)--- nothing
• Robert Sparks (RAI)--- no thanks
• Martin Stiemerling (Transport)--- (lost Martin)
• Sean Turner (Security)--- none, and no NomCom
• Ron Bonica (O & M)--- large interim
• Stewart Bryant (Routing)--- none
• Gonzalo Camarillo (RAI)--- nothing
• Benoit Claise (O & M)--- nothing
• Ralph Droms (Internet)--- none
• Wesley Eddy (Transport)--- (not on audio)
• Adrian Farrel (Routing)--- none
• Stephen Farrell (Security)--- kerberos and kitten, plan to merge by rechartering kitten, close kerberos after Atlanta
• Brian Hamerman (Internet)--- not today
• Russ Housley (General)--- pass
• Barry Leiba (Applications)--- none

1234 EDT Adjourned

Appendix: Snapshot of discusses/comments

(at 2012-09-27 07:30:03 PDT)

draft-ietf-eai-rfc5721bis

• Russ Housley: Comment [2012-09-23 14:45]:
  

    The abstract should mention that this document obsoletes RFC 5721.

• Adrian Farrel: Comment [2012-09-27 04:41]:
  

  Please ask the RFC editor to remove section 8 before publication.
  
  ---
  
  When a new document obsoletes an old one, it is really nice to include
  a short section stating the changes. I think it is unfortunate that this
  document doesn't include such a section.

• Stephen Farrell: Comment [2012-09-25 06:13]:
  

  (Sorry, ignore the previous mail, I attached the wrong comment
  to the wrong document.)
  
  I checked the diff with 5721 but its not that useful since there
  are a lot of changes. Apologies in advance if I comment on
  something that's unchanged from there and feel free to ignore
  such comments.
  
  - 2.1: Why mustn't clients issue the STLS command after UTF8?  I
  don't get that.

• Ralph Droms: Comment [2012-09-27 05:26]:
  

  Barry tells me the working group considered and rejected marking this
  document as "updates RFC 2449".  I'd like the working group to
  reconsider that decision, considering this text from the IANA
  considerations:
  
     Section 2 and 3 of this specification update two capabilities ("UTF8"
     and "LANG") to the POP3 capability registry [RFC2449].
  
     Section 5 of this specification also adds one new response code
     ("UTF8") to the POP3 response codes registry [RFC2449].
  
  It seems to me anyone implementing POP3 from scratch or updating an
  existing implementation should read this document as part of that
  implementation.

• Pete Resnick: Comment [2012-09-21 13:45]:
  

  In section 3.1:
  
     The character encoding format of maildrops may not be UTF-8 or ASCII.
  
  That sentence is wrong. Please correct.

• Sean Turner: Comment [2012-09-25 16:59]:
  

  Along the same lines as Stephen's suggestion in response to Chris:
  
  s7: A bit more precise ?:
  
  OLD:
  
    A mechanism to protect the
     integrity of the session, such as Transport Layer Security (TLS)
     [RFC2595] can be used to defeat such attacks.
  
  NEW:
  
     A mechanism to protect the integrity of the session can be used
     to defeat such attacks, e.g., issuing the STLS [RFC2595] command
     before issuing the LANG command.

draft-ietf-eai-5738bis

• Russ Housley: Discuss [2012-09-23 17:16]:
  

    5721bis is clear that support for downgrade is optional.  As I read
    5721bis, it says that one can downgrade, and if one does so, it must
    downgrade according to Section 7 of this document.  However, there
    is no normative language in Section 7 of this document.
  
    This document informatively references the downgrade drafts as
    examples, and the downgrade drafts are targeting the standards track.
  
    What specification MUST be followed to implement downgrade?

• Adrian Farrel: Comment [2012-09-27 04:32]:
  

  Section 4
  
     IMAP servers that advertise support for "UTF8=ACCEPT" or "UTF8=ONLY"
     MUST reject an APPEND command that includes any 8-bit in the message
     headers with a "NO" response, when IMAP clients do not issue "ENABLE
     UTF8=ACCEPT" or "ENABLE UTF8=ONLY".
  
  This looks like errata 2075 has not been applied.
  http://www.rfc-editor.org/errata_search.php?rfc=5738
  
  ---
  
  When a new document obsoletes an old one, it is really nice to include
  a short section stating the changes. I think it is unfortunate that this
  document doesn't include such a section.

• Stephen Farrell: Comment [2012-09-25 06:13]:
  

  
  I checked the diff with 5738 but its not that useful since there
  are a lot of changes. Apologies in advance if I comment on
  something that's unchanged from there and feel free to ignore
  such comments.
  
  - section 1: "Most of this specification" is an odd phrase. It'd
  be nicer if you could be more precise, or maybe just better to
  s/Most of this/This/
  
  - p4, 3rd last para says that the "server MUST NOT send UTF-8 in
  quoted strings to the client unless the client has indicated
  support using the "ENABLE UTF8=ACCEPT" command." Earlier you
  said that the "UTF8=ONLY" capability implies this, so I guess
  that this MUST NOT also doesn't apply in that case. But is that
  clear enough?  Maybe s/using the "ENABLE UTF8=ACCEPT"
  command/using the "ENABLE UTF8=ACCEPT" command or "UTF8=ONLY"
  capability/ would be better?
  
  - section 7 says that signatures might "not be applicable" to
  the variant version, which reads oddly to me. I think it'd be
  better to say that signatures may not longer be verifiable
  with the variant message.
  
  (The next two questions maybe apply to all four documents in
  this set, but I'll ask 'em here anyway.)
  
  - I have a security question, the answer to which isn't clear to
  me, but maybe you can help. Is there any situation where a
  mailbox name or a user id might contain non-ascii characters and
  where the IMAP server will treat those as equivalent to some
  mapping to ascii? For example if joerg can use an umlaut or not,
  but has only set up one of the two, is there ever a threat that
  I could get access to joerg's mail by setting up an account with
  the one he's not using? I guess I'm wondering if it might be
  worth adding a warning about that kind of mapping. I don't know
  if that belongs here or not, or is already somewhere else, since
  its really like the general problem of "cousin" domains in
  phishing (paypa1 etc), but I guess some discussion somewhere
  would be good.
  
  - Can EAI make it more likely that a sender would encrypt a
  message for the wrong recipient? If so, is that worth noting?
  Not sure where'd be right for that, but I wondered.

• Ralph Droms: Comment [2012-09-27 05:22]:
  

  Barry tells me the working group considered and rejected marking this
  document as "updates RFC 3501".  I'd like the working group to
  reconsider that decision, considering this text from the IANA
  considerations:
  
     This document redefines two capabilities ("UTF8=ACCEPT" and
     "UTF8=ONLY") in the IMAP 4 Capabilities registry [RFC3501].  Three
     other capabilities that were described in the experimental
     predecessor to this document (UTF8=ALL, UTF8=APPEND, UTF8=USER) are
     now made OBSOLETE.
  
  It seems to me anyone implementing IMAP from scratch or updating an
  existing implementation should read this document as part of that
  implementation.

• Pete Resnick: Comment [2012-09-21 15:07]:
  

  I really didn't work on this version of the document, but they seemed
  determined to leave my name on it, so I shall Recuse.

• Benoit Claise: Comment [2012-09-24 14:32]:
  

  No objection to the publication of this document.
  However, please fix the following issue.
  http://tools.ietf.org/html/draft-ietf-eai-5738bis-09#section-9. "The reference
  making them obsolete would be good to include", quoting my discussion with
  Michelle Cotton

• Barry Leiba: Comment [2012-09-21 12:42]:
  

  For the IESG, I'll note the following from the ballot text, in case anyone
  misses it.  All four documents will be on the 27 Sept telechat.
  
  [Please note: This document is one a set of four interdependent
  documents:
  
  draft-ietf-eai-5738bis
  draft-ietf-eai-popimap-downgrade
  draft-ietf-eai-rfc5721bis
  draft-ietf-eai-simpledowngrade
  
  These documents should be reviewed, evaluated, and understood
  together.]

• Sean Turner: Comment [2012-09-27 05:27]:
  

  I took tripped over the same sentence Stephen did.  Please consider the
  following changes proposed by Barry:
  
  OLD
     Because such messages are really variations on the original ones, not
     really "downgraded ones" (although that terminology is often used for
     convenience), they inevitably have relationships to the original ones
     that the IMAP specification [RFC3501] did not anticipate.
  
  NEW
  [no change; just including that sentence here for context]
  
  OLD
     In particular, digital signatures computed over the original message
     will often not be applicable to the variant version and servers that
     may be accessed by the same user with different clients or methods
     (e.g., POP or webmail systems in addition to IMAP or IMAP clients
     with different capabilities) will need to exert extreme care to be
     sure that UIDVALIDITY behaves as the user would expect.
  
  NEW
     This brings up two concerns in particular:
  
     First, digital signatures computed over and intended for the original
     message will often not be applicable to the variant message, and
     will often fail signature verification.  (It will be possible for some
     digital signatures to be verified, if they cover only parts of the
     original message that are not affected in the creation of the variant.)
  
     [no change to the next; I've just split it out as its own sentence.]
     Second, servers that
     may be accessed by the same user with different clients or methods
     (e.g., POP or webmail systems in addition to IMAP or IMAP clients
     with different capabilities) will need to exert extreme care to be
     sure that UIDVALIDITY behaves as the user would expect.

draft-ietf-eai-popimap-downgrade

• Russ Housley: Discuss [2012-09-27 06:30]:
  

    Why is this document on the standards track?  I would expect the
    standards track if the other documents in this cluster required this
    document to be followed if the optional downgrade capability is
    implemented.  However, that is not the situation.  Benoit Claise
    seems to have the same concern.

• Stephen Farrell: Comment [2012-09-25 06:14]:
  

  - Should the security considerations here have a MUST or SHOULD
  statement calling for the server to strip existing Downgraded-*
  header fields? If not, why not?
  
  - Would it be worthwhile having a PDF version of this document
  that contained examples that show actual non-ASCII characters in
  appendix A? If so, then pointing to that in the ASCII appendix A
  would be a good thing too.

• Benoit Claise: Discuss [2012-09-24 14:43]:
  

  The writeup mentions:
  
        Consequently the base IMAP and POP3
        documents are no longer dependent on particular downgrading
        choices and that two methods presented are, to a considerable
        extent, just examples.
  
  If these are just examples, why are they standards tracks? They should be
  informational. From RFC 2026:
  
  4.2.2  Informational
  
     An "Informational" specification is published for the general
     information of the Internet community, and does not represent an
     Internet community consensus or recommendation.
  
  Along the same lines, quoting Barry:
  
      The only good answer to this issue (having a client that doesn't support
      EAI using a server that does and has an "EAI message" to present to the
      client) is to get the client upgraded.  *Anything* else (see Pete's
      parenthesized list above) is bad in some regard, and the decision of how to
      handle the situation until an upgrade can happen simply has to be at the
      discretion of the server
  
  Please mention in the draft (maybe in section 1.3, after the first paragraph),
  something such as: While this document is a specification, the only good
  solution is to upgrade the client [RFC5721bis] [RFC5738bis]
  
  My justification is the following: yes, this is a spec, but we don't want to
  promote it, we just want the clients to be upgraded.
  
  Note: this is done in
  https://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/
  
     This document specifies a way to present such messages to the client.
     It values simplicity of implementation over fidelity of
     representation, since implementing a high-fidelity downgrade
     algorithm is likely more work than implementing proper support for
     [RFC5721] and/or [RFC5738].
  
  Btw, should be RFC 5738bis and RFC5721bis.

draft-ietf-websec-strict-transport-sec

• Stephen Farrell: Comment [2012-09-26 05:28]:
  

  This is a very well written document. Thanks!
  
  Only comment I have is that 6.1 says that directives are
  optional or required according to their definitions. Is it actually
  possible to define a new required directive without breaking
  interop with this spec? If not then I think saying that would
  be good.

• Robert Sparks: Discuss [2012-09-25 13:19]:
  

  I have two points that to discuss that I think will be easy to address.
  
  1) Consider the case where a policy maker or example.edu configures the server
  to enforce STS, and to include the "includeSubDomains" directive in the STS
  header field that server returns. This policy maker may think they've set policy
  for all the servers inside example.edu at this point, which is clearly not the
  case. A browser that only accessed a departmental server, say math.example.edu,
  would never see (so would never cache from) the response that contains the
  policy. Was this case discussed in the WG? Could some text be added to the
  document to make it more likely that the server administrator for example.edu
  would understand that configuring just the top level server will only cause
  browsers that actually access that top-level server to use STS on subdomains?
  
  2) The document does a great job of discussing how to handle the expiration time
  on cached entries when setting or updating those entries (that is, when
  processing a response). I'm not finding any text that says an implementation
  should check the expiration time before _using_ a cache entry (preparing a new
  request). I expected to see something in 8.3 (or perhaps 8.2) calling out that
  expired cache entries must not be used.

• Robert Sparks: Comment [2012-09-25 13:19]:
  

  In section 14.4's first bullet, where you note "the web application will be
  rendered unusable for the UA's user", consider calling out this as a reason
  for clients to consider providing a way for users to remove entries from the
  cache.
  
  Nit: In section 7.1 second paragraph "may be accomplished over the HTTP
  protocol" could be read to mean over an unsecure transport.

• Sean Turner: Comment [2012-09-26 16:30]:
  

  I was going to say "Well written indeed" and leave it at that but I thought s14
  was outstanding.
  
  In s11.2: Maybe make this a SHOULD:
  
   Additionally, server implementers should consider employing a default
   max-age value of zero in their deployment configuration systems.
  
  or say:
  
   Additionally, it is RECOMMENDED that server implementers employ
   a default max-age value of zero in their deployment configuration
   systems.

draft-ietf-eai-simpledowngrade

• Russ Housley: Discuss [2012-09-27 06:28]:
  

    It appears that one open issue has not been resolved.  The "Open
    Issues" section includes this question:
    >
    > Should Kazunori Fujiwara's downgrade document also mention
    > DOWNGRADED?
  
    5721bis is clear that support for downgrade is optional.  It points to
    Section 7 of 5738bis for guidance on downgrade if it is implemented,
    which in turn points to this document was an informational reference.
  
    Why is this document on the standards track?  I would expect the
    standards track if the other documents required this document to be
    followed if the optional capability is implemented.  However, that is
    not the situation.  Benoit Claise seems to have the same concern.

• Adrian Farrel: Comment [2012-09-26 14:44]:
  

  It is petty of me and you may ignore this Comment at your discretion,
  but...
  
     This document specifies a method for IMAP and POP servers to serve
     internationalized messages to conventional clients.
  
  1. Those would be "email clients" or "IMAP or POP clients" I guess
  2. What is convention these days?
  
  Would
  "...to email clients that do not include internationalization support"
  be better?
  
  ---
  
  Section 1 para 1
  
  s/attempt/attempts/
  
  ---
  
  Section 5
  
     Some POP or IMAP clients, such as Fetchmail, download messages and
     delete the version on the server.  This may lead to permanent loss of
     information when the only remaining version of a message is the
     synthetic message.
  
  This seems to suggest that the mechanisms described in this document
  might not always be what the user wants the server to do (i.e., they
  would prefer the message was hidden on the conventional MUA and found by
  the internationalized MUA, rather than downgraded for the conventional
  MUA and deleted from the server).
  
  That seems to suggest that the behavior of the server must be
  configurable per account with the default to hide.

• Stephen Farrell: Comment [2012-09-25 06:14]:
  

  
  - The reference on page 2 to 5738 should presumably be to
  5738bis?
  
  - Examples would be good here, and as with the other downgrade
  approach, it'd be nice if there were a PDF version that showed
  actual non-ASCII.

• Benoit Claise: Discuss [2012-09-24 14:46]:
  

  Same DISCUSS as
  https://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/ballot/#benoit-claise, with one difference for this document: mentions [RFC5721bis] and [RFC5738bis].

• Stewart Bryant: Comment [2012-09-24 23:05]:
  

  The most often cited originator of rule 12 was William of Ocam (b1285) though
  scollars who know more about these things than I think that it does back much
  further. I am most interested in the nature of the help that William was able
  to provide the Apps Area on this work.

draft-ietf-ipfix-ie-doctors

• Adrian Farrel: Discuss [2012-09-27 07:21]:
  

  Updated first point of the Discuss after conversation with Ron Bonica.
  
  I found rather a number of issues. I have tried to split them between
  my Discuss and Comment according to their magnitude. Inevitably I will
  have got this wrong, so please debate them with me.
  
  ---
  
  This document appears to update RFC 5102. That RFC defined
  the registry and sets up the guidelines for expert review of
  allocation requests.This document is changing those
  guidelines.
  
  Not quite sure how that will fit in when you come to publish
  I-D.ietf-ipfix-information-model-rfc5102bis, and I know that this I-D
  has a normative reference to that I-D so they will pop out together.
  
  A way to fix this would be to yank all of the IANA stuff and put it
  in 5102bis. Then this document simply instruct the IE-doctors to
  ensure the IANA allocation requests match the rules.
  
  ---
  
  Section 4
  
     o  The Information Element MUST be unique within the registry.  Its
        description MUST represent a substantially different meaning from
        that of any existing Information Element.  A proposed Information
        Element which is a substantial duplicate of an existing
        Information Element is to be represented using the existing
        Information Element.
  
  Surely this is too subjective. What does "substantially different"
  actually mean? I tried to rewrite this for you in terms of data type,
  units, and range, but I think that is probably only a part of what you
  are talking about. For re-use of an existing Information Element you
  presumably need those three parameters to be the same, *and* some other
  quality has to be the same.
  
  Depending on the description being similar seems really doubtful. Can
  you clarify this?
  
  ---
  
  Section 4
  
     o  The Information Element SHOULD contain minimal internal structure;
  
  Do you mean "minimal". I suppose you use this in the meaning "the least
  possible".
  
  Given the existence of parallel export and Structured Data, is there any
  reason not to interpret this statement as: you must only use a single
  Abstract Data Type.
  
  Of course, you may be attempting to also control the definition of new
  Abstract Data Types, but if so, you probably ought to call that out.
  
  ---
  
  Section 4
  
     o  The Information Element SHOULD be generally applicable to the
        application at hand, which SHOULD be of general interest to the
        community.
  
  I find this a bit worrying. What are you saying about proposals from
  outside the IETF? How is the "general interest to the community" to be
  measured? Are the designated experts called upon to call consensus?
  
  ---
  
  Section 4.3 defines rules for IANA Allocation of code points. Including
  notes on the ranges. Is it your intention that the registry is updated
  to point to this document? If so, you should make that statement in the
  IANA considerations section.
  
  On the other hand, this seems to be a restatement of what is already in
  the registry, so I wonder whether the section can be left out.
  
  ---
  
  Doesn't Section 11 give rise to some additional rules that are not
  captured in the body of the document and (importantly) not in the
  checklists of Section 7?
  
  ---
  
  Section 12
  
  Do you need to tell IANA how to populate the Revision and Date fields in
  the IE registry for IEs that have already been defined?

• Adrian Farrel: Comment [2012-09-26 16:22]:
  

  Just to let the shepherding AD know that it isn't very nice to find:
  
     Capitalized terms used in this document that are defined in the
     Terminology section of [I-D.ietf-ipfix-protocol-rfc5101bis] are to be
     interpreted as defined there.
  
  when the referenced I-D is not yet stable enough to receive a
  publication request. Nothing the authors can do except realise that any
  change to the referenced document may break this document.
  
  ---
  
  The use of 2119 language seems entirely inappropriate to me. There is
  nothing to be implemented and no bits on the wire. The designated
  experts are humans not machines - speak to them in English!
  
  ---
  
  Section 3, while providing a useful refresher on IPFIX seems to be out
  of scope for the document. It could be entirely removed without harming
  the document.
  
  ---
  
  Section 4.1
  
     o  Names of Information Elements SHOULD be descriptive.
  
  Why on earth do you want to allow non-descriptive names?
  
  ---
  
  Section 4.2
  
     Information Elements of type string or octetArray which have length
     constraints (fixed length, minimum and/or maximum length) MUST note
     these constraints in their description.
  
     The type of an Information Element MUST match the type of the data it
     represents.  More specifically, information that could be represented
     as a string, but which better matches one of the other data types
     (e.g. an integral type for a number or enumerated type, an address
     type for an address) MUST be represented by the best-matching type,
     even if the data was represented using a different type in the
     source.  In other words, an IPFIX application that exports Options
     Template Records mapping IP addresses to additional information about
     each host from an external database MUST use Information Elements of
     an address type to represent the addresses, even if the source
     database represented these as strings.
  
  Do you need to say that strings and octetArrays must not be used to
  encode data that would be more properly encoded in other data types
  perhaps using multiple information elements with a forward pointer to
  Section 4.5?
  
  ---
  
  Section 4.3
  
     In general, when adding newly registered Information Elements to the
     IANA IE registry, IANA SHOULD assign the lowest available Information
     Element identifier (the value column in [iana-ipfix-assignments]) in
     the range 128-32767.
  
  What does "in general" mean and how is IANA to interpret it?
  
  ---
  
  Section 4.9
  
     However, for reasons of history,
     there are several Information Elements within the IANA IE registry
     which do not follow best practices in Information Element design.
     These Information Elements are not necessarily so flawed so as to
     require deprecation, but they should be explicitly ignored when
     looking for guidance as to whether a new Information Element should
     be added.
  
  Now, I know the experts are experts, and it is completely obvious to
  them which IEs don't follow best practices, but the poor fool building
  a new spec is being asked for a rock. Can you not list the IEs that
  should be ignored?
  
  ---
  
  Section 6
  
     Due to the limited number space of Information Elements in the IANA
     IE registry, avoiding redundancy and clutter in the registry is
     important in defining new applications.
  
  Nah!
  I agree that avoiding redundancy and clutter are a good idea, but you
  cannot say that the IE has such limited space that this is the reason.
  Look, you have assigned fewer than 375 out of 32767 identifiers. If it
  fills up in the next 20 years I will buy you a bottle.

• Pete Resnick: Comment [2012-09-26 17:27]:
  

  The abstract tries to jam everything into a single convoluted sentence, and I
  think it ends up being completely unclear. I make a suggestion here, but I'm
  not sure I've captured what needs to be captured. The WG needs to check this:
  
     This document provides guidelines for how to write definitions of new
     Information Elements for the IP Flow Information Export (IPFIX)
     protocol. It provides instructions on using the proper conventions
     for Information Elements to be registered in the IANA IPFIX
     Information Element registry, and provides guidelines for expert
     reviewers to evaluate new registrations.
  
  I'll leave it to the authors to rewrite section 1 along the same lines. In
  section 1.1, I think you specifically need to mention people who write new IEs
  and *not* talk about "extending the applicability of IPFIX", as that confused
  the issue. I also find the use of the word "application" a bit odd here, and
  I've substituted "use case", but if "application" is understood in this
  community, that is fine. So, maybe something like:
  
     This document is meant for two separate audiences. For those wishing
     to write new Information Element specifications, it provides
     guidelines for how to decide which Information Elements are necessary
     for a given existing or new use case, instructions for writing the
     Information Element specification to be registered, and information
     on the kinds of documentation that will be required for the use case
     (up to and including publication of a new RFC). For the IPFIX
     experts...
  
  2. Regarding 2119: I agree with Adrian that the use of 2119 language in this
  document is wrong, and verges on downright silly. This document is not talking
  about protocol requirements, or even documentation requirements that need to be
  followed for interoperability purposes. So for instance, section 4.1 says,
  "Information Element Names should be defined in accordance with section 2.3 of
  [I-D.ietf-ipfix-information-model-rfc5102bis]" and then goes on to give some
  conventions as MUSTs and SHOULDs. But if we look at
  ietf-ipfix-information-model-rfc5102bis, we find:
  
     The following naming conventions were used for naming Information
     Elements in this document.  It is recommended that extensions of the
     model use the same conventions.
  
  So even the MUSTs are not requirements, but recommended naming conventions for
  extensions. I really think you should get rid of all of the 2119 language.
  
  That said, you'll note that this is in a COMMENT. I think for the most part,
  while useless and silly (it sounds like you are trying to be protocol police),
  using 2119 in this document is generally not harmful. I am most worried about
  the use of 2119 to control IANA actions (e.g., 4.3), but even there, disaster
  is unlikely. So I do beg with you to revisit your decision to use 2119 in this
  document; I think it adds nothing and detracts from the understanding of 2119
  in other documents. But I will not insist on DISCUSSing this with the IESG.

• Barry Leiba: Comment [2012-09-26 16:09]:
  

  The beginning of the document, through the beginning of Section 3 (end of page
  5), very strongly smells like an Applicability Statement, which should be on
  Standards Track.  Completion of review and further discussion supports BCP, but
  it will help to clarify the text up to page 5.  Pete has promised specific
  comments for that, so I'll leave them to him, but I'm happy to help with it as
  well.

• Stewart Bryant: Comment [2012-09-26 07:54]:
  

  Thank you for addressing my concerns.

draft-ietf-isis-mi

• Pete Resnick: Comment [2012-09-23 08:51]:
  

  +1 to Barry's comment: Good usage of 2119. Just one comment along those lines:
  
  2.4:
  
     The following sub-sections describe the additional rules
     an MI-RTR MUST follow when establishing adjacencies.
  
  I think this might be confusing to implementers. The next subsections contain
  one "SHOULD NOT" and some other guidance, but it's not clear what protocol
  requirement (i.e., "MUST") an implementer is REQUIRED to follow. I suggest
  replacing the sentence with:
  
     The following sub-sections describe additional procedures
     to follow when an MI-RTR establishes adjacencies.
  
  There are a few instances of your caps-lock key getting stuck. :-)
  
  In 2.1, change "BE" to "be" in two places.
  In 2.6.2, change "NOT" to "not" in two places.

• Barry Leiba: Comment [2012-09-18 06:04]:
  

  A couple of non-blocking comments, which I'd like the authors to please
  consider (and chat with me about if it helps):
  
  You have isis-genapp as a normative reference, but the only citation of it is
  as an example use case in the introduction.  Why is it normative?  If it is,
  shouldn't there be a citation when the normative bit comes up later?
  
  -- Section 2 --
  
     This MAY
     also imply IID/ITID specific routing calculations and IID/ITID
     specific routing and forwarding tables.  However, this aspect is
     outside the scope of this specification.
  
  I think this is not a 2119 "MAY" (one huge clue is the second sentence).  I
  suggest changing it to "might".  Kudos on what seems to be very crisp use of
  2119 language in the rest of the document.
  
  -----
  And, finally a totally trivial point: the last paragraph of the introduction
  says this:
  
     The above are examples of how MI-IS-IS might be used.  The
     specification of uses of MI-IS-IS is outside the scope of this
     document.
  
  That seems self-contradictory.  How about "Full specification of uses..."?

• Sean Turner: Discuss [2012-09-26 17:11]:
  

  s2.3: I'm curious if authentication is used on one ITID MUST it be used on all?
   I could read the last sentence as:
  
  If authentication is used then all ITID MUST also use authentication, but
  different authentication methods can used on the ITIDs but it's never no
  authentication. or Different ITIDs can have different authentication mechanisms
  (i.e., some have none some use 5304).

draft-ietf-krb-wg-kerberos-referrals

• Sean Turner: Comment [2012-09-27 07:29]:
  

  FAST is SHOULD in s6 but MUST in s11?  Which is it?
  
  s6: as noted by Tom, please add SIZE() around the (1..MAX).
  
  s11: I know you know EncKDCRepPart is defined in 4120 and I found it there too,
  but a pointer there would be nice.
  
  App A: To what version does current refer:
  
   In Microsoft's current implementation through the use of global
   catalogs any domain in one forest is reachable from any other domain
   in the same forest or another trusted forest with 3 or less
   referrals.

draft-ietf-krb-wg-camellia-cts

• Russ Housley: Comment [2012-09-23 15:14]:
  

    The Gen-ART Review by Joel Halpern on 13-Sept-2012 makes two
    suggestions to improve the document:
  
    1.  The document seems to use "random2key" (in section 3) and
    "random-to-key" (in section 4) to represent the same thing,
    apparently meaning the "random-to-key" function of section 6.
  
    2.  Section 6 defines Ki in a different way than section 4.
    Section 4 apparently uses K0 and Ki to mean K(0) and K(i) for
    the iteration.  (And then in the next line uses K1, K2, ... Kn
    for these, without parens.) But section 6, Ki is for a specific
    value in the encrypt/decrypt functions.  The simple solution
    would seem to be to consistently use parenthesis in section 4.

• Adrian Farrel: Comment [2012-09-27 04:15]:
  

  I've cleared my Discuss after reading email from Ken Raeburn as designated
  expert.
  
  However, Ken made a number of comments (captured below) that you may want to
  consider for a revised version...
  
  > It might help to explicitly call out RFC3962 as the reference
  > to use for the CTS description in section 6 where "CBC-CTS mode"
  > is mentioned, as a couple different approaches have been discussed
  > for handling the case where the plain text is a multiple of the
  > block size.  (Do you swap the last cipher text blocks for
  > consistency with the non-multiple case regardless of how full the
  > last block is, or is the "stealing" only a fix for handling non-
  > multiple cases and normal CBC should be used otherwise?  We went
  > with always swapping, as done in RFC 2040 as well.)  My vague
  > recollection is that it wasn't always clear from the various
  > descriptions of CTS that you could find on the net at the time
  > which way it should go, but I haven't looked into the matter in a
  > long time.  It's probably best to discourage the reader from going
  > and looking up CTS definitions from other, vague sources and
  > possibly drawing different conclusions; if we want them to do the
  > same as we do for AES, just point them at the AES spec.  The only
  > other link between CTS as used here and RFC 3962 is in the
  > introduction where the AES encryption types are mentioned, which
  > may not be a strong enough link.
  >
  > Just adding "[RFC3962]" after the first use of "CBC-CTS mode" there
  > should be adequate.
  >
  > That's the only thing I'd bring up with my designated-expert hat on
  > -- a minor issue of clarity and interoperability, and I could
  > possibly be convinced that it's clear enough already.
  >
  > But as long as I'm going over the document, a couple of very minor
  > editorial points:
  >
  > Section 6 is called "Kerberos Algorithm Protocol Parameters" and
  > section 7 is called "Checksum Parameters", but both are for Kerberos,
  > and the first is for an encryption algorithm specifically.  I'd
  > suggest using something like "Encryption Algorithm Parameters"
  > (dropping "protocol" too) and "Checksum Algorithm Parameters",
  > perhaps with "Kerberos" on the front of both, or not...
  >
  > Appendix A has the "author" (singular) acknowledging people for
  > reviews and feedback but no contributions of text, and in the
  > Author's Address section, Greg is listed as "editor" and no other
  > names are given.  Is Greg the only author, in which case he doesn't
  > need to be describe as "editor"?  Should some people be acknowledged
  > for text contributions too?

• Sean Turner: Comment [2012-09-27 07:26]:
  

  From the secdir review:
  
  As noted by Russ: is it random-to-key or random2key in s3/4?
  
  In s4, please reference section 6 for random-to-key and RFC 3961 for k-truncate
  as well
  
  In s3, what's the format for the string-to-key.
  
  Encryption and decryption description in section 6 seems a little incomplete. 
  In particular the setting of newstate seems to be missing in the encryption. 
  In the decryption perhaps you should define how newIV is determined.

draft-ietf-nea-asokan

• Adrian Farrel: Comment [2012-09-26 14:21]:
  

  The third sentence of the Introduction is an apparent non sequitur. It
  would be nice if some context was given to the statement.
  
  ---
  
  Section 5
  
     1. Protocols should make use of cryptographic binding, however
       binding identities of the tunnel endpoints in the EMA may be
       useful.
  
  This is hard to parse. Is there an "also" missing from the second
  clause?

• Martin Stiemerling: Comment [2012-09-25 06:11]:
  

  I have one point requiring clarification:
  
  Section 2, paragraph 1:
  
  >    The NEA Asokan Attack is a variation on an attack described in a
  >    2002 paper written by Asokan, Niemi, and Nyberg [1]. Figure 1
  >    depicts one version of the original Asokan attack. This attack
  >    involves tricking an authorized user into authenticating to a decoy
  >    AAA server, which forwards the authentication protocol from one
  >    tunnel to another, tricking a AAA server into believing these
  >    messages came from the attacker and granting access to him.
  
    Shouldn't it read that the 'believe that messages came from the user,
    but granting access to the attacker'?

• Stewart Bryant: Comment [2012-09-25 05:59]:
  

  I had no idea what a Network Endpoint Assessment was, until I stumbled on the
  reference to RFC5209. It would be a good idea to move the reference up to the
  first line of the Introduction.
  
  I kept meeting PT, but has no idea what that was until I found it in RFC5209. A
  sentence earlier in the text would be useful.