IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-12-19. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Nagendra Kumar (The scribe was sometimes uncertain who was speaking.)
Corrections from: John, Benoit, Spencer, Jari
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
Telechat:
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
3.4.2 Returning Items
Telechat:
1305 EST break
1312 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Agenda Working Group News
AMC will be on holiday starting Tuesday; Happy Holidays; next telechat January 9
1348 EST Adjourned
(at 2013-12-19 07:30:06 PST)
draft-ietf-httpbis-p1-messaging
Point 1: In 2.7.1, end of last paragraph: Before making use of an "http" URI reference received from an untrusted source, a recipient ought to parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks. Why no normative language here? I'm assuming this was deliberate, but it seems like the wrong call. Why not propose that the recipient reject this out of hand, unless there's some strong reason not to? I expect that you will explain why you made this decision and it will make sense to me, in which case that will resolve this DISCUSS point; otherwise, changing "ought to" to "SHOULD" would also satisfy. The referenced section of RFC 3986 has some good text on why this is important, but this document doesn't repeat much of it, so I'm concerned that a new reader wouldn't really get the significance of this advice. Point 2: In 5.5, suppose I connect to foo.example.org on port 80, and send the following: GET / HTTP/1.1 Host: foo.example.org:8080 This produces an effective URI of http://foo.example.org:8080/. What is the server supposed to do at this point? The obvious way to resolve this DISCUSS point is to update the text to address this problem. I think this example has the same property that leads you to require a 301 or 400 status in section 3.1.1. Point 3: In 3.2.4, paragraph 1: server MUST reject any received request message that contains whitespace between a header field-name and colon with a response code of 400 (Bad Request). A proxy MUST remove any such whitespace from a response message before forwarding the message downstream. Why the different handling in the two cases? Is it really less bad (and hence salvageable in the response? What if a user agent receives such whitespace? I expect you'll address this point by explaining why this is an issue in requests and not in responses, or else by at least adding text about how user agents should deal with this situation. I am asking this question based on the inconsistency I see here, not any special insight I have into the problem, so I'm assuming there's a straightforward explanation.
In 2.7.3: Characters other than those in the "reserved" set are equivalent to their percent- encoded octets (see [RFC3986], Section 2.1): the normal form is to not encode them. There's no explicit reference for the definition of a reserved set; this could be easily fixed thusly: Characters other than those in the "reserved" set (see [RFC3986], Section 2.2) are equivalent to their percent- encoded octets (see [RFC3986], Section 2.1): the normal form is to not encode them. Given that they follow each other, the reader will probably find the information either way, but it might be better to include both references. Section 3, Page 20, second paragraph: A recipient MUST parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet LF (%x0A). I don't understand what this means. I think I can guess what it means, but that's probably dangerous. What I think it means is that my reader should process the stream as UTF-8, storing it in a normalized Unicode format, either failing to process the request or doing something "sensible" when bad UTF-8 sequences are encountered, and the normalized Unicode should then be passed to the parser that parses the header lines. Is that roughly what's meant? If so, I think it could be more clearly stated. The list rule exception mentioned in section 1.2 confused the hell out of me until I got to section 7. Why is section 7 not a subsection of section 2? I assume the answer is "because it's long, and would suck the wind out of the document if it were at the beginning," which is fine, but if so, it would be nice if the text in 1.2 did a *bit* more foreshadowing. E.g.: This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with an extension defined in Section 7 that adds compact support for comma-separated lists with the addition of a # token to the usual ABNF token set, similar to the * token. Appendix B shows the collected ABNF with the list rule expanded. BTW, none of the hassling I have done here in these DISCUSSes and comments should be construed as a lack of enthusiasm for this document. It's really obvious that a lot of care went into this document—I'm seeing all kinds of really good advice based on practice in terms of how not to do an implementation that will be vulnerable to a variety of issues. I am very enthusiastic about this document. Thank you very much for doing it.
Throughout the document (and the other documents in the series): I now understand that you intend a two stage parse for header fields and have that represented in the ABNF as a separate overall message syntax and a header field value syntax. That's fine, but I would ask that you make this clearer somewhere in section 3 of the p1 document. You talk about the parsing, but I think it is well worth describing that there are two levels of ABNF, and that the ABNF rule name corresponds to the header field name. It is fine to do it this way, but it's not the way that ABNF has been used in the past, so best to make it crystal clear. Specific comments: 1: This HTTP/1.1 specification obsoletes and moves to historic status RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP versioning). Please, no, it doesn't (and shouldn't) move any of these documents to Historic (even if it were capitalized correctly ;-) ). It obsoletes them. Please strike "and moves to historic status". (I'm happy to give you the long explanation of why moving to Historic is not the right thing if you like.) Also, an editorial nit: I find the "we" affectation distracting. Sounds like an academic paper. 11 occurrences in this document. "This document" or "this specification" (or simply switching to the passive voice) are much more IETF-like. 2.3 (Editorial nit) "...upstream to downstream. Likewise, we use...". It's not "Likewise" here. "Upstream" and "downstream" are only about the direction of the message and don't have anything to do with who sent/received it. "Inbound" and "outbound" refer to direction based on who it's coming from (UA or OS). Strike "Likewise". 2.5, para 8 (and ff): I'm not a fan of the "MUST..., unless..." construct. People get into stupid conformance arguments over such things. I prefer "MUST either..., or ..." or "SHOULD..., the primary exception being...". 2.7.1, para 6: Why "MAY"? What else could it do? Is this a protocol option of some sort? para 7: The concept of "establishing authority" is not well explained here. What's the import of it? para 8: Why "ought to"? That seems like a fine candidate for a "SHOULD": You're giving implementation advice to avoid damage. 3.2.4: A proxy MUST remove any such whitespace from a response message before forwarding the message downstream. Really? Wouldn't that cause the aforementioned "security vulnerability"? A field value is preceded by optional whitespace (OWS)... "...and/or followed...", right? 3.2.6: This is your only use of the term "escape". A bit imprecise. I suggest reusing the quoted-pair text for quoted-cpair. 3.3.1: "encoding parameters MAY be provided by other header fields". I think MAY is wrong there. "Can"? 3.3.2: A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field. Why not? Can there not ever be a Transfer-Encoding that has no implicit length? I read 3.3.3 sub 3 and I still don't get it. 4.1: I presume chunk-size can't be "0" even though the ABNF allows it? 4.1.1: quoted-string doesn't allow folding, does it? Why do you need a new quoted-str-nf? 5.5, first paragraph: Why do you have "MUST reconstruct" instead of "reconstructs", or simply reversing the sense of the whole paragraph and say, "An 'effective request URI' is a reconstruction of the user agent's original target URI"? I haven't found anything in the documents that says that effective request URIs are going to be passed as protocol parameters, but rather they are for local processing and comparison. Given that, the "MUST reconstruct" seems inappropriate. 5.7.1: s/The received-by field/The received-by token OR The received-by portion of the Via header field 5.7.2: A non-transforming proxy MUST NOT modify the message payload (Section 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of a message that contains the no-transform cache-control directive. I get the second sentence. But isn't the first a definition of a non-transforming proxy? Is so, I think you should change "MUST NOT" to "will not" or "does not". 6.3: A server MAY assume that an HTTP/1.1 client intends to maintain a persistent connection until a close connection option is received in a request. [...] Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. I'm not sure how to implement the option/requirement of "assume". :-) What is it that you want/expect/permit the implementation to do/not do? 6.4: A "SHOULD" should not be used to "encourage" something. This seems like an utterly empty piece of normative text. "Be nice" without other guidance doesn't seem to lead to any useful interoperability. 7: Thus, a sender MUST expand the list construct as follows: [...] a recipient MUST expand the list construct as follows: The two MUSTs here strike me as goofy. Implementations of senders and recipients do not "expand" ABNF rules; they produce and parse text. Saying things like the following would make sense to me: In any production that uses the list construct, a sender MUST NOT produce empty list elements. In other words, senders MUST produce lists that satisfy the following syntax: [...] In other words, a recipient MUST accept lists that satisfy the following syntax: [...]
In general, this is a very nice introduction to the HTTP architecture. Thanks! COMMENT 1: """ The above categories ... are indistinguishable from a man-in-the-middle attack. """ It seems worth noting that "captive portal" is not equivalent to the other two terms; it's a special case. I would also expand the last sentence to explain a little more why the two are equivalent, and to clarify that the distinction is technical (since one could make moral distinctions between a MitM and a porn-filtering proxy): OLD: "They are indistinguishable from a man-in-the-middle attack." NEW: "Because these entities intercept and modify packets without the consent of either endpoint, these entities are indistinguishable at a protocol level from a man-in-the-middle attack." COMMENT 2: """ A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false. """ This seems optimistic. COMMENT 3: In Section 3.2.2, are the scare quotes around "good practice" necessary? COMMENT 4: In Section 3.2.3, "to white-out invalid or unwanted protocol elements" -- what does it mean to "white out" protocol elements? To replace them with whitespace? Why not just remove them? COMMENT 5 (almost a DISCUSS): In Section 4.1.2: Suppose you have an intermediary that decodes the chunked encoding of an inbound message and generates a new message with known length (Content-Length present). It seems like you need to specify what happens to trailer fields in this case. The answer seems to be that they're just appended to the header, but AFAICT, that's not specified in the text.
Thanks Tom Nadewu for your OPS-DIR review. I know how much you spent on this
one!
I see the HEAD request, which I didn't know about:
Transfer-Encoding MAY be sent in a response to a HEAD request or in a
304 (Not Modified) response (Section 4.1 of [Part4]) to a GET
request
I was wondering: where is the list of valid HTTP operations defined?
1 GET
The GET method is used to retrieve information from the given server using a
given URI. Requests using GET should only retrieve data and should have no
other effect on the data. 2 HEAD Same as GET, but only transfer the
status line and header section. 3 POST A POST request is used to send
data to the server, for example customer information, file upload etc using
HTML forms. 4 PUT Replace all current representations of the target
resource with the uploaded content. 5 DELETE Remove all current
representations of the target resource given by URI. 6 CONNECT Establish
a tunnel to the server identified by a given URI. 7 OPTIONS Describe the
communication options for the target resource. 8 TRACE Perform a message
loop-back test along the path to the target resource.
I finally found it (my mistake was that I was searching for "operation" in the
document while the correct term is "method"):
The request methods defined by this specification can be found in
Section 4 of [Part2], along with information regarding the HTTP
method registry and considerations for defining new methods.
This points to:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . 24
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32
Anyway, an extra sentence, such as the following one, would have helped me:
"Existing methods are GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE"
Also change "HEAD request" to "HEAD request method. Similar remark for "GET
request"
to ops-dir review noted (consistent with respect to usage in the document) but otherwise inconsistent employment of the term coding vs encoding in http 1.0 vs 1.1 vs here. I guess it's to much to ask that the name of the header field and the term of art employed to describe it be consistent.
draft-ietf-httpbis-p2-semantics
In general this document reads more like a book on how HTTP is used than a specification. But the taxonomy of semantic elements is useful and the specification is ultimately there, so OK. I agree with Stephen's comment that it would be useful to include Origin here in the list of "request context" headers. COMMENT 1: Section 5.1.1 defines an entirely new, secondary handshake using a header field. I realize this might be necessary for backward compatibility, but it seems so wrong. COMMENT 2: In Section 5.3.5, "A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field." This seems unnecessary, and unrealistic. For example, on my Mac, Safari sends "Accept-Language: en-us", but as far as I can tell, there is no way to change the value.
Why is there no mention of RFC 6454? That defines the Origin header field, which I think is widely implemented. There are a number of ways in which that could have been done (e.g. just a ref, or changing the IANA registry to point to here and update 6454) but making no mention of it at all seems wrong. Please consider whether it'd be worth including that header field here in some form or other. - 4.3.5 makes no mention of authorization, I would have thought that'd be useful here since mostly DELETE does require some authz when DELETE is allowed. - 4.3.6 makes no mention of TLS - is CONNECT really used without TLS? Seems odd to not mention (what I think) is the main use-case for this method at all. - 5.5.2: CSRF attack could do with a reference and expansion of the acronym
2: Even after reading sections 4 & 5, I find the last paragraph of this section
almost incomprehensible. Especially given that it's got a normative protocol
instruction in it (SHOULD NOT), I think it could use a rewrite.
3.3
a representation in the payload of a POST request (Section 4.3.3)
represents an anonymous resource for providing data to be processed,
such as the information that a user entered within an HTML form.
"anonymous resource"? I don't know what that means.
5: Why are you listing (and not providing semantics) for things that are not in
this document?
Cache-Control
Host
Pragma
Range
TE
Age
Expires
Warning
All Conditionals
All Authentication
5.3.1: Do you really want to allow a weight of "0." or "1." with no trailing
digits? Instead maybe:
qvalue = ( "0" [ "." 1*3DIGIT ] )
/ ( "1" [ "." 1*3("0") ] )
5.3.2: Completely bored ABNF dorking:
media-range = ( "*/*"
/ ( type "/" ( subtype / "*") )
) *( OWS ";" OWS parameter )
7.1.1.1: IMF-fixdate format differs from 5322 in case-sensitivity and the use
of "GMT" instead of "+0000". You should at least note that.
Okay you're on a role wrt well written. Kudos again! 0) s8.3.1: Should a consideration be whether the new header discloses privacy related-data?
*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) s4.1: Same comment as on p1 about 'ought to' register methods with IANA. 2) s4.3.3/4/5: What Stephen said about authorization. I'm surprised that there's nothing about just accepting things without knowing whence they came. 3) s4.3.7/8: Is it allowed for an HTTP server to just not respond to a OPTIONS/TRACE method? I.e., I'd rather not tell you what I support - kind of like not replying to ping messages? Or is a 501 response always returned. 4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF 5) s5.5.3: So what happens if this isn't followed: a sender MUST NOT generate advertising or other non-essential information within the product identifier. 6) s6.1: Is it worth mentioning that the reason-phrase can also be not sent? I think that's elsewhere but it might be worth mentioning again. 7) s6.4.6: What does a client do if it gets one of these in an HTTP 1.1 response? 8) s4.2.1/s8: "safe" was probably not the greatest of choices - readonly would have been better. But, I guess this is water under the bridge at this point.
draft-ietf-httpbis-p4-conditional
*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. 0) Abstract: Maybe would add stateless in front of protocol in the description.
draft-ietf-httpbis-p5-range
COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since. NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)." COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?
- 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?
*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) s2.1: might be good to have the ABNF match the text; The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive. 2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".
draft-ietf-httpbis-p6-cache
- section 8: It would be very useful to add some references where cache poisoning and how to handle it are explained in more detail.
COMMENT 1: In Section 1, a minor suggestion: OLD: "A private cache, in contrast, is dedicated to a single user." NEW: "A private cache, in contrast, is dedicated to a single user, for instance as a component of a user agent." COMMENT 2: In Section 3, you use "cache directive", "cache response directive", and "response cache directive". Choose one.
Please see Lionel's OPS-DIR review, and please engage in the discussion:
#1: Section 1.2.1. Delta Seconds
"A recipient parsing a delta-seconds value and converting it to binary
form ought to use an arithmetic type of at least 31 bits of non-
negative integer range."
How should the "ought to" above be interpreted? If it is a recommendation,
"SHOULD" is maybe more appropriate.
#2: section 4.3.1. Sending a Validation Request
No normative wording is used in this section, especially there is no "MUST" and
"MUST NOT". It seems therefore that this part is only for information and
provides some guidelines for sending validation requests. Is it really the
intention here?
#3: section 5.2. Cache-Control
"For the directives defined below that define arguments, recipients ought
to accept both forms, even if one is documented to be preferred. For any
directive not defined by this specification, a recipient MUST accept both
forms."
"MUST" seems more appropriate than "ought to" in the first sentence above. As I
understand the rest of the document, a recommendation can be given in the form
to use for a given directive (when applicable) but it is expected that both
forms will be always accepted by the cache. As a consequence,it does not seem
so relevant to make the difference between directives defined in this document
and in other documents.
#4: section 5.5. Warning
It could be clarified that Warn-text are only intended to be human readable or
to be logged and should not affect the interpretation of the warn-code.
*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) What Stephen said about cache poising.
draft-ietf-httpbis-p7-auth
COMMENT 1: In Section 3.1, suggest clarifying: OLD: "The origin server MUST send a WWW-Authenticate ... target resource." NEW: "The origin server MUST send a WWW-Authenticate ... target resource. (If the server is unwilling to grant access for any credentials, it should instead use the 403 (Forbidden) status code.)"
- 2.2: shouldn't there be some mention of how realms map to web-origins here? I don't necessarily mean in a normative manner, but to explain. - 4.2: I didn't find the description of chains of proxies very clear. An example would help I think. Although it looks like chains of proxies all doing 407 are not very well defined - is that fair? - Please check the secdir review. [1] I agree with the comment that this really should have some mention of using TLS to protect basic/digest, even if that ought also be elsewhere. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03491.html
Kathleen Moriarty made a Gen-ART review which raised comments which I believe would be useful to consider (but we've not seen a reply yet). Minor issues: In section 2.1, in third to last paragraph, why is ought used here instead of a keyword? This is a point that could help with interoperability, so I think a keyword is important. Unless there is another error message, one should be provided when the role access requirements are not met. Users would expect this functionality. Nits/editorial comments: Section 3.2.1 - please fix the run-on sentence, the first one as it is difficult to read. Suggestion: From: If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code, and a WWW-Authenticate header as per the framework defined above, which for the digest scheme is utilized as follows: To: If a server receives a request for an access-protected object and an acceptable Authorization header is not sent. The server responds with a "401 Unauthorized" status code and a WWW-Authenticate header as per the framework defined above. For the digest scheme, this is utilized as follows: Section 4.1, second to last paragraph. Please consider rewording the content in parenthesis, it is difficult to read and probably found just be a separate sentence rather than included with the prior sentence in parenthesis. "If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks)." Section 4.2, second paragraph, consider breaking the following sentence into two: From: However, if a recipient proxy needs to obtain its own credentials by requesting them from a further outbound client, it will generate its own 407 response, which might have the appearance of forwarding the Proxy-Authenticate header field if both proxies use the same challenge set. To: However, if a recipient proxy needs to obtain its own credentials by requesting them from a further outbound client, it will generate its own 407 response. This might have the appearance of forwarding the Proxy-Authenticate header field if both proxies use the same challenge set. Section 4.4, the last paragraph could be read more clearly with the following change: From: This header field contains two challenges; one for the "Newauth" scheme with a realm value of "apps", and two additional parameters "type" and "title", and another one for the "Basic" scheme with a realm value of "simple". To: This header field contains two challenges; one for the "Newauth"scheme with a realm value of "apps" and two additional parameters "type" and "title", and the second for the "Basic" scheme with a realm value of "simple". Section 6: Security Considerations Could you add in text to inform developers that content should not be accessed before authentication occurs when required? I know this sounds obvious, but I recently ran into this issue. On a Mac, I am able to see that the application server/database information is actually loaded before I authenticate (sure there is a SQL injection happening here too) and the screen is slightly greyed out. On a PC, it appears to block access, but this is a display thing rather than requiring the authentication to actually work prior to serving content. Perhaps something like the following: When a web service is configured to use authentication, content from the application server requiring authentication MUST not be accessed until the authentication has completed successfully.
*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. 0) Abstract: Maybe would add stateless in front of protocol in the description. 1) So I guess the reason we're not saying TLS is an MTI with basic/digest is that that's getting done in an httpauth draft? It really wouldn't hurt to duplicate that while we're getting the other one done (I know you *don't* want a reference to that draft).
draft-ietf-dime-rfc4005bis
- Thank you for section 8.2! (hence the yes:-) - As a side-comment, and not related to this draft at all, we should think about whether it'd be worth a look at the TLS ciphersuites mentioned in 6733 again, now that PFS ciphersuites are generally being more favoured. If say, Diameter/TLS were only starting to be deployed now, it might be worthwhile thinking about key exfiltration attacks and the impact of those, in the same way that the UTA WG are doing for other protocols. That could be done with a small RFC that updated 6733 and basically copied a new set of preferred PFS ciphersuites from one of the UTA documents, once those have firmed up a bit.
draft-ietf-pim-explicit-tracking
I'm with Brian (and Joel) here: how could two implementations inter-operate? As a prove, I searched for all instances of the RFC 2119 keyword, and I found 2 SHOULD, 1 SHOULD NOT, and 1 MAY. Clearly not enough of a specification. As Brian put it: "internal implementation details that are needed to support explicit tracking."
For Benoît: lack of 2119 key words isn't proof of anything; one can provide normative text and define a protocol without using those key words. That said, I'm with the abstainers here: I don't see it. From the shepherd writeup: "There are many implementations of explicit tracking already. They are not based on this document though, but they should be close in functionality to what is in this document." I have a two-part question: (1) Do those implementations interoperate with each other and with what's specified in this document, and (2) are those implementations likely to be changed to match what's specified in this document, and what would is mean to do so?
I have been involved in the discussion of this document for several years. For the most part, this spec really describes internal implementation details that are needed to support explicit tracking. In other words, it is unclear where in this spec there is normative text related to interoperability between two (or more) multicast routers. I don't see a need for this spec even though there are multiple (different!) implementations of the basic functionality.
given igmp/mld listening are a gateway function. and this draft appears to make no specific new requirements of hosts joining or leaving groups, I wonder on what basis two implementations would be considered interoperable on on the basis of this specification.
draft-ietf-mpls-mldp-hsmp
- What a file name, I bet it'd sound funny if someone tries to pronounce it:-)
I think I grok what this thing is doing at a high level. But the name "hub and spoke multipoint" seems inapt, since there's not actually a hub and spoke topology required, just a reverse path from leaves to root. Wouldn't something like "P2MP with Upstream Path (PUP)" be more accurate? The acronym "FEC" is never expanded, and might cause confusion for readers who like error correction.
I am balloting No-Obj based on a quick scan of the document showing no impact on the Internet Area protocols and trust in the RTG ADs doing the right thing.
Like Brian, I skimmed it, didn't see any security issues, and am trusting the RTG ADs to do the right thing.
draft-ietf-json-rfc4627bis
- ECMA-404 looks weird;-) - Please see the suggestions in the secdir review [1] which may or may not have gotten to you in mail already. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04485.html
Thanks for writing this. I would like to briefly discuss the topic of whether ordering is specified in Section 4 and WG's history on that topic before recommending the approval of the document.
The following comment seems inaccurate: "This revision does not change any of
the rules of the specification" et seq. The changes made after LC for ECMA
alignment have indeed caused texts that were not JSON (per 4627) to become
JSON. For example, the string " { \"a\": 1 } " would be illegal according to
RFC 4627, but is legal according to this document.
Thanks for the precise and complete "Appendix A. Changes from RFC 4627" section. Pretty handy for the review.
To the document shepherd: thanks for a good and useful shepherd writeup.
In addition to text asking IANA to change the reference document in the
registration (which has been worked out with IANA), I'd have liked to have seen
us take this opportunity to update the registration template to conform to RFC
6838 (with addition of "Security considerations" and "Fragment identifier
considerations" sections). That could be done with an RFC Editor note such as
this:
In Section 11:
Insert before "Interoperability considerations:"...
NEW
Security Considerations: See [this RFC], section 12.
END
Insert before "Additional information:"...
NEW
Fragment identifier considerations: Fragments are not used and are
not appropriate for this media type.
END
I'll also note that an issue has been raised that I'm not sure has been
adequately answered yet, as to the wisdom of our taking change control for this
media type.
I had the same understanding as Richard, but whatever you work out with Richard will be fine with me.
As the guy who kind of put a bug in somebody's ear to elevate this from Informational to Standard track - I thank all those involved.
draft-ietf-pce-vendor-constraints
For what it is worth, I agree with Robert Spark's Gen-ART review comment that some highlighting of the interoperability challenges of vendor-specific options might have been useful. I don't think it is a big problem in this case (and this seems to be confirmed by Adrian's reply) but some similar RFCs have talked about it. If you want to take a look at what has been done in the past, there's text in RFC 5094 Section 1 last two paragraphs, RFC 4243 Section 3 last paragraph, RFC 3588 Section 11.1.1 two last sentences, for instance. The general thrust is emphasising the local applicability of vendor information, encouraging documentation of vendor's information elements, and recommending standardisation when there's more general interest for the information in question.
Thanks for the Management Considerations section. Regards, the OPS AD.
draft-ietf-6man-ug
No objection to the publication, but let's speak about this one.
When you wrote about the "u/l" bit:
In an IID, this bit is in position 6, i.e., position 70 in the
complete IPv6 address.
You actually mean the 7th position because you start counting at 0. I guess
that you have RFC 4291 appendix. A in mind:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
Without knowing that you start counting at 0, this is a mistake.
Proposal (but feel free to develop your own text):
In an IID, this bit is in the seventh from the left, i.e., position 70 in
the complete IPv6 address, when starting counting at zero like in the
figures in RFC 4291 appendix A.
Same remark for the "i/g" bit:
In an IID, this bit is in position 7, i.e., position 71 in the
complete IPv6 address.
NEW ADDITION TO THIS "NO OBJECTION", FOLLOWING AN EMAIL DISCUSSION WITH BRIAN:
>>> RFC 4291, section 2.5.1
>>> <http://tools.ietf.org/search/rfc4291#section-2.5.1>. Interface
>>> Identifiers
>>> Interface identifiers in IPv6 unicast addresses are used to identify
>>> interfaces on a link. They are required to be unique within a subnet
>>> prefix. It is recommended that the same interface identifier not be
>>> assigned to different nodes on a link.
>>> "it's _required _to be unique", so you're right.
>>> On the other hand, I see "It is _recommended _that the same interface
>>> identifier not be assigned to different nodes on a link "
>>> It seems to me that those 2 sentences contradict each other. I'm
>>> slightly confused....
> That 'recommended' does seem screwy,
Is this something you should be updating (in the sense OLD/NEW) in the draft?
It would make sense to me...
I have no objection to the publication of this draft. Maybe it is just me, but it seems very strange to publish a Standards Track document, the substance of which seems to be to tell the reader that their *may* be a special meaning to two bits but they cannot know for certain that this is the case. I understand that for procedural reasons the RFC needs to be published as ST, but perhaps the definitive statements should be in the normative text and the informational text should be an appendix. I found the document very confusing to read, but given the expertise of the authors, shepherd, AD and reviewers, I conclude that the text correct, and the IPv6 address architecture is complex. Hopefully it is not yet too complex for those that need to deploy and configure IPv6.
Just trying to get a couple of reviews in early:
1) For the changes to s2.5.1 of RFC 4291 in s5, should it be:
"For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long. If derived
from an IEEE MAC-layer address, they MUST be constructed in Modified
EUI-64 format."
I.e., r/must/MUST?
was:
So I'm 100% in favor of the goal if this draft however:
Their aim is to reduce confusion
while retaining the useful aspects of the "u" and "g" bits in IIDs.
If they're now opaque then their useful attributes is that they are two bits.
the only way to know with any degree of certainty if an ip address is derived
from a mac address if if you have an L2 adjacency with the device or have
insight into how it was provisioned.
The text does not really mollify me with respect to retaining "useful" aspects
of the u and g bits.
brain carpenter said in response:
Yes, you're right; I think that phrase was written very early in the
life of the draft, when it seemed like a reasonable statement. After
several attempts at improving the sentence, I think the best solution
is to delete it, so the start of Section 5 would simply be:
This section describes clarifications to the IPv6 specifications that
result from the above discussion.
Brian
which I can live with.
draft-ietf-payload-rtp-aptx
I don't understand how section 3 does not have an accompanying IPR declaration. Nor do I get how this helps interoperability if the codec details themselves are not openly specified. And the section ends with an advertisement. Did the WG discuss those issues?
I share my colleagues' uncertainty with some of what's in this document. It disturbs me to see text such as this in a Standards Track document (from the first paragraph of Section 3): Standard apt-X and Enhanced apt-X are proprietary audio coding algorithms, which can be licensed from CSR plc. and are widely deployed in a variety of audio processing equipment. For commercial reasons, the detailed internal operations of these algorithms are not described in standards or reference documents. And at the end of Section 3, the address to whom we can write, presumably to buy software that does apt-X.... That said, the rest of the document does appear to provide a technical specification that the working group wants to publish. I'm going to let my colleagues' DISCUSS positions cover things, and ballot No Objection.
I hate to be that guy but I gotta ask .... Normally when we're defining a company specific thing we put the name of that company in the title to make it clear it's their "thing". Here the authors don't work for that company - how's this supposed to work? And, shouldn't this be in the vnd space?
I take it on the basis that there is no IPR disclosure that there is no IPR contained in section 3.
draft-ietf-ecrit-country-emg-urn
Wikipedia being what it is, if you use it as a reference you should also
provide the date of the reference. But I am surprised that established
emergency services that motivate this work don't have their wn stable
URLs that you can reference.
---
I don't agree with Sean that this document should attempt to list all
known emergency service categories since there is a mechanisms for new
ones to be added as requested. Of course, if you were to list them all
then adding Cave Rescue would be on my list.
However, I do worry that this schema negelects the call hierarchy that
varies by national authority (and sometimes by regional authority). In
the UK the Coast Guard can be called direct, but cave Rescue must be
invoked via the police, yet both use the same emergency telephone
number. In some countries, Cave Rescue has a dedicated phone number.
It strikes me that "police" is a very loose category in many states
where there are multiple disjoint police services that have different
jurisdictions and call-out mechanisms (not to mention control
mechanisms).
Anyway, I've not been following this work closely enough to know whether
this sort of categorisation really matters.
---
urn:service:sos.gas The 'gas' service allows the reporting of
natural gas (and other flammable gas) leaks or other natural gas
emergencies.
Why only "natural gas"? Would they not attend a leak of man-made gas?
This is nothing I'm going to make a big stink about, but I think it would greatly improve the document to do the following: 1: - Editorial: Change the first paragraph to: NEW The policy for registration of sub-services of the service URN with the 'sos' service type is defined in section 4.2 of RFC 5031 [RFC5031] as follows: Then change the table to simply an indented quote. Strike section 4. It's completely redundant. (Meaning you can also strike section 2.) Strike section 5.2. It could accidentally confuse people because they are looking at the wrong section. Section 5.3: I suggest simply stating that you are replacing the second paragraph of section 4.2 and not re-including the registrations. 5031 is still going to exist, and people will still have to refer to it, so there's nothing to be gained by completely replacing 4.2. Leave the registry pointing to 5031. That also doesn't require IANA to make a change. Editorial: The expert review should only approve services that have emergency nature, that... That's not grammatical. Also, the actor is called the "designated expert". Instead: NEW The designated expert should only approve sub-services that are emergency services, that...
The abstract really threw me, as did the consistent repetition of the "in one country only" mantra. May I suggest a couple of editorial changes that I think will fix that? Abstract: NEW Section 4.2 of RFC 5031 allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions in RFC 5031 to allow such registrations when, at the time of registration, those services are offered in one country only. END Then, I agree with Pete that Section 4 is redundant, but I also think Section 3 is redundant. All of this is said in Section 1, and doesn't need to be repeated. I suggest removing both sections 3 and 4. I also strongly agree that it's a bad idea to copy the text from 5031, and think removing Section 5.2 is correct. Then this document describes the change to 5031 in the Introduction, and then has the explicit new text in Section 5 (which should become Section 3). If anyone wants to see what it used to say, they can readily look at 5031.
I think that SOS is supposed to be capitalized. If any organization owns the definition of SOS it is the ITU for historical reasons, and they certainly think that it is capitalized. I wonder about the merits of a list given that by definition it is a partial list.
0) Where's hazmat fall? 1) Should there be a mine rescue service? If I'm in a mine, I'd sure like to have one (http://en.wikipedia.org/wiki/2010_Copiapó_mining_accident). Actually any reason you didn't collect all the SAR-type (search and rescue) services under sar?: sos.sar.m* where m* is mountain, marine, mine? 1) Does fire cover both urban fire services as well an rural fire services (e.g., wildfires in mountains)? 2) Should "gas" be generalized to "utility"? Power lines being down, power being out, and water mains spewing water when it's freezing can be bad too. So it could be: sos.utility.gas sos.utility.electric sos.utility.water Not sure if phone requires an immediate response but I could see some non-SIP people thinking it does: sos.utility.phone 3) Should there be one for social services? 4) We also need sos.cat to make sure more cats that want to get on the internet don't get stuck up trees ;)
draft-rosen-rph-reg-policy
Thanks for an admirably short document. I think the Abstract would be clearer by not stating the old management policies because when you do so, there is ambiguity about what the resultant policy is (you have a statement that the policy is foo and a statement that the policy is changed to bar). I suggest... This document updates RFC 4412 by changing tha IANA management policy of the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries to "IETF Review". --- Similarly in the Introduction OLD The management policy of these registries is "Standards Action" as defined in [RFC5226]. NEW The management policy of these registries defined by RFC 4412 was "Standards Action" as defined in [RFC5226]. END
4412 section 9 says: "A new namespace MUST be defined in a Standards Track RFC, following the 'Standards Action' policy in [RFC2434], and MUST include the following facets:..." Followed by a long list. Does this mean that that second MUST still applies, but those need to be stated in the registration? If yes, that's fine but worth saying. If no, then it definitely needs saying because someone could ask where all those things are defined. And one of those things is the IETF reference document, so I'm not sure what we're saving here really if we still need an RFC. But I guess there's a reason.
The third sentence of Section 1 is broader than the action that the document takes. Is this document an appropriate place to make a broad statement across many IETF registries?
I'm waiting to see the response to Brian Carpenter's Gen-ART review question.
ti -> to in the abstract. OLD: RFC4412 defines "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC4412 ti change the management policy of these registries to "IETF Review". NEW: RFC4412 defines "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC4412 to change the management policy of these registries to "IETF Review".
My "Yes" ballot reflects my general preference to soften our registration policies, which are often overstrict.
I like Adrian's suggestion ...
draft-ietf-opsawg-rfc5066bis
I always find it useful if the numeric form of an OID is also presented as well - some people might find it easier if the OIDs in section 3 were also shown that way. But just a nit really, feel free to ignore it.
draft-moonesamy-ietf-conduct-3184bis
From Appendix C:
The text about "think globally" was not removed as the meaning was
not clear.
This doesn't make sense—I think you have one too many or one too few nots here.
The security considerations section doesn't mention the possibility that a
participant failing to follow the advice in section 2, part 3 that "no one
shall ever knowingly contribute advice or text that would make a standard
technically inferior" can in fact result in an inadequately secure protocol
specification. I don't know if this is worth fixing, but it's something that
we've been accused of in the past, so perhaps it is worth specifically calling
out.
All in all, this is a significant improvement over RFC 3184, which is itself a
good document. Thanks for doing the work!
Thanks for taking this on.
Just a few Comments...
---
I would like the Abstract to note that this document obsoletes 3184 and
to provide a few words on what changes it makes. For example,
This document brings the guidelines up-to-date and obsoletes RFC 3184.
---
As Sean says, I guess 3184 can be moved to Historic at the same time.
---
In Section 1, I wondered why you didn't also mention RFC 3683 as many
conduct issues will arise on mailing lists. Maybe...
If conflicts arise they are resolved according to the
procedures outlined in RFC 2026 [RFC2026] and RFC 3683 [RFC3683].
...and, yes, I do see Appendix B.
---
Section 2, point 3
The goal of the IETF is to maintain and enhance a working, viable,
scalable, global Internet
I don't disagree, but since 3184 was written we have BCP 95 (currently
RFC 3935), and it might be helpful to align the text by quoting and
referencing. For example...
The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people
design, use, and manage the Internet in such a way as to make the
Internet work better [RFC3184].
---
Section 2, point 4
IETF participants read the relevant Internet-Drafts, RFCs, and
email archives beforehand, in order to familiarize themselves with
the technology under discussion.
"Beforehand" reads oddly to me. Before what? I suppose you mean before
joining in with the discussion. It would help to clarify.
---
In Appendix C
o The text about "think globally" was not removed as the meaning was
not clear.
I think s/was not/was/
When I read this I kept mentally prepending "ideally," to phrases. (Same as 3184.) I wish life were that simple:-)
I compared, with the rfcdiff tool, RFC 3184 and this draft, and I have to admit that I failed to see why we needed to update RFC 3184. Don't get me wrong, there are some nice text improvements and one paragraph was corrected (IPR), as mentioned in Appendix C. The only significant changes in the diff is the addition of the the appendix A and B. The content is useful, but these are only in the appendix, so not normative, right? Anyway, no objection. I was surprised to see that http://www.ietf.org/tao.html doesn't refer to RFC 3184. When this RFC will be published, the TAO should have a reference to it.
Consider the following a thought experiment... Is the Security Considerations correct given that failure to follow bullet #3 could lead to serious security issues?
Worth an informative reference in s1 after "consensus" to draft-resnick-on-consensus? Is it replaces or moves 3184 to historic?
draft-ietf-avt-srtp-not-mandatory
I am not quite comfortable with the discussion of interoperability. I do buy the argument of the document, but I don't see how, when I buy or implement RTP for one of the deployment or application scenarios listed in section 2, I end up with the right strong security. I believe the way to handle this is to describe for each of the cases in Section 2 what security is expected in any implementation. In that way, there is something to do a cross-check against, and interoperability is more likely. I'll leave this as a Comment and hope that the authors pick up on it and work through it with someone who has more clue than I do about the needs of interop and MTI security.
Thanks for working this through over >1 generation of security AD. Do you really need this bit: For a framework protocol, it appears that the only sensible solution to the strong security requirement of [RFC3365] is to develop and use building blocks for the basic security services of confidentiality, integrity protection, authorisation, authentication, and so on. When new uses for the framework protocol arise, they need to be studied to determine if the existing security building blocks can satisfy the requirements, or if new building blocks need to be developed. A mandatory to implement set of security building blocks can then be specified for that usage scenario of the framework. I'm concerned that composition like that could result in insecurity. I think I'd prefer you to delete this and the following para.
This document does a good job to list the different "RTP Applications and Deployment Scenarios" in section 2. Then, when it gets interesting, the content is somewhere else. The range of available RTP security options, and their applicability to different scenarios, is outlined in [I-D.ietf-avtcore-rtp-security-options]. Same answer in the section 4 "RTP Session Establishment and Key Management" The most important and widely used keying options for RTP sessions at the time of this writing are described in [I-D.ietf-avtcore-rtp-security-options]. Therefore, I don't understand how the document content maps the second part of the abstract? (this point is my DISCUSS) Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. I see "guidelines" in the section 6 title, but, as designer or reviewer, I'm not sure what the guidelines are. It seems the answer is always: "it depends, see draft-ietf-avtcore-rtp-security-options as a starting point. " I wonder why draft-ietf-avtcore-rtp-security-options-09 is not integrated in this document?
I appreciate the work that has gone into this doc. Thank you for seeing it through.
I know this has been a long time in the making. I have to admit I've never loved the idea of no MTI but we seem to do it for other protocols like HTTP, Oauth, eMail, and the list goes on. My assumptions here are 1) there won't be whole lotta these profiles coming our way, and 2) implementers actually want to have *secure* interoperable solutions. The Security Considerations really is: This entire memo is about mandatory to implement security or the lack thereof for RTP.
I await the arrival of draft-ietf-avt-srtp-a-really-good-idea-and-heres-how-for-your-usage
draft-ietf-httpbis-authscheme-registrations
nitty nit nit: suggest s/defined in standards-track RFCs/defined in RFCs/ might be better - reading this I got a scare for a second that that registry might require standards-track but it doesn't, its IETF review.
No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the
discussion.
Cut and paste from Sue Hares, OPS-DIR reviewer:
I am reviewing the following document: Susan Hares T 2013-12-17
draft-ietf-httpbis-authscheme-registrations-09
But the IESG write-up states the following should reviewed together:
* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth (Peter Schoenmaker Ops-Dir reviewer)
* draft-ietf-httpbis-method-registrations (Michael Sneed, Ops-dir
* draft-ietf-httpbis-authscheme-registrations (Sue Hares Reviewer)
I am concerned about the breaking of the review of
httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and
the draft-ietf-httpbis-method-registrations. I have read all three drafts.
So this is addressed to the reviewers of the httpbis documents for this week
Niclas Comstedt T 2013-12-17 draft-ietf-httpbis-p1-messaging-25
Menachem Dodge T 2013-12-17 draft-ietf-httpbis-p5-range-25
Lionel Morand T 2013-12-17 draft-ietf-httpbis-p6-cache-25
Sarah Banks T 2013-12-17 draft-ietf-httpbis-p2-semantics-25
Peter Schoenmaker T 2013-12-17 draft-ietf-httpbis-p7-auth-25
Michael Sneed T 2013-12-17 draft-ietf-httpbis-method-registrations-14
Susan Hares T 2013-12-17
draft-ietf-httpbis-authscheme-registrations-09
Review of the draft-ietf-httpbis-authscheme-registrations
This document: Not ready.
Why not ready: It is just really unclear exactly what IANA is putting in
<http://www.iana.org/assignments/http-authschemes>
Here’s my guess: I think that IANA is simply giving the following as
potential WWW-Authenticate RFC values
WWW-Authenticate: [Basic]|[Bearer] |
[Digest] |[Negotiate]| [OAuth]
What’s the problem with reviewing just this document: Reviewing just this
document is like tracing the validity of a string path that enters a wad of
strings and exits it. Without looking at the whole scheme, you cannot tell if
this is reason.
I have reviewed the specification reference in
draft-ietf-httpbis-authscheme-registrations.
1) Basic: RFC 2617: section 2 (nothing)
2) Bearer: RFC 6750: bearers
Bearer authentication have 3 different bearer authentication schemes but no
logging of which is used. The errors (due to HTTP errors reporting) seem to
merge several errors into the same error codes). Since this is an approved RFC,
why does IANA have error codes for the different Bearer schemes?
What level of this work is “just encode” and what level is updated to the
latest in security handshaking schemes? Should this be compared against the
OASIS work to secure portions of the information? That is – authenticate who
can have this piece of data using my HTTTP.
3) Digest: RFC 2617: Digest – Even for routing protocols (sometimes
called security light) the digests have been considered weak. What exactly the
author is trying to suggest needs to be included in the registry is not clear.
4) Negotiate: RFC 54559: Section 3: The author indicates that this breaks
syntax by mixing Kerberos (connection-oriented) and expanding the syntax
(Authenticate/Authorization) by not including the Kerberos gssapi-data in the
initial WWW-Authenticate header.
It is entirely unclearly why this kludge in limited use is any more a kludge
than the rest of the system. The comment on non-context specific ignores the
password/user digest issues of deployment
It is not clear why this needs to be noted in the IANA registration.
5) OAuth: RFC5849: Section 3.5.1
Authorization: OAuth realm="Example",
oauth_consumer_key="0685bd9184jfhq22",
oauth_token="ad180jjd733klru7",
oauth_signature_method="HMAC-SHA1",
oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
oauth_timestamp="137131200",
oauth_nonce="4572616e48616d6d65724c61686176",
oauth_version="1.0"
I have confirmed that referenced documents in do reference these documents and
have comments. However, unless I look at the wider context of these documents,
I do not know if the IANA work is complete.
What bothers me in the macro-view:
However, I would like to comment on the protected space concept (Realm) and
proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical
implementation is impacted by the new world of VMs and shared information.
Respectfully, but
Sue Hares
I might have said the following in addition to no security considerations: Security considerations for each method are described in the referenced RFC.
draft-ietf-httpbis-method-registrations
I might have said the following in addition to no security considerations: Security considerations for each method are described in the referenced RFC.
draft-ietf-payload-rtp-howto
3.2.1 says: "Note: These IPR rules applies on what is specified in the RTP Payload format Internet Draft (and later RFC), IPRs that relates to a codec specification from an external body does not require IETF IPR disclosure." That is the subject of a current thread on rtcweb and ipr@ietf.org so I want to check that the IESG agree that the above is correct before we put this out in a new RFC. (I'm not sure myself, but don't want us to contradict what could be an emerging consensus that's different from this, in the unlikely event that such a consensus emerges in the short-term.) Note that this discuss is also slightly different from the apt-x thing, in which case I believe that the codec is not openly published.
This is a trivial Discuss to fix, but it seems important because a reader who believes the references would miss parts of key BCPs. I'll be a Yes when it's resolved. In section 3.2.1. IETF Process and Publication, It is very important to note and understand the IETF Intellectual Property Rights (IPR) policy that requires early disclosures based on personal knowledge from anyone contributing in IETF. The IETF policies associated with IPR are documented in BCP 78 [RFC5378] (related to copyright, including software copyright for example code) and BCP 79 [RFC3979] (related to patent rights). BCP 78 is a single-RFC BCP, so that's correct now, but the base RFC could be reissued or updated in other RFCs included in the BCP, and BCP 79 is a multi-RFC BCP, so citing it as [RFC3979] isn't quite right. A bit further in the same section, in The main part of the IETF process is formally defined in RFC 2026 [RFC2026]. RFC 2418 [RFC2418] describes the WG process, the relation between the IESG and the WG, and the responsibilities of WG chairs and participants. both RFC 2026 and RFC 2418 are part of multi-RFC BCPs (BCP 9 and BCP 25, respectively). My suggestion would be cite all of these by BCP numbers.
These are all nit-level comments. Please do the right thing.
In section 3.2.1. IETF Process and Publication,
The standard tracks
previously allowed for documents of three different maturity
classifications, proposed, draft and Internet Standard. Since
October 2011 this has been reduced to only two levels: Proposed
Standard and Internet Standard [RFC6410].
you might consider describing only the current maturity classifications, unless
you expect awareness of draft standards to be of particular use to your target
audience.
In section 3.3.2. RTP Header
The RTP header contains a number of fields. Two fields always
require additional specification by the RTP payload format, namely
the RTP Timestamp and the marker bit. Certain RTP payload formats
also use the RTP sequence number to realize certain functionalities.
if you could give an example ("for example, the frobnitz payload format uses
the RTP sequence number as a covert channel to subvert network security
systems", or something), that would be helpful to me.
In section 3.3.3. RTP Multiplexing
The first one is separation of media streams of different types or
usages, which is accomplished using different RTP sessions. So for
example in the common multimedia session with audio and video, RTP
commonly multiplexes audio and video in different RTP sessions. To
achieve this separation, transport-level functionalities are used,
normally UDP port numbers.
[deleted down to]
For more discussion and consideration of how and when to use the
different RTP multiplexing points see
[I-D.ietf-avtcore-multiplex-guidelines].
[I-D.ietf-avtcore-multiplex-guidelines] describes the issues with NAT binding
keepalives and port exhaustion when using transport-level RTP multiplexing, but
there's no hint of those issues here. Maybe i's worth a sentence here that
points to the issues that [I-D.ietf-avtcore-multiplex-guidelines] explains?
In section 3.4.2.2. Declarative Usage in RTSP and SAP
SAP (Session Announcement Protocol) [RFC2974] is used for announcing
multicast sessions. Independently of the usage of Source-specific
Multicast (SSM) [RFC3569] or Any-source Multicast (ASM), the SDP
provided by SAP applies to all participants. All media that is sent
to the session must follow the media stream definition as specified
by the SDP. This enables everyone to receive the session if they
support the configuration. Here SDP provides a one way channel with
no possibility to affect the configuration that the session creator
has decided upon. Any RTP Payload format that requires parameters
for the send direction and which needs individual values per
implementation or instance will fail in a SAP session for a multicast
session allowing anyone to send.
does SAP appear often enough, in practice, to be described here, as if it was
in common use and payload designers should keep SAP in mind for new payload
specifications? If the answer is "yes", that's fine, but if not, maybe it's
worth pointing out that SAP is obsolete/obsolescent?
I know you're using it to explain declarative usage, but with no qualifiers, a
new payload designer could be forgiven for saying "SAP looks really simple,
let's use that!"
In section 3.5.2. Different Queuing Algorithms
Routers and switches on the network path between an IP sender and a
particular receiver can exhibit different behaviors affecting the
end-to-end characteristics. One of the more important aspects of
this is queuing behavior. Routers and switches have some amount of
queuing to handle temporary bursts of data that designated to leave
the switch or router on the same egress link. A queue when not empty
results in an increased path delay.
I wonder if a pointer to a recent description of Bufferbloat would be helpful?
I'm still running into lots of people who don't know/believe how much queuing
can increase path delay ...
In 3.5.3. Quality of Service
Using best effort Internet has no guarantees for the paths
properties. Quality of Service (QoS) mechanism are intended to
provide the possibility to bound the path properties. Where Diffserv
[RFC2475] markings effects the queuing and forwarding behaviors of
routers, the mechanism provides only statistical guarantees and care
in how much marked packets of different types that are entering the
network. Flow-based QoS like IntServ [RFC1663] has the potential for
stricter guarantees as the properties are agreed on by each hop on
the path.
it's possible to read this as saying that IntServ is better than DiffServ.
Perhaps the last sentence could end with something like "... by trading
per-flow state in the network for better performance"?
In section 4.1.1. Steps from Idea to Publication
Submission of the first version: When one has performed the above
one submits the draft as an individual draft. This can be done at
any time except the 3 weeks (current deadline at the time of
writing, consult current announcements) prior to an IETF meeting.
The statement about deadlines is going to be really fragile (we've changed this
since I joined the IESG in May). Is it necessary to include the "current"
deadline in this document?
I might have missed it but it's worth stating that if there's conflict between what the RFC editor wants in terms of format, etc. that the RFC wins out over this draft. For example, we later require a privacy/management/deployment considerations section in all drafts - those will need to be added.
draft-ietf-jose-use-cases
6.2 says "do what FIPS says" more-or-less. I don't think that should rise to this level of requirement. The first sentence is fine, but the 2nd is not IMO.
abstract: CMS isn't "in the past" suggest you make that present tense since this does not in any way OBSOLETE CMS. abstract: I'm also not sure that "overtaken" is right. Seems to me that these encoding schemes are fashion-items with an about 5 year "season" so being so definitive might look a bit silly next season. If you buy that, there'd maybe be other changes to make too. Generally, I don't think this needs to or should be doing a sales-pitch, and the same goes for the XML discussion too. intro: PGP is probably better "known" than S/MIME as a mail security solution. section 2: MAC == signing? Yuk. That does lead to developer confusion IMO. section 5: s/Several working groups/Several IETF working groups/ section 5: I thought Persona wasn't quite JOSE? Maybe I'm remembering wrong though (didn't check) typos: applicaitions, "JWT token" 5.4: What we use is OTR though. A ref to that would be good, just after you say that the CMS based approach hasn't been deployed. 5.7: This is a bit vague. I believe there are JOSE object that cannot be processed by the WebCrypto API and that there are WebCrypto algorithms that are not defined in JOSE, so API outputs cannot all be JOSE conformant. Is that correct? If so, then I think you need to say that for truth-in-advertising reasons. The fact that the WG think that's ok makes me sad. See also the secdir review [1] which calls out a few nits. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04481.html
Thanks for a well written document.
draft-ietf-avtcore-rtp-security-options
This was an awesome document, and very helpful for me (I've spent most of my
recent IETF years in RAI, but never on the media side). Thank you and the
working group for producing it.
I have a small number of comments, all about points of clarity. Please consider
them along with any other feedback you receive.
In section 3.1.1. Key Management for SRTP: DTLS-SRTP
DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
was developed in IETF primarily to meet security requirements for
SIP.
The actual security properties of an established SRTP session using
DTLS will depend on the cipher suites offered and used, as well as
the mechanism for identifying the end-points of the hand-shake. For
example some cipher suits provide perfect forward secrecy (PFS),
while other do not.
I can guess what perfect forward secrecy is, but I'm guessing. The term appears
four times in this draft, and the only reference is given the fourth time the
term is used, pointing to http://tools.ietf.org/html/rfc4949.
That RFC says this:
$ perfect forward secrecy
(I) For a key agreement protocol, the property that compromises
long-term keying material does not compromise session keys that
were previously derived from the long-term material. (Compare:
public-key forward secrecy.)
Usage: Some existing RFCs use this term but either do not define
it or do not define it precisely. While preparing this Glossary,
we found this to be a muddled area. Experts did not agree. For all
practical purposes, the literature defines "perfect forward
secrecy" by stating the Diffie-Hellman-Merkle algorithm. The term
"public-key forward secrecy" (suggested by Hilarie Orman) and the
definition stated for it in this Glossary were crafted to be
compatible with current Internet documents, yet be narrow and
leave room for improved terminology.
If "muddled area" is still accurate (I'm not remotely an expert), it might be
helpful to include a definition that is actually what you meant, but even if
the term is now perfectly clear, it would be helpful to have a reference the
first time the term is used.
Also in section 3.1.1
DTLS-SRTP usage is clearly on the rise. It is mandatory to support
in WebRTC. It has growing support among SIP end-points. DTLS-SRTP
was developed in IETF primarily to meet security requirements for
SIP.
This paragraph is true, but might be more useful to the reader if the last
sentence continued, "security requirements for SIP, such as ..." - SIP has
really broad applicability (people proposed using SIP for SmartGrid control,
and it would have worked), so helping people understand what problems STLS-SRTP
was solving might be helpful. Section 5.1 has some clues about this, but being
specific would be helpful to readers who aren't familiar with previous
discussions about media security in RAI.
In section 3.1.5. Key Management for SRTP: Other systems
The ZRTP [RFC6189] key-management system for SRTP was proposed as an
alternative to DTLS-SRTP. ZRTP provides best effort encryption
independent of the signalling protocol and utilizes key continuity,
Short Authentication Strings, or a PKI for authentication. ZRTP
wasn't adopted as an IETF standards track protocol, but was instead
published as an informational RFC. Commercial implementations exist.
Additional proprietary solutions are also known to exist.
It was very easy for me to miss the part where the section was talking about
"other systems _besides ZRTP_".
The text isn't wrong, but might be clearer if the section title was something
like "Key Management for SRTP: ZRTP and Other systems". If the the section
header and second paragraph used the same noun (either both "systems" or both
"solutions"), that would also work.
Thanks for this - definitely answered the mail.
draft-trammell-ipfix-tcpcontrolbits-revision
This message is not directed to the document authors, and I don't ask them to do anything to address it. I have no objection to the publication of this document, but I have to say that the reason given in the Ballot text for this document being published as AD Sponsored rather than the output of the IPFIX working group is pure baloney! We are carefully told that the document has been discussed on the working group mailing list and that there is clear consensus within the working group for it, but for some reason testing that consensus with a two week working group last call would somehow interfere with "the IPFIX WG slowly but surely finishing up his (sic) last deliverables and shutting down." I really don't think this matters, but when there is a working group dedicated to a topic, when using the working group would not add significant delay or effort, and when working group consensus is claimed, I can't see any reason not to use the working group.
- Is the ElementId value of 6 the same as the old one? If so, and the size of this is changing then I don't see how you get good backwards/ forwards compatibility without a flag day. Shouldn't this have a new ElementId or am I just missing something basic? - Please also see the secdir review. [1] There looked to be some tweaks to do based on the discussion between reviewer and author. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04355.html
I've changed to no objection, but still support Adrian's comment. I will be definitely to think again about the BCP 184 process and what it means when it is executed.
Another agreement with Adrian.
I agree with Adrian's comment. Additionally, I am suprised that the opportunity was not taken to to define bits 4..6 as "as defined by updates to the TCP specification" so that there is no need to publish an update to this RFC if TCP makes any enhancement to these bits.
draft-bundesbank-eurosystem-namespace
I assume that we have some formal statement from the ECB or ECSB affirming that the Bundesbank is acting on their behalf here? Of course it's absurd to think that they would mislead us, but it might be a nice thing to have for future reference.
- I'm surprised that you don't define a lexical equivalence rule - there is a long history of authorization/access control failures based on such ambiguity. I assume there are (or will be) eurosystem-specific rules for this, and if there are already then referencing those here would be good in case someone reads this RFC and writes code that makes bad assumptions. If those rules don't yet exist but will, then maybe say so, and provide whatever hint you can as to how a reader of the RFC can go find them. Or, define them if you can and just say that two URNs are only considered equivalent if they contain exactly the same octets. - p5 says that "there is no support for query instructions" - it'd maybe be better if that and similar bits of text said e.g. "query strings MUST NOT be used as part of 'eurosystem' URNs" or similar. As written someone might claim that 'urn:eurosystem:foo?bar=baz' is valid, and I'm not sure if you want that or not. (Same for fragments.) If you do take the approach I suggest then you may need to add a reference to RFC 2119. Having said that, I'm not really sure what's right here, and would expect that others (the "URI police":-) would have better/stronger opinions.
I believe the community section needs enhancement as discussed by David and Miriam.
I support Ted's comment that it would be nice to have some note from the ECB stating that it's OK for DBB to be managing this URN namespace. I'm not making this a DISCUSS because I assume that if there's a problem, the ECB and DBB will work it out and we can just update the registry to reflect whatever they agree to.
I support Stephen's comment about lexical equivalence. I didn't think all comparison failures are authentication comparison failures, either ...
I have no objection to the publication of this document or its contents. I am however wondering whether this type of IANA allocation cannot be delegated rather than requiring IESG review and approval.
status-change-std1-to-historic
conflict-review-lanthaler-profile-registry
I don't object to moving forward with this document, whether Adrian's astute observation is handled or not. The reason I don't object is that as Barry says, we don't have standing to object. It's entirely up to IANA to figure out how to deal with this. I think they would be within their rights to reject the request. One way we _could_ address this would be to add an IESG note saying that the IESG is aware of the issue here, and has agreed to take on responsibility for doing expert review at the request of the ISE (assuming that the ISE is willing to make such a request). I do not care one way or the other whether such a note is added, but it seems that it might be a sensible way forward, if we agree that the alternative is a likely unproductive attempt to navigate uncharted waters. It would be equally appropriate to cast caution to the wind and let the ISE attempt to navigate these waters, with our blessing.
For the record, this is the email I sent on the thread for Barry's Discuss... Interesting problem. I can see why the "specification required" part of Specification Required would be attractive to the authors. Barry, in the 5226bis work, would you consider creating "First Come First Served with Specification"? I believe that might be useful for such cases. In this case, I don't see the harm in appointing and maintaining a DE so long as one can be found (which, to be honest, is how all other DE registries work). The thing that does result is that the IESG comes on to the appeals path for the actions of the DE. Ah! The penny just dropped as I was typing. If this is with the ISE and is asking for IANA action then who is actually giving IANA the instructions? Not the IETF, I think. The IANA is allowed to manage any code space it wants outside of those it manages for the IETF, but that is not our business. So the use of 5226 terms would be "for convenience of similar terminology" and the necessary DE would not be any of our business. So it would not be a case of the IESG refusing to appoint a DE, but it would be up to IANA to work out how to appoint a DE for a registry that is not an IETF registry.
There are enough DISCUSSes already so I won't add to it. I would note though that if the ISE (or anyone else) did end up cutting a deal with IANA, then it'd be really crappy if that registry appeared on IANA's web site below [1] which should be "our" registries. (Having said that I've no idea how pure that distinction is.) So can we also clarify that the above is the case if that's not already clear as part of the resolution of the DISCUSSes. [1] https://www.iana.org/protocols
If, as Adrian concluded, this was using 5226 "for convenience of similar terminology", I'd agree it would be between IANA and the ISE to work this out. But the document doesn't do that. It normatively references 5226 and says that the procedures are "per [RFC5226]". That places a requirement on the IESG by the ISE. Either the document gets changed to say that it is doing something "like 5226", but the ISE (or my Aunt Gertrude or whoever) is in charge of appointing the DE, or this document gets a type 4 response. This should not be published as-is.
I'd like to discuss point 2 in my comments below with the IESG before approving this response.
While this document does not conflict with any IETF work, it creates a new registry with a policy of Specification Required. Specification Required necessitates the appointment of a designated expert to review the registration request, at least to determine that the specification that's provided is adequate. This raises two issues: 1. The document gives no guidance to the designated expert. RFC 5226 strongly suggests such guidance, and the in-progress 5226bis update is more emphatic about it. Section 4 of this document should say something about what the designated expert should consider in her review of registration requests. 2. This makes a commitment that the IESG will appoint and manage a designated expert for this registry. It's an open question whether it's appropriate for Independent Stream documents to put such a requirement on the IESG: we don't have standing to object to the publication of the document, because it is not in conflict with IETF work, but it would be a bad situation if the first registration request came up against an IESG that refused to appoint a DE. I'd like to discuss this situation with the IESG.
I agree with Adrian's observation that the appointment of a DE is not our responsibility and that observation needs to be made clear to the ISE and IANA.
Looking at the IESG reviews a type 3 or 4 response seems appropriate until the chain of authority is agreed. 3) Because this is ISE requiring the IESG to take on an additional task 4) Because it cannot be current procedure for ISE to require IESG to appoint and manage a DE I have no objection to the contents of the document and will clear when there is agreement between ISE, IANA and IESG on how to manage this process.
I'm with Pete.
conflict-review-wkumari-dnsop-defense-collision-mitigate
FWIW, my preference would have been for this document to have been AD-sponsored. I realize that this is not a recommended technique (as the abstract notes), but if we had it in the IETF stream, we could at least say, "There was IETF consensus that this was worth documenting, and it is not recommended."
I agree with Richard as well. If the author's up for it. I don't tihnk I've seen such a short document not recommend itself so often. Well done! But why not add more? You could add that to sections 4 and 6 as well:-)
Richard makes a valid point.
While this draft was presumably targeted at dnsop, it was not discussed there that I can recall, nor is there active work in the area of collision mitigation that this conflicts with that I am aware of.