IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-06-30. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1235 EDT break
1241 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
Reminder from Secretariat
1300 EDT Move to executive session
(at 2011-06-30 07:30:08 PDT)
draft-ietf-pim-mtid
We should pick up the comments raised by Thomas Clasuen in his Routing Directorate review
(1) end of 4.2.2, s/choose not/chooses not/ (2) 4.2.4.1 s/all together/altogether/
1) some "may" usage is in lower case and should probably be capitalized for clarity.
Please add introductory text prior to the bullets in sections 3.1, 4.2.4.1, and 4.2.4.2.
Acronyms should probably be expanded out and defined in the Abstract and the Intro.
Can you clarify the first paragraph of 4.2.3? It's not yet obvious why you felt a need to call out the Robustness Principle here specifically. Are you trying to note that you have some backwards compatibility with existing systems, provide guidance to implementers of the extension to be careful to achieve that compatibility, both, or something completely different?
This is updated.
#1) resolved
#2) Section 5.2, needs to include something to say how the reserved bits are set
and how they're treated. Maybe something like what's in RFC 4601:
Reserved
Set to zero on transmission. Ignored upon receipt.
#1) Section 3.2 contains the following:
- This value must be unique and consistent within the network
domain for the same topology.
r/must/MUST?
draft-ietf-payload-rfc3016bis
The only mention of RFC 3640 is in the Abstract, where you seem to
state that, in new implementations, *this* I-D is NOT RECOMMENDED.
That really isn't very good, is it? If you are going to have the
specific sentence in the Abstract (and I presume it is there for a
good reason) you siply must:
- include this point in the Introduction
- take the time somewhere in the document to explain the limitations
of this approach (possibly by reference) and make a clear statement
about the purpose of this document and when it should or should not
be used.
Can you please remove the citation ([RFC3640]) from the Abstract. --- For what it is worth, the ballot text says this document updates 3016. Obviously "update" is an overloaded term wrt RFCs, and "adds to" might be safer.
Security considerations says "Therefore, a single mechanism is
not sufficient, although if suitable, the usage of the Secure
Real-time Transport Protocol (SRTP) [RFC3711] is recommended."
I think that's just too vague - are you calling for SRTP to be
implemented or used? And what does "if suitable" mean? How's
that going to result in interop when crypto is needed?
If you said "Implementations SHOULD support SRTP." and then gave
examples of cases where you don't really want SRTP, and you do want
IPsec or TLS or nothing at all, then that would clear this up for me.
I believe this text has been used elsewhere as well (e.g. rfc 5993)
so this may be more a question for the chairs/WG, than the authors
of this document.
There may also be other ways to clarify this as well of course. In
particular, this issue is related to draft-ietf-avt-srtp-not-mandatory
which has been sitting for a year.
(1) VOP is used (2nd para p5) without expansion (2) p14, s/PayloadMux elements are contained/PayloadMux element is contained/ (3) p14, suggest rephrasing this: "is preceding the one or more PayloadMux elements." (4) 7.3, s/server must following/server must follow/ (5) 7.4, s/Followings are some examples/The following are some examples/ (6) section 11 title s/to/from/
Please consider the editorial comments from the Gen-ART Review by Suresh Krishnan on 26-Jun-2011.
Section 1.3 says: > Strictly speaking systems that support MPEG-4 Audio as specified in [RFC3016] are incompatible with systems supporting this document. However, all known existing systems do already comply with the specification in 3GPP PSS service [3GPP] and therefore there is no need to consider backward compatibility. I do not know what this 'strictly speaking' language exactly means. Also the 'all known' adjective is not a guarantee for the conclusion 'there is no need to consider backward compatibility' to be always true. The text here is probably sufficient, but I would prefer a more exact wording that says something like 'this specification is not bakwords compatible with RFC 3016, existing implementations of RFC 3016 MUST be updated to be compatible with this specification'
Why is RFC 3016 a normative reference if it is being obsoleted by this spec?
Please expand "SIP" on first use and provide an informative reference to RFC 3261. References to H.261, H.323, and H.245 would also be helpful.
Please clarify that the binary incompatibility the draft is addressing is due to the change in the encodings defined in 14496-3:2009 vs 14496-3:1999
These ought to be easy enough to answer/clear:
#1) Section 1.3 says that there's no backwards compatibility with RFC 3016.
Should 3016 be made Historic?
#2) Section 1.3 reads as if the 3GPP specification is the specification everyone
wants to be compatible with. Is that specification considered the definitive
source? That is, if there's a change made to the 3GPP specification would it
get reflected in this draft?
draft-ietf-appsawg-rfc3536bis
1) The definitions in this document are not normative, but the document is a
BCP. Isn't that a contradiction?
2) You say that a writing system is a set of rules for using a script to express
a language. A better example of this might be helpful. You use the example of
the American and British writing systems, but I have no idea what those are.
3) You use the term "character set" to describe the terms "coded character set"
and "repertoire". But you never define this term. In fact, in the definition of
charset you say, "Many protocol definitions use the term "character set" in
their descriptions. The terms "charset" or "character encoding scheme and
"coded character set" are strongly preferred over the term "character set"
because "character set" has other definitions in other contexts and this can be
confusing.
4) The definition of "Glyph" leaves me thoroughly confused. The problem is that
glyphs are described in terms of "glyph images". If I don't understand what a
glyph is, how am I supposed to understand what a glyph image is?
5) Your definition of Glyph code does more to explain what a glyph is than your
definition of glyph. It makes sense that glyphs might have something to do withn
fonts, because the Greek word "glyphe" means "carving".
Ron picked up chains of definitions that I also found
confusing. I had one other specific question and a more abstract
question:
1. I'm not clear about the relationship among the terms "character
encoding form," "coded character set" and "character encoding scheme."
I consulted RFC 2978 for help (would it be appropriate to cite RFC
2978 with the definitions of CCS and CES?), and it seems CCS/CES gives
everything needed to go from characters to an octet sequence. Where
does the "character encoding form" fit in?
2. I learned from RFC 2978 that a charset is a mapping from an octet
sequence to a character sequence, but the charset may not be a
complete mapping in the other direction. Based on this little
insight, I wonder about all of the other mappings in the document: are
any of the other mappings only useful in one direction? Would it be
useful to note the directionality of other mappings?
In Section 7.1 the definition ends with "<Stringprep>" but there is no such reference. --- While I found the indications of source references useful, I did not find that angle brackets were the best indicators as they are also used for two other (distinct) purposes in the document. --- Replacing <NONE> with <THIS> might send a more positive message.
(1) s/provides identifiers/provide identifiers/ in definition of language (standards is plural) (2) s/for global from the/for global use from the/ on p8 (3) Is anchor9 in 3.2 supposed to remain or not? I would have thought the time for comments on that was past?
I think this document should be published as an Informational RFC.
It seems to play a very similar role to RFC 2828, which is an
Informational RFC. Also, this document obsoletes RFC 3536, which
is an Informational RFC.
Updated DISCUSS taking into account changes from 02 to 03:
1. One of the major changes from 3536 is that the future RFC aims to be a BCP,
while 3536 was Informational. I expected to find a discussion on this respect
including some rationale of the change and including some language that
recommends using the terminology defined in this document. However section 1.1.
'Purpose of this Document' keeps using a language that is more appropriate to an
Informational document, like: 'This document attempts to define terms in a way
that will be most useful to the IETF audience.'
2. The defition of 'glyph' seems circular to me:
> A glyph is an abstract form that represents one or more glyph
images. The term "glyph" is often a synonym for glyph image,
which is the actual, concrete image of a glyph representation
3. Section 6 - is not the SnmpAdminString TC defined in RFC 3411 an example of
usage of an ASCII-compatible encoding (ACE) that has reached standard status?
1. section 3.1 - why is W3C called 'This group' rather than 'This organization' or 'This consortium'? 2. Appendix C should mention the change from Informational to BCP. I believe it is significant.
I don't agree that this document needs BCP status as currently formulated. We can find a way to address the downref inconvenience if that's a primary motivation. I don't find a basis in 2026 for "This is informational but we REALLY mean it". If there are requirements being placed on future IETF work (even if those requirements apply only to a particular set of groups), I can see an argument for BCP in the 2026 definitions. That said, if this is published as a BCP, I don't believe it does any harm to the work it is attempting to influence, and very little additional harm to how the world (especially outside the IETF) interprets RFCs with this designation (beyond continued erosion of the perception of BCPs as "special"), so I am balloting no objection while stating a preference that the choice be reconsidered.
What no proto write-up ;) I'm curious to see how Dan's 1st discuss point shakes out. If it's really going to be a BCP, then the following should be changed: The definitions in this document are not normative for IETF standards; however, they are useful and standards may make informative reference to this document after it becomes an RFC. If it's a BCP then, as Barry noted in his response to Dan, everybody could normatively reference this document. I'm not really sure I buy the rationale of wanting to make this a BCP because everybody wants to normatively reference it (because DOWNREFs are easy), but if that is the case, then we ought to say so. Is there somebody outside the IETF that can't reference an informational RFC that wants to refer to this draft?
draft-ietf-mpls-loss-delay
Please add text to section 2.9.10 stating that in the following conditions, delay measurement will be useless: - when the two router clocks differ by a significant portion of the round trip time - when probe processing contributes significantly to round trip time
The computation of the throughput metric is only very loosely specified here.
Since the counters exchanged can represent either a number of packets or a
number of bytes, then the throughput can either be computed in packets/time or
bytes/time depending on what units are used.
This is an administrative Discuss - I intend to move to move to a YES ballot.
This document is in an administrative second IETF last call because of a late
IPR disclosure. The IESG will hold its evaluation before this second last call
completes. I will hold this Discuss until last call completes in case any issues
are raised from the community.
This is just a discuss to check if the chat arising from Steve
Kent's secdir review [1] reached closure. The discussion seemed
to tail off a bit and I'm not clear if it was done or not.
[1] http://www.ietf.org/mail-archive/web/secdir/current/msg02727.html
(1) Section 2 as a whole is very wordy. While its fine to spell things out for clarity, this text perhaps demands too little from the reader, at the expense of clarity for the capable reader. (In other words, this seems just too long:-) Feel free to entirely ignore this comment though. (2) The "(B1,...,Bk)" notation isn't clear in 2.6 - are we measuring (A,B1) and (A,B2) etc. or are we measuring what happens on the path from A to Bk via B1,B2...etc.? Since the section is about unidirectional LSPs it may be easier to just deal with A and B here. (3) (2.9.3) Saying that the detailed measurement behavaiour "MUST be made clear to the user" seems wrong in two respects - a) a programmer won't know what'll be clear to all future users of their code, and b) there may be no (human) user that can see the direct mesurements, (the humans might only see derived statistics I guess). I also don't quite know how I'd test for that MUST. Maybe just loose the 2119 language there? (4) 2.9.5 assumes that intermediate nodes can reply to LM/DM messages, but that hasn't yet been stated. (5) Two timestamp formats are supported - would be good to include examples of each at the point where that's first mentioned in detail.
This DISCUSS is in part based on the OPS-DIR review performed by Benoit Claise.
1. The document defines new protocols without making any reference to the IPPM
OWAMP (RFC 4546) and TWAMP (RFC 5357) despite the bidirectional measurment
described in section 2.1 being very similar to the latest, for example, If there
are good reasons for which OWAMP and TWAMP are not suited in the MPLS
environment I suggest that these need to be clearly explained.
2. The applicability statement in section 1.1 risks to create confusion with the
IPPM work. I would rather drop it.
Although the procedures in this document are presented in the context
of MPLS, they have no essential dependence on MPLS and generalize
easily to other types of packet networks. Such generalizations are,
however, outside the scope of this document.
3. In Section 2.2:
The foregoing discussion has assumed the counted objects are packets,
but this need not be the case. In particular, octets may be counted
instead. This will, of course, reduce the MaxLMInterval
proportionately.
Proportionately to what? Probably with the ratio between 1 and the number of
octets in the minimal packet size on the respective media. Either be exact, or
use some other more suitable term (accordingly?).
4. What is the reason for not using the packet loss metrics definition from RFC
2680? (while the delay metrics are referenced from 2679 and 2681 repectively).
If that definition is not suitable I suggest that this is discussed if not
please add the reference.
5. I support Wesley's DISCUSS concerning the throuput metrics and discussion and
I generally feel very unconfortable with the way it is dealt with in this
document. Do we need reference to througput at all? after all the scope of the
document focuses on loss and delay. If we do I would also suggest a serious
rewrite starting from a proper definition of the metics or reference to existing
definitions in other RFCs if appropriate.
6. The PDV definition in section 2.5 is rather vague. I suggest to refer to
section 4 in RFC 5481 which makes a clear distinction between PDV and IPDV.
7. The document lacks proper manageability considerations:
section 2.9.7
This can be achieved in supporting
implementations by, for example, configuring the querier, in the case
of a bidirectional measurement session, to forward each response it
receives to the post-processor via any convenient protocol.
Post-processing devices may have the ability to store measurement
data for an extended period and to generate a variety of useful
statistics from them.
section 4.1
Measurement sessions are initiated at the discretion of the network
operator and are terminated either at the operator's request or as
the result of an error condition.
There is no mention about how to remotely configure this protocol (example: MIB
or YANG module), how to retrieve the results, what are the storage requirements
for the results and methods and periodicity of retreival of the results. There
is no mention about the security implications of activating two new protocols
that generate traffic in the network and what are the admissible levels of
traffic that can be generated.
This is an updated discuss based on an exchange with an author.
#1) Which of the 5 formats defined in Section 3.1 MUST be supported for an
implementation to be considered compliant to this document?
#2) Section 3.4 contains the following:
The Type space is divided into Mandatory and Optional subspaces:
Type Range Semantics
-------------- ---------
0-127 Mandatory
128-255 Optional
Upon receipt of a query message including an unrecognized mandatory
TLV object, the recipient MUST respond with an Unsupported Mandatory
TLV Object error code.
and Section 8.4 contains the following:
IANA is also requested to indicate that Types 0-127 are classified as
Mandatory, and that Types 128-255 are classified as Optional.
Wouldn't it be more 2119-like if you used REQUIRED and OPTIONAL? Isn't this
kind of saying that the elements in the 0-127 range MUST be supported?
Also later in 3.4 it includes:
127 Experimental use
You're requiring implementations to support the experimental TLV? I would think
that would be OPTIONAL.
#3) Which of the four TLV objects in Section 3.5 MUST be supported for an
implementation to be considered compliant to this document? It says zero or
more may be present but not which ones MUST be supported. Are any of them a
MUST?
#4) cleared
#1) Section 3.1 and 3.2 contains the following: TLV Block Optional block of Type-Length-Value fields Should Optional be OPTIONAL to indicate support requirement? #2) Section 4.2.2 contains the following: When transmitting an LM Query over a channel, the Version field MUST be set to 0. Shouldn't "over a channel" be removed? Isn't version always set to 0? #3) Section 4.2.2 contains the following: The Origin Timestamp field SHOULD be set to the time at which this message is transmitted, hmmm so what other time would be put there? The definition from earlier sections is: Origin Timestamp: Timestamp recording the transmit time of the query message. #4) Section 4.3.1 contains the following: When transmitting a DM Query over a channel, Shouldn't "over a channel" be removed? Isn't version always set to 0?
draft-ietf-dkim-rfc4871bis
I note that in Section 1.2 of RFC 4871 (May 2007) it says "there are currently
over 70 million domains." So while Section 1.3 of this I-D is not wrong to say
"there are currently over 70 million domains," it may be a significant
underestimate.
I am not completely comfortable with the use of "normative" RFC 2119 language in
ABNF comments. For example...
dkim-safe-char = %x21-3A / %x3C / %x3E-
7E
; '!' - ':', '<', '>' - '~'
; Characters not listed as "mail-safe" in
;
[RFC2049] are also NOT RECOMMENDED.
A terrible nit, but would you consider s/may/might/ in...
o The practical constraint that large (e.g., 4096 bit) keys may not
fit within a 512-byte DNS UDP response packet
Good job. Other, than (6) & (8) below, which I'd ask that you check, I'm entirely fine if you totally ignore these - they're just the notes I made as I read the thing again (after not having had to do that for a while:-) and are basically all nitty suggestions. (1) 2nd para of 2.6 refers to "i=" and "t=s" before those have been introduced. I wouldn't suggest defining them here, so I'm not sure what to change to make it better but maybe worth a look. Maybe you could get rid of the tags though for example by saying: "Note that acceptable values for the AUID may be constrained via a flag in public key record. (See Section 3.6.1)" (2) end of p20, maybe s/are expected to/may/ since we're doing a new spec now but not changing the version number. (3) 2nd last para, p23: signing non-existent header fields does not "prevent" later insertion, it allows detection of that after the fact. Same issue with last para on p23 as well. The change is obvious I guess if you want to make it. (4) p26, is "DNS TXT record" or "DNS TXT resource record" more correct? (And if so, do we care or not:-) If the latter then the same change would be needed in a few places. (5) Would it be useful for the reader and/or IANA to note that there are no new tags defined in section 7 compared to rfc4871? (6) Is 7.9 actually correct? That IANA registry references 4871 but should that be changed to this document or left alone? I've no idea. (7) Could/should appendix B.2.3 have an informative reference to dkim-mailinglists? Since that's now approved, it won't add any significant time for the RFC editor to do those together. (I think.) (8) The last paragraph of appendix C is odd - maybe the reference in there should be to rfc4870?
Appendix E should probably include a pointer to the errata. Some documents have included a URL for this purpose.
1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING"
and section 8.1):
INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
an attack in which an attacker modifies a message to include
content that solely benefits the attacker. It is possible for the
appended content to completely replace the original content in the
end recipient's eyes, such as via alterations to the MIME
structure or exploiting lax HTML parsing in the MUA, and to defeat
duplicate message detection algorithms. To avoid this attack,
signers should be wary of using this tag, and verifiers might wish
to ignore the tag, perhaps based on other criteria.
This is not an attack against DKIM. If the signer said, "I'm signing the first n
bytes of the body of this message" and the verifier is able to verify that the
signature is valid for n bytes of the body, the algorithm has succeeded. At
most, this should lead to an admonition that unsigned data is not verified and
therefore should not be trusted, but that seems obvious. There might be an
attack on an MUA that does not verify the DKIM signature, but that is outside
the scope of this document. Either way, 3.4.5 and 3.5 should have forward
references to 8.1. This is a security consideration, not anything "informative".
2. Section 6.1.3:
verifiers might treat a message that contains bytes beyond the
indicated body length with suspicion, such as by declaring the
signature invalid (e.g., by returning PERMFAIL (unsigned content)),
or conveying the partial verification to the policy module.
Up to the word "suspicion", fine. After that, it is complete nonsense. The
signature is not invalid. If what you mean is "and may choose to treat the
signature as if it were invalid (e.g., by going into the PERMFAIL state)", then
say that. And again, this is trying to wrap APIs and implementations choices
into the protocol.
3. Section 8.2: I don't see how this is DKIM specific. More importantly, this
section doesn't explain how user private keys relate in any way to keys used in
DKIM. Shouldn't this be a discussion about security of private keys in general
(not just ones on user machines)?
4. Section 8.5: I don't understand what the attack here is that has anything to
do with DKIM. I especially don't see why the accomplice is an essential part of
the example, unless all that is meant by "accomplice" is "relay". The attack
sounds like, "people can spam signed messages", which is not an attack on DKIM.
5. Section 8.14: This is a complete mischaracterization of the problem. This is
absolutely not an attack vector. If a signer wishes to prevent additional
*known* header fields from being verified, it can simply use the technique
outlined in 8.15. If the signer chooses not to do that, it is expressing the
intent that it considers messages valid that have additional header fields
added. *That's* the security consideration: Signers should know that failing to
include, e.g., "h=...:from:from:..." on messages with one "From:" header field
are leaving themselves open to this attack. The attack is not on the verifier.
Additionally:
Note that the technique for using "h=...:from:from:...", described in
Section 8.15 below, is of no effect in the case of an attacker that
is also the signer.
That sentence is utter nonsense. The signer *can't* be the attacker for purposes
of DKIM when it comes to the header fields it's willing to sign. The
Introduction (section 1) makes it absolutely clear that DKIM is about
transmitting information from a signer to a verifier.
Section 8.14 needs to be completely rewritten. It is nonsensical as it stands.
6. Section 8.15:
Implementers need to consider this possibility when designing their
input handling functions. Outright rejection of messages that
violate the relevant standards such as [RFC5322], [RFC2045], etc.
will interfere with delivery of legacy formats. Instead, given such
input, a signing module could return an error rather than generate a
signature; a verifying module might return a syntax error code or
arrange not to return a positive result even if the signature
technically validates.
DKIM can perfectly well deal with the obsolete syntax. The signer can sign as
many "From:" fields as the message has when signed, and add a ":from" to the
"h=" tag to insure that the right number of them are verified. As in 8.14, the
attack is not on DKIM per se; it's on signers that don't properly use the "h="
tag to sign those header fields that they don't want added to.
Other malformed input might cause problems for a DKIM implementation, but
multiple header fields where 5322 3.6 only allows one is not that sort of
attack.
These first 15 comments are things that I think are potentially real problems,
but I haven't heard enough back from the authors yet to know if they are worthy
of a DISCUSSion.
1. Section 2.7: I don't understand what the word "module" means in this context.
It sounds like some sort of specific implementation, not part of a protocol. I
don't know what it means to deliver values to a module.
2. Section 3.5:
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have
the value "1". Note that verifiers must do a string comparison on
this value; for example, "1" is not the same as "1.0".
What is the intention of "string comparison" here? There's no case sensitivity
to worry about. There's no character encoding to worry about. Why not instead
say, "Note that verifiers must (MUST?) ensure that the value is '1'; for exmaple
'1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) What is this trying
to convey.
Also, the value is not listed as "plain-text".
3. Section 3.5, "h=":
INFORMATIVE EXPLANATION: By "signing" header fields that do not
actually exist, a signer can allow a verifier to detect
insertion of those header fields after signing. However, since
a signer cannot possibly know what header fields might be
created in the future, and that some MUAs might present header
fields that are embedded inside a message (e.g., as a message/
rfc822 content type), the security of this solution is not
total.
a. I don't understand what MUAs presenting "header fields that are embedded
inside a message" has to do with anything.
b. I don't know what the words, "the security of this solution is not total" are
supposed to mean.
Don't you simply mean: "However, since a signer cannot possibly know what header
fields might be defined in the future, this mechanism can't be used to prevent
the addition of any possible unknown header fields."?
4. Section 3.5, "h=":
INFORMATIVE EXPLANATION: The exclusion of the header field name
and colon as well as the header field value for non-existent
header fields allows detection of an attacker that inserts an
actual header field with a null value.
I cannot parse that sentence. I have no idea what it means.
5. Section 3.7: "content-hash" is not defined.
6. Section 3.9:
a. Neither TEMPFAIL nor PERMAFAIL is defined at this point.
b. I have no idea what the "output of a DKIM verifier module" is supposed to
mean.
I suspect that section 3.9 is at least misplaced in this document, and probably
completely unnecessary as it sounds like implementation details.
7. Section 4.2, first INFORMATIVE NOTE: Why is this an informative note? It
seems like good protocol adivce and therefore should say that signers SHOULD NOT
sign exiting DKIM-Signauture fields.
8. Section 4.2, last paragraph: PERMFAIL is still not defined to this point.
I suspect sections 3.8 through all of section 4 belong after (or in) section 6.
9. Section 5.1: I don't know what the term "signing address" means.
10. Section 5.3:
Therefore, a verifier
SHOULD NOT validate a message that is not compliant with those
specifications.
This section is about signing, not verifying. What is that sentence doing in
there?
11. Section 5.4:
INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits
header fields to be reordered (with the exception of Received
header fields)
5322 does *not* permit header fields to be reordered. It says:
...header fields SHOULD NOT be reordered when a message is transported
or transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message.
Suggest: "Despite the fact that [RFC5322] does not absolutely prohibit header
fields to be reordered..."
12. Section 6.1:
A verifier SHOULD NOT treat a message that has one or more bad
signatures and no good signatures differently from a message with no
signature at all; such treatment is a matter of local policy and is
beyond the scope of this document.
The two clauses in that sentence seem contradictory. Is there an
interoperability requirement that I not treat messages in a particular way, or
is it a matter of local policy?
13. Section 6.1 (and subsections): This section is playing some sort of game.
The beginning of 6.1 describes some "statuses" and says things like, "The
'(explanation)' is not normative text; it is provided solely for clarification."
If it wanted to give an algorithm for Verfiers to follow, where there was a
certain state machine with states of "PERMFAIL" and "TEMPFAIL", that would have
been OK. But it is clear from the use of the phrasing, for example, "return
PERMFAIL (signature syntax error)", the document is trying to sneak in some sort
of actual APIs into the protocol spec. I think this is bogus and would much
prefer that these sections be rewritten to say, "enters a PERMFAIL state",
perhaps labeling each paragraph with the explanation. For example, the first
paragraph of 6.1.1 could read:
Signature syntax
Implementers MUST meticulously validate the format and values in the
DKIM-Signature header field; any inconsistency or unexpected values
MUST cause the header field to be completely ignored and the verifier
enters a PERMFAIL state. Being "liberal in what you accept" is
definitely a bad strategy in this security context. Note however that
this does not include the existence of unknown tags in a DKIM-Signature
header field, which are explicitly permitted.
Version compatibility
Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature
header field with a "v=" tag that is inconsistent with this
specification.
The current text is too cute by half, and I think it obfuscates the meaning.
14. Section 6.1, first "INFORMATIVE NOTE" on attack by many bad sigs: This is a
security consideration instead, not an informative note. Should be a forward
reference to section 8.3
15. Section 6.1.3: I don't understand the meaning of the note, "(note that this
version does not actually need to be instantiated)".
These last 10 comments are simply stylistic and editorial stuff. If they make
sense to fix, great. If not, I'm not concerned.
1. I find the use of the word "INFORMATIVE" throughout the document superfluous.
No other word (e.g., NORMATIVE) is used in its place. I think they should all be
removed. They serve no purpose.
2. The ABNF "0*" construct is not normally used. Just "*" is sufficient.
3. Section 3.4.4:
INFORMATIVE NOTE: It should be noted that the relaxed body
canonicalization algorithm may enable certain types of extremely
crude "ASCII Art" attacks where a message may be conveyed by
adjusting the spacing between words. If this is a concern, the
"simple" body canonicalization algorithm should be used instead.
I think this MITM attack (the ability to insert and delete whitespace to send
coded ASCII Art messages to the recipient) is so far fetched as to not be worthy
of mention. If the WG really thinks it is worthy of mention, it should go in
security considerations.
4. Section 3.5: It would be nice to subsection each tag here. (e.g., "v=" could
be 3.5.1, etc.)
5. Section 3.5, "h=":
It would be nice to add a sentence similar to the one in 5.4: "The field MAY
contain multiple instances of a header field name; this means that multiple
occurrences of the header field are being signed by the signing algorithm."
6. Section 3.6.1: It would be nice to subsection each of the tags.
7. Section 3.10: Is this not completely redundant with the text in 3.6.1
regarding "t=s"?
8. Section 4.1: The "INFORMATIVE EXAMPLES" don't need to be called out as such.
The title of the section is "Example Scenarios". All of the text here is
example, and as such it is all informative.
9. Section 5.1, INFORMATIVE NOTE: Instead of saying "Signing modules may be
incorporated into any", how about "A signer can be implemented as part of any"?
10. Section 5.5: Though section 5.5 is titled "Recommended Signature Content",
it is clear that the entire section is devoted to the topic of section 5.4:
"Determine the Header Fields to Sign". These two sections should be combined,
and might be subsections of a larger section. But it was very confusing to read
these as separate.
1. It's good to see draft-ietf-dkim-implementation-report, which has a thorough overview of the interoperability testing held in 2007. However, that I-D does not discuss interoperability regarding the clarifications in RFC 5672. Are they covered here? Does the community have enough experience with them to enable us to say that there are at least two interoperable implementations of RFC 5672? 2. In Section 3.2, why not reference RFC 4648, perhaps with text about line feeds (etc.), instead of Section 6.8 of RFC 2045? 3. In Section 3.2, we might consider adding an informative reference to RFC 3629 with regard to UTF-8. 4. In Secton 3.6.2, we might consider adding a normative reference to RFC 1464 with regard to DNS TXT RRs. 5. In Section 6.1, we might consider adding an informative reference to RFC 4732 with regard to denial of service attacks. (Also Sections 8.3, 8.7, 8.12.) 6. In Section 6.1.1, we might consider changing MAY to SHOULD. This seems like something we'd recommend, not describe as purely optional. 7. In Section 7, "one has been obsoleted" makes it sound as if a new tag has been defined to replace it (as in RFC 2026); we might consider changing it to "one has been designated as historic".
draft-ietf-soc-overload-design
In Section 1 Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse. Reading (and re-reading) this paragraph, I could not extract from the text whether the concern is the network throughput of SIP messages, or the impact on the data flows that are controlled by the SIP messages. It seems to me that you need to make this clear up front, and that you should spend some time distinguishing the impact of SIP overload on existing data flows from the case you are describing. It may be that this is obvious to the informed reader, but it should be easy for you to explain, and that will make life easier for future readers.
Nice document, with good security considerations. Thanks. One possible additional security consideration - if an attacker can convince senders that various other nodes are overloaded, then it could cause traffic to be directed towards attacker-chosen servers. That could either be part of a DoS on the attacker-chosen servers, or, if the attacker-chosen servers are operated by or for the attacker, then the attacker could monitor possibly many more calls than otherwise.
This is a nice piece of architectural work. How did this end up in a WG instead of the IRTF? :-) One mostly editorial comment. From the Introduction: Overload can pose a serious problem for a network of SIP servers. During periods of overload, the throughput of a network of SIP servers can be significantly degraded. In fact, overload may lead to a situation in which the throughput drops down to a small fraction of the original processing capacity. This is often called congestion collapse. That's not congestion collapse. The first paragraph of section 2 talks about what *is* congestion collapse: congestion-related retransmissions themselves increasing congestion. Something's missing from the above paragraph.
This is a very well written document. Before I turn my ballot into a YES I would
like to DISCUSS one aspect of the SIP overload control which is related to
manageability and specifically to observability. As I understand from the
document and from the WG charter several methods of SIP overload control will be
proposed and more than one may be supported by a SIP server. How can a network
operator know what is supported on each device in the network? Also, for
existing deployments, are there any mechanisms (alerts or status indication)
that show whether one of the specific mechanism was triggered and activated? I
believe that the design document needs to add some text refering to these
operational aspects.
This is a fine document. Please expand acronyms on first use (e.g., "UA", "UAC",
"UAS", "RPH"). A reference to RFC 4732 ("Internet Denial-of-Service
Considerations") might be appropriate.
Please take these editorial suggestions into account: 1) At "Introducing many such short-lived sybils" - I suggest s/sybils/servers. If you want to compare this to a sybil attack, an additional sentence would be better. 2) I suggest s/affecting a reduce in the service/affecting a reduction in the service/ 3) At "keep the receiver window fill", I suggest s/fill/full/
draft-ietf-mpls-tp-loss-delay-profile
I'm changing from DISCUSS to No Objection, because I think it's sufficient to address any possible concerns with the throughput metrics via the draft-mpls- loss-delay document that this one refers to.
I dunno what security mechanisms are available for use in an MPLS-TP environment, but if there are some that are not available outside that environment, then it might be good to mention those here.
The Gen-ART Review by Wassim Haddad on 29-Jun-2011 suggested one editorial improvement: Page 1: Abstract: remove _the_ efficient and accurate measurement
1. I am a little puzzled by this Internet-Draft. Let me copy section 2:
> 2. MPLS-TP Measurement Considerations
> Several of the considerations discussed in [I-D.ietf-mpls-loss-delay]
> can be disregarded in the more restrictive context of MPLS-TP:
> o Equal Cost Multipath considerations (Section 2.7.3 of
> [I-D.ietf-mpls-loss-delay])
> o Considerations for direct LM in the presence of Label Switched
> Paths constructed via the Label Distribution Protocol (LDP) or
> utilizing Penultimate Hop Popping (Section 2.7.6 of
> [I-D.ietf-mpls-loss-delay])
First, the version [I-D.ietf-mpls-loss-delay] is two versions back the latest
one which is also on the agenda of the IESG telechat. The ECM considerations now
belong to Section 2.9.3, and the direct LM considerations belong to section
2.9.8.
My principal question is however - are these the only two considerations that
can be ignored from [I-D.ietf-mpls-loss-delay] and everything else applies? If
this is the case I would suggest to include clear text that says it.
2. The measurement profiles defined in sections 3 and 4 define a restricted set
of parameters and modes that need to be configured in a specific manner. Are
these the only parameters that need to be configured in a different manner for
MPLS-TP and all the rest of the parameters and modes defined in [I-D.ietf-mpls-
loss-delay] can be configured in any way the operator choses to? If this is the
case I would suggest to include clear text that says it.
3. As with [I-D.ietf-mpls-loss-delay] I have reservations about the lack of
manageability considerations. The only paragraph that deals with manageability
is:
> The assumption of this profile is that the devices involved in a
measurement operation are configured for measurement by a means
external to the measurement protocols themselves, for example via a
Network Management System (NMS) or separate configuration protocol.
This is too little. It tells nothing about any data model to be used (MIB or
YANG module), or about how the results of the measurement are being retrieved
from the routers/switches. Moreover, as such a protocol is not mentioned in [I-D
Please expand LM at first occurence.
This ought to be easy enough to answer and is tied up in a discuss on draft-
ietf-mpls-loss-delay:
It wasn't clear to me in draft-ietf-mpls-loss-delay that all of the "mandatory"
TLV objects MUST be supported and if any of the "optional" TLV object should
also be supported. If they are, then this can go away. If not, shouldn't this
draft say which TLV objects are required?