IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2013-07-11. These are not an official record of the meeting.

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

Corrections from:

1 Administrivia

1. Roll Call 1134 EDT Amy:
• Jari Arkko---yes
• Richard Barnes---yes
• Stewart Bryant---yes
• Gonzalo Camarillo---yes
• Benoit Claise---yes
• Michelle Cotton---yes
• Spencer Dawkins---yes(10 minutes late)
• Adrian Farrel--- regrets
• Stephen Farrell---yes
• Heather Flanagan--- (30 mins late)
• Sandy Ginoza---yes
• Brian Haberman---yes
• Joel Halpern---yes
• Susan Hares---yes
• Russ Housley---yes
• Joel Jaeggli---yes
• Barry Leiba---yes
• Ted Lemon---yes
• John Leslie---yes
• Cindy Morgan---yes
• Ray Pelletier--- regrets
• Carlos Pignataro---yes
• Pete Resnick---yes
• Martin Stiemerling---yes
• Sean Turner---yes
• Amy Vezza---yes
2. Guests:
• Juergen Quittek---
3. Bash the Agenda
• No changes
4. Approval of the Minutes of the past telechat
• June 27 minutes---No objections -- Approved
• June 27 narrative minutes---No objections -- Approved (revised as they came on today)
5. Review of Action Items from last Telechat
• Amy: Pete AI preservation of mail archives
• Pete: That one is still in progress
• Amy: Second Action propose text for the general description of the IESG for the position description provided to NomCom
• Pete: That one is done

2. Protocol Actions

2.1 WG Submissions

[Scribe Note: Late agenda bash swapping the first two items in 2.1.1]

2.1.1 New Items

• Message Header Field for Indicating Message Authentication Status (Proposed Standard)
  draft-ietf-appsawg-rfc5451bis [txt]
  Token: Barry Leiba (app area)
  Discusses/comments [ballot]:
• Ted Lemon: Comment [2013-07-10 20:29]:
  Throughout the document, the term 'this header field' and 'the header field' is used to refer to the Authentication-Results header field. This isn't very user friendly—I keep wondering if the antecedent has changed. Once it's clear to the reader what the document is about, I think this is less of an issue, but it made starting to read it kind of painful. I think it would be more friendly to say 'the authref header field' each time, even though it's an extra word. I realize that this is a fairly minor cognitive load for the reader, but when it comes to even minor cognitive loads, less is more.
  In 2.5.7:
  "Extension results MUST only be used within ADMDs that have explicitly consented to use them."
  Wouldn't it be better to say:
  "Extension results MUST NOT be used within ADMDs that have not explicitly consented to use them."
  I suggest this because 'MUST only' is not an RFC 2119 key word, but I think you mean the two words together to be normative. It's understandable either way, so this is a minor nit, but take it for what it's worth.
  From section 5:
  "For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. It may also invalidate signed messages whose signatures cover external instances of this header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing all others."
  Although this alludes to the problem of breaking DKIM, for example, it doesn't fully address it. A DKIM message may be signed in a way that can be validated, and yet not come from a trusted external service provider. If the DKIM signature includes an Authentication-Results header, removing it will break the signature, preventing the MUA from validating it. This seems like a big loss of functionality, since the end user doesn't have a way of opting out of this breakage.
  This could be easily mitigated by changing the name of the header field rather than removing it: change it to Elided-Authentication-Results or something. Then the MUA can reverse that and calculate the DKIM signature.
  I realize that this may be a non-issue in practice. I haven't seen a DKIM signature that signed an Authentication-Results header, and maybe it just never happens. But this seems so easy to fix that it ought to be worth the minor effort involved.
• Stephen Farrell: Comment [2013-07-09 09:53]:
  - note to RFC editor in the abstract I guess needs changing now that this is going for PS
  - intro: Are ADSP and VBR really in common use?
  - 1.6: you say valid use 'requires removing' this when the message first arrives in the ADMD. I think that'd be better as a 'MUST remove' but is clear enough. (Section 5 has a MUST btw, though also allows for not removing messages you get *directly* from a 'trusted' peer. Is 'directly' there really verifiable in general?)
  - 1.7: I guess this is changed by the new PS target.
  - 2.3: You say MUAs SHOULD use the authserv-id field to determine whether to use or ignore the header field. That's unchanged since 5451 but I wonder if it'd be better to say that MUAs need to have a whitelist or similar of values that are ok for this? What's actually done here? (This isn't a discuss since its the same in 5451.)
  - 2.4 and 2.5.7: I think I agree that adding these means that cycling at PS is correct.
  - section 4, 2nd last para: has a new SHOULD NOT that seems sensible - but I wondered why this was a SHOULD NOT and not a MUST NOT? I can't think of a case where an AR is better containing stuff that the MUA can't see. If there are such cases, maybe mention one. Or maybe I've misinterpreted the text? (It is a bit hard to get.)
  - section 7: Thanks!
• Barry Leiba: Comment [2013-07-09 07:35]:
  Because of the changes being made in the document, I'm changing the target status to Proposed Standard, and it's likely to be presented in six months or so for upgrade to Internet Standard.
• Spencer Dawkins: Comment [2013-07-08 17:36]:
  I am sympathetic to Pete's DISCUSS on advancing to full standard while making incompatible changes, but I'll let you folks hash that out - it wouldn't affect my ballot position either way.
  I found this specification clear and especially appreciated the context in sections like Operational Guidance.
  I had some non-blocking comments that I'd ask you to consider along with other comments you might receive.
  In 1.1. Purpose
  "In particular, the mere presence of this header field SHOULD NOT be construed as meaning that its data is valid, but, rather, that it is reporting assertions made by one or more authentication schemes applied somewhere upstream."
  This doesn't look like a 2119 SHOULD NOT to me ... are you saying something like 'the mere presence of this header field doesn't mean that its data is valid'?
  In 1.5.2. Security
  "By contrast, DKIM is agnostic as to the routing of a message but uses cryptographic signatures to authenticate agents claim (some) responsibility for the message (which implies authorization) and ensures that the listed portions of the message were not modified in transit."
  This sentence isn't parsing for me. Missing word, perhaps?
  In 2.5.1. DKIM and DomainKeys
  "neutral: The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed. This result SHOULD also be used for other failures not covered elsewhere in this list."
  I don't think this is an RFC 2119 SHOULD, but my larger point is, if you encounter a failure that's not covered in this list, what other choice is there? (Return no result? return the wrong result?)
  In 6.2. Email Authentication Method Name Registry
  "Each method must register a name, the specification that defines it, a version number associated with the method being registered (preferably starting at '1'),"
  this 'preferably' is Mostly Harmless, but I'd think if the intent was to avoiding confusing the reader, you'd be better off mandating that. 'Preferably' seems to say 'you could *probably* trust that version 5 isn't the first version, but you can't know that for certain'.
  A couple of paragraphs down,
  "IANA is also requested to add a 'version' field to all existing registry entries. All current methods are to be recorded as version '1'."
  seems to mandate starting at '1' for existing methods, so I'm confused why new methods might not begin with version '1'.
• Brian Haberman: Comment [2013-07-08 12:16]:
  Cool to see the Implementation Status section...
• Stewart Bryant: Comment [2013-07-03 08:38]:
  I missed the note that section 7 is to be deleted.
• Sean Turner: Comment [2013-07-09 09:20]:
  I hate to slow down progression of this to IS, but I do agree with Pete's assertion that this probably needs to recycle based on the number of changes.* (I'll note Barry's already said he's going to make it cycle so no action but thought I should be on record)
  How does this draft seemingly get away with not normatively referencing the authentication methods? On the one hand, I can see the argument that this protocol merely copies information from another protocol to a field and then sends it on its way back to the originator. On the other hand, doesn't the creator of the report need to understand the various authentication mechanisms to know what result to send back? And please don't get me wrong, I don't want to hold publishing this up based on this comment - I'm just curious.
  * the diff tool worked nicely here comparing the original rfc and the bis.
• Telechat:
• Amy: It was version 09, now it is version 10. I had an open position from Richard -- no, I do not.
• … no DISCUSSes in the tracked. Unless objections, this is approved
• Barry: We are still talking about stuff. 
• Amy: OK, thanks, will move it to Point Raised.

• Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Internet Standard)
  draft-ietf-ipfix-protocol-rfc5101bis [txt]
  Token: Joel Jaeggli (ops area)
  IPR: Cisco's Statement of IPR Related to draft-ietf-ipfix-protocol-rfc5101bis-03
  Discusses/comments [ballot]:
• Ted Lemon: Discuss [2013-07-09 16:21]:
  I see a lot of cases of definitions for attributes of option templates where the text defining the attribute has been removed since RFC5101, and [IANA-IPFIX] is given as a reference where the definitions can be found. For example in section 4.3, the definitions for notSentFlowTotalCount, notSentPacketTotalCount and notSentOctetTotalCount.
  This seems really weird to me. If the text is identical in the document and in the registry, it's certainly fair to say that this is redundant. But the way I would be inclined to address the redundancy would be to keep the text in the IETF standard, and abbreviate the text in the registry, pointing the registry back at the document. The IANA registry is not a standard—it's a living document, which can change over time, so the explanatory text in it can likewise change over time. It probably _won't_, but I think relying on that is a bad idea.
  To clear this DISCUSS, you would need to give a satisfactory explanation as to why it makes sense to move normative text out of this document into the IANA registry, or you could restore the text to this document, or you could point out another IETF standard that also contains the definitions (and perhaps change the reference in this document to point to that one, rather than to the IANA registry). Or you could get the other ADs to gang up on me and tell me I'm making a fuss over nothing. :)
• Ted Lemon: Comment [2013-07-09 16:12]:
  The document uses the term 'treatment,' I think as a term of art, but it results in some constructs that are hard to parse, like this one in section 2, Page 8, about halfway down:
  "As sampling is a packet treatment, this definition includes packets selected by a sampling mechanism."
  It might help to add a terminology section on 'packet treatment.' However, this depends on the target readership, so I'm by no means demanding that such a section be added; simply suggesting it based on the fact that I stumbled over the term when reading the document.
  It seems unnecessary to repeat 'network byte order (also known as big-endian byte order)' throughout the document. It might be better to just say 'network byte order (also known as big-endian byte order)' the first time, and just 'network byte order' subsequently.
  In 6.1.3 and 6.1.4, the floating point format is specified as IEEE 754 in network byte order. IEEE 754 doesn't specify a network byte ordering for floating point numbers. I think the encoding is fairly straightforward, but I am not convinced that a reader of this document who did not already know what IEEE 754 encoding in network byte order means would be able to figure it out. It would help to have a reference here to a document that defines what 'network byte order' means here, or just a quick statement about how the bytes are arranged.
  In 8.2, there's a paragraph that's supposed to clarify the applicability of templates to data records that's got such a big parse stack it left my head spinning. I propose the following change:
  OLD: Put another way, a Template describes Data Records contained in IPFIX Messages with an Export Time between the Export Time of the IPFIX Message containing the Template Record and either the Export Time of the IPFIX Message containing the Template Withdrawal withdrawing it or the end of the Transport Session, inclusive.
  NEW: Put another way, a Template describes Data Records contained in IPFIX messages when the export time of such messages is between a specific start and end time. The start time is the Export Time of the IPFIX Message containing the Template record. The end time is one of two times. If the template is withdrawn during the session, then it is the Export Time of the IPFIX message containing the Template Withdrawal for the template. Otherwise, it is the end of the Transport Session.
  In the last paragraph of the first part of section 9, the text does not mention the handling of a malformed message in the case of TCP transport. I think in this case there is no way to resynchronize, because it's impossible to characterize the error that caused the malformed message. That being the case, doesn't the TCP connection have to be dropped when a malformed message is encountered? Shouldn't this be mentioned either in Section 9 or Section 10.4?
  Overall this update to RFC 5101 looks like a significant improvement. Thanks for doing it!
• Adrian Farrel: Comment [2013-07-07 14:00]:
  I hate the idea of tit-for-tat Discusses and will not raise one. However, having recently seen a number of Discusses entered on documents saying that insufficient attention had been paid to RFC 5706 and the manageability issues and impacts for protcols, I must observe that this document is considerably lacking in that department. I looked for, but could not find an existing RFC providing a management framework for IPFIX although I do notice that a MIB module exists. Maybe RFC 5153 is supposed to cover this, but on a brief skim it does not seem to give much information about how IPFIX is managed.
  Please note that just because IPFIX is, itself, a management protocol does not mean that the impact that the impact on te network of its use should not be considered. Indeed, there are considerable concerns about how IPFIX could impact a live network. Furthermore, IPFIX needs to be managed, operated, and diagnosed in its own right, and that bears description.
  I leave it to the sponsoring AD and document editors to examine why they are comfortable to progress this document without this material.
  Section 8.4
  "Default settings for these values are deployment- and application-specific."
  I.e., there are no default settings?
• Stephen Farrell: Comment [2013-06-10 10:01]:
  - I mostly used the diff to 5101 for this review.
  - In section 8, you have new text saying that the CP MUST store all template record information for the duration of each transport section. I wondered if that creates any potential for a DoS?
  - Is all the naming stuff in 11.3 fully worked out and likely to be, or actually, implemented? E.g. it says that use of DNS-ID is a SHOULD be implementaton of CN based lists is a MUST - does that make sense really? v- You say: SSL/TLS before TLS1.1 is a MUST NOT, TLS1.1 is a MUST and TLS1.2 is a SHOULD. Would it not be better to just say TLS1.2 is a MUST? Perhaps TLS1.2 support is (soon) more likely to be widely available for this kind of application - did you check recently? (I didn't, and [1] is a year old now.)
  [1] http://www.imperialviolet.org/2012/06/08/tlsversions.html
  - I wondered if its possible to analyse network timing to try to discover what kind of IPFIX collecting is going on, for example, via timing analysis. Since I don't know, I'm not asking that you add something to section 11, but I do wonder:-)
• Martin Stiemerling: Comment [2013-06-11 07:12]:
  In support of Spencer's DISCUSS point
• Spencer Dawkins: Comment [2013-06-11 12:54]:
  Brian provided explanations and text proposals (following), and these proposals address my DISCUSS (cleared) and all but one of my comments.
  On the #3 text proposal below ... we're talking about an Observation Domain using a single TCP connection, is that correct?
  If an OD sends a TCP stream that looks like this (each observation is transmitted as a separate IP packet)
  - Observation 1
  - Observation 2 (assume this one gets lost in the network)
  - Observation 3
  - Observation 4
  - Observation 5
  TCP guarantees in-order delivery, so the sending TCP will retransmit Observation 2 tenaciously, and the receiving TCP holds everything it receives after Observation 2 until it can deliver the retransmitted Observation 2. The Collecting Process won't see Observation 3 until after Observation 2 is successfully transmitted.
  If two Observation Domains, 'a' and 'b', are sharing a single TCP connection, and the interleaved TCP stream looks like this:
  - Observation a-1
  - Observation a-2 (assume this one gets lost in the network)
  - Observation a-3
  - Observation b-1
  - Observation b-2
  - Observation b-3
  - Observation a-4
  - Observation b-4
  - Observation b-5
  - Observation a-5
  the in-order delivery guarantee spans Observation Domains, so not only does the receiving TCP hold everything for Observation Domain 'a' until it receives Observation a-2, it holds everything for Observation Domain 'b', because all of these observations are being blocked by the same head of line problem with the same TCP connection.
  So in this proposed text:
  "Exporting Processes may choose IPFIX Message lengths lower than the maximum in order to avoid head-of-line blocking and/or to ensure timely export of Data Records."
  I think you can minimize head-of-line blocking, but I don't think you can avoid it.
  Maybe minimizing head-of-line blocking is OK (the Collecting Process is, after all, not a human, so I'm not sure why it would care about head-of-line blocking, as long as it sees reliable in-order delivery in the fullness of time), so I don't want to be difficult, but I did want to try to explain better what I was trying to say.
  From Brian:
  To summarize, I suggest the following changes to the document to address this DISCUSS and COMMENT:
  (1) NEW definition for Sequence Number in Section 3.1 (s/SHOULD/can/):
  "Sequence Number: Incremental sequence counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process. Each SCTP Stream counts sequence numbers separately, while all messages in a TCP connection or UDP transport session are considered to be part of the same stream. This value can be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number."
  (2) NEW Section 10.2.5. Failover (in 10.2 SCTP) (clarify failure detect by lower-layer timeout):
  "If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish an association, SCTP will automatically retry association establishment using exponential backoff. The Exporter MAY log an alarm if the underlying SCTP association establishment times out; this timeout should be configurable on the Exporter.
  "The Exporting Process MAY open a backup SCTP association to a Collecting Process in advance, if it supports Collecting Process failover."
  (3) NEW Section 10.4.3. MTU paragraph 2 (remove confusing head of line blocking language):
  "Exporting Processes may choose IPFIX Message lengths lower than the maximum in order to avoid head-of-line blocking and/or to ensure timely export of Data Records."
  (4) NEW Section 10.4.4. Connection Establishment and Shutdown first two paragraphs:
  "The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). An Exporting Process MAY support more than one active connection to the same Collecting Process to avoid head of line blocking across Observation Domains.
  "The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter."
  (5) NEW Section 10.4.5. Failover (in 10.4 TCP) (clarify failure detect by lower-layer timeout):
  "If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, TCP will automatically retry connection establishment using exponential backoff. The Exporter MAY log an alarm if the underlying TCP connection establishment times out; this timeout should be configurable on the Exporter.
  "The Exporting Process MAY open a backup TCP connection to a Collecting Process in advance, if it supports Collecting Process failover.
• Sean Turner: Comment [2013-06-10 12:45]:
  Should probably say something about the version of DTLS you want supported in s11.3 or is that covered in s11.1?
  Do you need to up the SHOULD in RFC 6347 about the cookie exchange to a MUST?
• Joel Jaeggli: Comment [2013-07-05 15:29]:
  The opsdir review of the latest draft is extensive...
  Thanks sue for doing it
  (see link)
• Telechat:
• Amy: This document version -09, going for Standards Track, Joel is our Token
• Juergen: In the DISCUSS, the issue is how we handle IE for IPFIX. The number is going to be big so we change how we do IE with IANA and in the RFCs we had a Template on what needs to be specified so we implemented the same with IANA. What we have in IANA is the same as we had in the past. I think that was the point that was not considered to be appropriate here, right?
• Ted: One of the ADs, I cannot remember, 
• Juergen: Probably Ben in the past
• Ted: Well, supposedly there was a discussion earlier, but it is interesting because we have standards language that does not appear in RFCs but does appear in an IANA registry and is Normative. That's not normal use of an IANA registry as it usually appears in two places and the document is Normative and the IANA registry reflects the doc. This is different because what was into IANA is some text and not a code point, and the text in the registry is normative, but the normative text is not reflected in the RFC, which is the standard. That is the difference that triggered my DISCUSS. Does anybody else think it is weird?
• Joel: From my perspective, the text is descriptive and that's why it is in the registry. I do not think it's...
• Juergen: It is an advantage for any developer that wants to use it because the info all there in IANA.
• Ted: I understand that benefit. The question is where the standard lives, do we have a standard or have we gotten rid of it?
• Joel: If we say the Description field is informative and not normative, does that change?
• Ted: Could
• Pete: Question because I did not understand. What goes in the registry, does it define the field of affect protocol?
• Ted: Yes, what goes in the registry affects the protocol.
• Benoit: I've been silent because I am co-author but I can clarify. The discussion happened already and what we see here is a consequence of 5102bis, and the registry became normative already.
• Stewart: To Ted's point, there is no protocol in the registry, it is the definition of a field
• Ted: so if you remove it you can use the protocol?
• Stewart: Yes, it would not be an interesting protocol.
• Ted: You can implement the protocol without ever referring to IANA.
• Ted: As far as Benoit's point, I looked at the discussion on the previous document, and did not see this. If no one else sees an issue I won't hold the document. But I do think that we have RFC text in an IANA registry and not in an RFC
• Juergen: But we are just using the field
• Ted: Am I correct no one sees an issue?
• Joel: I am sponsoring and I do not see an issue
• Ted: I will clear the discuss. I will change it to an Abstain so that you understand
• Joel: I can live with that.
• Benoit: We need to make some changes and are waiting on something from the security directorate
• Joel: Also the non-DISCUSS management criteria.
• Juergen: That's true.
• Benoit: Use a new "manageability considerations" section on that one.
• Joel: We have suggested text that hopefully satisfies Adrian/<someone>. I think it makes the document better. I think that is an improvement, consolidating sections. If people trust me to take this doc and solve issues with the authors then we can move on.
• Amy: Ted  from Discuss to Abstain. Means will be no DISCUSSes, therefore goes into Approved but will need a Revise ID, right?
• Joel: Yes, revised ID needed.
• Amy: OK,  Approved - revised id needed.
• Juergen: dropping off at 11:54am
• Benoit: Actually you can stay.
• Juergen: I won't follow the discussion without the doc. Will drop off.

2.1.2 Returning Items

• Constrained Application Protocol (CoAP) (Proposed Standard)
  draft-ietf-core-coap [txt]
  Token: Barry Leiba (app area)
  Discusses/comments [ballot]:
• Ted Lemon: Comment [2013-04-24 20:32]:
  >P. 14: informative reference to HHGTG almost, but not entirely, helpful. :)
  P. 15: why start at version 1 when you can only have a total of 4 versions? Wouldn't version 0 be a better choice?
  P. 19: I'm a little uncomfortable with this text:
  "There is no expectation and no need to perform normalization within a CoAP implementation (except where Unicode strings that are not known to be normalized are imported from sources outside the CoAP protocol)."
  I think what's intended here is right, but you've mentioned what amounts to a strong suggestion, if not a requirement, as a parenthetical note. It seems like what you intended was something like this:
  "There is no expectation and no need to perform normalization within a CoAP implementation, since senders are expected to be implemented with pre-normalized strings. However, strings received from non-CoAP sources SHOULD be normalized where possible."
  Of course, there's actually no value to normalization in this case if it can't be depended on, and I suspect that you don't want to make that a MUST. So this might be a better way to do it:
  "There is no expectation and no need to perform normalization within a CoAP implementation, since senders are expected to be implemented with pre-normalized strings. Strings received from non-CoAP sources and then forwarded by CoAP senders cannot be assumed to have been normalized, and may not compare correctly with normalized strings representing the same text."
  I don't have a strong opinion about how this should be done, but it seems like the text as written doesn't give clear guidance. It seems that cross-proxies ought to be able to do normalization, and maybe other proxies could as well, but that's a much bigger change.
  Section 4.1: Even though I think it doesn't make any sense to do this, it might be worth stating how a receiver should behave if it receives an ACK with a request.
  Section 4.2: Wouldn't this:
  "More generally, Acknowledgement and Reset messages MUST NOT elicit any Acknowledgement or Reset message from their recipient."
  be better stated this way?
  "More generally, recipients of Acknowledgement and Reset messages MUST NOT respond with either Acknowledgement or Reset messages."
  Might be worth grouping for operator precedence here:
  OLD: ACK_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * ACK_RANDOM_FACTOR
  NEW: ACK_TIMEOUT * (2 ** (MAX_RETRANSMIT - 1)) * ACK_RANDOM_FACTOR
  OLD: 2 * MAX_LATENCY + PROCESSING_DELAY
  NEW: (2 * MAX_LATENCY) + PROCESSING_DELAY
  Section 5.8: The use of the word 'safe' to describe methods is really confusing because of save/unsafe options. It would help ease of comprehension if you used a different word--e.g., read-only. I realize that this goes somewhat against the idea of sharing nomenclature with HTTP, but I think the clash between safe/unsafe options and safe/unsafe methods is confusing enough that you aren't really benefiting from that anyway.
  In 5.9: as a user and implementor of RESTful systems who has learned by doing more than by reading, the term 'action result' is somewhat opaque to me. I think I know what it means, but it might be nice to explain what it means before using it like this:
  "Like HTTP 201 'Created', but only used in response to POST and PUT requests. The payload returned with the response, if any, is a representation of the action result."
  5.9.2.2: I think you mean 'first' rather than 'previously':
  "The client is not authorized to perform the requested action. The client SHOULD NOT repeat the request without previously improving its authentication status to the server. Which specific mechanism can be used for this is outside this document's scope; see also Section 9."
  5.10.1: how does the client know that an endpoint hosts multiple virtual servers in time to leave out the Uri-Host option? Is this literally just in the case where the hostname appears in the URI to be decomposed as an IP address literal?
  "are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers."
  In 5.10.8.2: I can't quite understand what is meant here. I could see it meaning either or both of the following:
  1. If If-None-Match appears in a query with one or more If-Match options, and none of the If-Match options match, the condition is fulfilled.
  2. If If-None-Match appears in a query, no If-Match options may appear in that query; the condition is met if the target doesn't exist.
  I think that the text means just (2), but because of the name of the option, I want it to mean (1), even though the text doesn't say that, and since the text doesn't say that If-None-Match and If-Match are mutually exclusive, I can easily imagine someone reading the text and carelessly assuming that it means (1) or (1 or 2).
  In 6.4, why /url/? This is really confusing--I was halfway through this section, and kind of confused, before I realized that the slashes were for emphasis, and weren't path separators.
  Also in 6.4, the text does not account for the case where there's a user part to the authority section of the URI.
