IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-06-07. These are not an official record of the meeting.
Narrative scribe: Susan Hares and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Corrections from: Brian Haberman (6/11), Sean Turner (6/11), Benoit Claise (6/11), Barry Lieba (6/21) [V3]
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Source IP, source UDP, source DCCP, Dest IP, dest UDP, dest DCCP [ A , udpa , dccpa1 , B , udpb , dccpb1 ] for RTP [ A , udpa , dccpa2 , B , udbp , dccpb2 ] for RTCP
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
3.3.2 Returning Items
Telechat:
Telechat:
1254 EDT break
1300 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
Telechat:
Telechat: [9:10-9:12am]
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1425 EDT Adjourned
(at 2012-06-07 07:30:13 PDT)
draft-ietf-dccp-udpencap
"These fields identify the UDP ports on which the source and destination (respectively) of the packet are listening for incoming DCCP-UDP packets. The UDP port values do not identify the DCCP source and destination ports." I don't know if there is enough DCCP in the wild that any of the router vendors have implemented ECMP support for it, so the following comment may be moot. This encapsulation is going to trigger the use of UDP ECMP in place of DCCP ECMP, but without enough entropy in the packet header for ECMP to occur. Thus a service using this encapsulation will probably see worse performance from the routing layer than a service running a native transport. This probably deserves discussion in the document.
As pointed out by Robert as well, this draft had not been reviewed by the SDP directorate. Flemming has been kind enough to review the draft on a short notice. This is his review: http://www.ietf.org/mail-archive/web/mmusic/current/msg09365.html I have taken some of his comments as discuss-level comments and some as comment- level comments. 1) Section 5.2 states: <quote> If the "a=rtcp:" attribute [RFC3605] is used, then the signalled port is the DCCP port used for RTCP. </quote I think this warrants further discussion. How will this work if non-consecutive ports are to be used for DCCP-UDP itself and how will this work if a middlebox looks at the "a=rtcp" attribute and assumes the currently defined behavior in RFC 3605, which would effectively provide it with the port information for the (UDP native) RTCP stream today ? 2) Section 5.4 discusses how to negotiate DCCP-UDP versus native DCCP (DCCP- STD) and in particular considers only the use of ICE for this (with the details of the encoding "left for future study"). While this may be appropriate for the basic use of DCCP-UDP versus DCCP-STD, it is arguably not appropriate when it comes to negotiating different RTP profiles within each of these (which are defined in this draft). SDP Capability Negotiation would be more suitable for this, as described in RFC 5939 Section 3.7. At a minimum, a reference to that effect and those considerations should be provided.
Section 3.8, 4th paragraph:
s/a DCCP-UDP server must therefore/a DCCP-UDP MUST
therefore/ ??
Various instances of
repeat words and a few spelling errors that should be caught by a spell-checker.
Also:
- Section 5.1, first paragraph:
s/(from [RFC4566]:/(from [RFC4566]):/
^
- Section 5.4, second paragraph
s/DCCPx/DCCP/
- Section 6, last paragraph:
s/A firewall than/A firewall that/
- ICE-TCP is now RFC 6544
My only comment is really a question: do we want to define a mechanism for working around IPv6 NAT, thereby perhaps passively encouraging the deployment of IPv6 NAT. I realize the mechanism in this document is completely protocol independent and the definition of its use on IPv6 costs essentially nothing.
Martin already found everything I found
- Isn't this really pretending that the need for a UDP encapsulation is "short-term"? Why is such pretense useful? - Along the same lines, is a "SHOULD prefer DCCP-STD" not going to lead to another happy-eyeballs problem to be solved later? (The 1st para of section 5 says the above, but 5.4 says that its ok to prefer DCCP-UDP where low connection setup time is important, which appears to be the exception that makes preferring DCCP-STD a SHOULD and not a MUST?) - So a portmapper-like thing like this is going to have a problem with DANE perhaps - has anyone thought that out? that is, what port should I use when I name the DANE TLSA record? I assume it ought be the DCCP destination port, and that any resulting DTLS session is with the process listening there and not the portmapper. But am I right? This could well be a topic for future study rather than someting to decide here. (Not sure.) But in any case, saying something might be useful. - I think section 6 could usefully say that a client MUST establish DTLS sessions with the listener on the DCCP port and not the UDP port. - typo: 3.4, s/A DCCP-UDP implementations MAY/ DCCP-UDP implementations MAY/
Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 25-May-2012. Please find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07453.html
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: Ditto on "Update 5762", and on Stephen's DANE comment. Also... -- 3.8 -- In list item 2: A DCCP endpoint MUST implement one of the two methods: Does that mean *exactly one*, or might it implement both, using each in different circumstances? Regardless of the answer to that question, the 2119 MAYs in the two methods are wrong. If at least one of these MUST be implemented, then they are *not* both entirely optional (which is what MAY means). I suggest changing "MAY accept" and "MAY support" to "accept" and "supports", respectively, and changing "A DCCP server" to "The DCCP server" in both cases. ======== Other comments; no need to respond to these. Take them or modify them as you please: -- Introduction -- There's no need for the [RFC4340] citation *twice* in the first paragraph, and then once again in the second. The first citation will do for all three. I would also change that first citation to be this way: "The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport-layer protocol that..." The same is true for the three [RFC5597] citations in the second paragraph, though the reference style (of which I'm not terribly fond, but nevermind) makes it matter less. Still, I might change the second and third instances to just say "RFC 5597", without making them citations. -- 3 -- A DCCP implementation MAY allow services to be simultaneously offered over any or all combinations Does this really need to be a 2119 MAY? Why on Earth? -- 5 -- This is considered a scenario that has the potential to be an important use-case. That's double-talk. Please find a different way to say what you really mean. -- 5.1 -- The second sentence is missing a closing paren. It also should probably have a citation for [RFC5234]. -- 5.2 -- Do you really want to cite RFC 4234? -- 6 -- OLD A firewall than interprets NEW A firewall that interprets
Please consider the comments from Carsten Bormann's review: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06038.html
1) The requirement to only use a single UDP port when encapsulating DCCP that would have been on two ports (separate RTP and RTCP) at the end of section 4 seems to interact with the demultiplexing rules in section 3.8. The six-tuples there would look something like: Source IP, source UDP, source DCCP, Dest IP, dest UDP, dest DCCP [ A , udpa , dccpa1 , B , udpb , dccpb1 ] for RTP [ A , udpa , dccpa2 , B , udbp , dccpb2 ] for RTCP Those have the same UDP 4-tuple, so any DCCP endpoint that implemented the first of the two methods in section 3.8 (end of page 9) would not allow whichever of those came second. The media stream would fail to work. 2) Please clarify what "active 6-tuple" means. At what point does it become active? When does it become de-active? How much work is it for one application to tie up all the 6-tuples at a peer, at least for a given UDP 4-tuple? 3) The second paragraph of section 3.8 may need clarification. Is the sentence that starts "Because of this," trying to say that other applications on the same host as a server listening on the default port should not use the default port as their source port? 4) Why is the requirement in Section 3.7 (to follow the guidance of rfc4340 section 14) a SHOULD? What else would a a DCCP-UDP implementation do?
I don't think this received an SDP directorate review so far (see http://www.ietf.org/iesg/directorate/sdp.html), though I think Colin did point this document out to MMUSIC. I don't anticipate any problems with the SDP defined here, but will try to get additional eyes on it quickly. Please request a review for future documents that add to SDP. Consider renaming section 5.4 to "possible negotiation mechanisms" or something similar
Good document with some nits: - ID-Nits complains a bit about unused references and one obsoloted reference ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) - the document header should mention that this memo updates RFC 5762. - Section 3., paragraph 7: > Section 3.8 describes usage of UDP ports. This includes > implementation of a DCCP-UDP encapsulation service as a daemon that > listens on a well-known port, allowing multiplexing of different DCCP > applications over the port. s/over the port/over the same port/ - Section 5.4., paragraph 2: > An approach to doing this might be to include candidates for the > DCCP-UDP encapsulation and native DCCP into an Interactive > Connectivity Establishment (ICE) [RFC5245] exchange. Since DCCP is > connection-oriented, these candidates would need to be encoded into > ICE in a manner analogous to TCP candidates defined in [ICE-TCP]. > Both active and passive candidates could be supported for native > DCCPx and DCCP-UDP encapsulation, as may DCCP simultaneous > open[RFC5596]. In choosing local preference values, it may make > sense to to prefer DCCP-UDP over native DCCP in cases where low > connection setup time is important, and to prioritise native DCCP in > cases where low overhead is preferred (on the assumption that DCCP- > UDP is more likely to work through legacy NAT, but has higher > overhead). s/DCCPx/DCCP-STD/
This draft says: DCCP-UDP provides all of the security risk-mitigation measures present in DCCP-STD, and also all of the security risks. But the draft doesn't say anything about an MTI security mechanism. If this is really based at NAT traversal, then you might want to say something about DTLS because DCCP points to IPsec, which is all kinds of fun to setup to traverse NATS. Or is there some other mechanism that should be the MTI? If DTLS is invoked, then how does all that affect firewalls that intercept the messages?
draft-ietf-dane-protocol
Please add a description of Full Certificate to Section 2.1.2. I suggest: "Using the Certificate binary structure defined in [RFC5280]." Based on the briefing in the SAAG Session at IETF 83, I strongly suggest that this text be removed from Section 6. > > At the time this is written, it is expected that there will be a new > family of hash algorithms called SHA-3 within the next few years. It > is expected that some of the SHA-3 algorithms will be mandatory > and/or recommended for TLSA records after the algorithms are fully > defined. At that time, this specification will be updated.
Section 1.3 says: > > This document only applies to PKIX [RFC5280] certificates, not > certificates of other formats. Later updates to this document might > specify how to use certificates in other formats. > I suggest that the second sentence be deleted. Neither the TLS charter nor the DANE charter calls for support of new certificate formats. An informative reference to define "SSL proxy" would be very helpful.
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:
-- 1.2, last paragraph --
This document only
relates to securely associating certificates for TLS and DTLS with
host names; other security protocols are handled in other documents.
This makes it sound like there are other documents related to DANE for things
like IPsec and SSH. They're about keys in DNS in general, and the next sentence
refers to non-DANE stuff. Then the last sentence comes back to TLS/DTLS.
I suggest doing this paragraph as two paragraphs, this way:
Sentence 1. Sentence 2. Sentence 5.
Sentence 3. Sentence 4.
And then re-phrase the new second paragraph to say something like,
"...retrieving certificates from DNS for other protocols is handled in other
documents."
-- 1.3 --
The DNSSEC signature needs to be validated on all responses
that use DNSSEC in order to assure the proof of origin of the data.
Don't *all* responses need to use DNSSEC, as well? Or is it possible to have a
mixture of DNSSEC and unsecured DNS responses? Maybe it would be better to say
it this way?:
NEW
The DNSSEC signature needs to be validated on all DNS responses
in order to assure the proof of origin of the data.
-- 2.2 --
[in three places] MUST be represented as an 8-bit
unsigned decimal integer.
What does "decimal integer" mean? I presume you should just take the word
"decimal" out in all three places. Or is there something I'm missing?
-- 2.3 --
The order here is odd: you haven't introduced the _443 and _tcp things
yet, but you're showing them in the examples. Maybe that's OK, but it feels a
little confusing to me. Consider moving the examples after Section 3 (to a new
Section 4).
-- 4.1 --
If the DNSSEC validation state on the response to the request for
the TLSA RRset is bogus, this MUST cause TLS not to be started
Clearly, "bogus" is a technical term that means something distinct from
"indeterminate or insecure" (in the next bullet). Alas, I cut class the day
they explained "bogus", and so I need an explanation. Can you help? (I can't
explain why I didn't think about this when I reviewed -14; sorry.)
Thus, in order to achieve
any security benefit from certificate usage 0 or 1, an application
that sends a request for TLSA records needs to get either a valid
signed response containing TLSA records or verification that the
domain is insecure or indeterminate.
There you define two criteria:
1. Get a valid signed response containing TLSA records.
2. Get verification that the domain is insecure or indeterminate.
If a request for a TLSA record
does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication
that TLSA was applied.
What indication might it make? Are we just talking about audit logs of some
sort? In a user application, who will know or care about any indication that
TLSA was applied?
In any case, this sentence seems to say that the application can get neither of
(1) or (2), and yet still continue with the TLS handshake. It's advised not to
set an indication that it's using TLSA, but that's not a MUST, and anyway it can
go ahead with the handshake in any case.
If an application has a configuration setting
for turning on TLSA use, or has any indication that TLSA is in use
(regardless of whether or not this is configurable), that application
MUST not start a TLS connection or abort a TLS handshake if either of
the two criteria above are not met.
That sentence confuses me, for a couple of reasons. It seems contradictory to
the prior sentence. If you didn't get what you expect...
a. It says that if you have a configuration setting for TLSA, whether or not the
setting is enabled, you have to abort. I don't think that's what you mean.
b. It says that if you ignored the advice above and set your indication anyway,
you MUST NOT [if you keep this, you need caps on the "not"] do stuff. But the
previous sentence said you could go ahead anyway.
c. The scope of the MUST NOT is wrong: it appears to say that you MUST NOT abort
the TLS handshake, and I'm sure you don't mean that.
d. If *either* of the two are not met? You mean if *both* are not met, because
getting either is OK (and they're mutually exclusive). Right?
-- 8.3 --
For this reason, it is RECOMMENDED that DNSSEC validation always be
performed on-host, even when a secure path to an external validator
is available.
I found this odd, because at several earlier points you talked about using an
external validator with a secure path, and this is the first mention that it's
not advisable. Please consider a reference to this section the first time you
talk about that option (Sec 1.3), possibly in 4.1 after the bullet list, and
also in Appendix A.3.
========
Other comments; no need to respond to these. Take them or modify them
as you please:
-- 2.1.2 --
(Note that the use of "selector" in this document is completely
unrelated to the use of "selector" in DKIM [RFC6376].)
Was there really confusion about that? Wow. DKIM also doesn't have anything to
do with certificates. Oh, well... no harm in mentioning this.
-- 8 --
This in
essence allows an intermediate CA to be come a trust anchor
Typo: "become" should be one word.
Last paragraph:
While such trust is limited to the
specific domain name, protocol, and port for which the TLSA query was
made, local policy may deny to trust the certificate (such as due to
weak cryptography), the same as it is with PKIX trust anchors.
This is a really awkward sentence. May I suggest this?:
NEW
While such trust is limited to the
specific domain name, protocol, and port for which the TLSA query was
made, local policy may decline to accept the certificate (for reasons such
as weak cryptography), as is also the case with PKIX trust anchors.
In general, I find section 3 wrongheaded. I think it was a poor design choice to use _port._protocol.rest.of.name. But a poor design choice is not a reason for a DISCUSS. However, I do think that the document should make *some* attempt to justify this poor design choice. Perhaps it's not a poor design choice at all and I'm all wet. But I'd like to hear an explanation. Section 1 says (emphasis mine, excerpted): TLS uses certificates to bind keys and *names*. The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any *domain name*. The DNS Security Extensions (DNSSEC) provides a similar model that involves trusted keys signing the information for untrusted keys. However, DNSSEC provides three significant improvements. Keys are tied to *names in the Domain Name System (DNS)*, rather than to arbitrary identifying strings; this is more convenient for Internet protocols. Signed keys for any domain are accessible online through a straightforward query using the standard DNSSEC protocol, so there is no problem distributing the signed keys. Most significantly, the keys associated with a *domain name* can only be signed by a key associated with the parent of that *domain name*; for example, the keys for "example.com" can only be signed by the keys for "com", and the keys for "com" can only be signed by the DNS root. This prevents an untrustworthy signer from compromising anyone's keys except those in their *own subdomains*. DNS-Based Authentication of Named Entities (DANE) offers the option to use the DNSSEC infrastructure to store and sign keys and certificates that are used by TLS. DANE is envisioned as a preferable basis for binding public keys to *DNS names*, because the entities that vouch for the binding of public key data to *DNS names* are the same entities responsible for managing the *DNS names* in question. Nowhere does it say that any legacy use of the CA model, nor any designed use of the DANE model, is about anything but a biding between keys and *domain names*. Yet section 3 goes on to add the additional design requirement that I use a port *and* a transport to identify the TLSA record I'm looking for. That prevents me from having a single TLSA record for "www.example.com", which I suspect will be the widest use case, unless I try to do crazy things with wildcards or DNAMEs (and all of their associated pain) as described in Appendix A. There was a requirement in 6394 that "DANE should be able to support multiple application services with different credentials on the same named host, distinguished by port number", but nowhere does that say that it has to be done on the lookup side. (For example, it could be that multiple TLSA records exist for "www.example.com", but they are distinguishable from the data returned. If data size was the problem, you could have had the TLSA records point to a record that actually contained the cert data.) And nowhere does 6394 say that multiple *transports* is a requirement. Note that 6394 also gives wildcard use as a requirement, but that is barely met by this document in that I can't wildcard "all names", but rather I must create subdomains of "_tcp.example.com" and "_udp.example.com" and "_sctp.example.com" and put wildcards under there. Even then, that does not allow me to wildcard all possible transports which I currently don't know about. So I think this was a terrible design choice. I don't think it reasonably satisfies the requirements of 6394. But a design choice it is. I do ask that you add some text justifying that design choice.
draft-ietf-codec-opus
At this stage the authors do not need to do anything. I wish to discuss the following with my IETF collegues and will update this discuss accordingly. Given that the IETF knows of IPR claims and is publishing the software package as part of an RFC, I am concerned that we have an obligation to have included in the copyright notice a pointer to those IPR claims, lest at some point in the future the IETF are accused of failing to warn implementers of those claims. This may be something that needs clarifying with IETF council.
I am saddened that the IETF failed to meet the following goal for this work, i.e. to address the following: "There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications."
Is FEC really an accurate title for the mechanism described in section 2.1.7?
(non-blocking comments for the AD and editors) reference [Burg] has nothing but an author and title; it has to be locatable somehow other than google wikipedia references should be replaced by an actual textbook or other materials, in my opinion
I am balloting No Objection on this document on the basis that it has no impact on the internet's routing infrastructure, and that the WG and ADs have done a substantive review --- Per the Apps Dir review by Claudio Allocchio, I like the idea of adding a note (IESG Note?) to this document to highlight and make an exception of the use of code as a specification language.
p20 says you MUST zero out padding bits. I wondered if there are any situations where so many zero'd padding bits would be sent and where the bits are being stream-enciphered that that'd create a problem. Dodgy stream-cipher setups have been seen in the wild in the past so this could in such a case be a real problem. One could say that these padding bits MUST be random or MUST be set to zero except when a stream cipher is used in which case they MUST be set randomly. While neither seems perfect, either would be better than exposing a key. You can't tell from the ciphertext if there's a covert channel in any case, so zero'ing the padding bits is no help to any intermediary once they're sent with confidentiality. If this is a potential problem, it'd be good to know how often padding might happen and if there's any way to force it to happen by manipulating the channel. Perhaps the best thing to do here is change the MUST to a SHOULD and document the potential problem in the security considerations section.
- I agree that Pete's discuss needs to be resolved. It may be that there's a way to do that without the IETF trust owning the code, I don't know. I did also note that celt/pitch.c also has a CSIRO copyright from 2007-2008. Were people from CSIRO involved in the WG? If so, does whatever code is involved constitute an IETF contribution (I would think so) and has someone checked that no IPR declarations from CSIRO are needed? (Same question applies for all such contributors.) This is (I think) a varition on Pete's discuss since I guess that people from Xiph and Skype (the examples he quoted) have been involved in this work so any IPR declartions from them will have been done already. - If code comments conflict with the text of the body of the draft, then which is normative? Its clear that code wins but I'm not sure about comments within the code. I'm ok with any reasonable answer here, but wanted to check. - The code contains things like "#ifdef FIXED_POINT" which is commented out in the top level Makefile. If the normative specification is the source code, what is the normative status of code that's only conditionally compiled and that is not compiled with the distributed Makefile? Have all such conditionally compiled code fragments been tested to the same extent as the code that is compiled with the default Makefile? I'm ok with any reasonable answer here, but wanted to check. - I think a few references to introductory materials about codecs would be useful in the intro for the poor victim^Wreader who's handed this and told to implement or optimise opus. - p13, [SRTP-VBR], RFC 6562, says that VBR SHOULD NOT be used for "highly sensitive" voice and goes on to say that VBR is ok if you're just matching the bandwidth but maybe not if the variation is driven by the speech signal. I think it'd be good to note both of those aspects here. I'd also personally prefer if both 6562 and this said "possibly sensitive" rather than "highly sensitive" since I don't know how code at this layer could know what's really sensitive or not. This might also be worth repeating in (or moving to) the security considerations as well as it would perhaps be more visible there. nits - p28, says "This same data MUST also be returned as raw bits when requested." Requested by whom? I didn't get that. - p30, says "this draft" s/draft/memo/ or whatever - p31, says "SHOULD take measures to conceal the error" but doesn't say what those might be - p32, all those "1/8th bit" phrases read oddly to me but maybe that's standard fare for codec folks. - p151, says that padding is used in CBR mode but doesn't seem to say what kind of padding. If its the same as for my discuss (i.e. zero padding) then maybe the same considerations apply here? (Not sure)
I support both Pete's and Sean's DISCUSS issues. I will also add that the instructions for extracting the source code does not work on a Mac running OS X 10.7.4. The base64 utility present in OS X generates an unrecognizable archive format that cannot be decompressed by tar.
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:
-- 1.1.3 --
clamp(lo,x,hi) = max(lo,min(x,hi))
With this definition, if lo > hi, the lower bound is the one that is
enforced.
I'm not sure I understand what that text means. Are you saying that
if, for example, you write "clamp(5,x,2)", it means the same as
"clamp(2,x,5)" ? If that's the case, then maybe it should be defined
as this:
clamp(a,x,b) = max(min(a,b),min(x,(max(a,b)))
In any case, please re-phrase the text to make clearer what you mean.
-- 4.4 --
Have packet loss and clock drift been modelled, and have the
recommendations in 4.4 and 4.4.1 thus been validated? There seems to be a lot
of speculation there, and I wonder how much basis in real experimentation there
is.
========
Other comments; no need to respond to these:
This is easily the most technically dense and esoteric document I've every read,
in the IETF or elsewhere.
I'm not qualified to judge most of this document, and I expect that the number
of people in the IETF who are can be counted on one hand. I'm afraid that
includes the participants in the codec working group, and that was one of the
concerns some of us had when the WG was chartered. How many in the working
group *really* reviewed this entire document, and understand it? How much
consensus is there in the WG and in the IETF as a whole behind this, in all its
details?
That said, everything I can tell about this codec is that it's a good one, and
that it was worth doing, despite the extraordinary number of IPR statements that
apply to it (considering the WG's goals). So I approve of the publication of
it, and I've reviewed it as best I could.
There was concern brought up in the Applications Directorate review about the
mechanism of using C code as a specification. I don't have a concern about
that, and find it an acceptable mechanism.
I did find myself wondering idly, as I read section 4.2.7.5.6, whether
"cos(pi*n[k])" was intentional, and whether anyone asked Victoria's Secret about
an IPR statement with respect to trademark....
Examining the source files and some of the other files, I find things similar to this: Copyright (c) 2011 Xiph.Org Foundation, Skype Limited I think the copyright for the source code should all be held by the IETF Trust with appropriate template information. The reason I am concerned that this might take a while is that in at least the case of the COPYING file in the root directory, the copyright is held by several organizations and individuals. I believe all of those folks must be contacted and explicitly agree to allowing their code to also be copyright by the IETF Trust. (The files in the git repository cited in the document probably also should have the IETF Trust copyright. Moreover, I would prefer to see the repository hosted on an IETF site rather than on github. I am concerned about drift of the code on github from the code in the RFC and ending up in a situation where the github version is -- de facto -- the place to go for the standard.)
Like others, I don't feel I can give a substantive review to much of this document and will simply trust that it has gotten sufficient review. The one technical thing I noticed: A few variables that need to be unsigned because they're used in shift right (>>) operations are not explicitly specified as unsigned, in particular ft (used in 4.1.5) and b0 (used in 4.1.1). You do note other variables as unsigned, so I took these as omissions, but it may be clear from context. It seems to me a review of such variables might be useful. Like other ADs, I have some concerns about the use of source code for the normative spec: - First of all, this does turn the entire concept of "independent interoperable implementations" on its head. If the source code is normative, I don't see how we could ever judge that an implementation was independent and therefore how this spec would be advanced along the standards track. - Furthermore, I've got some concerns that we may, at some point in the future, encounter a small edge case where the code simply has a bug, but the text of the document makes it clear what the intention was. I would hate for us to say, "Well, the code is the normative reference, so the bug must stand and we must update the descriptive text to suit." I doubt that would happen, but we are in unchartered waters by using source as the normative spec. - Finally, the source code here is in base64, compressed, tarred format. It is completely unreadable in the spec. I do not know of any other RFC that has humanly-unreadable text in it. Again, we are in completely unchartered waters. And it is these "unchartered waters" that are the real issue all around. We may need to discuss how we handle this document now and in the future. But we signed up for this in the charter, so I'm willing to see it play out. There is no doubt that this document is an entirely odd duck.
A nit: Section 3., paragraph 1: [...] > the internal framing used to pack multiple frames into a single > packet. This framing is not self-delimiting. Instead, it assumes > that a higher layer (such as UDP or RTP [RFC3550] or Ogg [RFC3533] or > Matroska [Matroska-website]) will communicate the length, in bytes, You mean that some lower layer (UDP, RTP, etc) will take care of this. Those are not higher layers in the IETF sense.
Updated ... I haven't complete my review (this one is a beast), but I thought I'd start the process rolling: 1) If we're going to be distributing source code: Can we include a sha1/sha256 checksums or something in the Appendix? It's pretty common to do so when distributing source code. Could we also include the output of the idsigcheck code (https://tools.ietf.org/tools/idsigcheck/code) and place that somewhere permanent to make sure the contents haven't been doctored (and we're not distributing a virus). 2) I glossed right over the pointer to the RFC in the previous paragraph. cleared this one... 3) (right out of my league here and I'm sure there was some discussion about this) There's also a file called copying - shouldn't it include the following: Copyright (c) <insert year> IETF Trust and the persons identified as authors of the code. All rights reserved. and shouldn't it be in all the .h, .c, etc. files? 4) (right out of my league here and I'm sure there was some discussion about this) Some of the copyright years in the .h files are farther back the readme. opus_types goes back to 1994. Does the readme need to cover all the dates?
The following command in the appendix don't work:
cat draft-ietf-codec-opus.txt | grep '^\ \ \ ###' | sed -e
's/...###//' | base64 -d > opus_source.tar.gz
I think you need to r/draft-ietf-codec-opus.txt/rfcXXXX.txt and note that the
RFC editor should update this when it's published.
draft-ietf-mpls-ldp-gtsm
(1) 5082 has a MUST for authentication if negotiating GSTM. I don't get why this "built-in" negotiation, which seems to me to be added post-facto, gets around this need for strong authentication. I'm not going to insist that you define such authentication, (be nice if someone did though), but I do think you need to say you're not adhering to the MUST from 5082. (2) When receiving an LDP Link Hello with G=1, what checks are to be made on the TTL for that packet? If you don't enforce GSTM on that, then presumably attacks could be mounted with a Link Hello that has G=0, defeating the negotiation (hence point (1) above I guess;-). Why is this ok? If you're really taking a "leap of faith" here, then that's probably fine, but should be stated IMO. In any case I think you need to be clear about whether the TTL on this packet needs checking or not. nits: - typo in section 3? "(i.e.,g G=1)" - s/g//? - typo in section 5: s/may cause LDP peering session/may cause an LDP peering session/
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- 2.1 -- The G flag is meaningful only if the T flag is set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. What happens if it isn't? SHOULD means, basically, MUST unless you fully understand the consequences... so what are the consequences, so that an implementor might have a chance to understand them? ======== Other comments; no need to respond to these. Take them or modify them as you please: -- 1 -- Therefore, GTSM can fully benefit LDP protocol peering session established using Basic Discovery. I don't understand this sentence; maybe there's a word missing. But it also seems awkward. Does it mean this?: NEW Therefore, GTSM can provide full benefit to an LDP protocol peering session that was established using Basic Discovery. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration. But you just said that RFC 5082 said not to do that. I understand what you're getting at, so maybe this will make it clear?: NEW That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration, while retaining the spirit of the advice in RFC 5082.
RFC 5082 says there's a MUST for authentication but doesn't say what mechanism - and that's fine. LDP's authentication mechanism, TCP-MD5, must be a configurable option (i.e., not always used). Doesn't using GSTM with LDP invoke a requirement to *use* the authentication mechanism (i.e., upgrade from a configurable option)?
draft-ietf-trill-rbridge-bfd
This is I believe comparing the TRILL case with MPLS-TP "TRILL BFD uses the TRILL Rbridge Channel [TRILLChannel] similar to the way that MPLS OAM protocols use the MPLS Generic Associated Channel [RFC5586]. However, the RBridges that implement TRILL are IS-IS [IS-IS] based routers, not label switched routers; thus TRILL BFD is closer to IPv4/IPv6 BFD than to MPLS BFD." It is unclear what the above statement means. Whilst TRILL uses ISIS and MPLS-TP does not, the fundamentals high speed detection is is common to all. Where TRILL and MPLS-TP are closer than that are to the IP case is that neither have the use of IP addresses available to them.
I am surprised that TRILL did not take the opportunity to profile out the echo mode, since I understand that it is rarely used in IP networks and not used in MPLS_TP networks.
From the shepherd writeup: There are references to section 10 and section 4, which should both be references to section 7.
John Scudder raised a number of concerns in his Routing Directorate review. I support these in my Discuss as follows. 1. It is not clear why demand mode was explicitly excluded. TRILL would actually seem to be a reasonable fit for demand mode. Please either include demand mode, or a short note on why it is excluded. 2. "there will be only a single TRILL BFD Control session between two RBridges over a given interface visible to TRILL." This text is a little hard to parse and may be ambiguous. Please find a way to re-write it with reference to a pair of RBridges RB1 and RB2 and their interfaces RB1_Int1 and RB2_Int1. Or something like that. 3. "the entire TRILL BFD Echo protocol specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is RECOMMENDED that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back." The use of "RECOMMENDED" contradicts "left to the discretion of" because "RECOMMENDED" is a very strong encouragement to do something. I think you need "suggested" as this is just general advice to an implementation. 4. In two places text like the following appears: "Is the M-bit in the TRILL Header non-zero? If so, discard the frame. TRILL support of multi-destination BFD Echo is beyond the scope of this document." If multi-destination doesn't make sense in the context of TRILL, it is fine to exclude it by enforcing that the M-bit be zero. However, "beyond the scope of this document" normally means something like "we may do it in the future but haven't worked it out yet". By forcing the discard under these conditions you are doing more than putting the function out of scope: you are disabling it. You might solve this by mandating the setting of the bit to zero, and saying that if the bit is non-zero the behavior is future description, and that an implementation MAY discard the packet. 5. The Security Considerations section specifies how authentication is to be done, but doesn't provide an analysis of it or of any broader issues. According to RFC 3552 (Section 5) the Security Considerations section should include an analysis of issues that arise from the operation of the protocol defined in the rest of the document, including but not limited to the security features of that protocol. You could place the current text in a subsection of the Security Considerations (called "Authentication") and add more text to the core section. Additionally, I think you are missing a normative reference to https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-oam/ This is necessary to set the context for why you are using BFD and for what purpose. It would also clarify which BFD features are needed and what OAM features (from the whole set) are addressed by BFD. Finally, although I understand that the scope of this document is limited to encapsulation, I think that this leaves the solution deficient. It needs a description of bootstrapping in the Trill environment.
It is very odd to bring this document forward ahead of the normatively referenced draft-ietf-trill-rbridge-channel Doing this makes the review less certain.
- I'm not clear if the key derivations described in section 6 are mandatory to implement or not. It says that if IS-IS auth is in effect, then you "use" (would that be better with a 2119 MUST?) BDF Meticulous Keyed SHA1 (nice name btw:-), but its not clear to me if that means this is MTI or not. - What does "that state of IS-IS shared secret" mean? Maybe s/that state//? - I don't get why this only needs/uses key ID 0, can you explain further? I guess I'd have expected that if the IS-IS-shared-key had a key ID, then that would be used for the derived key(s) defined here. - I'm wondering if the authentication scheme described here is really used or not? I think it'd be good to say if its real or fictional, if that is known.
Thank you for addressing my DISCUSS so quickly.
Minor comments; no need to respond: I find citing nroff in the Acknowledgments section to be odd, for whatever that's worth. (I also can't remember when I last saw an actual normative reference to ASCII.)
I agree with the shepherd's recommendation to change the reference for [ASCII]
to ANSI X3.4. I suggest looking at the references in RFC5891 for an example:
[ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968. ANSI
X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains
definitive for the Internet.
I wonder if what is said about congestion control in Section 7 of RFC 5880 is also applicable to this draft. The current draft text denies this, as it states in Section 5: > It is up to the operator of an RBridge campus to configure the rates > at which TRILL BFD frames are transmitted on a link to avoid > congestion (e.g., link, I/O, CPU) and false failure detection. This seems to be absolutely contradicting RFC 5880 on the matter of congestion control.
s6 contains the following: If such IS-IS authentication is in effect then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges use BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below I think you need to say what the MTI is in this case. That might be as simple as adding "MUST" before "use" but that's a little more than MTI that's mandatory to use. Are you trying to say that in this case, BFD Meticulous Keyed SHA1 authentication [RFC5880] with keying material derived as shown below MUST be supported as a configurable option: ey [material derivation here]?
draft-ietf-dnsext-dnssec-bis-updates
During the "no answer" mega-discussion on the DANE list, [1] I seem to recall this comment was made more than once: "you're seeing all this because you're maybe the first new application that really needs DNSSEC," or words to that effect. Should any of that discussion be reflected in this document? (I assume its not already there for timing reasons if nothing else.) [1] http://www.ietf.org/mail-archive/web/dane/current/msg04845.html
The Gen-ART Review by Richard Barnes on 25-May-2012 raised two major concerns. The Gen-ART Review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07454.html Building on this review, I have these suggestions: (1) Section 4.1: Please clarify the threat model. If the zone operator is malicious, then it can simulate the necessary zone cut and still prove the non-existence of records in the child zone. (2) Section 5.10: Please explain why the "Accept Any Success" policy is more preferable the "Highest Signer" policy. This analysis might not appear in Section 5.10; it could appear in an appendix.
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: Ditto Sean's comments about DNSSEC vs DNSSECbis, and about Draft Standard -> Internet Standard. -- 2.1 -- signal that a zone MAY be using NSEC3, rather than NSEC. This MAY and the one in the following paragraph are misused: they should not be 2119 terms. Describing what a zone "may be using" is simply a descriptive phrase, not anything normative. Actually, I would say "might be using". -- 5.2 -- Isn't the point really more general: that if the validator is unable to validate the signature, *for whatever reason*, it treats the zone as unsigned? Wouldn't it be better to make that general point clear... and then give unknown or unsupported key or message digest algorithms as reasons it would be unable to validate? ======== Other comments; no need to respond to these. Take them or modify them as you please: -- 2 -- There's a SSnake in the graSSS in the SSection title.
Is there a reference that could be added to section 3.1 to where the scaling concerns called out there are discussed?
These are my preliminary sets of comments:
1) Any reason you can't just refer to DNSSECbis as DNSSEC? I guess does the
outside world know DNSSECbis isn't DNSSEC?
2) General: r/RFCXXXX/[RFCXXXX] throughout except for the abstract. A couple of
times I thought the RFC references needed to be included in [] so it's probably
better to just do it everywhere. You also need to add [RFC2308] as a reference.
3) s1 paragraph two: RFC 6410 got rid of Draft Standard so either
r/Draft/Internet or r/from Proposed Standard to Draft Standard/along the
Internet Standards track. Or something like that.
4) s1.2: To cut down on the possible "where is X defined" you could add
something like: "Readers are assumed to be familiar with DNSSECbis documents as
the terminology used herein comes from those documents."
5) s2, s2.1, s2.2: Could you replace the three instances of "should {also} be"
with "are"? If the WG considers them part of the core, then aren't they? It
also avoids the whole question about whether it ought to be SHOULD (not that I'm
asking to change that).
6) s2.1: Pet peeve requirements in a paragraph that starts with Note. Couldn't
you just r/Note that the/The
7) s5.5: Might be worth pointing out that this was filed as an errata.
8) s5.6, s5.7, and s5.10: I was already to give you the kudos for each section
being clear about which document was being updated until I got to these
sections. Please state which RFC you're updating in these sections. In s5.6 is
it updating 3225?
9) s5.11: could you just strike "note that"
draft-ietf-trill-rbridge-extension
Could you provide use-cases for this extension mechanism? What extensions do you intend to define? How do these extensions fit into your current charter?
I had questions that overlapped a subset of Adrian's COMMENT, so would encourage the authors and AD to pay attention to his ballot.
I have no objection to the publication of this document.
I have a number of questions and issues you might want to look at before
the document is published as an RFC.
---
Does this document update 6325?
---
Abstract say...
This document specifies an initial extension providing
additional flag bits and specifies two of those bits.
The Introduction says...
This
document specifies an initial extension providing additional flag
bits and specifies one of those bits.
Anyway, it appears you define the meaning of three bits (if you include
CRSVS). And, through the definition of the structure, you sort of define
the meaning of the others.
---
If there is an indication that at least one CHbH option present, does
each hop have to scan all options to check whether they are relevant?
This seems to be a compounding factor for the note in Section 2.
The note is good, but I wonder what the consequences is of an increased
likelihood of dropping a packet with a hop-by-hop critical option.
---
In section 2
o flag affecting an as yet unspecified class of RBridges, for
example border RBridges in a TRILL campus extended to support
multi-level IS-IS
It seems odd that if the class of RBridges is unspecified, you can give
an example like this. I suggest that you rebrand this flag as reserved
for future extensions, or go to the trouble of defining its real use.
The same ambiguity arises in the text describing CRSVS in 2.3.1
BTW s/flag/flags/ ?
---
Section 2
if it is a
known unicast frame
Are there unicast frames where it is impossible to know that they are
unicast?
---
Section 2.3
(The first two critical summary bits are as specified in [RFC6325].
In this document an "S", for Summary, has been added at the end of
their acronyms.)
Bit(s) Description
---------------------
0-3 Crit.: Critical summary bits.
0 CHbHS: Critical Hop-by-Hop extension(s) are present.
1 CItES: Critical Ingress-to-Egress extension(s) are present.
2 CRSVS: Critical reserved extension(s) are present.
The bracketed text is a little confusing. There are indeed only two
summary bits defined in 6325. There is a third bit defined here. All
three bits have been given an "S" suffix.
---
Is section 2.4 simply egg sucking, or is there something else that needs
to be explained?
I don't understand the security model for the ingress-to-egress extensions. Given that hop-by-hop extensions can be modified/dropped, there can be no ingress-to-egress cryptographic security, however this is not stated. Were it stated, it would appear to make all extensions hop-by-hop, at least in terms of (non)end-to-end security. Either that or you need a quite complex set of security mechanisms, which I assume you don't want. Or, perhaps the WG were happy that introducing extensions like this, means never being able to use cryptographic security and extensions between ingress and egress? (Or some highly complex in-between state.) I'm not looking for any specific change for now, but rather just to understand what's the expectation here for e2e-like cryptographic security.
- Pure opinion from a TRILL-ignoramus: this seems over complex to me. - I don't get how the TLVs are encoded, and associated with the various flag fields, e.g. CItE etc. That may be "obvious" but I didn't get it at all sorry. - I don't get how extended flag thing is supposed to work. How is someone supposed to know when to allow addition of the bicycle extension? - This: "Any extended flag indicating a significant change in the structure or interpretation of later parts of the frame which, if the extended flag were ignored, could cause a failure of service or violation of security policy MUST be a critical extension. If such an extended flag affects any fields that transit RBridges will examine, it MUST be a hop-by-hop critical extended flag" seems like it'd be a fine source for useless rathole arguments. - What does: "A transit or egress RBridge may assume that the critical summary bits are correct." mean? - This seems very odd: "Conflicting extensions SHOULD NOT be defined, but if they are,..."
-- 5 -- Please explain (briefly -- a sentence or two will surely do) the reason for selecting Standards Action for this registry. I'd prefer it if that sentence or two were in the IANA Considerations, unless there's a reason not to put it there. I understand that there is a limited number of bits to be given out, so freely allocating them for the asking would be harmful. Still, Standards Action is very heavyweight: did you consider IETF Review (which could allow Informational or Experimental documents to do allocations, with community consensus and IESG approval), or even Specification Required (where you could give instructions that the designated expert exert tight control over the allocations)?
What Adrian said....
draft-ietf-mile-iodef-xmlreg
Section 1, Introduction IODEF extensions via class extension through AdditionalData and RecordItem elements, as per section 5.2 of [RFC5070], generally register their namespaces and schemas with the IANA XML Namespace registry at ... => remove "generally" - There is one nit catched by the nit checker: => The draft header indicates that this document updates RFC5070, but the abstract doesn't seem to mention this, which it should.
Please consider the editorial comments in the Gen-ART Review by Suresh Krishnan on 5-Jun-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07483.html
This document defines no protocol, does not say how to implement a protocol, and does not have anything to do with a protocol except for information about how an IANA registry is to be used. Why is this going on the standards track? This should either be Informational, or more likely BCP.
Consider "designated by the IESG" instead of "designated by the IETF Security Area Directors."
draft-ietf-manet-nhdp-mib
This document fails to provide use cases. Because it doesn't provide use cases, it is not clear that any/all of its objects are useful. While this comment might be leveled concerning regarding MIB, it is particularly applicable in this case because we have so little operational experience with ad hoc networks. Will the ad hoc network include a NOC? What policy will that NOC attempt to enforce? What information/control will the NOC need to enforce that policy.
I am voting no objection on the basis that other members of the IESG who are more knowledgeable on MIBS will have reviewed this.
- There is a clear DISCUSS coming from the MIB-doctor review. Please address it. - While reading through the document, I've been really waiting for an applicability statement section. A sentence [RFC6130] such as "if router A is able to exchange packets with router B, and router B is able to exchange packets with router C, this does not guarantee that router A and router C can exchange packets directly" got me thinking about the management and operational aspects. How do you plan on using this MIB module, taking into account that you're dealing with an ad-hoc network? Note that the write-up mentions: "This document shepherd is not aware of existing implementations of this MIB although several implementers have indicated interest in the work." So the potential implementers should have some views on the following questions. I'm really after 3 different parts in the applicability statement (or call it use cases if you want to): configuration management, monitoring, and notification. And I have questions such as: * one static NMS or each MANET router configures/monitors his (newly attached) neighbor(s)? * where are the notifications sent to? * Do you expect all MANET routers to always have connectivity to a static NMS? * etc... Obviously, monitoring, for example, is important in ad-hoc networks, but please let us know how you envision doing this. For example, right now, I see the term "appropriate SNMP management stations", and I have no clue what's "appropriate" in the management of an ad- hoc network. I see some other MANET MIB modules... * draft-ietf-manet-olsrv2-mib-04 Definition of Managed Objects for the Optimized Link State Routing Protocol * draft-ietf-manet-report-mib-02 Definition of Managed Objects for Performance Reporting * draft-ietf-manet-smf-mib-04 Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set However, this document is the first MANET MIB module to reach the IESG, so those operational questions are important. If this is expressed in a different document, let me know, and I can review it. Along the same lines, 1. see Al Morton's review, part of the OPS-DIR > General question: Is a lossy, mobile ad-hoc network compatible with > SNMPv3? In other words, will the link performance information needed > for troubleshooting really be available when it is needed most, and > critical nodes may be unreachable? 2. Read Ron's Bonica's Abstain
- Abstract This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. Should this be "MANET router"? "MANET router" is used in RFC6130 Alternatively, I see in this document: "NHDP router" "router in a Mobile Ad Hoc Network (MANET)" Same remark for the introduction, which uses the same text. - First occurence of NHDP must be expanded.
I agree with Sean's discuss. DES just isn't up to this these days. p60 - I think you mean confidentiality and not privacy?
draft-melnikov-smtp-priority
I agree with Adrian's comments
The document talks about end-to-end use across a mix of MTAs that do or do-not support the extensions, but not across MTAs with different administrators. The applicability of this mechanism would seem to apply only to a single "domain" of administration, where control of incoming messages at the edge can be performed to make sure the system isn't abused. I think the same problems from interdomain IP QoS apply here as the initial MTA where the priority was approved may not be able to tell if it will be approved all the way across the path of other MTAs to the destination. In the case where there are multiple MX records, I believe this document is only advocating continuing to use the record that was selected based on the RFC 5321 algorithm (using the specified record priority, or randomly within a single priority) and doesn't attempt to "balance load" across them. The assumption here must be that the network resource bottleneck is shared between this MTA and the multiple potential next-hops. If there's a situation where there isn't a shared bottleneck, however, this assumption will not lead to optimal behavior, and I think the topic should at least be touched upon and discussed somewhat.
I agree with Martin's DISCUSS point that in Section 5.1, "congestion" refers to existence of a queue at the application layer, and does not have anything to do with network-layer congestion which should probably be clarified.
I have no objection to the publication of this document. --- Are you sure you have not conflated priority and importance? High priority messages need to be delivered quickly and an implementation may want to let them overtake lower priority messages. High importance messages need to be delivered (eventually) and should have a lower chace of being dropped. 4.1 with its ability to reject low priority messages appears to be doing importance. --- Appendix E gives some motivations for 19 priorities. It seems like a very large number to me. Experience with this sort of range of options and priority levels suggests that it only adds confusion. I suppose my question is: are you sure?
- (An almost "discuss"): 4.6 means that anyone who is ok to send me a prio=9 message can cause me to send a whole bunch of prio=9 messages (as DSNs). Is that not a new DoS vector? Please explain why not. (The rest are not near-discusses btw.) - The writeup is somewhat coy about the use-case. Its military messaging, ala STANAG 4406/ACP 123. - I don't get why the EHLO keyword has no parameters. I'd have thought that a parameter there could be a useful way to signal some semantics for MT-PRIORITY values. Maybe that was discussed before though. (I've not kept up with all the mail on this draft btw.) - I agree that the "untrusted source" concept in 4.1 seems broken and that a resolution such as that discussed via email seems right, that is, that this is down to bilateral agreement really rather than being tied to SMTP AUTH so directly. - Is 4.3 really needed? Seems like its not about relaying but is generally true. - What exactly does "retain" mean in 4.4? I guess it means that the MLA MUST forward the mail with the same MT-PRIORITY value to any next-hop that supports it. But what if only 50% of the next-hops for a given message support this? - I don't get what X.3.TBD2 means at the end of p7. (I even looked at 2034 and still don't get it.) - Saying its "important" for MUAs to support this spec seems over-stated. If you want to keep the term "important" then I guess it'd be good to specify to whom what is important? (Not all players in this space have commensurate interests.) - 5.1, possible nit, possible significant comment. A lower priority message could be sent first with advantage to all. If e.g. the sending MTA knows that sending the higher priority message over a later, but "better", interface, e.g. that is currently down. This is a familiar concept when dealing with contacts in DTNs. I think maybe it'd be better to talk about trying to get the mail delievered earlier rather than the speciifics of how priorities map to sending things from queues.
I agree with Adrian's comment that 19 priorities may be hard to manage.
1) There is some tension between the requirements in Sections 4.1 and 4.2 (highlighted by a requirement in Section 10). Section 4.1 says "The SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy." Section 10 reinforces that MTAs "MAY override the priority values" But Section 4.2 to take the results of 4.1 (which includes the possibility of changing the message priority), but goes on to say: "For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if that value is not supported (as a distinct priority value) by the MTA's implementation of this extension." This appears to be a conflict. Would it better capture the intent to change that last sentence to sat "only because that value is not supported" instead of "if that value is not supported"? If so, I suggest rewriting the sentence without using the 2119 MUST NOT. Would the following work? (Adam Roach put this together): "An MTA that supports the MT-PRIORITY extension MUST include an MT-PRIORITY parameter whenever it relays a message to an MTA or MDA that also supports the MT-PRIORITY extension. The MTA sets the value of the MT-PRIORITY parameter according to its local policy. In the absence of a policy-based reason for adjusting the value, the MTA SHOULD set the MT-PRIORITY parameter to the value determined from the procedure described in section 4.1. Note that this value might be different than the priority level at which the MTA actually handles the request, due to the rounding described in section 5." Section 5 also reiterates this MUST and might need to be adjusted to match. 2) Amplifying Stephen's almost-discuss: Do we really want to preempt real messages in favor of DSNs? If so, are there security considerations specific to DSNs that this document should point to (that would discuss how to mitigate large numbers of malicious DSNs)? 3) Section 5.4 restricts MTAs from rejecting messages based on priority or priority+size (arguing that only MSAs should do so). Why is this particular kind of rejection being treated differently than other kinds of rejections at MTAs? Is there a general requirement to avoid these bounces in another document you can point to instead? If not, a discussion of the tradeoffs of a policy that would result in a rejection seems more appropriate than a normative restriction to not reject. 4) What discourages an MUA (the UA, not the user) that gets a rejection stating that its priority was too low from immediately resubmitting the request with a higher priority? Is there anything that discourages a user from doing so? 5) (The clarification the Transport ADs have asked for may obviate this). Can the document clarify why and when an MTA would want to open a new connection for sending higher priority messages? If it has a connection already, why wouldn't it just use that? If there's no transport congestion, and the queues behind the existing connection are backing up, how is opening a new connection going to help? If there _is_ transport congestion, opening a new connection is going to hurt.
I have a DISCUSS about this paragraph and the benefit of this mechanism: Section 5.1., paragraph 6: > This extension provides benefits in networks with limited available > bandwidth or long round trip times, when the actual message transfer > over the network can create a significant portion of the overall > message delivery time from a sender to a recipient. It is also > useful in case of a congestion, for example resulting from an MTA > queue build-up. When neither of the two conditions mentioned above > is true, the use of the MT-PRIORITY SMTP extension will not result in > a better SMTP service. Congestion is there if the incoming rate is higher than the outgoing rate on a bottleneck. How does this mechanism help when there is congestion? This isn't clear to me at all. First of all, this seems to be talking about congestion on the SMTP level and not necessarily at the transport level. Please clarify this in the text. This mechanism can even increase the queue length at a MTA, if high priority messages arrive at the same rate (or even higher) than the outgoing rate from that MTA. This situation would also occur without the priority mechanism, but the mechanism can make the situation even worse for lower priority messages. The will be queued up and potentially starve to death in the queue, if higher priorty messages keep arriving and they are being jumped to the front or near front of the queue. I do not see that it is safe to state that this mechanism will help in congestion at the SMTP level. Further, how is the queue to be managed with the different priority levels?
- I agree with Adrian about the really high number of priority levels - What do the priority level mean in a multi-domain scenario, i.e., two domains can have a completely different understanding about what a particular level means. - Section 6., paragraph 0: > Unextended SMTP does not offer a service for timely delivery. The > "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in > [RFC2852] is an example of an SMTP extension providing a service that > can be used to implement such constraints. But note that use of the > DELIVERBY extension alone does not guarantee any priority processing. Does this extension allow timely delivery? Or is it simply trying to enhance timely delivery? And what is timely delivery? I don't see how this is offering a service for timely delivery in all circumstances.
Is it appropriate for the IETF to recommend the mappings for others (thinking here mostly about MMHS and NS/EP values) in App A and C? Seems like we ought to define the mechanism and then somebody representing those communities defines what values they want?
Updated #4 based on some IMs with Alexey: 0) BTW - my initial thought about this draft was "I wish I had of thought of this ten yeas ago." Really hoped you'd go all the way and have different precedences/priorities for the to and cc recipients ;) 1) App A: Actually ACP123/STANAG 4406 specifies a range from 0-31. And (this relates to the discuss) if somebody specifies four more values higher than override how will the mapping get done? 2) App A: In 123/4406, there's priority and precedence. The values you list are from precedence so I assume you're talking about those values and not the urgent, routine, and non-urgent values for priority. App A says priority though: Military Messaging as specified in ACP 123 [ACP123] (also specified in STANAG 4406 [STANAG-4406]) defines six priority values. 3) App B contains the following: Where SMTP is used to support military messaging, the following mappings SHOULD be used. Should this say mixer instead of military messaging? 4) I'm trying to wrap my head around why if you go from MMHS to SMTP you'd map urgent and flash to different level but if you went through MIXER to get to SMTP you'd get flash and override mapped to the same level (urgent) And, what do you do if both primary-precedence and mixer priority are there?
draft-ietf-appsawg-about-uri-scheme
I have no objection to the publication of this document as an Informaitonal RFC. Following on from the transition to Informational (for which, thanks), you might consider s/specifies/describes/ (But this is a *very* unimportant comment!)
The FCFS registration scheme could lead to anyone registering an about-token that's in current use in a browser. Why isn't expert review more suitable here to protect against such abuse? For example, nothing here prevents me from registering about:config, which is used by >1 browser. I don't get why that is not a problem. (This is almost a discuss btw, I'd really like to see a response if possible before the telechat.) Why does about-token "correspond" to hier-part from 3986? What would "about://example.com/foo/bar" mean? I'd have thought that omitting the authority would be correct for this scheme - why am I wrong?
Just a non-blocking comment that can be resolved easily... The Acknowledgments section appears to be incomplete. The first sentence looks fragmented, maybe an editing mistake?
no objection if this draft is really going for informational (as listed in the draft) and not as Standards Track as listed in the datatracker.
I have no objection to the publication of this document as an Informational RFC.
draft-ietf-tcpm-tcpmss
I don't understand what we gain by having this statement: Additional clarification was sent to the TCP Large Windows mailing list in 1993 [Borman93]. The goal can't be to acknowledge the person who posted the email, as this is the author ;-) And it's even confusing. Should I review this email on the top of the document. This can't be, right? Note: that's the first time I see, part of a RFC, a reference to a specific email in the archive Regards, Benoit.
I am surprised about the perceived need to update an obsoleted RFC, but if folk really want to do it, I think they should make it very clear in this document that RFC 2385 has been obsoleted by RFC 5925 so that readers understand that using RFC 2385 with the correction documented here is not the preferred approach. --- Would a reference to RFC 6151 help?
Please consider the editorial comments in the Gen-ART Review by Martin Thomson on 24-May-2012. Please find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07452.html
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: In addition to Adrian's comment... -- 8 -- At least RFC 879 and RFC 2385 should be normative references here. It's kind of hard to imagine how this can Update those, and not cite them normatively. (Don't make the mistake of thinking that Informational documents don't have normative references.)
The abstracts seems to be rather short in order to give hints to a reader, i.e., it would be good to the part of IP options and TCP MSS from the into.
Just a reminder to publish a version that incorporates changes agreed to as part of the secdir review.
draft-ietf-mile-template
Extending on Adrian's point: I would be glad if you discussed with the Ops ADs the need to include a section in Extensons I-Ds covering Manageability Considerations for the extensions. While I understand that not all extensions have management and operational considerations, a way forward could be a new manageability section that would contain something such as: If an extension implies some operational and management considerations such as defined in RFC5706 appendix A, then those considerations must be covered in this section"
- shouldn't you reference draft-ietf-mile-iodef-xmlreg-01?
- section 2 "A non-
exhaustive list of good candidate extensions to IODEF includes:"
This sentence
really looks like you're proposing new work. Could you change it to something
such as "a few examples ..."
- class extension through AdditionalData and
RecordItem elements,
as per section 5.2 of [RFC5070]
s/and/or
- section
A.6 and A.7. It seems that you redo the RFC editor document here. This is
confusing.
Thank you for this document I have no objeciton to its publication. Here are a few minor and non-blocking Comments that I would appreciate you reading before publication is complete. --- You will need to remove the citaiotn notation ([ ]) from the Abstract. -- You should clean up the unused reference to RFC 3339. --- I would be glad if you discussed with the Ops ADs the need to include a section in Extensons I-Ds covering Manageability Considerations for the extensions. --- I found the nesting of appendixes a little perturbing, but it is probably easy enough to grok.
Please consider the editorial comments in the Gen-ART Review by Peter Yee on 26-May-2012. Please find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07455.html
In a Last-Call discussion, the author agreed with a comment made by Peter Saint- Andre that the reference to RFC6545 should be informational, but that change has not yet been made. It should be made more obvious that the examples in Appendix B are examples, and not actual registrations. Using a real protocol for the example is hazardous. Could you replace the first example (ENUM) with something clearly not real? (btw, RFC6116 defines e164.arpa.) Can you provide a reference into the existing IODEF specifications for where the kind of extension discussed in item 3 of section 3 is anticipated?
Peter's Last-Call comments also included some editorial suggestions. I would like to amplify his first comment on being very clear when the use of these templates (and the guidance around the selection of a namespace value) are appropriate.
draft-levine-application-gzip
I have no objection to the publication of this document. Please check zlib/Zlib/ZLIB for consistency
Are the contact points for these registrations ok? The template calls for a person/email address, but both give URLs: http://www.zlib.net/ and http://www.gzip.org which is fine information but perhaps not what's needed?
I have no problem with the publication of this document. I have one editorial nit that you may take or leave as you see fit. - The cross referencing notation of "Section [blah]" is confusing given that it uses short-hand names for sections. Please consider changing these to "Section #" style notation.
draft-irtf-rrg-ilnp-arp
draft-irtf-rrg-ilnp-v4opts
Thank you for addressing my discuss items. I would like to suggest that the authors verify that the IPv4 routers in their test network forward packets containing options with adequate performance before they invest significant time in the IPv4 Option approach.
Thank you for publishing draft-irtf-rrg-ilnp-v4opts-05.txt, which revises the specification to use the IPv4 experimental option code. I have two minor editorial comments: In Figure 1, the option length fields should be "OL=20" and "OL=12". In Figure 3, the option length field should be "OL=12".
I agree with Stewart's Discuss stating that there is no need to allocate IPv4 options for this experiment since it can be run on existing experimental options. The authors give a reason why using the existing values would not meet their requirements. I dispute the reason as follows: > In order to experiment with a new protocol, an experimental value may > be needed that won't collide with an existing or future usage. It is precisely the nature of experiments that they may colide if they are run in overlapping networks. There are sufficient code points available that this can be coordinated if there are multiple experiments. There are no existing experiments that immediately spring to mind. Future experiments will be less likely as IPv4 is sunsetted. --- The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
draft-irtf-rrg-ilnp-icmpv4
Thank you for addressing my concerns.
I have cleared my Discuss on the basis of the new revision to this document. Thanks to the authors for moving to an experimental code point for this work. --- The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.