• Adrian Farrel: Comment [2013-04-29 07:34]:
  I want to thank the authors and WG for producing this specification. I think it may be one of the more important pieces of work in recent years. As might be expected with a document of over 100 pages reviewed by a pedant, I have a list of nits and worries. These are all enetered as Comments: I hope you will find time to address them and make the resulting RFC more polished, but none of them comes even close to a requirement that you change the text, and I am ballotting Yes.
  How quickly we forget!
  I looked up the spec of a typical home computer around the time of HTTP v1.0 and discovered that it was not so very different from what you are scoping your environment to today.
  That is not to say that your work is not valid. Far from it! But I do believe it might be helpful to explore in more detail why you don't simply run an early, low-function version of HTTP.
  FWIW, I believe the answer is that you want some of the advanced functions that have been added to HTTP over the years, but do not want the full family of rich features that may chew memory and bandwidth.
  What about the use of CoAP on the wider Internet?
  A very minor terminology point from Section 1.2
  "Confirmable Message: Some messages require an acknowledgement. These messages are called 'Confirmable'. When no packets are lost, each Confirmable message elicits exactly one return message of type Acknowledgement or type Reset.
  Non-confirmable Message: Some other messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor."
  You have picked a form 'confirmable' and 'non-confirmable' tha expresses the ability to do something: this message can be confirmed.
  But you have mapped the form to a description that requires action: an acknowledgement must be sent.
  'Can be confirmed' != 'A confirmation must be sent'
  'Cannot be confirmed' != 'A conformation does not need to be sent'
  I don't believe this is too important because you are defining the tems, but I do think that the casual reader will not embed your redefinitions of normal English words, and so will be confused by these terms in the text.
  Section 1.2. Also a very minor point.
  "Acknowledgement Message: An Acknowledgement message acknowledges that a specific Confirmable Message arrived. It does not indicate success or failure of any encapsulated request."
  The fact that and Acknowledgement Message can carry a response is lost in this definition. Maybe you need (including fixes to your typos)...
  "Acknowledgement Message: An Acknowledgement Message acknowledges that a specific Confirmable Message arrived. Of itself, an Acknoweledgement Message does not indicate success or failure of any request encapsulated in the Confirmable Message, but the Acknoweledgement Message may also carry a Piggy-backed response (q.v.)."
  My feeling was that the Message IDs shown in figures 2 through 6 were confusing in their randomness. For example, you could spend a lot of time staring at figures 2 and 3 trying to work out how CON is encodeded as 0x7d34 while NON is encoded as 0x01a0.
  Since you want to show Message IDs to show how they correspond on different parts of the flow, you could have written, e.g.,                          Client              Server
•                             |                  |
•                             |   CON [MsgID1]   |
•                             +----------------->|
•                             |                  |
•                             |   ACK [MsgID1]   |
•                             |<-----------------+
•                             |                  |
• 
  
  Section 2.1
  "As CoAP is based on UDP, it also supports the use of multicast IP"
  I don't think it is based on UDP. I think it runs over UDP.
  Section 2.3
  "As CoAP was designed according to the REST architecture and thus"
  Maybe insert another pointer to [REST].
  Section 4.2
  "A Confirmable message always carries either a request or response and MUST NOT be empty, unless it is used only to elicit a Reset message."
  That is a bit of an over-use of 'MUST NOT'. I think
  "A Confirmable message always carries either a request or response, unless it is used only to elicit a Reset message in which case it is empty."
  Section 4.2
  "A CoAP endpoint that sent a Confirmable message MAY give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached: E.g., the application has canceled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. In particular, a CoAP request message may have elicited a separate response, in which case it is clear to the requester that only the ACK was lost and a retransmission of the request would serve no purpose. However, a responder MUST NOT in turn rely on this cross-layer behavior from a requester, i.e. it SHOULD retain the state to create the ACK for the request, if needed, even if a Confirmable response was already acknowledged by the requester."
  This paragraph is giving me some worries.
  I think the initial MAY confuses the CoAP implementation with the endpoint containing the CoAP implementation. The endpoint may give up, and may instruct the CoAP implementation to stop retransmitting. But I think a CoAP implementaiton must not give up unless it is told to.
  The drop from MUST NOT to SHOULD in the final sentence seems odd. My understanding was that a CoAP implementation MUST always retain the state to create the ACK for the request. Is this use of SHOULD a relaxation, and how does it square with the MUST NOT?
  Section 4.6
  "Messages larger than an IP fragment result in undesired packet fragmentation."
  s/undesired/undesirable/ ?
  Section 4.6
  "A CoAP message, appropriately encapsulated, SHOULD fit within a single IP packet (i.e., avoid IP fragmentation) and (by fitting into one UDP payload) obviously MUST fit within a single IP datagram."
  s/MUST/will/
  Section 12
  I am surprised that IANA was relaxed about the use of 'reserved' in Section 12.
  For example, in 12.1 you have two ranges marked 'Reserved' without any clue to what this means. For example, does it mean that allocations can be made, that an RFC can dedicate them to a new use, or that they must never be allocated?
  In 12.1.2 you have
  "The Response Codes 96-127 are Reserved for future use. All other Response Codes are Unassigned."
  I take 'Unassigned' to mean available for assignment according to the policy for the registry. But 'Reserved or future use' means what?
  In 12.2 you have
  "| 0 | (Reserved) | |"
  This is the meaning of 'reserved' I think we are used to, and means will not be made available for allocation. (Although I am puzzled that you don't include the pointer to this RFC.)
• Richard Barnes: Comment [2013-05-15 09:06]:
  Overall, this is a very nicely written specification. Thanks!
  In Section 2.2., are requests and responses in 1-1 correspondence? Or can a single request receive more than one response?
  In Section 3, why is version number 1 and not 0? What's the plan here, do we get 3 or 4 versions out of this?
  In Section 4.3, would it make sense to have something stronger than MAY for cases where future messages are likely to be screwed up, e.g., where CoAP syntax is malformed? (A 'STFU RST'?)
  From Section 4.2 and 4.3, I generated a table mapping message types to request/response/empty:             CON NON ACK RST
• Request     X   X   ?   !
• Response    X   X   X   !
• Empty       !   !   X   X    
• 
  
  Might be helpful to include something like that as a summary. This might be a bad idea, but: Did the WG consider allowing an ACK to contain a request? In the case where a CON contains a response and the client wants to send another request, it would save a message to put the request in the ACK to the response.
• Stephen Farrell: Comment [2013-05-26 13:54]:
  Thanks for addressing my discuss points. I've left the comments in below from last time, but didn't check 'em against -17.
  --- former discuss points
  (1) I think you made a change to 5.6 for this but I still think (now at COMMENT level) that it'd be really good to say that CoAP is currently well defined only for URI schemes like coap(s) and http(s) but maybe not others. Basically, you need a scheme://host:port syntax or else you have to do some more specification work to get CoAP interop.
  (3) You now say 'SHOULD use 32 bits of randomness' which is ok. I think it might be worth adding that CoAP nodes that might be targetted with many guesses SHOULD also detect and react to that.
  Text of discuss (3) was: 4.2, last para: this creates an attack that can work from off-path - just send loads of faked ACKs with guessed Tokens and some of 'em will be accepted with probability depending on Token-length and perhaps the quality of the RNG used by the sender of the CON. That could cause all sorts of 'interesting' application layer behaviour. Why is that ok? (Or put another way - was this considered and with what conclusion?) I suspect you need to have text trading off the Token length versus use of DTLS or else CoAP may end up too insecure for too many uses. (Note: the attack here is made worse because the message ID comparison can be skipped. Removing that 'feature' would help a lot here.) 5.3.1's client 'may want to use a non-trivial, randomized token' doesn't seem to cut it to me. How does this kind of interaction map to DTLS sessions/epoch? Basically, I'd like to see some RECOMMENDED handling of token length that would result in it not being unsafe to connect a CoAP node to the Internet. (And please note recent instances where 10's of thousands of insecure devices have been found via probing the IPv4 address space. These are real attacks.)
  (4) 4.4, implementation note - this seems unwise since it means that once Alice has interacted with Bob, then Bob can easily guess the message IDs that Alice will use to talk to Charlie. This is no longer a DISCUSS because you said that the WG figure its ok and given you say to randomise at the start (of what?) then its marginal.
  --- old comments below, sorta checked against -16
  (see link)
• Martin Stiemerling: Comment [2013-07-01 05:36]:
  -18 addresses all of my concerns and thank you for addressing them!
• Jari Arkko: Comment [2013-05-16 06:51]:
  Thank you for this important work and well written specification. While there are aspects that I would personally have done differently and some fine-tuning of the spec could continue, I believe the document is ready to move to an RFC. I also believe it that is a much-awaited spec and very useful to the Internet community in its current state.
  I do agree with some of the points raised in other reviews, and those need to be addressed.
  I did have one specific additional suggestion worth bringing up here. Dan Romascanu did a Gen-ART review and raised the issue that the parameter changes discussed in S4.8.1 are security sensitive, i.e., changes in the parameters may cause security/denial-of-service issues. This should be noted somewhere in the S11. I'd make a brief observation that it is security sensitive and should be addressed in any system that allows configuration of these parameters.
  Here's what Dan wrote:
  3. Section 4.8 defines a number of CoAP protocol parameters and derived parameters that according to 4.8.1 may be changed. Some of these parameters have limitations and their changes may affect the basic functionality of the nodes, the interaction between nodes or between nodes and servers, as well as the functioning in constrained environments. However there is no risk analysis in Section 11 (Security Considerations) about the threats related to mis-configuration of the modes and un-appropriate or malevolent changes in these parameters, and recommendations of security counter-measures on this respect.
• Pete Resnick: Comment [2013-06-28 11:55]:
  Thanks for addressing my more serious concerns. Nothing blocking, but for your consideration:
  By section number:
  4.2/4.3: 'Reject' in the sense it is talked about in these sections is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that 'hears about' the rejection. (It's hard to me to think of a circumstance where someone or something was 'rejected' and only the rejector ever knew about it.) In your use, 'silently ignore' is one possible form of rejection. That's just weird.
  If you're going to do this, I'd define the term up front. Maybe even capitalize 'Reject' wherever you use it.
  Either way, in both 4.2 and 4.3, 'MUST reject' is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and 'MAY involve sending' is a strange construction.
  4.5: I think the MAYs confuse things and might encourage implementers to take that path. Instead of:
  "This rule MAY be relaxed in case the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples for relaxed message deduplication:"
  I suggest: 'Exceptions to this are when the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples of these exceptions:'. Also:
  "As a general rule that MAY be relaxed based on the specific semantics of a message, the recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once."
  I suggest: 'The recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once, though the specific semantics of the message might dictate an exception.'
  4.6: I feel like this section is really one big implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of protocol instructions.
  5.3.2: Change 'the client will likely send a Reset message so it does not receive any more retransmissions' to 'the client will send'. A client that has lost state that receives what it will see as a random CON message will always send back a Reset.
  5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits of the most significant byte so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed.
  5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD.
  8.1:
  "A server SHOULD be aware that a request arrived via multicast, e.g. by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available."
  That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast.
  This also gives a reason not to allow RST on *any* NON messages.
  12.1: I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes.
• Benoit Claise: Comment [2013-05-16 07:25]:
  I lacked some time to review the draft details. However, after a discussion with Joel Jaeggli, and with the OPS DIR review from Mehmet, I trust that the OPS aspects have been taken care of.
• Spencer Dawkins: Comment [2013-05-20 23:12]:
  (see link)
• Brian Haberman: Comment [2013-04-23 08:27]:
  Thank you for a well-written document. I do support Pete's DISCUSS points.
• Stewart Bryant: Comment [2013-04-24 09:12]:
  I am entering no-objection on the basis that this has no impact on the routing layer and I am confident that the applications layer ADs will ensure the quality of the design.
• Sean Turner: Comment [2013-07-08 07:35]:
  Hey thanks for doing an excellent job addressing my comments. Looking forward to progressing this one down the standards track ;)
• Joel Jaeggli: Comment [2013-04-24 22:45]:
  I support some of the points raised by mehmet against draft 13 (addressed by carsten) which ultimately are not likely to be resolved by the this draft alone.
  "** Concerning the migration path, and future versions of CoAP in the same network:
  "- It would be useful to state clearly, in which cases it is dangerous to change any of the recommended default values or parameters in future versions of CoAP and would potentially impact the co-existence of two CoAP versions. Thus such a statement would support an incremental deployment to be successful."
  Again, I believe this is future work, which also applies for the configuration and management data model.
  Protocol debugging is aided by the self-describing nature of the protocol messages. This has worked pretty well in the (informal and formal) interops so far.
  Future work will have to address management interfaces for CoAP nodes, including management of security related events. I think some of this will have to integrate with resource discovery, an active subject in the working group.
  Grüße, Carsten
  this is not a dicuss because frankly I think at some point you have to draw a line under work that has been done so far and progress work from there.
• Telechat:
• Amy: The token is Barry, no DISCUSSes. Unless there's an objection, looks like this doc is approved
• Pause
• Amy: OK, no objections, approved. Ready to go. Approved -- announcement to be sent (to be sent Monday)

2.2 Individual Submissions

2.2.1 New Items

• (none)

2.2.2 Returning Items

• (none)

2.3 Status Changes

2.3.1 New Items

• (none)

2.3.2 Returning Items

• (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

• LISP MIB (Experimental)
  draft-ietf-lisp-mib [txt]
  Token: Brian Haberman (int area)
  Discusses/comments [ballot]:
• Adrian Farrel: Discuss [2013-07-07 14:55]:
  Two relatively small and easy-to-fix Discuss points
  While it is not against the allocation policy to assign this module under mib-2, I should have thought that given the Experimental nature of this work, it would be better placed under 1.3.6.1.3 experimental.
  Please let me know that this was considered and sicussed with the MIB Doctor.       lispUseProxyEtrAddressLength OBJECT-TYPE
•           SYNTAX     Integer32 (5..259)
•           MAX-ACCESS not-accessible
•           STATUS     current
•           DESCRIPTION
•               'This object is used to get the octet-length of
•               lispUseProxyEtrAddress.'
•           ::= { lispUseProxyEtrEntry 1 }
•       lispUseProxyEtrAddress OBJECT-TYPE
•           SYNTAX     LispAddressType
•           MAX-ACCESS not-accessible
•           STATUS     current
•           DESCRIPTION
•               'Address of Proxy ETR configured on this device.'
•           ::= { lispUseProxyEtrEntry 2 }
• ...but...
• LispAddressType ::= TEXTUAL-CONVENTION
•     DISPLAY-HINT '39a'
•     SYNTAX OCTET STRING (SIZE (5..39))
• 
  
  So what would it mean if lispUseProxyEtrAddressLength had length 40?
• Adrian Farrel: Comment [2013-07-07 14:55]:
  The RFC Editor will want the Introduction to be Section 1.
  Section 2
  "This draft describes the Management Information Base (MIB) module for"
  s/draft/document/
  I think the document would benefit from a description of how SNMP is exepected to work across the locator/ID separation.
  Section 7
  The Imports clauses have comments that are direct citations. The same applies to some Description clauses. This is generally not done because when the module is extracted (which it often is) the references section is lost.
  Time to clean up idnits before passing this to the RFC Editor?
  Shepherd write-up says
  "I checked the ID nits and there are no warning or errors."
  However, idnits shows me an unused reference.     lispMappingDatabaseTable OBJECT-TYPE
•         DESCRIPTION
•             In general, this table would be representative of all
•             such mappings for the given LISP site to which this device
•             belongs.'
• 
  
  In general?     lispFeaturesInstanceID OBJECT-TYPE
•         MAX-ACCESS not-accessible
•         DESCRIPTION
•             'This represents the Instance ID of the LISP header.
•             An Instance ID in the LISP address encoding helps
•             uniquely identify the AFI-based address space to which
•             a given EID belongs. It's default value is 0.'
•         DEFVAL { 0 }
• 
  
  How does a defualt for a not-accessible object work?
  Truth values. For example...     lispFeaturesRlocProbeEnabled OBJECT-TYPE
•         SYNTAX     TruthValue
•         MAX-ACCESS read-only
•         STATUS     current
•         DESCRIPTION
•             'Indicates the status of rloc-probing feature on this
•             device.  If this object is TRUE, then this feature is
•             enabled.'
•         ::= { lispFeaturesEntry 12 }
• 
  
  I think it is normal to use lower case 'true' and 'false' to be consistent with the definition of TruthValue. In text, it is even preferable to use 'true(1)' and 'false(2)'.     lispFeaturesRouterTimeStamp OBJECT-TYPE
•         MAX-ACCESS read-only
•         DEFVAL { 0 }
•     lispMappingDatabaseTimeStamp OBJECT-TYPE
•         MAX-ACCESS read-only
•         DEFVAL { 0 }
• 
  
  ...etc.
  How does a default for a read-only object work?     lispMappingDatabaseDecapOctets OBJECT-TYPE
•         SYNTAX     Counter64
•         MAX-ACCESS read-only
•         STATUS     current
•         DESCRIPTION
•             'The number of octets of LISP packets that were decapsulated
•             by this device addressed to a host within this EID-prefix.
• 
  
  Is it clear that this count is after decapsulation?
  The name of the LispAddressType TC is confusing. The TC may have the address type embedded in it, but the TC is actually used to define objects that contain addresses. LispAddress would be a better name.
• Stephen Farrell: Comment [2013-07-10 03:28]:
  I didn't go back and re-read the LISP RFCs so there might be nothing here, but did anyone really check whether or not the information exposed here about mappings could assist a bad actor in mounting an attack against a LISP deployment?
  My concern is that the base LISP RFCs could have an inbuilt assumption that the mapping tables aren't known to all attackers, but this does expose some of that, and that might make an attack feasible that previously was not, e.g. by reducing the size of a space from which a bad actor would have to guess values. If someone tells me that 'yes, we looked at that and its ok' that'll be fine. If you didn't look, it'd be great if someone could do that now just in case since it could be painful later if something does turn up.
  There are a few nits in the secdir review [1] that are worth a look, and one change that the authors said they want to make.
  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04038.html
• Benoit Claise: Comment [2013-07-10 13:16]:
  - Section 5
  "Provide a means for obtaining (read-only) a current status of LISP features enabled on a device, and (read-only) a current status of configuration attributes related to those features. (This MIB provides read-only capabilities; it does not provide any capablities for setting or changing features.)"
  I'm confused by 'provides read-only capabilities'. Please change this sentence. These are not capabilities, but a list of enabled/disabled features.     lispFeaturesTable OBJECT-TYPE
•         SYNTAX     SEQUENCE OF LispFeaturesEntry
•         MAX-ACCESS not-accessible
•         STATUS     current
•         DESCRIPTION
•             'This table represents the ON/OFF status of the
•             various LISP features that can be enabled on LISP devices.'
• 
  
  'Capabilities' means: I support A, B, C, D, ... This is at least what the capabilities tables in previous MIB tables meant. lispFeaturesTable means: A, B, and D are enabled.
  - I was (slightly) confused by the fact that you combine parameters (lispFeaturesMapCacheSize, lispFeaturesMapCacheLimit) in a lispFeaturesTable
  - I agree with Adian's comments (not DISCUSS) regarding the MIB module
  Editorial
  Section 5:
  s/meachanism/mechanism
• Barry Leiba: Comment [2013-06-27 07:24]:
  Totally ignorable, completely non-blocking comments here:
  (see link)
• Sean Turner: Comment [2013-06-28 14:00]:
  The MIB doctors boilerplate for security has changed ever so slightly:
  http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
  The big change is the 2nd to last paragraph needs to be:
  "Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]."
• Telechat:
• Amy: -11, for Experimental. Token is Brian. Currently one DISCUSS on the tracked, discuss it today?
• Brian: Yes. Not Adrian, but we can work it out with Benoit. Adrian responded that this should be Experimental and I am inclined to agree with Adrian that this should be experimental branch and not lisp
• Benoit: I can explain my thinking: I reviewed 4181 which is guidelines for reviewers and MIB doctors. Let me copy it to the Chat window. So I ask myself if LIPS is deployed in the Internet. So I asked a LISP expert in my company. Answer: yes, it deployed on 10000s of nodes. So I asked, is this MIB implemented? He said no, waiting for the RFC. I asked, will you use this in the nodes? He said, obviously yes. So I thought it would be a good idea to have it in MIB2. So that's how I thought about it. Feel free to decide whatever you want out of that.
• Stewart: The text you copied suggest that it should be a non-experimental stream even if the protocol is experimental.
• Brian: My concern was the text that ADrian copied that this is a protocol experimental. I agree with you Benoit that long term should be in the non-experimental tree
• Stewart: Then, the RFC 4181 also contradicts itself.
• Benoit: The questions is: Is this deployed today in the Internet?
• Stewart: I know it is or about to be.
• Brian: In the WG I heard that this is deployed. Not sure if experimentally or broad. I am inclined to say that "there is deployment and there is plan to use this MIB to manage those deployments"
• Spencer: This discussion sounds like the discussion in the APP areas about using "X-" header fields for experiments, because no one replaces them when they enter widespread use, so you have "X-" header fields that were experimental in 1992 but used everywhere now. But those guys were trying to say: do not do that anymore because it is hard to manage experimental. Didn't they have a draft about that?
• Barry: Not just a draft, it's now an RFC
• Stewart: Yes, and in this case there is intention to use in deployment
• Brian: Then we need to have a chat with Adrian. There are enough comments that there will be Revised ID needed, so will discuss with ADrian
• Amy: OK, revised ID needed.

• Extensions to VPLS PE model for Provider Backbone Bridging (Informational)
  draft-ietf-l2vpn-pbb-vpls-pe-model [txt]
  Token: Stewart Bryant (rtg area)
  Note: Giles Heron (giheron@cisco.com) is the document shepherd.
  IPR: Nortel Networks Limited Statement about IPR claimed in draft-ietf-l2vpn-pbb-vpls-pe-model-02
  Discusses/comments [ballot]:
• Ted Lemon: Comment [2013-07-11 05:55]:
  I think the authors should consider whether the density of acronyms in this document is something that should be continued going forward. I am impressed that Barry found this document easy to read.
  I am not proposing that any changes be made to this particular document at this late date, but I would like to encourage the authors to consider a different balance in future documents. For instance, why is pseudowire abbreviated PW? SA is used twice in the document; why not write 'source address'?
  Generally speaking you should abbreviate things that are used so frequently that it's clunky to spell it out each time, and spell everything else out so that the reader doesn't spend more time flipping back and forth between the text and the glossary than actually reading.
  It's possible that all these terms are used so frequently by practitioners that there's no problem, so maybe I am making too much of this, but I found that the excessive use of acronyms in this document had a really negative impact on readability.
• Barry Leiba: Comment [2013-07-02 16:47]:
  I found this to be an easy-to-read document that was informative for someone not immersed in this technology. Good work.
• Spencer Dawkins: Comment [2013-07-10 15:27]:
  Like Barry, I thought this was very readable (especially given the long strings of hyphenated uppercase letters that are in every spec in this space :-)
  I had a couple of non-blocking comments for readability, and one question for the ADs (again, not blocking, just checking my own understanding of How Things Are Done).
  In Abstract
  "IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported."
  Did I miss where you said 'better than $WHAT'? I'm sure you had something in mind ...
  4. Packet Walkthrough
  "Because of text-based graphics, the Figure 3 only shows PWs on the core-facing side; however, in case of MPLS access with spoke PWs, the PE reference model is simply extended to include the same PW Forwarder function on the access-facing side. To avoid cluttering the figure, the access-side PW Forwarder (Fwdr) is not depicted without loss of any generality."
  I don't think the last sentence in this paragraph means what it was likely intended to mean, (double negatives don't work well in English) but rather than try to fix it, I would suggest something like
  "Because of text-based graphics, the Figure 3 only shows PWs on the core-facing side; however, in case of MPLS access with spoke PWs, the PE reference model is simply extended to include the same PW Forwarder function on the access-facing side. To avoid cluttering the figure, the access-side PW Forwarder (Fwdr) is not depicted."
  ending the sentence here
  FOR THE ADs: in 11. Contributors
  "The following authors contributed to this document: John Hoffmans (KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent)."
  We're including the organization names because they would have been on the front page anyway, right?
• Telechat:
• Amy: For Info, Token is Stewart. Currently no DISCUSSes. Unless there are objections this one is approved.
• <pause>
• Amy: Stewart, currently I have no text in the tracked.
• Stewart: There are comments, should go to Point-raised
• Amy: Will go to Point-raised -- write-up needed, Stewart, tell us when you are OK.

• Use of OSPF-MDR in Single-Hop Broadcast Networks (Experimental)
  draft-ietf-ospf-manet-single-hop-mdr [txt]
  Token: Stewart Bryant (rtg area)
  Discusses/comments [ballot]:
• Ted Lemon: Comment [2013-07-11 06:09]:
  This is a really minor nit, because I suspect anybody (other than me) reading this document already knows what an LSA is before they start, but the acronym is heavily used and never expanded.
• Pete Resnick: Comment [2013-07-11 07:16]:
  I do not know enough about the technology to even know how the following might cause confusion to implementers, but I am utterly mystified by this sentence in section 2:
  "o AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology)."
  Read as 2119 terms: 'AdjConnectivity must be set to 2 to avoid damage or interop problems, but there are special cases (unspecified here) where you might not do that. However, 1 is also a perfectly good value. That said, 0 must never be used, in order to avoid damage or interop problems, but there are special cases (unspecified here) where you might use 0, so long as you understand the implications.' That sentence seems triply internally self-contradictory.
• Benoit Claise: Comment [2013-07-10 15:40]:
  Similarly to the Security Considerations ...
  "5. Security Considerations: This document describes the use of OSPF-MDR in a single-hop broadcast network, and raises no security issues in addition to those already covered in [RFC5614]."
  I was hoping for ...
  "6. Management Considerations: This document describes the use of OSPF-MDR in a single-hop broadcast network, and raises no management issues in addition to those already covered in [RFC5614]. It actually simplifies the management and operations compared to RFC5614 because going from two-hop to a single-hop implies that ..."
  But wait, there are no management considerations in RFC 5614, and I don't see any related management documents at https://datatracker.ietf.org/wg/ospf/ Granted, it's not fair to have a DISCUSS on this document, and it's too late for RFC5614, but we're left without management considerations. I'm stuck with a single option for now: let this document go through, but please think about management considerations in the future, either in the document itself, or in a management dedicated document specific to your technology. In this specific case, let me hope that draft-nguyen-manet-management will address the OSPF-MDR (1 hop and 2 hops)
• Spencer Dawkins: Comment [2013-07-10 20:11]:
  In 2. Operation in a Single-Hop Broadcast Network
  "When OSPF-MDR is used in a single-hop broadcast network, the following parameter settings and options (defined in [RFC5614]) should be used:
  "o AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology)."
  Is there any guidance you can give about when the choice of 1 (uniconnected) would be appropriate?
  I might also be curious about when the choice of 0 (full topology) would be appropriate, but let's start with 1 (uniconnected).
• Telechat:
• Amy: Token is Stewart, no DISCUSSes, objections?
• <pause>
• Stewart: Same comments as before.
• Amy: This will go into approved - point raised.

• A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents (Informational)
  draft-ietf-straw-b2bua-taxonomy [txt]
  Token: Gonzalo Camarillo (rai area)
  Note: Christer Holmberg (christer.holmberg@ericsson.com) is the document shepherd.
  Discusses/comments [ballot]:
• Ted Lemon: Comment [2013-07-11 06:45]:
  In 4.6 and 4.7, it would be helpful to expand the various CSCF acronyms, since it's not necessarily obvious to the reader what they stand for.
  This is a really helpful document—thanks for writing it!
• Stephen Farrell: Comment [2013-07-09 10:31]:
  - Section 5: I support Joel's dicusss - some of the very clear security and privacy implications of the different roles should be called out here. (And they're not all bad implications.) So I hope he's not convinced he's in the rough.
  - Section 3: a table just listing the type names with or without a one-line description and a pointer to the section where they're defined migth be useful for the reader.
  - 3.1: Why would a b2bua like this save SDP bodies? Wouldn't that have some privacy implications?
  - 3.2.1: A reference for 'NAT behaviour' might be a good addition.
  - 4.6 & 4.7: lots of unexpanded acronyms, which seems like a bad plan for a taxonomy document (even if they're IMS terms:-)
• Richard Barnes: Comment [2013-07-08 18:24]:
  Overall, thanks for a nicely written document. It seems like a helpful guide to understanding some real devices, and why they do what they do.
  C1. At the top level of Section 3.1, you say that a 'Signaling-plane B2BUA' doesn't modify SDP bodies. But then Section 3.1.3 describes an 'SDP-modifying signaling-only B2BUA'. It would be helpful to be more specific at the top level (3.1) as to what sort of SDP modification these things *don't* do, then in 3.1.3 as to what sort of modifications they *do*. It seems like the line is something like, 'These B2BUAs don't do anything that changes the path that media takes (in particular, they don't insert themselves on the media path), but they may make SDP changes that affect what is sent on the media plane.'
  C2. The jump from CSeq-only modification (3.1.1) to modification of all headers (3.1.2) seems a little stark. It might be worth noting that there are lots of gradations in the 'Signaling-only' bucket -- some have only a few intrusive behaviors, some edit headers heavily, often dependent on configuration -- but because there are not clear categories, we group them together into this bucket.
  C3. In Section 3.2.2, s/mux/multiplex/g
  C4. The top level of Section 3 says that a conference server is not a B2BUA, but then Section 3.2.3 lists 'conference servers' among the things that are 'Media-termination B2BUAs'. Based on Section 4.5, it seems like what you mean here is that *some* conference servers terminate media. 'This is the role performed, for example, by transcoders and some conference servers.'
• Benoit Claise: Comment [2013-07-10 04:03]:
  Your terminology section is not a terminology section, it 'just' listing acronyms. This is weak for a taxonomy document ;-)
  I was expecting:
  "Back-to-Back User Agent [RFC3261]: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.
  "User Agent Client (UAC), [RFC3261]: A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction.
  "User Agent Server (UAS) [RFC3261]: A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction."
  Alternatively,
  "The User Agent Client (UAC) and User Agent Server (UAS) are defined in [RFC3261]. The User Agent Server (UAS) is redefined compared to [RFC3261] definition:
  "Back-to-Back User Agent: a SIP Back-to-Back User Agent, which is the logical combination of a User Agent Server (UAS) and User Agent Client (UAC).
  Later I see
  "Furthermore, this document defines 'B2BUA' following the definition provided in [RFC3261], which is the logical concatenation of a UAS and UAC."
  That confuses me, specifically because I would have expecting this in the terminology section, and it does it 'follow' the definition in RFC3261: the spirit maybe. I don't mind the repeat here, but the terminology section must be clear
  Close to a DISCUSS. Please engage in the discussion (if you don't plan on fixing this)
  Editorial:
  - Expand a few acronyms with their respective first occurrence: SBC, PBX
  Thanks for this document. It will be useful.
• Barry Leiba: Comment [2013-07-10 11:37]:
  UPDATED:
  An Applications Directorate review was just posted, and I'm sorry that it's so late (it was not the reviewer's fault, but a processing problem). There's nothing in the review that I would mark as blocking, but the review makes a lot of reasonable suggestions:
  http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09960.html
  Before the document is final, please have a look at the review and address the suggestions that you think are good ones.
  My original comments:
  There's an oddity in the shepherd writeup that I'd like to clear up, but it's not at the level of a blocking DISCUSS:
  Q: Why is this the proper type of RFC?
  A: It’s published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
  Other bits of the shepherd writeup do talk about working group consensus, so I presume that this is just a bad answer... but I want to be clear about the status of this document, which is a product of a working group and is asking to be published in the IETF Stream: This *is* intended to be an IETF consensus document, yes?
  Another very small point: the text in the Acknowledgments section is part of ancient boilerplate, and doesn't belong here any more.
• Spencer Dawkins: Comment [2013-07-10 21:39]:
  I support Joel's DISCUSS and Barry's request to consider the Applications Directorate review.
  In the Abstract
  "There are numerous types of SIP Back-to-Back User Agents (B2BUAs), performing different roles in different ways. For Example IP-PBXs, SBCs and Application Servers. This document identifies several common B2BUA roles, in order to provide taxonomy other documents can use and reference."
  I don't think you can fix the middle sentence ('For Example ...') because you're just listing names with no details, and adding details probably isn't appropriate in an Abstract - it's probably clearer to delete the sentence altogether. Isn't it also pointed toward system types, more than roles? And the document says it's focused on roles.
  At a minimum, in 3.1. Signaling-plane B2BUA Roles
  "This implies it does not modify SDP bodies, although it may save them and/or operate on other MIME body types."
  It would be helpful to say more about 'may save them' (for instance, why would the B2BUA do that?).
  In 3.1.2. Signaling-only
  "An example of such a B2BUA would be some forms of Application Servers and PBXs, such as a server which locally processes REFER requests and generates new INVITEs on behalf of the REFER's target. Another example would be an [RFC3323] Privacy Service Proxy performing the 'header' privacy function."
  I really like the examples you provided here. It would be great if you could provide examples for the descriptions as well.
  In 3.2. Media-plane B2BUA Roles
  "A Media-plane B2BUA is one that operates at both the SIP and media planes, not only on SIP messages but also SDP and potentially RTP/RTCP or other media. Such a B2BUA may or may not replace the Contact URI, modify or remove all Via and Record-Route headers, modify the To and From header fields, etc. No SIP header field is guaranteed to be copied from the received request on the UAS side to the generated request on the UAC side, and SDP will also be modified."
  I'm confused about a taxonomy where categories are described by what they might or might not do ...
  Is 'and SDP will also be modified' typically true, always true, or something else?
  In 3.2.1. Media-relay (and in other places as well)
  "A B2BUA which performs a media-relay role is one that terminates the media plane at the IP and UDP/TCP layers on its UAS and UAC sides, but neither modifies nor restricts which forms of UDP or TCP payload are carried within the UDP or TCP packets. Such a role may only support UDP or only TCP or both, as well as other transport types or not. Such a role may involve policing the IP packets to fit within a bandwidth limit, or converting from IPv4 to IPV6 or vice-versa. This is typically similar to a NAT behavior, except a NAT operating in both directions on both the source and destination information; it is often found as the default behavior in SBCs."
  naming TCP, UDP, or both repeatedly might be clearer if you replaced references with a more general 'transport'.
  In 4. Mapping SIP Device Types to B2BUA Roles, as you point out, these are marketing category terms without strict definitions. Given that I could build a device and call it by any of these names, how helpful is this section (and its subsections)?
• Sean Turner: Comment [2013-07-10 17:30]:
  +1 support Joel.
• Joel Jaeggli: Discuss [2013-07-09 08:24]:
  I can probably be convinced that I'm in the rough. This started out as a comment and ended up as a discuss so that we could dicuss it.
  I am somewhat doubtful that the security considerations section is adequate. If you're going to survey them all you should be able to make some appropriate statement about the security considerations for back to back user agents of varying varieties. in particular a number of them eliminate the possibility of end-to-end security mechanisms being employed generally transparently... votherwise no objections.
• Telechat:
• Amy: Token is Gonzalo, I do have a DISCUSS
• Gonzalo: I am driving and cannot see the tracker, so we can take it on the list.
• Joel: Observation: There are more people that supported my discuss. The Security considerations with type of <something>. We should be able to get some descriptive text but some considerations.
• Gonzalo: That discuss I have seen and actually agree. But I am not in front of my laptop.  Someone has been non responsive. Victor has been on-and-off and on vacation. I will wait until they are active again.
• Joel: I am happy to engage
• Amy: Going to AD Follow-up.

3.1.2 Returning Items

• (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

• (none)

3.2.2 Returning Items

• Adobe's Secure Real-Time Media Flow Protocol (Informational)
  draft-thornburgh-adobe-rtmfp [txt]
  Token: Martin Stiemerling (tsv area)
  IPR: Adobe Systems Incorporated's Statement about IPR related to draft-thornburgh-adobe-rtmfp-00
  Discusses/comments [ballot]:
• Pete Resnick: Comment [2013-06-25 14:53]:
  I believe this document obviously belongs with the ISE instead of as an individual submission via AD, but I have no intention to stand in the way of its publication. I trust Martin to get the non-consensus template on the document. I have reviewed this strictly as if I were doing a conflict review, and I find no conflict between this and IETF work. But because I do think it belongs with the ISE, I simply Abstain.
• Stephen Farrell: Comment [2013-07-11 03:19]:
  Thanks for handling my discuss.
  I didn't check if these coments were addressed or not. Feel free to chat about 'em, but since they're non-blocking you don't have to:-)
  - 1.1: Saying the security is 'always on' seems wrong when that's not specified here. The first three security bullets should be rewritten to say that the security bits are currently missing. (Or move those to the putative section I suggested adding.)
  - 2.1.2: Interesting that your VLU's are the same as DTNRG's SDNVs. [RFC6256] I'm not suggesting a change just interested that they're the same.
  - 2.2.3: I think you should also re-iterate here that there is no 'Cryptography Profile' currently publicly specified.
  - 2.3.6: I didn't get why or when its ok to replace a cookie that was incorrect? Seems like a bad thing to be doing. (And what hash function do you mean?)
  - 2.3.7: initiatorCertificate: what certificate format do you mean? RC5280 or something else? And do you mean just one cert or a chain?
  - 3.5: If you add the security bits, don't you need some more state for certificate status checking, e.g. to do OCSP?
• Richard Barnes: Comment [2013-07-08 18:23]:
  I agree with Pete and others that this should be handled by the ISE. At the very least, publishing this document in the IETF stream seems to contradict its own statement that it is 'not the product of an IETF activity'.
• Gonzalo Camarillo: Comment [2013-06-27 07:33]:
  Being more explicit (e.g., in the Introduction) about why this is being published would have been useful. Proprietary protocols can be documented for a number of reasons: historical reasons, to enable new implementations to be compatible with legacy ones, to get new implementations to use this protocol instead of a standard one, etc. Which one applies here?
• Spencer Dawkins: Comment [2013-06-25 06:22]:
  I'm a Yes, because anytime we can document protocols with significant deployment, that's helpful for network operators.
• Brian Haberman: Comment [2013-07-02 11:17]:
  I agree with Pete's points. The ISE is the proper place to publish these types of documents since the IETF will not have change control over the protocol. I strongly support publishing this document, but feel it should be done via the ISE since it is not a consensus-based document. Given that, I will simply abstain.
• Stewart Bryant: Comment [2013-06-25 11:04]:
  Whilst I agree with Spencer on the utility of the protocol, the Abstract and the introduction needs to make it clear that this is a proprietary protocol, and not a protocol endorsed by the IETF.
  Whilst in this particular case this may be obvious, we need to hold all vendors to the same standard.
• Telechat:
• Amy: Token is Martin. Martin, I do have a DISCUSS in the tracked.
• Martin: Yes, Pete wants to say something
• Barry: It's your problem, update the wiki. The proposed boiler that is in the wiki is something we agreed in discussion and if you want something in then stick it in. I think your suggestion is good.
• Pete: OK, if nobody objects I will update the wiki with that one and then we can discuss if to do something more general.
• Barry: You can clear your DISCUSS and we can take it to the Wiki
• Pete: Going to Abstain
• Amy: Pete going from DISCUSS to ABSTAIN, and with that this would be approved.
• Martin: But put it in Point Raised because I need to check the RFC Editor notes. 
• Amy: OK, and Martin let us know when it is ready.

3.3 Status Changes

3.3.1 New Items

• (none)

3.3.2 Returning Items

• (none)

3.4 IRTF and Independent Submission Stream Documents

3.4.1 New Items

• IETF conflict review for draft-kiyomoto-kcipher2
  conflict-review-kiyomoto-kcipher2 [txt] A Description of KCipher-2 Encryption Algorithm (ISE: Informational) 
• draft-kiyomoto-kcipher2 [txt] 
• IPR: KDDI Corporation's Statement about IPR related to draft-kiyomoto-kcipher2-04 
• IPR: Qualcomm Incorporated's Statement about IPR related to draft-kiyomoto-kcipher2-05 
• IPR: KDDI Corporation's Statement about IPR related to draft-kiyomoto-kcipher2-06
  Token: Stephen Farrell
  Discusses/comments [ballot]:
• Sean Turner: Comment [2013-06-28 14:16]:
  Hopefully somebody checked the test vectors.
  I also can never remember whether code is supposed to include the BSD license or not.
• Telechat:
• Amy: Conflict review is version -00, the doc is version -09. I have no DISCUSSes for this "no problem message". If no objections this can go with "no problem message from the IESG".
• <pause>
• Amy: OK, this one goes with the note attached. Stephen, any other issues
• Stephen: No. I do not think so.

• IETF conflict review for draft-irtf-samrg-sam-baseline-protocol
  conflict-review-irtf-samrg-sam-baseline-protocol [txt] Application Layer Multicast Extensions to RELOAD (IRTF: Experimental) 
• draft-irtf-samrg-sam-baseline-protocol [txt]
  Token: Brian Haberman
  Discusses/comments [ballot]:
• Barry Leiba: Comment [2013-07-02 16:58]:
  Editorial comments for.the authors:
  1. The synonyms (MUST, SHALL) are in RFC 2119 to accommodate different customs and different writing styles. They weren't meant to be intermixed in the same document, and certainly not in the same paragraph, and it's probably going to confuse readers if you do. For example:
  "8.4. Leave: When leaving a multicast group a node SHALL change its local state to indicate that it left the group. If the node has no children in its table it MUST send a LEAVE request to its parent, from where it SHALL travel up the multicast tree and stop at a node which has still children remaining after removing the leaving node.
  Someone reading this is likely to wonder why you didn't say that the node MUST change its local state, or that it SHALL send a LEAVE request to its parent, and what difference is intended there.
  I strongly suggest that you pick one word or the other, and then go through the document and make sure you use only that one, consistently.
  2. While we're at it: we don't normally use 2119 words to tell IANA what we want them to do. 'IANA is asked to register...', rather than 'IANA SHALL register...'. Not a big deal, of course, so take this or leave it. But we should be gentle and genteel to our IANA friends, you know.
• Telechat:
• Amy: Document is version -04, review is version -01, I have no DISCUSSes in the tracked for this. Unless there are issues, this can go back.
• Michelle: This particular document creates registries but we never got the message, so we never reviewed.
• You and Lars.
• Michelle: OK,
• Joel: Then I hold it for IANA Review. 
• Someone: stream editor
• Joel: I agree.
• Michelle: I thought it there was an impact of IANA during the conflict review, is that where we say something?
• Barry: I do not think so, we determined there is no conflict with IETF work, but you need to work with Lars on the IANA review.
• Michelle: I will contact Lars. Shouldn't we have gotten the message?
• Pete: You should have gotten the message at other point
• Barry: Not sure what the process is, need to solve with lars
• Russ: This is confusing, because if there is an existing registry, we should address here. But this is a new registry, so no concerns.
• Michelle: I will check with Lars on process going forward.
• Joel: This seems rare case. IRTG docs have created registries but not common
• Pete: All that said, look at the note we add, because the registry they create falls under <IANA-RFC> Expert Review, so that IESG approves the expert.
• Someone: And IESG will be approving the experts soon.
• Michelle: I will follow-up with Lars between today and tomorrow.
• Amy: This conflict review goes back to IRTF
• Brian: OK.

3.4.2 Returning Items

• IETF conflict review for draft-donley-nat444-impacts
  conflict-review-donley-nat444-impacts [txt] Assessing the Impact of Carrier-Grade NAT on Network Applications (ISE: Informational) 
• draft-donley-nat444-impacts [txt]
  Token: Joel Jaeggli
  Discusses/comments [ballot]:
• Martin Stiemerling: Comment [2013-07-02 04:57]:
  I am balloting no objection, as Pete has already raised the point about the correct write-up.
• Telechat:
• Amy: Currently no DISCUSSes for this. Unless there are concerns, then it is approved to go back to the ISC
• Amy: Approved, will be sent Monday as usual

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

1. (none)

4.1.2 Proposed for Approval

1. Security Automation and Continuous Monitoring (sacm)
   Token: AD Telechat:: 
• Amy: Anyone has objections for the creation of this WG?
• <pause>
• Amy: No objections. I see we have chairs.
• Sean: We actually change the chairs. We have Dan and <someone>
• Amy: Has not been regenerated in a while. Everything else is in place.
• Amy: No objections, so this is approved. This will be a WG for IETF.

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

1. (none)

4.2.2 Proposed for Approval

1. Managed Incident Lightweight Exchange (mile)
   Token: AD Telechat:: 
• Amy: rechartering proposed for approval. This is one of Sean;s WG. I do have a blocking comment for this WG recharter.
• Sean: Benoit's point was that make sure "mile" will not be used to enforce SLAs. And it is not. I am perfectly happy to strike that text, if people are concerned that it will be used to enforce SLA. It is just an example. I do not know what people want me to do, I am happy either.
• Benoit: I would prefer to remove it, but you can clarify incident vs. trigger.
• Sean: I will strike it, save it, and we are done. It is just an example. OK, it's gone.
• Benoit: I will move to no objection.
• Benoit: BTW -- what about the comment that I had?
• Sean: They will be looking at things like "this is not clear". It is a simple statement that they will fix things. 
• Benoit: Fine with me then.
• Amy: Benoit cleared his discuss. Did I hear you say you have edits?
• Sean: I did, I can tell you if I have then done before the call. 
• Amy: Now it is 03. Probably will be -04 before you are done?
• Sean: Yes.
• Amy: Will check with you.

5. IAB News We can use

• Joel: IAB did a couple of things of note. The first one is about dotless domains, answer to the new TLD stuff. We cannot stop people doing stuff, but we can tell "this does not work as you might think".  Will have an Individual submission BCP sponsored by Jari and approved by the iesg for proper review.
• Joel: IAB working on appeal form JF Morfin, we are trying to figure out what it is. There is another appeal that we do not have text but we know it's coming
• Pete: did you notice the discussion on IETF list and IETF SMTP list regarding dotless domains.
• Joel: I know about the SMTP list. And the IETF one regarding SM's point. It was an Oops and being fixed.
• Joel: Thank you.

[Scribe Note: The five-minute break and second roll-call was moved here]

1254 EDT break

1300 EDT back

• Jari Arkko---yes
• Richard Barnes---yes
• Stewart Bryant---yes
• Gonzalo Camarillo---yes
• Benoit Claise---yes
• Michelle Cotton---yes
• Spencer Dawkins---yes
• Adrian Farrel---no
• Stephen Farrell---yes (it is Call-in User_7 now)
• Heather Flanagan---no
• Sandy Ginoza---yes
• Brian Haberman---yes
• Joel Halpern---yes
• Susan Hares---yes
• Russ Housley---yes
• Joel Jaeggli---yes
• Barry Leiba---yes
• Ted Lemon---yes
• John Leslie---yes
• Cindy Morgan---yes
• Ray Pelletier--- regrets
• Carlos Pignataro---yes
• Pete Resnick---yes
• Martin Stiemerling---yes
• Sean Turner---yes
• Amy Vezza---yes

6. Management Issues

1. IESG Description for NomCom (Jari Arkko) Telechat:: 
• Jari: discussed on mailing-list, proposal... apps... <unintelligible> 
• Jari: The ones that I have seen are OK. Not under huge time pressure but would like to have this before Berlin. we talked offline... did the IESG put this out for public comment, or did we have Nomcom do so  
• Pete: Allison has not done the random selection yet so that we have a little time, abut certainly would like to have this ready and approved before Berlin. Therefore I'd put in the agenda again for next week. Did the IESG put this out for public comments before sending to Nomcom, or is that the Nomcom's responsibility
• Russ: In the past they put it in the website and use it in the interviews. And although I've not seen the write ups that go to the confirming body (modulo the ones that come to IESG)), it is my understanding that they can say "the community does not agree and we removed this requirement", or "think this is important and added this requirement:. Jari delivers it to Alexa and Alexa to Nomcom.
• Martin: On the transport era, we agreed to send it to the list saying what changed. We got a lot of feedback in Orlando and we want to have the community know what we send to Nomcom.
• Jari: I think that's a great idea. <unintelligible>. Should we do that more generally with all the areas?
• Pete: We can get feedback in the areas now that we have the wiki page and we can point people "take a look and let us know"
• Spencer: I have encountered situations when voting members of Nomcoms feel they cannot change the requirements they got from the IESG. The Nomcom is allowed to do that. So it would be useful for the Nomcom to say "this is what we have been told about the positions we're reviewing, so send feedback about the position descriptions now and don't wait until you are providing feedback on willing nominees."
• Pete: Your dutiful liaison wants to ask Nomcom that they ask quite explicitly.
• Spencer: That sounds lovely, thank you.
• Jari: And when you send it to the areas, <unintelligible>. Are there discussions on the content of the description? Have people had time to look at them?
• Someone: I think it is fine.
• Barry: I read the general stuff, and I think it is fine.
• Jari: Is next week reasonable?
• Pete: Yes, everyone has marching orders to check for next week.
• Amy: Should we keep this in the agenda for next week?
• Jari: Yes, please.
2. [IANA #691007] Acceptance of media-type registration from standards organization: OASIS (Amanda Baber - IANA) Telechat::
• Amy: Amanda added this but Michelle you can speak to it.
• Michelle: This is a media-type but an independent stream document, so we need to ask you if we need to add OASIS to our list, and then send it to Experts
• Barry and Pete: Yes, add it to list, no brainer. Add this organization to the list.
• Barry: Objections? <pause> Sold.
• Michelle: If the secretary could send us a not that we should add OASIS we will finish with the process.
• Barry: Secretariat has the appropriate text on file, right?
• Amy: Yes, this is the 2nd or 3rd that we've done.
• Barry: Text posted to Jabber room is correct, thank you.
3. Timing of directorate reviews (Jari Arkko) Telechat:: 
• Jari: First: Shepherds on the call please make sure you take a look at your docs and identify people to invite. Another: sending docs back to the WG. Third: discussion on various review teams about this. <unintelligible>. After WGLC. Martin I think said <unintelligible> are we ready for next step and proceed with experiment. 
• Stewart: exactly the same number of requests.
• Jari: exactly.
• Stephen: The other question for Jari. Is the WG chair ask for directorate reviews on a document
• Jari: Leave it to them. May not be sensible to ask everything every time. 
• Barry: I thought this change was for someone to say "the doc is ready for review now" and then trigger all Directorate reviews. Certainly there are times when a chair can say "I want a Security Directorate Review" but the general case is the chair saying "doc ready" and then trigger 
• Jari: Not for every doc.
• Barry: Agreed, but for some docs the shepherd can say "doc ready for review"
• Stephen: Need a mail alias for this.
• Barry: Need to add the Directorate mailing list and directorate managers to that list?
• Stephen: Yes, and also the IESG so that we see how the experiment is going
• Barry: I like that idea.
• Jari: Should reviewers post the review to the WG mailing list, or chairs?
• Spencer: Do Russ and Jari have a sense of how often GenART reviewers engage people on mailing list for discussion?
• Jari: Not on the IETF list.
• Barry: We had a separate conversation that went nowhere about where should Directorate reviews should be posted. We should have an agenda item in berlin,
• Russ: With secdir and GenART in my previous role, they need to follow current practices for last call.
• Barry: But they do not, since secdir reviews do not go to the IETF lists, and neither goes to WG lists.
• Russ: it depends on where the comments are targeted for. For the IESG for decision making, or for the source of the document?
• Barry: Some ADs have said their Directorates are for the ADs. GenART, secdir, and appsdir are Last-Call comments, the boiler plate says that.
• Stephen: This is a different topic, take it next week?
• Barry: Yes.
• Jari: Yes, independent of early review. I am fine with that answer. My main question is about the sector and GenART
• Stephen: Yes, we should have that mailing list.
• Jari: Yes, and explain to the WG Chairs what is happening. I will take the action to create the mailing list and inform the list managers.
• Benoit: In Ops are the response is 50%
• Joel: we are removing about half the people from the list.
• Jari: i did not hear an answer for transport directors -- are they in or out.
• Martin: we'll discuss this with directorate.
• Jari: All right -- anything else to discuss on the topic? <pause> I guess not. Action Item for me are to create the mailing list and description for early directorate reviews,
• Amy: Action Itemss for Jari to create the mailing list. That's the last of the management items.
4. MMM (Member) Telechat::

7. Agenda Working Group News

• Ted Lemon (Internet)---<no news in the Jabber room>
• Pete Resnick (Apps)---No working group news.
• Sean Turner (Security)---No working group news.
• Jari Arkko (General)--- <unintelligible>
• Richard Barnes (RAI)--- No working group news.
• Stewart Bryant (Routing)--- Yes, but pens down.
• Gonzalo Camarillo (RAI)--- No working group news.
• Benoit Claise (O & M)--- No working group news.
• Spencer Dawkins (Transport)--- Yes. CDNI has a IPR disclosure on a draft that the WG chair is also the inventor for. He was one of the document authors when it was an individual draft. I appreciate very much the support that Benoit and other ADs have provided. Martin and I are trying to figure it out. 
• Stephen Farrell (Security)--- No working group news.
• Brian Hamerman (Internet)--- No working group news.
• Joel Jaeggli (O & M)--- No working group news.
• Barry Leiba (Applications)--- No working group news.
• Adrian Farrel (Routing)---
• Martin Stiemerling (Transport)---

Amy: We are finishing early. Anything else anyone needs to discuss? 

Amy: Reminders: We are waiting for chars for the IPR BOF. Our next official telechat is next Thursday.

Amy: That's it, thanks, have a great week!

1105 EDT Adjourned

Appendix: Snapshot of discusses/comments

(at 2013-07-11 07:30:05 PDT)

draft-ietf-ipfix-protocol-rfc5101bis

• Ted Lemon: Discuss [2013-07-09 16:21]:
  I see a lot of cases of definitions for attributes of option templates where
• the text defining the attribute has been removed since RFC5101, and
• [IANA-IPFIX] is given as a reference where the definitions can be found.   For
• example in section 4.3, the definitions for notSentFlowTotalCount,
• notSentPacketTotalCount and notSentOctetTotalCount.
• This seems really weird to me.   If the text is identical in the document and
• in the registry, it's certainly fair to say that this is redundant.   But the
• way I would be inclined to address the redundancy would be to keep the text in
• the IETF standard, and abbreviate the text in the registry, pointing the
• registry back at the document.  The IANA registry is not a standard—it's a
• living document, which can change over time, so the explanatory text in it can
• likewise change over time.   It probably _won't_, but I think relying on that
• is a bad idea.
• To clear this DISCUSS, you would need to give a satisfactory explanation as to
• why it makes sense to move normative text out of this document into the IANA
• registry, or you could restore the text to this document, or you could point
• out another IETF standard that also contains the definitions (and perhaps
• change the reference in this document to point to that one, rather than to the
• IANA registry).   Or you could get the other ADs to gang up on me and tell me
• I'm making a fuss over nothing.   :)
• Ted Lemon: Comment [2013-07-09 16:12]:
  The document uses the term "treatment," I think as a term of art, but it
• results in some constructs that are hard to parse, like this one in section 2,
• Page 8, about halfway down:
•   As sampling is  a packet treatment, this definition includes packets selected
•   by a    sampling mechanism.
• It might help to add a terminology section on "packet treatment."   However,
• this depends on the target readership, so I'm by no means demanding that such a
• section be added; simply suggesting it based on the fact that I stumbled over
• the term when reading the document.
• It seems unnecessary to repeat "network byte order (also known as big-endian
• byte order)" throughout the document.   It might be better to just say "network
• byte order (also known as big-endian byte order)" the first time, and just
• "network byte order" subsequently.
• In 6.1.3 and 6.1.4, the floating point format is specified as IEEE 754 in
• network byte order.   IEEE 754 doesn't specify a network byte ordering for
• floating point numbers.   I think the encoding is fairly straightforward, but I
• am not convinced that a reader of this document who did not already know what
• IEEE 754 encoding in network byte order means would be able to figure it out.  
• It would help to have a reference here to a document that defines what "network
• byte order" means here, or just a quick statement about how the bytes are
• arranged.
• In 8.2, there's a paragraph that's supposed to clarify the applicability of
• templates to data records that's got such a big parse stack it left my head
• spinning.   I propose the following change:
• OLD:
•   Put another way, a Template describes Data Records contained in IPFIX
•   Messages with an Export Time between the Export Time of the IPFIX
•   Message containing the Template Record and either the Export Time of
•   the IPFIX Message containing the Template Withdrawal withdrawing it
•   or the end of the Transport Session, inclusive.
• NEW:
•   Put another way, a Template describes Data Records contained in IPFIX
•   messages when the export time of such messages is between a
•   specific start and end time.   The start time is the Export Time of the IPFIX
•   Message containing the Template record.   The end time is one of two
•   times.   If the template is withdrawn during the session, then it is the
•   Export Time of the IPFIX message containing the Template Withdrawal
•   for the template.   Otherwise, it is the end of the Transport Session.
• In the last paragraph of the first part of section 9, the text does not mention
• the handling of a malformed message in the case of TCP transport.   I think in
• this case there is no way to resynchronize, because it's impossible to
• characterize the error that caused the malformed message.   That being the
• case, doesn't the TCP connection have to be dropped when a malformed message is
• encountered?   Shouldn't this be mentioned either in Section 9 or Section 10.4?
• Overall this update to RFC 5101 looks like a significant improvement.   Thanks
• for doing it!
• Adrian Farrel: Comment [2013-07-07 14:00]:
  I hate the idea of tit-for-tat Discusses and will not raise one.
• However, having recently seen a number of Discusses entered on documents
• saying that insufficient attention had been paid to RFC 5706 and the
• manageability issues and impacts for protcols, I must observe that this
• document is considerably lacking in that department. I looked for, but
• could not find an existing RFC providing a management framework for
• IPFIX although I do notice that a MIB module exists. Maybe RFC 5153 is
• supposed to cover this, but on a brief skim it does not seem to give
• much information about how IPFIX is managed.
• Please note that just because IPFIX is, itself, a management protocol
• does not mean that the impact that the impact on te network of its use
• should not be considered. Indeed, there are considerable concerns about
• how IPFIX could impact a live network. Furthermore, IPFIX needs to be
• managed, operated, and diagnosed in its own right, and that bears
• description.
• I leave it to the sponsoring AD and document editors to examine why they
• are comfortable to progress this document without this material.
• ---
• Section 8.4
•   Default settings for these values are deployment- and
•   application-specific.
• I.e., there are no default settings?
• Stephen Farrell: Comment [2013-06-10 10:01]:
  - I mostly used the diff to 5101 for this review.
• - In section 8, you have new text saying that the CP MUST
• store all template record information for the duration of
• each transport section. I wondered if that creates any
• potential for a DoS?
• - Is all the naming stuff in 11.3 fully worked out and likely
• to be, or actually, implemented? E.g. it says that use of
• DNS-ID is a SHOULD be implementaton of CN based lists is a
• MUST - does that make sense really?
• - You say: SSL/TLS before TLS1.1 is a MUST NOT, TLS1.1 is a
• MUST and TLS1.2 is a SHOULD. Would it not be better to just
• say TLS1.2 is a MUST? Perhaps TLS1.2 support is (soon) more
• likely to be widely available for this kind of application -
• did you check recently? (I didn't, and [1] is a year old
• now.)
•   [1] http://www.imperialviolet.org/2012/06/08/tlsversions.html
• - I wondered if its possible to analyse network timing to try
• to discover what kind of IPFIX collecting is going on, for
• example, via timing analysis. Since I don't know, I'm not
• asking that you add something to section 11, but I do
• wonder:-)
• Martin Stiemerling: Comment [2013-06-11 07:12]:
  In support of Spencer's DISCUSS point
• Spencer Dawkins: Comment [2013-06-11 12:54]:
  Brian provided explanations and text proposals (following), and these proposals
• address my DISCUSS (cleared) and all but one of my comments.
• On the #3 text proposal below ... we're talking about an Observation Domain
• using a single TCP connection, is that correct?
• If an OD sends a TCP stream that looks like this (each observation is
• transmitted as a separate IP packet)
• - Observation 1
• - Observation 2 (assume this one gets lost in the network)
• - Observation 3
• - Observation 4
• - Observation 5
• TCP guarantees in-order delivery, so the sending TCP will retransmit
• Observation 2 tenaciously, and the receiving TCP holds everything it receives
• after Observation 2 until it can deliver the retransmitted Observation 2. The
• Collecting Process won't see Observation 3 until after Observation 2 is
• successfully transmitted.
• If two Observation Domains, "a" and "b", are sharing a single TCP connection,
• and the interleaved TCP stream looks like this:
• - Observation a-1
• - Observation a-2 (assume this one gets lost in the network)
• - Observation a-3
• - Observation b-1
• - Observation b-2
• - Observation b-3
• - Observation a-4
• - Observation b-4
• - Observation b-5
• - Observation a-5
• the in-order delivery guarantee spans Observation Domains, so not only does the
• receiving TCP hold everything for Observation Domain "a" until it receives
• Observation a-2, it holds everything for Observation Domain "b", because all of
• these observations are being blocked by the same head of line problem with the
• same TCP connection.
• So in this proposed text:
•   Exporting Processes may choose IPFIX Message lengths lower than the
•   maximum in order to avoid head-of-line blocking and/or to ensure
•   timely export of Data Records.
• I think you can minimize head-of-line blocking, but I don't think you can avoid
• it.
• Maybe minimizing head-of-line blocking is OK (the Collecting Process is, after
• all, not a human, so I'm not sure why it would care about head-of-line
• blocking, as long as it sees reliable in-order delivery in the fullness of
• time), so I don't want to be difficult, but I did want to try to explain better
• what I was trying to say. --
• From Brian:
• To summarize, I suggest the following changes to the document to address this
• DISCUSS and COMMENT:
• (1) NEW definition for Sequence Number in Section 3.1 (s/SHOULD/can/):
• Sequence Number
•       Incremental sequence counter modulo 2^32 of all IPFIX Data Records
•       sent in the current stream from the current Observation Domain by
•       the Exporting Process. Each SCTP Stream counts sequence numbers
•       separately, while all messages in a TCP connection or UDP
•       transport session are considered to be part of the same stream.
•       This value can be used by the Collecting Process to identify
•       whether any IPFIX Data Records have been missed. Template and
•       Options Template Records do not increase the Sequence Number.
• (2) NEW Section 10.2.5. Failover (in 10.2 SCTP) (clarify failure detect by
• lower-layer timeout):
•   If the Collecting Process does not acknowledge an attempt by the
•   Exporting Process to establish an association, SCTP will automatically
•   retry association establishment using exponential backoff. The
•   Exporter MAY log an alarm if the underlying SCTP association establishment
•   times out; this timeout should be configurable on the Exporter.
•   The Exporting Process MAY open a backup SCTP association to a Collecting
•   Process in advance, if it supports Collecting Process failover.
• (3) NEW Section 10.4.3. MTU paragraph 2 (remove confusing head of line blocking
• language):
•   Exporting Processes may choose IPFIX Message lengths lower than the
•   maximum in order to avoid head-of-line blocking and/or to ensure
•   timely export of Data Records.
• (4) NEW Section 10.4.4. Connection Establishment and Shutdown first two
• paragraphs:
•   The IPFIX Exporting Process initiates a TCP connection to the
•   Collecting Process. An Exporting Process MAY support more than one
•   active connection to different Collecting Processes (including the
•   case of different Collecting Processes on the same host). An Exporting
•   Process MAY support more than one active connection to the same
•   Collecting Process to avoid head of line blocking across Observation Domains.
•   The Exporter MAY log an alarm if the underlying TCP connection establishment
•   times out; this timeout should be configurable on the Exporter.
• (5) NEW Section 10.4.5. Failover (in 10.4 TCP) (clarify failure detect by
• lower-layer timeout):
•   If the Collecting Process does not acknowledge an attempt by the
•   Exporting Process to establish a connection, TCP will automatically
•   retry connection establishment using exponential backoff. The
•   Exporter MAY log an alarm if the underlying TCP connection establishment
•   times out; this timeout should be configurable on the Exporter.
•   The Exporting Process MAY open a backup TCP connection to a Collecting
•   Process in advance, if it supports Collecting Process failover.
• Sean Turner: Comment [2013-06-10 12:45]:
  Should probably say something about the version of DTLS you want supported in
• s11.3 or is that covered in s11.1?
• Do you need to up the SHOULD in RFC 6347 about the cookie exchange to a MUST?
• Joel Jaeggli: Comment [2013-07-05 15:29]:
  The opsdir review of the latest draft is extensive...
• Thanks sue for doing it
• Appendix A.  Operations and Management Review Checklist
• Well written.  Only a few technical questions/considerations:
• a) What happens when different observation points of an observation domain have
• different levels of timing (nano-second vs. second)? Does the second timing
• data get put in a different queue than nano-second data? b) Is there key
• rotation with DLTS using 2-way/3-way/ or 4-way handshake? c) What happens if
• the transports switch rapidly (UDP to TCP to STCP and rotate (UDP to TCP to
• UDP)? Are these denial of service attacks?
• Editorial:
• page 8 Flow key – could use an example.
• page 25 – 4.1 end of sentence change from: ; see (IPFIX-IANA] for their
• definitions”  to: defined in [IPFIX-IANA]: p. 36 Section 8.0 last paragraph –
• could use an example. p. 50 section 11.1 – Last paragraph the offset by commas
• that starts “,i.e., a true and ends (and/or TCP), this” is confusing.  Please
• reword
• p. 51  11.2 para. 1 “[RFC5246] and [5347],” to [RFC5246] and [5347]” otherwise
• sentence does not have strong sense of while.’
• p. 52  section 11.4, para. 2 change “or scope information, a large amount” to
• “or scope information, or a large amount”
• p. 53 “section 11.4 para 5 change “a Collecting process; if provided, the” to
• “a Collecting process; and if provided, the”
• A.1.  Operational Considerations
• 1. Has deployment been discussed:
• a. Does the document include a description of how this protocol or technology
• is going to be deployed and managed?
• Actual Deployments are not discussed in depth. Management and operational
• conditions for multiple transport, DOS, and scaling issues are discussed.
• b. Is the proposed specification deployable?  If not, how could it be improved?
• This solution has description of scaling and management concerns. Any solution
• that monitors at per interface or more refined will run into issues with
• scaling.
• Improving the deployment would take another approach to the problem of
• store/forward or trigger updates. However, this document is about updating an
• existing process. For this approach, the authors have done a good job at
• working through possible refinements. If IETF wants
• c. Does the solution scale well from the operational and management
• perspective? Does the proposed approach have any scaling issues that could
• affect usability for large-scale operation?
• Most issues have been mentioned. A few things that should be considered: 1)
• fluctuations between times and queuing for different observation points or
• different data and 2) fluctuations if the transport failures cause the
• implementation to rate between transports.
• d. Are there any coexistence issues?
• Coexistence issues in transports or IDs are clearly stated. The document
• specifies it is interoperable with previous version of protocol [RFC101]
•   2.  Has installation and initial setup been discussed?
• * Is the solution sufficiently configurable? Are configuration parameters
• clearly defined? Are configuration parameters normalized?  Does the
• configuration have a reasonable default value?
• Solution appears to be configurable, defined, and normalized, with default
• values, but that configuration is dealt with elsewhere, and it is not the topic
• of this draft. o Configuration: RFC6615 (MIB), RFC627 (NETCONF), o
• Implementation guidelines [RFC5153], testing [RFC5471]
• * Will configuration be pushed to a device by a configuration
•           manager, or pulled by a device from a configuration server?
• The MIB and NETCONF options allow either configuration manager to push the
• information. It is not clear if the IPFix device, exporter, collecting process
• or collector can pull global configuration.  Since the TLVs in a sense
• self-configure, this is in a sense pulling the configuration.
• * How will the devices and managers find and authenticate each other?
• The devices and managers appear to find each other in an a priori manner via
• configuration. Group functions exist for observation point to observation
• domain, collecting processes to collecting hosts, and exporter processes to
• exporters.  However, it does not appear that these grouping processes
• self-detect. The data within these monitoring flows self-detect but the
• identity does not appear to find each outside of configuration. If I have
• missed this, you might consider that I re-read RFC3917, RFC5470, RFC6615(MIB),
• RFC6728(netconf), RFC6727 (MIB), and RFC5102bis (MIB).
• RFC6728 indicates that the following trees/substrees contain sensitive
• information and write operations can have an impact: a) /ipfix/Observation b)
• ipfix/cache c) ipfix/exportingProcess d) ipfix/collectingProcess
• Due to these statements and section 11 that states an IPFIX collecting process
• (or processes) must prevent collection from an unauthorized Exporting Process
• or the export of data to an unauthorized collected process.
• This implies that the “discover” each method would need additional security
• mechanisms.
• 3. Has the migration path been discussed?  Are there any backward compatibility
• issues?
• The document states the protocol is interoperable with RFC5101. The
• self-defining mechanism seems to provide this.
• 4. Have the Requirements on other protocols and functional
•       components been discussed?
• In quick summary – Yes. The smorgasbord of options and parameters has been
• described,
• The impact of the ipfix process on the underlying carrying protocols (UDP, TCP,
• STCP), the device/node in the being sampled, the exporters impact, the
• collectors impact have been carefully specified. New protocol functions are
• either specified or reference by RFC. The NETCONF/YANG or MIB models are given
• as Management.
•   5.  Has the impact on network operation been discussed?
•         This document does discuss:
• o how ipfix increases traffic load and choice the network operator has in
• managing, o how ipfix will increase traffic load on existing networks and how
• to manage it, o how the protocol use impacts exporting processes and exporter,
• collecting processes and collector, o how the device impacts the behaviors of
• other protocols by sending traffic load and how to manage it, o how the device
• requires security.
• Since the IDs are self-defining, it does not appear that the DNS service has a
• critical impact on these. The DNS-ID is mutual authentication process which
• requires the DNS-ID as specified in section 6.4 of RFC6125. The security
• requires that the Common-Name (CN-IDs) not be placed in identifiers.
• 6. Have suggestions for verifying correct operation been discussed?
• The Testing operations exists RFC5471 and RFC5153. Since the protocols are
• interoperable only the differences need to be examine.
• The only differences that section 1.1 notes that impact implementation and
• testing are the timer encodings link to epochs or rollover, and template
• management relaxation.
• While section 5 and section 8 cover this information to one skilled in the art,
• it may be worthwhile to update both RFC5471 and RFC5153 with the appropriate
• information.
• 7. Has management interoperability been discusses?
• In short, yes.  This protocol is a model protocol for information models, data
• models, and choices across platforms.
• 8. Are there fault or threshold conditions that should be reported
• This management information has timing implications and ties to a timing
• utility.  The information is reporting on a constant stream. There does not
• appear to be any notifications defined in MIBs. This is not(!!) a polling
• application for event-drive. Overload alarms/notifications might be useful,
• except they might further provide a DOS attack.
• State saving, caching, template definition keeping are described carefully and
• thoroughly.
•   9.  Is configuration discussed?  See Section 3.4.
•       *  Are configuration defaults and default modes of operation
•           considered? Defaults are described in MIB. Default process
•           in this document. The discussion seems sufficient.
•       *  Is there discussion of what information should be preserved
•           across reboots of the device or the management system?  Can
•           devices realistically preserve this information through hard
•           reboots where physical configuration might change (e.g.,
•           cards might be swapped while a chassis is powered down)?
• Topics regarding reboot are not covered in this document. The word restart is
• only used regarding restarting the UDP. The word reboot is not used.
• A.2.  Management Considerations
•   Do you anticipate any manageability issues with the specification?
• 1. Is management interoperability discussed?
• The management may be centralized or distribution or a combination. The
• collector processes are considered to be remote from the exporting processes.
• However, the exportation/collection can be in the same virtual environment.
• No textual or graphical user interfaces are required. The format of the
• protocol utilizes TLVs. The internal data may be considered “sensitive” and may
• be encrypted due to its sensitivity whether it is textual or binary.
•   2.  Is management information discussed?  See Section 3.2.
• * What is the minimal set of management (configuration, faults,
•           performance monitoring) objects that need to be instrumented
•           in order to manage the new protocol?
•         This is not discussed in this document.
•   3.  Is fault management discussed?  See Section 3.3.
• * Is Liveness Detection and Monitoring discussed? For the liveness indications
• for the transport protocols (STCP, UDP, TCP) and the exterior needs for
• liveness/monitoring neded when UDP is issued.
• * Does the solution have failure modes that are difficult to diagnose or
• correct? Faults and alarms are logged. However, if errors reoccur the mere
• keeping of the faults may overload. An overload mechanisms on exporting was
• discussed in 4.2 (Metering process)and 4.3 exporting process.
• 4. Is configuration management discussed?
• * Is protocol state information exposed to the user?  MIBS and YANG/netconf
• model expose state and tables to user.
• * Significant failures of transport, stopping metering (4.2), stopping export
• (4.3) are discussed.
• 5. Is accounting management discussed?
• Only in terms of the link between performance data and accounting.
•   6.  Is performance management discussed?  See Section 3.6.
• * Protocol impacts performance of nodes (exporter load, collector load) and the
• network data passage (due to amount of data sent. This is discussed. * Protocol
• performance information is exposed when the information is dropped (metering
• 4.2, exporting, 4.3).  The performance issues are discussed, but the
• performance metrics
•       *  Is protocol performance information exposed to the user?
• 7. Is security management discussed?
• Security features required to support IPFIX are discussed in section 11. This
• section discussed the security features the protocol requires, the
• applicability of TLS and DTLS, the usage of a unique secure channel, the mutual
• authentication, protection against DOS, and security issues with UDP only,
• requirement to log IPFIX attack, how to secure the collector, and the need to
• secure the data collected.
• A.3.  Documentation
• * Is an operational considerations and/or manageability section part of the
• document?  Security section is. The document weaves the operational
• considerations and management within the whole document since this is a
• protocol that impacts monitoring. The actual management and monitoring of the
• protocol doing the flow monitoring is part of this discussion. The
• configuration and data models are (thankfully) elsewhere described.
• * Does the proposed protocol have a significant operational impact on the
• Internet?  Yes, yes, and yes!
• * Is there proof of implementation and/or operational experience? Significant
• lessons learned are causing the update.  No specific implementation or
• operational experience is noted.

draft-ietf-appsawg-rfc5451bis

• Ted Lemon: Comment [2013-07-10 20:29]:
  Throughout the document, the term "this header field" and "the header field" is
• used to refer to the Authentication-Results header field. This isn't very user
• friendly—I keep wondering if the antecedent has changed. Once it's clear to the
• reader what the document is about, I think this is less of an issue, but it
• made starting to read it kind of painful. I think it would be more friendly to
• say "the authref header field" each time, even though it's an extra word. I
• realize that this is a fairly minor cognitive load for the reader, but when it
• comes to even minor cognitive loads, less is more.
• In 2.5.7:
•   Extension results MUST only be used within ADMDs that have explicitly
•   consented to use them.
• Wouldn't it be better to say:
•   Extension results MUST NOT be used within ADMDs that have not explicitly
•   consented to use them.
• I suggest this because "MUST only" is not an RFC 2119 key word, but I think you
• mean the two words together to be normative.   It's understandable either way,
• so this is a minor nit, but take it for what it's worth.
• From section 5:
•   For simplicity and maximum security, a border MTA could remove all
•   instances of this header field on mail crossing into its trust
•   boundary.  However, this may conflict with the desire to access
•   authentication results performed by trusted external service
•   providers.  It may also invalidate signed messages whose signatures
•   cover external instances of this header field.  A more robust border
•   MTA could allow a specific list of authenticating MTAs whose
•   information is to be admitted, removing all others.
• Although this alludes to the problem of breaking DKIM, for example, it doesn't
• fully address it.   A DKIM message may be signed in a way that can be
• validated, and yet not come from a trusted external service provider.  If the
• DKIM signature includes an Authentication-Results header, removing it will
• break the signature, preventing the MUA from validating it.   This seems like a
• big loss of functionality, since the end user doesn't have a way of opting out
• of this breakage.
• This could be easily mitigated by changing the name of the header field rather
• than removing it: change it to Elided-Authentication-Results or something.  
• Then the MUA can reverse that and calculate the DKIM signature.
• I realize that this may be a non-issue in practice.   I haven't seen a DKIM
• signature that signed an Authentication-Results header, and maybe it just never
• happens.   But this seems so easy to fix that it ought to be worth the minor
• effort involved.
• Stephen Farrell: Comment [2013-07-09 09:53]:
  - note to RFC editor in the abstract I guess needs changing
• now that this is going for PS
• - intro: Are ADSP and VBR really in common use?
• - 1.6: you say valid use "requires removing" this when the
• message first arrives in the ADMD. I think that'd be better
• as a "MUST remove" but is clear enough. (Section 5 has a MUST
• btw, though also allows for not removing messages you
• get *directly* from a "trusted" peer. Is "directly" there
• really verifiable in general?)
• - 1.7: I guess this is changed by the new PS target.
• - 2.3: You say MUAs SHOULD use the authserv-id field to
• determine whether to use or ignore the header field. That's
• unchanged since 5451 but I wonder if it'd be better to say that
• MUAs need to have a whitelist or similar of values that are ok
• for this? What's actually done here? (This isn't a discuss since
• its the same in 5451.)
• - 2.4 and 2.5.7: I think I agree that adding these means that
• cycling at PS is correct.
• - section 4, 2nd last para: has a new SHOULD NOT that seems
• sensible - but I wondered why this was a SHOULD NOT and not a
• MUST NOT? I can't think of a case where an AR is better
• containing stuff that the MUA can't see. If there are such
• cases, maybe mention one. Or maybe I've misinterpreted the
• text? (It is a bit hard to get.)
• - section 7: Thanks!
• Barry Leiba: Comment [2013-07-09 07:35]:
  Because of the changes being made in the document, I'm changing the target
• status to Proposed Standard, and it's likely to be presented in six months or
• so for upgrade to Internet Standard.
• Spencer Dawkins: Comment [2013-07-08 17:36]:
  I am sympathetic to Pete's DISCUSS on advancing to full standard while making
• incompatible changes, but I'll let you folks hash that out - it wouldn't affect
• my ballot position either way.
• I found this specification clear and especially appreciated the context in
• sections like Operational Guidance.
• I had some non-blocking comments that I'd ask you to consider along with other
• comments you might receive.
• In 1.1.  Purpose
•   In particular, the mere presence of this header field SHOULD NOT be
•   construed as meaning that its data is valid, but, rather, that it is
•   reporting assertions made by one or more authentication schemes
•   applied somewhere upstream.
• This doesn't look like a 2119 SHOULD NOT to me ... are you saying something
• like "the mere presence of this header field doesn't mean that its data is
• valid"?
• In 1.5.2.  Security
•   By contrast, DKIM is agnostic as to the routing
•   of a message but uses cryptographic signatures to authenticate agents
•   claim (some) responsibility for the message (which implies
•   authorization) and ensures that the listed portions of the message
•   were not modified in transit.
• This sentence isn't parsing for me. Missing word, perhaps?
• In 2.5.1.  DKIM and DomainKeys
•   neutral:  The message was signed but the signature or signatures
•       contained syntax errors or were not otherwise able to be
•       processed.  This result SHOULD also be used for other failures not
•       covered elsewhere in this list.
• I don't think this is an RFC 2119 SHOULD, but my larger point is, if you
• encounter a failure that's not covered in this list, what other choice is
• there? (Return no result? return the wrong result?)
• In 6.2.  Email Authentication Method Name Registry
•   Each method must register a name, the specification that defines it,
•   a version number associated with the method being registered
•   (preferably starting at "1"),
• this "preferably" is Mostly Harmless, but I'd think if the intent was to
• avoiding confusing the reader, you'd be better off mandating that. "Preferably"
• seems to say "you could *probably* trust that version 5 isn't the first
• version, but you can't know that for certain".
• A couple of paragraphs down,
•   IANA is also requested to add a "version" field to all existing
•   registry entries.  All current methods are to be recorded as version
•   "1".
• seems to mandate starting at "1" for existing methods, so I'm confused why new
• methods might not begin with version '1'.
• Brian Haberman: Comment [2013-07-08 12:16]:
  Cool to see the Implementation Status section...
• Stewart Bryant: Comment [2013-07-03 08:38]:
  I missed the note that section 7 is to be deleted.
• Sean Turner: Comment [2013-07-09 09:20]:
  I hate to slow down progression of this to IS, but I do agree with Pete's
• assertion that this probably needs to recycle based on the number of changes.* 
• (I'll note Barry's already said he's going to make it cycle so no action but
• thought I should be on record)
• How does this draft seemingly get away with not normatively referencing the
• authentication methods?  On the one hand, I can see the argument that this
• protocol merely copies information from another protocol to a field and then
• sends it on its way back to the originator.  On the other hand, doesn't the
• creator of the report need to understand the various authentication mechanisms
• to know what result to send back?  And please don't get me wrong, I don't want
• to hold publishing this up based on this comment - I'm just curious.
• *  the diff tool worked nicely here comparing the original rfc and the bis.

draft-ietf-core-coap

• Ted Lemon: Comment [2013-04-24 20:32]:
  P. 14: informative reference to HHGTG almost, but not entirely,
• helpful.  :)
• P. 15: why start at version 1 when you can only have a total of 4 versions?  
• Wouldn't version 0 be a better choice?
• P. 19: I'm a little uncomfortable with this text:
•             There is no
•             expectation and no need to perform normalization within a
•             CoAP implementation (except where Unicode strings that are
•             not known to be normalized are imported from sources
•             outside the CoAP protocol).
• I think what's intended here is right, but you've mentioned what
• amounts to a strong suggestion, if not a requirement, as a
• parenthetical note.  It seems like what you intended was something
• like this:
•             There is no expectation and no need to perform
•             normalization within a CoAP implementation, since senders
•             are expected to be implemented with pre-normalized
•             strings.  However, strings received from non-CoAP sources
•             SHOULD be normalized where possible.
• Of course, there's actually no value to normalization in this case if
• it can't be depended on, and I suspect that you don't want to make
• that a MUST.   So this might be a better way to do it:
•             There is no expectation and no need to perform
•             normalization within a CoAP implementation, since senders
•             are expected to be implemented with pre-normalized
•             strings.  Strings received from non-CoAP sources and then
•             forwarded by CoAP senders cannot be assumed to have been
•             normalized, and may not compare correctly with normalized
•             strings representing the same text.
• I don't have a strong opinion about how this should be done, but it
• seems like the text as written doesn't give clear guidance.  It seems
• that cross-proxies ought to be able to do normalization, and maybe
• other proxies could as well, but that's a much bigger change.
• Section 4.1: Even though I think it doesn't make any sense to do this,
• it might be worth stating how a receiver should behave if it receives
• an ACK with a request.
• Section 4.2: Wouldn't this:
•   More
•   generally, Acknowledgement and Reset messages MUST NOT elicit any
•   Acknowledgement or Reset message from their recipient.
• be better stated this way?
•   More generally, recipients of Acknowledgement and Reset messages
•   MUST NOT respond with either Acknowledgement or Reset messages.
• Might be worth grouping for operator precedence here:
• OLD:
•         ACK_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * ACK_RANDOM_FACTOR
• NEW:
•         ACK_TIMEOUT * (2 ** (MAX_RETRANSMIT - 1)) * ACK_RANDOM_FACTOR
• OLD:
•         2 * MAX_LATENCY + PROCESSING_DELAY
• NEW:
•         (2 * MAX_LATENCY) + PROCESSING_DELAY
• Section 5.8: The use of the word "safe" to describe methods is really
• confusing because of save/unsafe options.  It would help ease of
• comprehension if you used a different word--e.g., read-only.  I
• realize that this goes somewhat against the idea of sharing
• nomenclature with HTTP, but I think the clash between safe/unsafe
• options and safe/unsafe methods is confusing enough that you aren't
• really benefiting from that anyway.
• In 5.9: as a user and implementor of RESTful systems who has learned
• by doing more than by reading, the term "action result" is somewhat
• opaque to me.  I think I know what it means, but it might be nice to
• explain what it means before using it like this:
•   Like HTTP 201 "Created", but only used in response to POST and PUT
•   requests.  The payload returned with the response, if any, is a
•   representation of the action result.
• 5.9.2.2: I think you mean "first" rather than "previously":
•   The client is not authorized to perform the requested action.  The
•   client SHOULD NOT repeat the request without previously improving its
•   authentication status to the server.  Which specific mechanism can be
•   used for this is outside this document's scope; see also Section 9.
• 5.10.1: how does the client know that an endpoint hosts multiple
• virtual servers in time to leave out the Uri-Host option?  Is this
• literally just in the case where the hostname appears in the URI to be
• decomposed as an IP address literal?
•   are sufficient for requests to most servers.  Explicit Uri-Host and
•   Uri-Port Options are typically used when an endpoint hosts multiple
•   virtual servers.
• In 5.10.8.2: I can't quite understand what is meant here.  I could see
• it meaning either or both of the following:
•   1. If If-None-Match appears in a query with one or more If-Match
•   options, and none of the If-Match options match, the condition is
•   fulfilled.
•   2. If If-None-Match appears in a query, no If-Match options may
•   appear in that query; the condition is met if the target doesn't
•   exist.
• I think that the text means just (2), but because of the name of the
• option, I want it to mean (1), even though the text doesn't say that,
• and since the text doesn't say that If-None-Match and If-Match are
• mutually exclusive, I can easily imagine someone reading the text and
• carelessly assuming that it means (1) or (1 or 2).
• In 6.4, why /url/?  This is really confusing--I was halfway through
• this section, and kind of confused, before I realized that the slashes
• were for emphasis, and weren't path separators.
• Also in 6.4, the text does not account for the case where there's a
• user part to the authority section of the URI.
• Adrian Farrel: Comment [2013-04-29 07:34]:
  I want to thank the authors and WG for producing this specification. I
• think it may be one of the more important pieces of work in recent
• years. As might be expected with a document of over 100 pages reviewed
• by a pedant, I have a list of nits and worries. These are all enetered
• as Comments: I hope you will find time to address them and make the
• resulting RFC more polished, but none of them comes even close to a
• requirement that you change the text, and I am ballotting Yes.
• ---
• How quickly we forget!
• I looked up the spec of a typical home computer around the time of HTTP
• v1.0 and discovered that it was not so very different from what you are
• scoping your environment to today.
• That is not to say that your work is not valid. Far from it! But I do
• believe it might be helpful to explore in more detail why you don't
• simply run an early, low-function version of HTTP.
• FWIW, I believe the answer is that you want some of the advanced
• functions that have been added to HTTP over the years, but do not want
• the full family of rich features that may chew memory and bandwidth.
• ---
• What about the use of CoAP on the wider Internet?
• ---
• A very minor terminology point from Section 1.2
•   Confirmable Message
•       Some messages require an acknowledgement.  These messages are
•       called "Confirmable".  When no packets are lost, each Confirmable
•       message elicits exactly one return message of type Acknowledgement
•       or type Reset.
•   Non-confirmable Message
•       Some other messages do not require an acknowledgement.  This is
•       particularly true for messages that are repeated regularly for
•       application requirements, such as repeated readings from a sensor.
• You have picked a form "confirmable" and "non-confirmable" tha expresses
• the ability to do something: this message can be confirmed.
• But you have mapped the form to a description that requires action: an
• acknowledgement must be sent.
• "Can be confirmed" != "A confirmation must be sent"
• "Cannot be confirmed" != "A conformation does not need to be sent"
• I don't believe this is too important because you are defining the tems,
• but I do think that the casual reader will not embed your redefinitions
• of normal English words, and so will be confused by these terms in the
• text.
• ---
• Section 1.2. Also a very minor point.
•   Acknowledgement Message
•       An Acknowledgement message acknowledges that a specific
•       Confirmable Message arrived.  It does not indicate success or
•       failure of any encapsulated request.
• The fact that and Acknowledgement Message can carry a response is lost
• in this definition. Maybe you need (including fixes to your typos)...
•   Acknowledgement Message
•       An Acknowledgement Message acknowledges that a specific
•       Confirmable Message arrived.  Of itself, an Acknoweledgement
•       Message does not indicate success or failure of any request
•       encapsulated in the Confirmable Message, but the Acknoweledgement
•       Message may also carry a Piggy-backed response (q.v.).
• ---
• My feeling was that the Message IDs shown in figures 2 through 6 were
• confusing in their randomness. For example, you could spend a lot of
• time staring at figures 2 and 3 trying to work out how CON is encodeded
• as 0x7d34 while NON is encoded as 0x01a0.
• Since you want to show Message IDs to show how they correspond on
• different parts of the flow, you could have written, e.g.,
•                         Client              Server
•                             |                  |
•                             |   CON [MsgID1]   |
•                             +----------------->|
•                             |                  |
•                             |   ACK [MsgID1]   |
•                             |<-----------------+
•                             |                  |
• ---
• Section 2.1
•   As CoAP is based on UDP, it also supports the use of multicast IP
• I don't think it is based on UDP. I think it runs over UDP.
• ---
• Section 2.3
•   As CoAP was designed according to the REST architecture and thus
• Maybe insert another pointer to [REST].
• ---
• Section 4.2
•   A Confirmable message
•   always carries either a request or response and MUST NOT be empty,
•   unless it is used only to elicit a Reset message.
• That is a bit of an over-use of "MUST NOT". I think
•   A Confirmable message
•   always carries either a request or response, unless it is used only
•   to elicit a Reset message in which case it is empty.
• ---
• Section 4.2
•   A CoAP endpoint that sent a Confirmable message MAY give up in
•   attempting to obtain an ACK even before the MAX_RETRANSMIT counter
•   value is reached: E.g., the application has canceled the request as
•   it no longer needs a response, or there is some other indication that
•   the CON message did arrive.  In particular, a CoAP request message
•   may have elicited a separate response, in which case it is clear to
•   the requester that only the ACK was lost and a retransmission of the
•   request would serve no purpose.  However, a responder MUST NOT in
•   turn rely on this cross-layer behavior from a requester, i.e. it
•   SHOULD retain the state to create the ACK for the request, if needed,
•   even if a Confirmable response was already acknowledged by the
•   requester.
• This paragraph is giving me some worries.
• I think the initial MAY confuses the CoAP implementation with the
• endpoint containing the CoAP implementation.  The endpoint may give up,
• and may instruct the CoAP implementation to stop retransmitting.  But I
• think a CoAP implementaiton must not give up unless it is told to.
• The drop from MUST NOT to SHOULD in the final sentence seems odd. My
• understanding was that a CoAP implementation MUST always retain the
• state to create the ACK for the request.  Is this use of SHOULD a
• relaxation, and how does it square with the MUST NOT?
• ---
• Section 4.6
•   Messages
•   larger than an IP fragment result in undesired packet fragmentation.
• s/undesired/undesirable/  ?
• ---
• Section 4.6
•   A CoAP message, appropriately encapsulated, SHOULD fit within a
•   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
•   one UDP payload) obviously MUST fit within a single IP datagram.
• s/MUST/will/
• ---
• Section 12
• I am surprised that IANA was relaxed about the use of "reserved" in
• Section 12.
• For example, in 12.1 you have two ranges marked "Reserved" without any
• clue to what this means. For example, does it mean that allocations can
• be made, that an RFC can dedicate them to a new use, or that they must
• never be allocated?
• In 12.1.2 you have
•   The Response Codes 96-127 are Reserved for future use.  All other
•   Response Codes are Unassigned.
• I take "Unassigned" to mean available for assignment according to the
• policy for the registry. But "Reserved or future use" means what?
• In 12.2 you have
•                   |      0 | (Reserved)     |           |
• This is the meaning of "reserved" I think we are used to, and means will
• not be made available for allocation. (Although I am puzzled that you
• don't include the pointer to this RFC.)
• Richard Barnes: Comment [2013-05-15 09:06]:
  Overall, this is a very nicely written specification.  Thanks!
• In Section 2.2., are requests and responses in 1-1 correspondence?  Or can a
• single request receive more than one response?
• In Section 3, why is version number 1 and not 0?  What's the plan here, do we
• get 3 or 4 versions out of this?
• In Section 4.3, would it make sense to have something stronger than MAY for
• cases where future messages are likely to be screwed up, e.g., where CoAP
• syntax is malformed?  (A "STFU RST"?)
• From Section 4.2 and 4.3, I generated a table mapping message types to
• request/response/empty:
•             CON NON ACK RST
• Request     X   X   ?   !
• Response    X   X   X   !
• Empty       !   !   X   X
• Might be helpful to include something like that as a summary.  This might be a
• bad idea, but: Did the WG consider allowing an ACK to contain a request?  In
• the case where a CON contains a response and the client wants to send another
• request, it would save a message to put the request in the ACK to the response.
• Stephen Farrell: Comment [2013-05-26 13:54]:
  Thanks for addressing my discuss points. I've left the comments
• in below from last time, but didn't check 'em against -17.
• --- former discuss points
• (1) I think you made a change to 5.6 for this but I still
• think (now at COMMENT level) that it'd be really good to say
• that CoAP is currently well defined only for URI schemes like
• coap(s) and http(s) but maybe not others. Basically, you need
• a scheme://host:port syntax or else you have to do some more
• specification work to get CoAP interop.
• (3) You now say "SHOULD use 32 bits of randomness" which
• is ok. I think it might be worth adding that CoAP nodes
• that might be targetted with many guesses SHOULD also
• detect and react to that.
• Text of discuss (3) was:
• 4.2, last para: this creates an attack that can work
• from off-path - just send loads of faked ACKs with guessed
• Tokens and some of 'em will be accepted with probability
• depending on Token-length and perhaps the quality of the RNG
• used by the sender of the CON. That could cause all sorts of
• "interesting" application layer behaviour. Why is that ok?
• (Or put another way - was this considered and with what
• conclusion?) I suspect you need to have text trading off the
• Token length versus use of DTLS or else CoAP may end up too
• insecure for too many uses. (Note: the attack here is made
• worse because the message ID comparison can be skipped.
• Removing that "feature" would help a lot here.) 5.3.1's
• client "may want to use a non-trivial, randomized token"
• doesn't seem to cut it to me. How does this kind of
• interaction map to DTLS sessions/epoch? Basically, I'd like
• to see some RECOMMENDED handling of token length that would
• result in it not being unsafe to connect a CoAP node to the
• Internet. (And please note recent instances where 10's of
• thousands of insecure devices have been found via probing
• the IPv4 address space. These are real attacks.)
• (4) 4.4, implementation note - this seems unwise since it
• means that once Alice has interacted with Bob, then Bob can
• easily guess the message IDs that Alice will use to talk to
• Charlie. This is no longer a DISCUSS because you said that
• the WG figure its ok and given you say to randomise at
• the start (of what?) then its marginal.
• --- old comments below, sorta checked against -16
• intro, 2nd para: better to not talk about the WG name and
• its work really, but about the resulting protocol
• intro, last para: more sales pitch language
• 3: Message ID - with 16 bits that imposes a rate limit on
• how often you can send. I don't think that's described and
• I'm curious as to whether it'd set to max goodput for CoAP
• that'd be way less than otherwise possible with e.g. HTTP.
• - I think in a mail Carsten said its 250/second max or
• something, I still think this'd be great information to
• say explicitly early on in the spec since it might prevent
• someone spending a lot of effort before they find out that
• CoAP doesn't work for their use-case.
• 7.1 - what if I want to only do discovery via DTLS? What
• does "support" mean for port 5683 then? Carsten said that
• you do need to still listen on 5683 even if you only
• want to do work on <TBD>. I'm not so happy about that but
• its not DISCUSS level.
• 12.7 - as it turns out I also don't see why this needs
• two ports - the cost is two more bytes for security which
• is significantly-enough less than the current cost (in
• terms of message size) for security. Am I wrong? Carsten
• responded: "yep, that's what we want" and I'm ok with that,
• if not convinced.
• Martin Stiemerling: Comment [2013-07-01 05:36]:
  -18 addresses all of my concerns and thank you for addressing them!
• Jari Arkko: Comment [2013-05-16 06:51]:
  Thank you for this important work and well written specification. While there
• are aspects that I would personally have done differently and some fine-tuning
• of the spec could continue, I believe the document is ready to move to an RFC.
• I also believe it that is a much-awaited spec and very useful to the Internet
• community in its current state.
• I do agree with some of the points raised in other reviews, and those need to
• be addressed.
• I did have one specific additional suggestion worth bringing up here. Dan
• Romascanu did a Gen-ART review and raised the issue that the parameter changes
• discussed in S4.8.1 are security sensitive, i.e., changes in the parameters may
• cause security/denial-of-service issues. This should be noted somewhere in the
• S11. I'd make a brief observation that it is security sensitive and should be
• addressed in any system that allows configuration of these parameters.
• Here's what Dan wrote:
• 3. Section 4.8 defines a number of CoAP protocol parameters and derived
• parameters that according to 4.8.1 may be changed. Some of these parameters
• have limitations and their changes may affect the basic functionality of the
• nodes, the interaction between nodes or between nodes and servers, as well as
• the functioning in constrained environments. However there is no risk analysis
• in Section 11 (Security Considerations) about the threats related to
• mis-configuration of the modes and un-appropriate or malevolent changes in
• these parameters, and recommendations of security counter-measures on this
• respect.
• Pete Resnick: Comment [2013-06-28 11:55]:
  Thanks for addressing my more serious concerns. Nothing blocking, but for your
• consideration:
• By section number:
• 4.2/4.3: "Reject" in the sense it is talked about in these sections is an
• internal state change. That's confusing to me, as the normal sense of the
• English word implies a party that "hears about" the rejection. (It's hard to me
• to think of a circumstance where someone or something was "rejected" and only
• the rejector ever knew about it.) In your use, "silently ignore" is one
• possible form of rejection. That's just weird.
• If you're going to do this, I'd define the term up front. Maybe even capitalize
• "Reject" wherever you use it.
• Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's
• an internal state and nothing a protocol requirement is useful for) and "MAY
• involve sending" is a strange construction.
• 4.5: I think the MAYs confuse things and might encourage implementers to take
• that path. Instead of:
•   This rule MAY be relaxed in case
•   the Confirmable message transports a request that is idempotent (see
•   Section 5.1) or can be handled in an idempotent fashion.  Examples
•   for relaxed message deduplication:
• I suggest: "Exceptions to this are when the Confirmable message transports a
• request that is idempotent (see Section 5.1) or can be handled in an idempotent
• fashion.  Examples of these exceptions:". Also:
•   As a general rule that MAY be
•   relaxed based on the specific semantics of a message, the recipient
•   SHOULD silently ignore any duplicated Non-confirmable message, and
•   SHOULD process any request or response in the message only once.
• I suggest: "The recipient SHOULD silently ignore any duplicated Non-confirmable
• message, and SHOULD process any request or response in the message only once,
• though the specific semantics of the message might dictate an exception."
• 4.6: I feel like this section is really one big implementation note: Because it
• is a layer violation, it's not clear to me that any implementer has the ability
• to figure out much of this. (For example, the idea that an implementer would be
• willing to -- or even know how to -- set the Do Not Fragment bit or figure out
• the Path MTU is a bit hopeful.) I have no objection to this section, but it
• might be better as an implementation note rather than a set of protocol
• instructions.
• 5.3.2: Change "the client will likely send a Reset message so it does not
• receive any more retransmissions" to "the client will send". A client that has
• lost state that receives what it will see as a random CON message will always
• send back a Reset.
• 5.4.6: If it were me, I would have put the NoCacheKey bits in the high four
• bits of the most significant byte so that you could simply do a <224 test for
• cache-matching options. I suppose this ship has sailed.
• 5.5.1: The implementation note notwithstanding, I don't understand why
• Content-Format is not a SHOULD.
• 8.1:
•   A server SHOULD be aware that a request arrived via multicast, e.g.
•   by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if
•   available.
• That SHOULD is not meaningful. It is useful, not required with exceptions (as
• SHOULD indicates), for the server to know that it is using multicast.
• This also gives a reason not to allow RST on *any* NON messages.
• 12.1: I think it would be much easier to figure these out if you separated out
• the bit fields of code type and code, and then had sub-registries for request
• codes, success codes, client error codes, and server error codes.
• Benoit Claise: Comment [2013-05-16 07:25]:
  I lacked some time to review the draft details. However, after a discussion
• with Joel Jaeggli, and with the OPS DIR review from Mehmet, I trust that the
• OPS aspects have been taken care of.
• Spencer Dawkins: Comment [2013-05-20 23:12]:
  On 5/20/2013 3:35 PM, Carsten Bormann wrote:
• > Spencer,
• >
• > thank you for this attentive review.
• > I have done some of the changes as simple editorial fixes, these are
• > marked like [1373] below and can be reviewed in
• > http://trac.tools.ietf.org/wg/core/trac/changeset/1373
• > (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).
• Hi, Carsten,
• Thank you for the quick and careful response.
• We've discussed my DISCUSS, so I'm changing my ballot position to YES (but
• please make Martin happy on his transport-ish DISCUSS :-).
• I have a couple of places where I've suggested text that seems clearer to me,
• but I moved these to COMMENTs on my ballot.
• > Grüße, Carsten
• >
• >         
• ---------------------------------------------------------------------- >       
•   DISCUSS: >         
• ---------------------------------------------------------------------- > >     
•     Note that I plan to ballot Yes, after we resolve these questions. > >      
•   I have three points - the first one is the one I'm most curious about. > >  
•       In 4.8.1.  Changing The Parameters > >            It is recommended that
• an >            application environment use consistent values for these
• parameters. > >          I'm thinking about this in an IOT/M2M context where
• it's somewhere >          between inconvenient and impossible to change
• parameters on all the >          deployed devices at once. I understand that
• configuring these parameters >          is out of scope for the doc, so assume
• changing the parameters is out of >          scope as well. > > Yes.  The
• assumption is that implementations better don't start > changing the parameters
• until there is a good way to do so. > >          If you start deploying new
• devices into that environment with >          significantly different
• parameters, is it more likely that performance >          would suffer, or that
• something would break? (I don't care what the >          answer is, I'd just
• like for the reader to have one - do you HAVE to get >          the parameters
• right the first time, or do you WANT to get them right, >          but you can
• deploy new devices with different parameters and let the old >          devices
• be removed/replaced over time?) > > The answer is different for each parameter
• and for the direction in > which you change it.  I don't think we can provide
• all the definitive > answers in this document.
• For "changing the parameters" above ... I think what you're saying in your
• response to me is more helpful than the way I read the text in -16. If I'm
• understanding correctly, the situation is
• - the specification doesn't include a way to change parameters without a "flag
• day", and
• - if an application environment uses consistent parameters, everything will
• work, but
• - if an application environment doesn't use consistent parameters, what happens
• next is out of scope for this specification (and, for extra credit, is
• unpredictable)
• As a COMMENT, I'd be more comfortable if
•     It is recommended that an
•     application environment use consistent values for these parameters.
• continued to say "Operation with inconsistent values in an application
• environment is outside the scope of this specification", or something like that.
• As an aside, also as a COMMENT ... I am now noticing that the specification has
• "recommended" in lower case. If you were telling me it's "RECOMMENDED = SHOULD
• = do it this way unless you're sure what you're doing, and if you think you
• know what you're doing, but you break it, you own it", I'd be more comfortable.
• That's consistent with the way I read this text in 2119:
• 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
•   may exist valid reasons in particular circumstances to ignore a
•   particular item, but the full implications must be understood and
•   carefully weighed before choosing a different course.
• >          This one is on the edge of being a Comment:
• >
• >          In 5.10.5.  Max-Age
• >
• >            The value is intended to be current at the time of transmission.
• >            Servers that provide resources with strict tolerances on the value
• of >            Max-Age SHOULD update the value before each retransmission. > >
•         Will servers know that resources they serve have strict >         
• tolerances? > > Yes.  It is typically in the nature of a resource to be
• replaced > periodically (e.g., the ECB exchange rate -- this has a very
• specific > Max-Age) or be on a more unpredictable basis.  In the CoRE model, >
• servers generally should be aware about the nature of the resources > they are
• serving. > >          The >          answer may be "yes", I'm just asking. If
• not, I'm wondering if this >          should be a MUST. > > Because both the
• condition on the SHOULD and the desired behavior are > very much local matter,
• a MUST won't have a much different outcome > here.  Maybe the SHOULD should be
• turned into a non-RFC 2119 > implementation guidance recommendation.
• Your explanation was very helpful to me. I'm fine with SHOULD as 2119 language
• here - that matches what I'm hearing you say.
• >          This one is on the edge of being a comment:
• >
• >          In 7.2.  Resource Discovery
• >
• >            The discovery of resources offered by a CoAP endpoint is extremely
• >            important in machine-to-machine applications where there are no
• >            humans in the loop and static interfaces result in fragility.  A
• CoAP >            endpoint SHOULD support the CoRE Link Format of discoverable
• >            resources as described in [RFC6690]. > >          Is it obvious
• that this is a SHOULD? Is CoRE Link Format necessary for >          resource
• discovery, or can you also accomplish this with humans if >          they're in
• the loop? I'm just trying to wrap my head around "it's >          extremely
• important but implementations might not do it". > > This is more of a policy
• statement, a statement of expectation: If you > want to be part of the CoRE
• ecosystem, do CoAP and do RFC 6690, > because that will maximize
• interoperability.  So this may be another > SHOULD abuse.  (But it does impact
• interoperability!)
• This is very helpful. What I wasn't getting was whether there was any way other
• than CoRE Link Format to discover resources when there are no humans in the
• loop.
• Again, as a COMMENT, I'm reading this response as "SHOULD support the CoRE Link
• Format of discoverable resources as described in [RFC6690] if there are no
• humans in the loop, to maximize interoperability". Am I getting that right?
• And if this is a statement of expectation, I'm OK with SHOULD, if the working
• group thinks that's appropriate.
• >         
• ---------------------------------------------------------------------- >       
•   COMMENT: >         
• ---------------------------------------------------------------------- > >     
•     I think this specification is well-written, it's important, and a lot of > 
•         people will need to read it - that's why I'm being picky on comments. >
• >          Martin already has a DISCUSS about some of the more transport-ish
• topics >          (support for UDP-lite, etc.). I'm sympathetic, but didn't
• restate them. >          If Martin is happy, I'll be happy. > >          In
• this text: >            Constrained networks like >            6LoWPAN support
• the expensive fragmentation of IPv6 packets into >            small link-layer
• frames. > >          Is "support" the right word here? I'm not understanding
• "support the >          expensive fragmentation". > > 6LoWPAN has a mechanism
• for ("supports") sending IPv6 packets that are > larger than the link layer
• packet size.  This mechanism is expensive > in the sense that it reduces
• performance similar to the way > fragmentation often does.
• So I should be reading this as something like "Constrained networks like
• 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames,
• but this mechanism is expensive in that it reduces performance"?
• >
• >          In this text:
• >            Although CoAP could be used for
• >            compressing simple HTTP interfaces
• >
• >          Is "compressing ... interfaces" the right way to say this?
• >
• > No.  [1385]
• Ack.
• >          I've seen other reviewers mention "short messages" in "CoAP is based
• on >          the exchange of short messages", but it may also be worth clearly
• >          distinguishing "short message" from "SMS" ("short message service")
• - as >          I understand it, the two phrases have nothing in common, but
• they are >          both used in the document (at the beginning of Section 3,
• and even in the >          same paragraph) without qualification. > > Oh.  Good
• catch.  [1373]
• Ack.
• >            Response codes
• >            correspond to a small subset of HTTP response codes with a few CoAP
• >            specific codes added, as defined in Section 5.9.
• >
• >          I get this, but I'm wondering if it's worth thinking about whether
• these >          similar but unrelated namespaces can semi-collide (if HTTP is
• extended to >          include a 328 response code, is it OK for CoAP to define
• a 3.28 response >          code that means nothing like what HTTP 328 means?)
• Given that 404 and >          4.04 are similar, for example, I'd expect some
• implementers to guess what >          less common CoAP response codes are,
• based on HTTP response codes, rather >          than check carefully. That's an
• obscure comment, but I thought I should >          ask. > > We already deviate
• from a strict one-to-one correspondence with HTTP > (e.g., we have a 2.05 where
• HTTP uses 200).  So "correspond" may > indeed be too strong.  [1386]
• Ack.
• >          In 6.4.  Decomposing URIs into Options, is "fail this algorithm"
• clear? >          It might be a term of art for HTTP folk, but I'm not familiar
• with it. > >            4.  If |url| has a <fragment> component, then fail this
• algorithm. > > Indeed, this is hixiefied speak (right out of text in the
• versions of > the websockets spec that were current when we wrote this, and
• still in > HTML5).  It might be shorter to just say "fail", but the intent is
• not > for the node to blow up in smoke, but to specifically fail the >
• algorithm defined in this section (as explained in the introduction to > 6.4).
• No, I think you're doing this right (thanks for the clue!).
• >          In 8.1.  Messaging Layer
• >
• >            When a server is aware that a request arrived via multicast, it
• MUST >            NOT return a RST in reply to NON.  If it is not aware, it MAY
• return >            a RST in reply to NON as usual. > >          Doesn't this
• tell me that the MUST NOT is not required for >          interoperability? I'm
• only quibbling about the use of 2119 >          language. > > This hand-waving
• is a reaction on a specific restriction of the POSIX API > that I don't wish on
• anyone.  "Please avoid using RFC3542-challenged > environments.  But if you
• have to (.NET?)..." > >          On a >          related point, if there was a
• sentence that started out "to keep Bad >          Thing X from happening, ..."
• that would be helpful. > > Good point.  [1387]
• Ack.
• >          There's similar language in 8.2.  Request/Response Layer
• >
• >            When a server is aware that a request arrived via multicast, the
• >            server MAY always ignore the request, in particular if it doesn't
• >            have anything useful to respond (e.g., if it only has an empty
• >            payload or an error response).
• >
• >          but MAY is pretty weak anyway (maybe "can always ignore the
• request", to >          avoid the 2119 question?). > > This is trying to say
• that the peer has to be able to cope with the > "MAY"-type behaviour described,
• so it does affect interoperability and > I think 2119 language is appropriate
• here.
• I understand why you're using 2119 language now. I'm not sure I understand how
• the requirement for the peer is different from either the request or response
• getting lost.
• I'm reading the spec as saying that multicast requests are sent as
• non-confirmable at the messaging layer, so if there's no confirmation at the
• messaging layer and no response from the server at the request/response layer,
• does the peer see any difference between hearing nothing back because something
• was lost, and hearing nothing back because the server had nothing to say?
• >          In 11.3.  Risk of amplification
• >
• >            This is particularly a problem in nodes that enable NoSec access,
• >            that are accessible from an attacker and can access potential
• victims >            (e.g. on the general Internet), as the UDP protocol
• provides no way >            to verify the source address given in the request
• packet.  An >            attacker need only place the IP address of the victim
• in the source >            address of a suitable request packet to generate a
• larger packet >            directed at the victim.  Such large amplification
• factors SHOULD NOT >            be done in the response if the request is not
• authenticated. > >          I don't understand what the SHOULD NOT means in
• practice. Is this saying >          the server shouldn't return large resources
• for NoSec requests (whatever >          "large" means), or ? If this is saying
• the same thing as the text on >          using "slicing/blocking mode" two
• paragraphs, down, it would be clearer >          to combine these points in a
• single paragraph. > > Well, it is leading into it, and you just have to read
• one more > paragraph before it comes...  (I'm still optimistic that at least
• some > implementers read a whole section before writing code.) > [ceterum
• censeo deploy BCP38...]
• My apologies for not being clearer in my comment.
• I'm looking at this text:
•   This is particularly a problem in nodes that enable NoSec access,
•   that are accessible from an attacker and can access potential victims
•   (e.g. on the general Internet), as the UDP protocol provides no way
•   to verify the source address given in the request packet.  An
•   attacker need only place the IP address of the victim in the source
•   address of a suitable request packet to generate a larger packet
•   directed at the victim.  Such large amplification factors SHOULD NOT
•   be done in the response if the request is not authenticated.
• [annoyingly distracting paragraph deleted here]
•   A CoAP server can reduce the amount of amplification it provides to
•   an attacker by using slicing/blocking modes of CoAP
•   [I-D.ietf-core-block] and offering large resource representations
•   only in relatively small slices.  E.g., for a 1000 byte resource, a
•   10-byte request might result in an 80-byte response (with a 64-byte
•   block) instead of a 1016-byte response, considerably reducing the
•   amplification provided.
• and I'm not seeing
• - the SHOULD NOT, which is conditional on whether the request is authenticated,
• and
• - the subsequent suggestion to use slicing/blocking, which is not conditional
• on authentication, seamlessly hooked together.
• Is the intention that the recommendation to use slicing/blocking be conditional
• on authentication, or should the server always use slicing/blocking whether the
• request is authenticated or not?
• Is that clearer? ("writing text is hard" :-)
• Spencer
• Brian Haberman: Comment [2013-04-23 08:27]:
  Thank you for a well-written document.  I do support Pete's DISCUSS points.
• Stewart Bryant: Comment [2013-04-24 09:12]:
  I am entering no-objection on the basis that this has no impact on the routing
• layer and I am confident that the applications layer ADs will ensure the
• quality of the design.
• Sean Turner: Comment [2013-07-08 07:35]:
  Hey thanks for doing an excellent job addressing my comments.  Looking forward
• to progressing this one down the standards track ;)
• Joel Jaeggli: Comment [2013-04-24 22:45]:
  I support some of the points raised by mehmet against draft 13 (addressed by
• carsten) which ultimately are not likely to be resolved by the this draft alone.
• > ** Concerning the migration path, and future versions of CoAP in the same
• network: > > - It would be useful to state clearly, in which cases it is
• dangerous to change any of the recommended default values or parameters in
• future versions of CoAP and would potentially impact the co-existence of two
• CoAP versions. Thus such a statement would support an incremental deployment to
• be successful.
• Again, I believe this is future work, which also applies for the configuration
• and management data model.
• Protocol debugging is aided by the self-describing nature of the protocol
• messages. This has worked pretty well in the (informal and formal) interops so
• far.
• Future work will have to address management interfaces for CoAP nodes,
• including management of security related events. I think some of this will have
• to integrate with resource discovery, an active subject in the working group.
• Grüße, Carsten
• ---
• this is not a dicuss because frankly I think at some point you have to draw a
• line under work that has been done so far and progress work from there.

draft-ietf-lisp-mib

• Adrian Farrel: Discuss [2013-07-07 14:55]:
  Two relatively small and easy-to-fix Discuss points
• While it is not against the allocation policy to assign this module
• under mib-2, I should have thought that given the Experimental nature
• of this work, it would be better placed under 1.3.6.1.3 experimental.
• Please let me know that this was considered and sicussed with the MIB
• Doctor.
• ---
•       lispUseProxyEtrAddressLength OBJECT-TYPE
•           SYNTAX     Integer32 (5..259)
•           MAX-ACCESS not-accessible
•           STATUS     current
•           DESCRIPTION
•               "This object is used to get the octet-length of
•               lispUseProxyEtrAddress."
•           ::= { lispUseProxyEtrEntry 1 }
•       lispUseProxyEtrAddress OBJECT-TYPE
•           SYNTAX     LispAddressType
•           MAX-ACCESS not-accessible
•           STATUS     current
•           DESCRIPTION
•               "Address of Proxy ETR configured on this device."
•           ::= { lispUseProxyEtrEntry 2 }
• ...but...
• LispAddressType ::= TEXTUAL-CONVENTION
•     DISPLAY-HINT "39a"
•     SYNTAX OCTET STRING (SIZE (5..39))
• So what would it mean if lispUseProxyEtrAddressLength had length 40?
• Adrian Farrel: Comment [2013-07-07 14:55]:
  The RFC Editor will want the Introduction to be Section 1.
• ---
• Section 2
•   This draft describes the Management Information Base (MIB) module for
• s/draft/document/
• ---
• I think the document would benefit from a description of how SNMP is
• exepected to work across the locator/ID separation.
• ---
• Section 7
• The Imports clauses have comments that are direct citations. The same
• applies to some Description clauses.  This is generally not done because
• when the module is extracted (which it often is) the references section
• is lost.
• ---
• Time to clean up idnits before passing this to the RFC Editor?
• Shepherd write-up says
•   I checked the ID nits and there are no warning or errors.
• However, idnits shows me an unused reference.
• ---
•     lispMappingDatabaseTable OBJECT-TYPE
•         DESCRIPTION
•             In general, this table would be representative of all
•             such mappings for the given LISP site to which this device
•             belongs."
• In general?
• ---
•     lispFeaturesInstanceID OBJECT-TYPE
•         MAX-ACCESS not-accessible
•         DESCRIPTION
•             "This represents the Instance ID of the LISP header.
•             An Instance ID in the LISP address encoding helps
•             uniquely identify the AFI-based address space to which
•             a given EID belongs. It's default value is 0."
•         DEFVAL { 0 }
• How does a defualt for a not-accessible object work?
• ---
• Truth values. For example...
•     lispFeaturesRlocProbeEnabled OBJECT-TYPE
•         SYNTAX     TruthValue
•         MAX-ACCESS read-only
•         STATUS     current
•         DESCRIPTION
•             "Indicates the status of rloc-probing feature on this
•             device.  If this object is TRUE, then this feature is
•             enabled."
•         ::= { lispFeaturesEntry 12 }
• I think it is normal to use lower case "true" and "false" to be
• consistent with the definition of TruthValue.  In text, it is even
• preferable to use "true(1)" and "false(2)".
• ---
•     lispFeaturesRouterTimeStamp OBJECT-TYPE
•         MAX-ACCESS read-only
•         DEFVAL { 0 }
•     lispMappingDatabaseTimeStamp OBJECT-TYPE
•         MAX-ACCESS read-only
•         DEFVAL { 0 }
• ...etc.
• How does a default for a read-only object work?
• ---
•     lispMappingDatabaseDecapOctets OBJECT-TYPE
•         SYNTAX     Counter64
•         MAX-ACCESS read-only
•         STATUS     current
•         DESCRIPTION
•             "The number of octets of LISP packets that were decapsulated
•             by this device addressed to a host within this EID-prefix.
• Is it clear that this count is after decapsulation?
• ---
• The name of the LispAddressType TC is confusing. The TC may have the
• address type embedded in it, but the TC is actually used to define
• objects that contain addresses. LispAddress would be a better name.
• Stephen Farrell: Comment [2013-07-10 03:28]: 
• I didn't go back and re-read the LISP RFCs so there might be
• nothing here, but did anyone really check whether or not the
• information exposed here about mappings could assist a bad
• actor in mounting an attack against a LISP deployment?
• My concern is that the base LISP RFCs could have an inbuilt
• assumption that the mapping tables aren't known to all
• attackers, but this does expose some of that, and that might
• make an attack feasible that previously was not, e.g.  by
• reducing the size of a space from which a bad actor would
• have to guess values. If someone tells me that "yes, we
• looked at that and its ok" that'll be fine. If you didn't
• look, it'd be great if someone could do that now just in
• case since it could be painful later if something does turn
• up.
• There are a few nits in the secdir review [1] that are worth
• a look, and one change that the authors said they want to
• make.
•   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04038.html
• Benoit Claise: Comment [2013-07-10 13:16]:
  - Section 5
•       Provide a means for obtaining (read-only) a current status of LISP
•       features enabled on a device, and (read-only) a current status of
•       configuration attributes related to those features.  (This MIB
•       provides read-only capabilities; it does not provide any
•       capablities for setting or changing features.)
• I'm confused by "provides read-only capabilities". Please change this
• sentence.
• These are not capabilities, but a list of enabled/disabled features.
•     lispFeaturesTable OBJECT-TYPE
•         SYNTAX     SEQUENCE OF LispFeaturesEntry
•         MAX-ACCESS not-accessible
•         STATUS     current
•         DESCRIPTION
•             "This table represents the ON/OFF status of the
•             various LISP features that can be enabled on LISP devices."
• "Capabilities" means: I support A, B, C, D, ...
• This is at least what the capabilities tables in previous MIB tables meant.
• lispFeaturesTable means: A, B, and D are enabled.
• - I was (slightly) confused by the fact that you combine parameters
• (lispFeaturesMapCacheSize, lispFeaturesMapCacheLimit) in a
• lispFeaturesTable
• - I agree with Adian's comments (not DISCUSS) regarding the MIB module
• Editorial
• Section 5:
• s/meachanism/mechanism
• Barry Leiba: Comment [2013-06-27 07:24]:
  Totally ignorable, completely non-blocking comments here:
• In Section 5... I get the impression that all this stuff is read-only.  Is that
• right?  You don't say it enough. OK, sorry for the light sarcasm: seriously, I
• think it would be adequate to say it only in the first sentence, and get rid of
• the other instances, as the section as a whole isn't long:
•   The objectives for this LISP MIB module are to provide a read-only
•   meachanism to support the functions below.  All objects in this MIB
•   are read-only; there is nothing writeable here.
• In Section 9... As there's recently been a discussion of how "RECOMMENDED" can
• be a problematic 2119 key word, and as its use here seems strained, forcing
• passive voice unnecessarily, I suggest (again, completely non-blocking, so
• ignore me if you particularly like it as it is, but I think it reads better
• this way):
• - Implementers SHOULD consider the security features as provided by the SNMPv3
• framework.
• - Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.  Deployment
• SHOULD be SNMPv3 with cryptographic security enabled.
• Sean Turner: Comment [2013-06-28 14:00]:
  The MIB doctors boilerplate for security has changed ever so slightly:
• http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
• The big change is the 2nd to last paragraph needs to be:
•   Implementations SHOULD provide the security features described
•   by the SNMPv3 framework (see [RFC3410]), and implementations
•   claiming compliance to the SNMPv3 standard MUST include full
•   support for authentication and privacy via the User-based Security
•   Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826].
•   Implementations MAY also provide support for the Transport Security
•   Model (TSM) [RFC5591] in combination with a secure transport such
•   as SSH [RFC5592] or TLS/DTLS [RFC6353].

draft-ietf-l2vpn-pbb-vpls-pe-model

• Ted Lemon: Comment [2013-07-11 05:55]:
  I think the authors should consider whether the density of acronyms in this
• document is something that should be continued going forward. I am impressed
• that Barry found this document easy to read.
• I am not proposing that any changes be made to this particular document at this
• late date, but I would like to encourage the authors to consider a different
• balance in future documents. For instance, why is pseudowire abbreviated PW? 
• SA is used twice in the document; why not write "source address"?
• Generally speaking you should abbreviate things that are used so frequently
• that it's clunky to spell it out each time, and spell everything else out so
• that the reader doesn't spend more time flipping back and forth between the
• text and the glossary than actually reading.
• It's possible that all these terms are used so frequently by practitioners that
• there's no problem, so maybe I am making too much of this, but I found that the
• excessive use of acronyms in this document had a really negative impact on
• readability.
• Barry Leiba: Comment [2013-07-02 16:47]:
  I found this to be an easy-to-read document that was informative for someone
• not immersed in this technology.  Good work.
• Spencer Dawkins: Comment [2013-07-10 15:27]:
  Like Barry, I thought this was very readable (especially given the long strings
• of hyphenated uppercase letters that are in every spec in this space :-)
• I had a couple of non-blocking comments for readability, and one question for
• the ADs (again, not blocking, just checking my own understanding of How Things
• Are Done).
• In Abstract
•   IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines
•   an architecture and bridge protocols for interconnection of multiple
•   Provider Bridge Networks (PBNs). PBB was defined in IEEE as a
•   connectionless technology based on multipoint VLAN tunnels.  PBB can
•   be used to attain better scalability in terms of number of customer
•   MAC addresses and number of service instances that can be supported.
• Did I miss where you said "better than $WHAT"? I'm sure you had something in
• mind ...
• 4. Packet Walkthrough
•   Because of text-based graphics, the Figure 3 only shows PWs on the
•   core-facing side; however, in case of MPLS access with spoke PWs, the
•   PE reference model is simply extended to include the same PW
•   Forwarder function on the access-facing side. To avoid cluttering the
•   figure, the access-side PW Forwarder (Fwdr) is not depicted without
•   loss of any generality.
• I don't think the last sentence in this paragraph means what it was likely
• intended to mean, (double negatives don't work well in English) but rather than
• try to fix it, I would suggest something like
•   Because of text-based graphics, the Figure 3 only shows PWs on the
•   core-facing side; however, in case of MPLS access with spoke PWs, the
•   PE reference model is simply extended to include the same PW
•   Forwarder function on the access-facing side. To avoid cluttering the
•   figure, the access-side PW Forwarder (Fwdr) is not depicted.
•                                                               ^
•                                     ending the sentence here
• FOR THE ADs: in 11. Contributors
•   The following authors contributed to this document: John Hoffmans
•   (KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme
•   Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent).
• We're including the organization names because they would have been on the
• front page anyway, right?

draft-ietf-ospf-manet-single-hop-mdr

• Ted Lemon: Comment [2013-07-11 06:09]:
  This is a really minor nit, because I suspect anybody (other than me) reading
• this document already knows what an LSA is before they start, but the acronym
• is heavily used and never expanded.
• Pete Resnick: Comment [2013-07-11 07:16]:
  I do not know enough about the technology to even know how the following might
• cause confusion to implementers, but I am utterly mystified by this sentence in
• section 2:
•   o  AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal
•       to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology).
• Read as 2119 terms: "AdjConnectivity must be set to 2 to avoid damage or
• interop problems, but there are special cases (unspecified here) where you
• might not do that. However, 1 is also a perfectly good value. That said, 0 must
• never be used, in order to avoid damage or interop problems, but there are
• special cases (unspecified here) where you might use 0, so long as you
• understand the implications." That sentence seems triply internally
• self-contradictory.
• Benoit Claise: Comment [2013-07-10 15:40]:
  Similarly to the Security Considerations ...
•     5. Security Considerations
•       This document describes the use of OSPF-MDR in a single-hop broadcast
•       network, and raises no security issues in addition to those already
•       covered in [RFC5614].
• I was hoping for  ...
•     6. Management Considerations
•       This document describes the use of OSPF-MDR in a single-hop broadcast
•       network, and raises no management issues in addition to those already
•       covered in [RFC5614]. It actually simplifies the management and
•       operations compared to RFC5614 because going from two-hop to a
•       single-hop implies that ...
• But wait, there are no management considerations in RFC 5614, and I don't see
• any related management documents at https://datatracker.ietf.org/wg/ospf/
• Granted, it's not fair to have a DISCUSS on this document, and it's too late
• for RFC5614, but we're left without management considerations. I'm stuck with a
• single option for now: let this document go through, but please think about
• management considerations in the future, either in the document itself, or in a
• management dedicated document specific to your technology. In this specific
• case, let me hope that draft-nguyen-manet-management will address the OSPF-MDR
• (1 hop and 2 hops)
• Spencer Dawkins: Comment [2013-07-10 20:11]:
  In 2.  Operation in a Single-Hop Broadcast Network
•   When OSPF-MDR is used in a single-hop broadcast network, the
•   following parameter settings and options (defined in [RFC5614])
•   should be used:
•   o  AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal
•       to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology).
• Is there any guidance you can give about when the choice of 1 (uniconnected)
• would be appropriate?
• I might also be curious about when the choice of 0 (full topology) would be
• appropriate, but let's start with 1 (uniconnected).

draft-ietf-straw-b2bua-taxonomy

• Ted Lemon: Comment [2013-07-11 06:45]:
  In 4.6 and 4.7, it would be helpful to expand the various CSCF acronyms, since
• it's not necessarily obvious to the reader what they stand for.
• This is a really helpful document—thanks for writing it!
• Stephen Farrell: Comment [2013-07-09 10:31]:
  - Section 5: I support Joel's dicusss - some of the very clear
• security and privacy implications of the different roles should
• be called out here. (And they're not all bad implications.) So
• I hope he's not convinced he's in the rough.
• - Section 3: a table just listing the type names with or without
• a one-line description and a pointer to the section where
• they're defined migth be useful for the reader.
• - 3.1: Why would a b2bua like this save SDP bodies? Wouldn't
• that have some privacy implications?
• - 3.2.1: A reference for "NAT behaviour" might be a good
• addition.
• - 4.6 & 4.7: lots of unexpanded acronyms, which seems like a bad
• plan for a taxonomy document (even if they're IMS terms:-)
• Richard Barnes: Comment [2013-07-08 18:24]:
  Overall, thanks for a nicely written document.  It seems like a helpful guide
• to understanding some real devices, and why they do what they do.
• C1. At the top level of Section 3.1, you say that a "Signaling-plane B2BUA"
• doesn't modify SDP bodies.  But then Section 3.1.3 describes an "SDP-modifying
• signaling-only B2BUA".  It would be helpful to be more specific at the top
• level (3.1) as to what sort of SDP modification these things *don't* do, then
• in 3.1.3 as to what sort of modifications they *do*.  It seems like the line is
• something like, "These B2BUAs don't do anything that changes the path that
• media takes (in particular, they don't insert themselves on the media path),
• but they may make SDP changes that affect what is sent on the media plane."
• C2. The jump from CSeq-only modification (3.1.1) to modification of all headers
• (3.1.2) seems a little stark.  It might be worth noting that there are lots of
• gradations in the "Signaling-only" bucket -- some have only a few intrusive
• behaviors, some edit headers heavily, often dependent on configuration -- but
• because there are not clear categories, we group them together into this bucket.
• C3. In Section 3.2.2, s/mux/multiplex/g
• C4. The top level of Section 3 says that a conference server is not a B2BUA,
• but then Section 3.2.3 lists "conference servers" among the things that are
• "Media-termination B2BUAs".  Based on Section 4.5, it seems like what you mean
• here is that *some* conference servers terminate media.  "This is the role
• performed, for example, by transcoders and some conference servers."
• Benoit Claise: Comment [2013-07-10 04:03]:
  Your terminology section is not a terminology section, it "just" listing
• acronyms. This is weak for a taxonomy document ;-) I was expecting:
•       Back-to-Back User Agent [RFC3261] : A back-to-back user agent (B2BUA) is
•       a
•         logical entity that receives a request and processes it as a
•         user agent server (UAS).  In order to determine how the request
•         should be answered, it acts as a user agent client (UAC) and
•         generates requests.  Unlike a proxy server, it maintains dialog
•         state and must participate in all requests sent on the dialogs
•         it has established.  Since it is a concatenation of a UAC and
•         UAS, no explicit definitions are needed for its behavior.
•       User Agent Client (UAC), [RFC3261]: A user agent client is a logical
•       entity
•         that creates a new request, and then uses the client
•         transaction state machinery to send it.  The role of UAC lasts
•         only for the duration of that transaction.  In other words, if
•         a piece of software initiates a request, it acts as a UAC for
•         the duration of that transaction.  If it receives a request
•         later, it assumes the role of a user agent server for the
•         processing of that transaction.
•       User Agent Server (UAS) [RFC3261]: A user agent server is a logical entity
•         that generates a response to a SIP request.  The response
•         accepts, rejects, or redirects the request.  This role lasts
•         only for the duration of that transaction.  In other words, if
•         a piece of software responds to a request, it acts as a UAS for
•         the duration of that transaction.  If it generates a request
•         later, it assumes the role of a user agent client for the
•         processing of that transaction.
• Alternatively,
•     The User Agent Client (UAC) and User Agent Server (UAS) are defined in
•     [RFC3261]. The User Agent Server (UAS) is redefined compared to [RFC3261]
•     definition:
•       Back-to-Back User Agent: a SIP Back-to-Back User Agent, which is the
•       logical combination of a User Agent Server (UAS) and User Agent Client
•       (UAC).
• Later I see
•   Furthermore, this document defines 'B2BUA' following the definition
•   provided in [RFC3261], which is the logical concatenation of a UAS
•   and UAC.
• That confuses me, specifically because I would have expecting this in the
• terminology section, and it does it "follow" the definition in RFC3261: the
• spirit maybe. I don't mind the repeat here, but the terminology section must be
• clear Close to a DISCUSS. Please engage in the discussion (if you don't plan on
• fixing this)
• Editorial:
• - Expand a few acronyms with their respective first occurrence: SBC, PBX
• Thanks for this document. It will be useful.
• Barry Leiba: Comment [2013-07-10 11:37]:
  UPDATED:
• An Applications Directorate review was just posted, and I'm sorry that it's so
• late (it was not the reviewer's fault, but a processing problem).  There's
• nothing in the review that I would mark as blocking, but the review makes a lot
• of reasonable suggestions:
• http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09960.html
• Before the document is final, please have a look at the review and address the
• suggestions that you think are good ones.
• ----------------------------------------------
• My original comments:
• There's an oddity in the shepherd writeup that I'd like to clear up, but it's
• not at the level of a blocking DISCUSS:
•   Q: Why is this the proper type of RFC?
•   A: It’s published for the general information of the Internet community,
•       and does not represent an Internet community consensus or recommendation.
• Other bits of the shepherd writeup do talk about working group consensus, so I
• presume that this is just a bad answer... but I want to be clear about the
• status of this document, which is a product of a working group and is asking to
• be published in the IETF Stream: This *is* intended to be an IETF consensus
• document, yes?
• Another very small point: the text in the Acknowledgments section is part of
• ancient boilerplate, and doesn't belong here any more.
• Spencer Dawkins: Comment [2013-07-10 21:39]:
  I support Joel's DISCUSS and Barry's request to consider the Applications
• Directorate review.
• In the Abstract
•   There are numerous types of SIP Back-to-Back User Agents (B2BUAs),
•   performing different roles in different ways.  For Example IP-PBXs,
•   SBCs and Application Servers.  This document identifies several
•   common B2BUA roles, in order to provide taxonomy other documents can
•   use and reference.
• I don't think you can fix the middle sentence ("For Example ...") because
• you're just listing names with no details, and adding details probably isn't
• appropriate in an Abstract - it's probably clearer to delete the sentence
• altogether. Isn't it also pointed toward system types, more than roles? And the
• document says it's focused on roles.
• At a minimum, in 3.1.  Signaling-plane B2BUA Roles
•   This implies it does not modify SDP bodies,
•   although it may save them and/or operate on other MIME body types.
• It would be helpful to say more about "may save them" (for instance, why would
• the B2BUA do that?).
• In 3.1.2.  Signaling-only
•   An example of such a B2BUA would be some forms of Application Servers
•   and PBXs, such as a server which locally processes REFER requests and
•   generates new INVITEs on behalf of the REFER's target.  Another
•   example would be an [RFC3323] Privacy Service Proxy performing the
•   'header' privacy function.
• I really like the examples you provided here. It would be great if you could
• provide examples for the descriptions as well.
• In 3.2.  Media-plane B2BUA Roles
•   A Media-plane B2BUA is one that operates at both the SIP and media
•   planes, not only on SIP messages but also SDP and potentially RTP/
•   RTCP or other media.  Such a B2BUA may or may not replace the Contact
•   URI, modify or remove all Via and Record-Route headers, modify the To
•   and From header fields, etc.  No SIP header field is guaranteed to be
•   copied from the received request on the UAS side to the generated
•   request on the UAC side, and SDP will also be modified.
• I'm confused about a taxonomy where categories are described by what they might
• or might not do ...
• Is "and SDP will also be modified" typically true, always true, or something
• else?
• In 3.2.1.  Media-relay (and in other places as well)
•   A B2BUA which performs a media-relay role is one that terminates the
•   media plane at the IP and UDP/TCP layers on its UAS and UAC sides,
•   but neither modifies nor restricts which forms of UDP or TCP payload
•   are carried within the UDP or TCP packets.  Such a role may only
•   support UDP or only TCP or both, as well as other transport types or
•   not.  Such a role may involve policing the IP packets to fit within a
•   bandwidth limit, or converting from IPv4 to IPV6 or vice-versa.  This
•   is typically similar to a NAT behavior, except a NAT operating in
•   both directions on both the source and destination information; it is
•   often found as the default behavior in SBCs.
• naming TCP, UDP, or both repeatedly might be clearer if you replaced references
• with a more general "transport".
• In 4.  Mapping SIP Device Types to B2BUA Roles, as you point out, these are
• marketing category terms without strict definitions. Given that I could build a
• device and call it by any of these names, how helpful is this section (and its
• subsections)?
• Sean Turner: Comment [2013-07-10 17:30]:
  +1 support Joel.
• Joel Jaeggli: Discuss [2013-07-09 08:24]:
  I can probably be convinced that I'm in the rough. This started out as a
• comment and ended up as a discuss so that we could dicuss it.
• I am somewhat doubtful that the security considerations section is adequate. If
• you're going to survey them all you should be able to make some appropriate
• statement about the security considerations for back to back user agents of
• varying varieties. in particular a number of them eliminate the possibility of
• end-to-end security mechanisms being employed generally transparently...
• otherwise no objections.

draft-thornburgh-adobe-rtmfp

• Pete Resnick: Comment [2013-06-25 14:53]:
  I believe this document obviously belongs with the ISE instead of as an
• individual submission via AD, but I have no intention to stand in the way of
• its publication. I trust Martin to get the non-consensus template on the
• document. I have reviewed this strictly as if I were doing a conflict review,
• and I find no conflict between this and IETF work. But because I do think it
• belongs with the ISE, I simply Abstain.
• Stephen Farrell: Comment [2013-07-11 03:19]:
  Thanks for handling my discuss.
• I didn't check if these coments were addressed or not. Feel
• free to chat about 'em, but since they're non-blocking you
• don't have to:-)
• - 1.1: Saying the security is "always on" seems wrong when
• that's not specified here. The first three security bullets
• should be rewritten to say that the security bits are
• currently missing.  (Or move those to the putative section I
• suggested adding.)
• - 2.1.2: Interesting that your VLU's are the same as DTNRG's
• SDNVs. [RFC6256] I'm not suggesting a change just interested
• that they're the same.
• - 2.2.3: I think you should also re-iterate here that there
• is no "Cryptography Profile" currently publicly specified.
• - 2.3.6: I didn't get why or when its ok to replace a cookie
• that was incorrect? Seems like a bad thing to be doing. (And
• what hash function do you mean?)
• - 2.3.7: initiatorCertificate: what certificate format do
• you mean? RC5280 or something else? And do you mean just
• one cert or a chain?
• - 3.5: If you add the security bits, don't you need some more
• state for certificate status checking, e.g. to do OCSP?
• Richard Barnes: Comment [2013-07-08 18:23]:
  I agree with Pete and others that this should be handled by the ISE.  At the
• very least, publishing this document in the IETF stream seems to contradict its
• own statement that it is "not the product of an IETF activity".
• Gonzalo Camarillo: Comment [2013-06-27 07:33]:
  Being more explicit (e.g., in the Introduction) about why this is being
• published would have been useful. Proprietary protocols can be documented for a
• number of reasons: historical reasons, to enable new implementations to be
• compatible with legacy ones, to get new implementations to use this protocol
• instead of a standard one, etc. Which one applies here?
• Spencer Dawkins: Comment [2013-06-25 06:22]:
  I'm a Yes, because anytime we can document protocols with significant
• deployment, that's helpful for network operators.
• Brian Haberman: Comment [2013-07-02 11:17]:
  I agree with Pete's points.  The ISE is the proper place to publish these types
• of documents since the IETF will not have change control over the protocol.  I
• strongly support publishing this document, but feel it should be done via the
• ISE since it is not a consensus-based document.  Given that, I will simply
• abstain.
• Stewart Bryant: Comment [2013-06-25 11:04]:
  Whilst I agree with Spencer on the utility of the protocol, the Abstract and
• the introduction needs to make it clear that this is a proprietary protocol,
• and not a protocol endorsed by the IETF.
• Whilst in this particular case this may be obvious, we need to hold all vendors
• to the same standard.

conflict-review-kiyomoto-kcipher2

• Sean Turner: Comment [2013-06-28 14:16]:
  Hopefully somebody checked the test vectors.
• I also can never remember whether code is supposed to include the BSD license
• or not.

conflict-review-irtf-samrg-sam-baseline-protocol

• Barry Leiba: Comment [2013-07-02 16:58]:
  Editorial comments for.the authors:
• 1.  The synonyms (MUST, SHALL) are in RFC 2119 to accommodate different customs
• and different writing styles.  They weren't meant to be intermixed in the same
• document, and certainly not in the same paragraph, and it's probably going to
• confuse readers if you do.  For example:
•   8.4.  Leave
•   When leaving a multicast group a node SHALL change its local state to
•   indicate that it left the group.  If the node has no children in its
•   table it MUST send a LEAVE request to its parent, from where it SHALL
•   travel up the multicast tree and stop at a node which has still
•   children remaining after removing the leaving node.
• Someone reading this is likely to wonder why you didn't say that the node MUST
• change its local state, or that it SHALL send a LEAVE request to its parent,
• and what difference is intended there.
• I strongly suggest that you pick one word or the other, and then go through the
• document and make sure you use only that one, consistently.
• 2.  While we're at it: we don't normally use 2119 words to tell IANA what we
• want them to do.  "IANA is asked to register...", rather than "IANA SHALL
• register...".  Not a big deal, of course, so take this or leave it.  But we
• should be gentle and genteel to our IANA friends, you know.

conflict-review-donley-nat444-impacts

• Martin Stiemerling: Comment [2013-07-02 04:57]:
  I am balloting no objection, as Pete has already raised the point about the
• correct write-up.