IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-09-12. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Carlos Pignataro (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Link #5 +---------+ Link #4
+------------------------| |-----------------------+
| +----| ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Figure 4 - OCh Visible Topology for LO ODUj connection management
Telechat:
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 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
3.4.2 Returning Items
Telechat:
1224 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
Telechat::
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
Telechat::
1238 EDT break
1242 EDT back
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
Amy: reminder that BoF Coordination before our next telechat; I need to cover two jobs next week, be kind
1330 EDT Adjourned
(at 2013-09-12 07:30:08 PDT)
draft-ietf-repute-media-type
If I am reading this ABNF correctly:
reputon = "{" [ reputon-object
*(value-separator reputon-object) ] "}"
reputon-object = "reputon" name-separator response-set
...then a reputon is one or more reputon objects, each of which is denoted with
the string "reputon". IOW:
{ "reputon": { ... }, "reputon": {...} }
Is that correct? If so, isn't a little weird to use "reputon" as the string
that denotes a reputon object, which is a _part_ of a reputon, not a whole
reputon? Or am I just not understanding the ABNF (which is quite possible—I'm
hardly an expert).
The relationship between the term "clutch hitter" and "choke" is not going to
be obvious to many readers (e.g., not obvious to me). This may not be the
best example to use to make the point you are making here.
Are assertions not allowed to contain whitespace characters? I ask because
you use names like "choke-hitter" and "is-good" instead of "choke hitter" and
"is good". Given that these appear in quotes, it seems unnecessary to
substitute dashes for spaces.
And the antiparticle of the reputon is... a disreputon? It seems strange that the context for the reputon is relegated to a parameter of the media type, when it's really a semantic attribute, not a type/encoding attribute. Suggest moving it inside the reputon or reputon collection structures. In "sample-size": JSON doesn't have a notion of the length of an integer, so saying "64-bit" here seems odd, unless you mean that it MUST NOT exceed 2**64-1. I agree with Barry's comment that a collection of reputons (repu-meson?) should be an array rather than an object.
See https://datatracker.ietf.org/doc/draft-ietf-repute-model/ballot/#benoit-claise
Three points, if you please (UPDATED): 1. RFC 4627 says that the names within a JSON object SHOULD be unique. Yet this explicitly defines a setup wherein a reputation object contains multiple reputons, all of which have the same name, "reputon". Why is that a good design? Perhaps just make the reputation object be an array, where each reputon is an element of the array? 2. You specify information to be included with a registration request, but not the information that will actually be in the registry table. As the policy for the registry is Specification required, I suggest that you make it clear that the information you're asking for has to be clearly documented in the specification, and that you limit the actual registry to a minimum of information -- maybe the first four items: name, description, reference, status. That avoids an awkward and cluttered registry, and also avoids duplicatin of information in the registry that's already in the specification. The actual registry information needs to be specified in the document, so IANA knows what to do. 3. Specification Required implies Expert Review, so you need to give instructions to the designated expert. As part of that, you should say what the DE should consider when reviewing. You can also say that no DE review is necessary if the specification is in an IETF consensus RFC. (Alternatively on that last point, you can explicitly designate the policy as "Specification Required or IETF Review".) If you want expert review *even* for IETF consensus documents, it would be good to say that explicitly.
draft-ietf-repute-email-identifiers
From 3.2:
rfc5321.helo: The RFC5321.Helo value used by the (see [SMTP])
client
rfc5321.mailfrom: The RFC5321.MailFrom value of the envelope of
the message (see [SMTP])
rfc5322.from: The RFC5322.From field of the message (see [MAIL])
Given that these data are not validated except in the case where SPF is used,
it seems like a bad idea to maintain statistics on them. The fact that
someone is joe-jobbing me does not mean that my email address is meaningfully
associated with spam, but it'll sure look like that given the way reputations
are calculated.
If you want to retain these, you ought to mention the security problems
associated with them in the security considerations section, but I really
question the validity of using them at all. They are certainly useful in
combination with other information on a per-message basis, but I don't see how
that can work with the repute data model.
What's the ">" in 3.1, definition of abusive?
There appears to be a stray ">" character in "abusive". There appears to be a stray ")" character in "spf".
See https://datatracker.ietf.org/doc/draft-ietf-repute-model/ballot/#benoit-claise That document also defines a media type to contain a reputon for transport, and also creates a registry for reputation applications and the interesting parameters of each. This should be: for a reputation application. Right? Since the reputons are valid for a single application.
This document registers an item in a registry that is not yet created, but that requires expert review (via specification required). Changing my DISCUSS on the creating document to clarify that it's not necessary for IETF consensus RFCs.
draft-ietf-repute-model
Clearing the following DISCUSS on the basis of Murray Kucherawy's proposal: Section 4.1 appears to be confusing two different things by referring to them with the same term: "response set." I think a response set is a predefined data type. But the first paragraph of 4.1 refers to a response set as if it were data, not a data type. The second paragraph says that each response set has an IANA-registered name, which is consistent with a response set being a data type. You also have a related draft that actually defines a response set for email, so that confirms my belief that a response set is a data type, not data. Proposed text from Murray: A "Response Set" is a representation for data that are returned in response to a reputation query about a particular entity. The data representation is specific to the application; though all applications have a few key fields in common, some of the reputation data returned in the evaluation of email senders would be different than that returned about a movie, restaurant, or baseball player. Non-discuss comments: The box around the DKIM signer and validator in figure 1 is a bit confusing. Is it really necessary? I know the technology well enough that the meaning was clear to me, but someone who isn't particularly knowledgeable about DKIM and SMTP might not successfully navigate this. I think the dotted line makes the relationship clear enough. But this is clearly a matter of opinion, so please take it as input, not a directive. Figure 2 is even more confusing—you have dotted arrows going between the client and server, and solid arrows going two and between two transport boxes. Is there a reason to have the two sets of arrows? I get the value of showing that more than one transport is possible, but why the dotted arrows here? Also, why is the arrow between the database and server unidirectional? Doesn't the server query the database? Again, this is just my opinion, but I really encourage you to consider changing this diagram.
I welcome the inclusion of a Privacy Considerations section, but I wonder whether it goes far enough. In Section 2 you observe: Typically client and service operators enter into some kind of agreement during which some parameters are exchanged such as the location at which the reputation service can be reached, the nature of the reputation data being offered, possibly some client authentication details, and the like. If *that* agreement can be breached, then any party may be able to issue requests to the server. While securing the client-server exchanges can help to protect the privacy of the entities about which reputation information is held, it is of no value if the "agreement during which some parameters are exchanged" is leaky. So I think you should say more about the mechanisms and security underlying this agreement. I am also looking ahead a little toward the inevitable legal action caused by a reputation server holding, in private, information about an entity that that entity holds to be false or misleading. There will inevitably be a requirement one day for entities to be able to make reputation enquiries about themselves. I wonder whether this needs to be discussed.
8.1 says it is "imperative" to protect sensitive information in transit. I have no idea how DNS is a suitable transport for that without a way to encrypt data accessed via the DNS. In addition, there doesn't seem to be any object-level data integrity/origin-authentication scheme defined for the non-DNS transports. And you don't even recommend TLS for the http transport. How's that all fit together?
- intro: "community or the Internet public generally" is misleading to the point of being plain wrong. There is afaik no concept that repute will use the community or the Internet public generally at all - its meant for companies to make money providing useful services as I understand it. This seems like badly misleading overselling. - 4.1.1 says the rating is between 0.0 and 1.0, which is fine. But what precision is the finest granularity? Is 0.000000000000000000000000001 ok to use? Is that transport dependent or not? If it is, why is it? If its not, why isn't it specified here? - the -media-type draft says that ratings could be linear or e.g. exponential I don't get why that is transport specific and not specified here. Am I missing something? - section 8 is missing a consideration: if someone asks a reputation provider about identifier X then that provider now knows that X probably exists and can start making a list of the X's and who's asked about them. That could be privacy sensitive.
1. The notion of application is not clear, and lead to some ambiguities.
Example 1:
OLD: IANA registries are created in a separate document.
NEW: IANA registries are created in a separate document, application-specific.
Example 2: you don't say that reputon are application-specific. This is a key
concept
Example 3:
One of the key properties of a Response Set is called an Assertion.
Assertions are claims made about the subject of a reputation query.
For example, one might assert that a particular restaurant serves
good food. In the context of this model, the assertion would be
"serves good food".
Isn't it?
In the context of this model, the assertion would be
"serves good food" for the application "restaurant"?
Because I guess that "serves good food" is not valid for email
You see, an application definition and explaining that reputon are per
application would clarify a lot of things.
2.
The document discussed the Response Set, but doesn't tell what is contained in
the Query (*) So I can only guess that the application is part of query.
Explaining what MUST/SHOULD/MAY be part of the query and reply are important
topics for an architecture document. Also, can I query: get me all the reputons
you know about the application "application context = X" and "identity = Y".
I'm asking for good food, but I might interested to know that they have good
wine, or slow service, etc... It's a basic answer the architecture document
should be answering (**)
(*) is this http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/
section 3.1
The components to the question being asked comprise the following:
o The subject of the query;
o The name of the host, or the IP address, at which the reputation
service is available;
o The name of the reputation application, i.e., the context within
which the subject is being evaluated;
o Optionally, name(s) of the specific reputation assertions or
attributes that are being requested.
(**) I eventually found the information in
http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/
If a client makes a
request about a subject but does not specify an assertion of
interest, the server can return reputons about any assertion for
which it has data; in effect, the client has asked for any available
information about the subject. A client that receives an irrelevant
reputon simply ignores it.
3.
Each application requires its own specification of the Response Set.
What I understand now (after speaking to Pete who clarified a few things for
me) is that each application requires its own registry, with its own set of
reputons, but not necessary its own new protocol, with its own new encoding.
http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/ is one example of
protocol encoding, and this could be reused. This was very confusing to me.
It seems that there are good piece of information in the different drafts to
solve the points 2 and 3 (without rewriting or cutting and pasting a lot of
information between the different drafts, which would be ideal solution
obviously), but those drafts are not even referenced. At the very minimum, you
would need pointers like the following:
The key pieces of data found in a reputon for all reputation
applications are defined in
http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ section 3.1
The ABNF syntax of a reputon is specified in
http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ section XXX
Some good examples (and you would need these to understand this
architecture: OK, no need to mention this :-)) are specified at
http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ section 6.2
http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/ specifies one
example of protocol encoding: over the Hypertext Transfer Protocol using
JSON as the payload meta-format. Other encodings could be envisaged.
draft-ietf-repute-media-type must be normative, right?
Bottom line: assuming that the architecture draft is the first draft a newcomer
to the repute work will read, it lacks some key pieces of information. And this
information is spread across the different drafts. Once you have the different
pointers, I advice you to review the 4 drafts with the fresh mind of a
newcomer, and if the story is complete. Therefore, this DISCUSS is valid for
the set of 4 repute documents.
Editorial: expand the acronyms in figure 1 As OPS AD, this one makes me happy, even if I still have to read the draft 9.3. Further Discussion Numerous other topics related to use and management of reputation systems can be found in [I-D.REPUTE-CONSIDERATIONS]. From the draft title/abstract, it might be more appropriate to say 9.3. Further Discussion Numerous other topics related to operational considerations of reputation systems can be found in [I-D.REPUTE-CONSIDERATIONS]. Not really a DISCUSS, but please consider them or come back to me if you disagree. - I'm confused by the title. A model? The abstract says: an architecture We have architectures, frameworks, (with some disagreement between the two). Is there really a need for having a third term "model"? Why don't you simply call it architecture? - Figure 1/2 and the related text are not consistent. Section 2 speaks about client/server, then figure 1 speaks about Identifier Assessor and Reputation Service, then figure 2 speaks about client/server again. What you call a Client in figure 2 is the Identifier Assessor in figure 1, and the server in figure 2 is the Reputation Service in figure 1. Correct? It would be great to be consistent and to clearly explain that the protocol is between Identifier Assessor and Reputation Service.
Non-blocking... I agree with Joel's assessment that there are some missing pieces to this document series.
I support Stephen's discuss position. Figure 1: There can be more than one author of an email message, so should figure 1 indicate that by replacing Author with Author(s)? Figure 2: Are the lines to the transport boxes really needed? It seems like you're trying to show protocol interactions as well as protocol layers and keep wondering why that's necessary in one Figure. s5: Isn't it the identifier of the entity being rated not the identity of the entity? Or is the idea that the application context scopes the identity to the an identifier?
this is non-blocking... Manageability considerations for a reputation system? addition/state change/determination of state change. I can imagine a number of things that I don't see well described in the document series.
draft-ietf-repute-query-http
1. Underspecified security considerations:
The security considerations section says:
In particular, the basic protocol used for
this service to retrieve a URI template from a well-known
location is basic HTTP, which is not secure without
certain extensions.
Why haven't you said what extensions would make it
secure? I assume you mean TLS? Shouldn't you
say that? In fact, is there a reason not to require TLS?
You could clear this either by satisfactorily explaining
why you didn't just say "TLS," by updating the document
to say TLS, and optionally by updating the document
to require TLS.
2. Underspecified template requirement:
In 3.2, you say that there might be more than one template,
but don't say why. Can you expand on that a bit? It
seems as if one reason for specifying multiple templates
would be so that you could specify one with and one
without the optional "assertion" variable.
There are two problems with this. First, I think specifying
two templates is required, not optional, or, alternatively, a
server that offers only a single template may effectively
either require or prohibit the optional "assertion" variable
by so doing.
You can clear this item by updating the document to explain
which you intend, or by explaining that I am completely
failing to understand what you actually intended, which is
of course quite possible.
Relating to DISCUSS item 2, I think the only reason to give multiple templates is to address the optional "assertion" variable. If that is so, you might want to say so. If that is not so, you might want to explain what other use multiple templates could have. If you do the latter, you probably want to add some specification language that describes how that works. If you actually mean to do the latter, then this comment probably ought to be a DISCUSS, because the current text isn't explicit enough to allow for interoperability in that case, but I'm assuming you don't mean that. E.g., perhaps you mean for templates to be able to have an explicit value for one of the variables, so that different queries can go down different query trees, for the benefit of pattern matching in the HTTP server. If so, I don't think this document actually allows that to be done.
I support the Discusses and Comments relating to Security. Notwithstanding the reference to the Considerations document, this document should strengthen the use of the mechanisms it defines by observing that the use of reputation information has no value unless it can be trusted and therefore the mechanisms MUST be run over a secure transport. --- I did not see any mention of how the requester knows the identity of "the host providing reputation service". I think this should be mentioned in section 3.2
- I assume 6570 defines the syntax that "application",
"service", "subject" and "assertion" have to follow and says
if any percent encoding is needed? Don't you need to also say
that here though or point to a bit of RFC 6570?
- Seems odd to have the {service} in all templates but yet say
it MUST be the same as the origin to which the template query
was sent.
- How does HTTP response caching interact with the expires
field in the JSON reputon? I expected to be told that here.
- I would have thought that setion 5 should encourage running
this over TLS at least. Why not? (I have a related DISCUSS
on the -model draft.)
The Introduction says "The mechanism is a two-stage query", but the first stage is never defined. (That is, how the client gets the templat.). This document needs to define the first-stage query, or else make the description one-stage -- since if the first stage is undefined, the the template is just a configuration parameter.
See https://datatracker.ietf.org/doc/draft-ietf-repute-model/ballot/#benoit-claise
Clients SHOULD NOT repeat the query prior to the timestamp in the Expires field, or wait no less than one day if the Expires field is not present. Two non-blocking points about this: 1. It's easy to confuse the reference to the expires field with the expires field in the reputon. Maybe you can say something to avoid that possible confusion. 2. I can't make head nor tail of the apparent double negative after the comma. Will you please reword that?
I support Ted's position.
draft-ietf-tsvwg-sctp-sack-immediately
I have no objection to the publication of this document. Curiously, after reading it I cam to enter this position and found two other ADs had already made the point I wanted to make. Clearly, if the receiver is a legacy implementation, it will ignore the I bit, and perhaps this is the point. Since this document updates 4960, the behaviour on receipt of the I bit becomes normative, so making the behaviour somewhat optional (via SHOULD) seems a good way to get off the hook. However, the wording in section 5.2 does leave this all a bit ambiguous.
Section 5.2 invites the question: Why shouldn't the receiver delay and, more importantly, under what circumstances is it reasonable for the receiver to delay and when is it not reasonable? Might be handy to give some advice here.
I had the same reaction to Pete. Under what circumstances would the receiver choose to delay (i.e., not obey the SHOULD)? If none exist, then it should be a MUST.
draft-ietf-spfbis-4408bis
Holding my own DISCUSS: Text needs to be created (probably for section 3.1) to better describe the reason this document settled on TXT RR only and therefore why no precedent is set for future use of the TXT RR.
Clarifications needed regarding size limitations in 3.4, and perhaps some clarifications in 4.6.4.
- 4.1: given that recursion is allowed and that you have overall limits on how many DNS transactions can be done, is the "transactions-remaining" value also an implicit parameter of a check_host() call? This is only a comment since check_host is not a formal API but it'd seem to make it easier to get right if you make that implicit parameter explicit. Or do the limits apply to each call as you recurse? That wasn't entirely clear to me. - I didn't get appendix D at all - what's that do? - Appendix E.1, 2nd bullet: what's that? I think it needs a reference if you want it to be understood.
disclaimer: I've only reviewed the changes compared to the RFC 4088. Regarding "Appendix J. Change History": NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to publication) Personally, I like it when the new RFC has one section summarizing the changes compared to the initial RFC. This would be a mix of: Appendix J. Change History", but no needs to mention the editorial changes Appendix C. Changes in implementation requirements from RFC 4408 Regards, Benoit
I have two very small points that I think are unclear, and important enough that we have to get them right, both regarding the check_host() function. These should be really easy to clear up: -- Section 4.6 -- The check_host() function parses and interprets the SPF record to find a result for the current test. If there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. I think you're trying to say that syntax checking is done before any evaluation, but you aren't saying it. It matters, because implementations that make different choices in that regard won't get the same results from check_host() in all cases, as they're required to. Maybe this?: NEW The check_host() function parses and interprets the SPF record to find a result for the current test. The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation. END -- Section 5.5 -- I have to say that I'm not happy about the pseudocode here: what situation are we in when the pseudocode differs from the text? Which wins? I already see a case where they differ: the new pseudocode says "if more than 10 sending-domain_names are found, use at most 10", and there's nothing of the sort in the text. Does the working group really think there's enough value in having pseudocode there that it's worth saying the same thing twice and relying on them to be truly the same? And is it really worth it for mechanism that's not recommended for use? I strongly suggest making sure that the text says what you want it to, and removing the pseudocode.
I have a bunch of editorial comments that I'd like you to consider. They're
all non-blocking, but I think they'll improve the document, and I'll be happy
to chat about them if you like.
-- Section 2.5 --
Performing the authorization check other than using the MAIL FROM and
client address at the time of the MAIL command during the SMTP
transaction can cause problems, such as the following: (1) It might
be difficult to accurately extract the required information from
potentially deceptive headers; (2) legitimate email might fail
because the sender's policy had since changed.
I found that to be awkwardly worded and hard to understand. Please consider
this rewrite:
NEW
The authorization check is performed during the SMTP transaction
at the time of the MAIL command, and uses the MAIL FROM value and
the client IP address. Performing the check at later times or
with other input can cause problems such as the following:
* It might be difficult to accurately extract the required
information from potentially deceptive headers.
* Legitimate email might fail the authorization check because
the sender's policy has since changed.
END
-- Section 2.6 --
It would really read best if the subsections were worded to be parallel. As it
stands, subsections 1, 3, 4, 6, and 7 are worded as "result X means Y", and
subsections 2 and 5 are not. Can you re-word 2 and 5 to be parallel to the
others?
Also, why are "neutral" and "fail" called "explicit statements", but "pass",
for example, is not?
-- Section 3 --
Each SPF record is placed in the DNS tree at the owner name it
pertains to, not a subdomain under it, such as is done with SRV
records [RFC2782].
This looks like it's saying that SRV records are placed in subdomains, and I
don't think that's what you mean. Or is it? In any case, it's not clear (and
I know this text is from the original).
Maybe this (which also avoids the two different "it"s)?:
NEW
Each SPF record is placed in the DNS tree at the owner name it
pertains to, not in a subdomain under the owner name. This is
similar to how SRV records [RFC2782] are done.
END
The example in this section might be published via these lines in a
domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all"
What does "smtp-out" have to do with anything? It's not otherwise used, and it
seems to contradict what you say about subdomains in the previous paragraph.
-- Section 4 --
This description is not an API (Application Program Interface)
definition,
Two total nits on this:
1. You never use "API" other than here, so there's no need to define it, and
2. the usual expansion of "API" is application programMING interface.
I suggest, "This description is not an application programming interface
definition, [etc]."
-- Section 4.5 --
Starting with the set of records that were returned by the lookup,
discard records that do not begin with a version section of exactly
"v=spf1". Note that the version section is terminated either by an
SP character or the end of the record. A record with a version
section of "v=spf10" does not match and is discarded.
Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and.... Why
is it necessary or desirable to single out "v=spf10" here?
-- Section 4.6.4 --
SPF implementations MUST limit the total number of mechanisms and
modifiers ("terms") that cause any DNS query to 10 during SPF
evaluation. Specifically, the "include", "a", "mx", "ptr", and
"exists" mechanisms as well as the "redirect" modifier count against
this collective limit. The "all", "ip4", and "ip6" mechanisms do not
count against this limit. If this number is exceeded during a check,
a "permerror" MUST be returned. The "exp" modifier does not count
against this limit because the DNS lookup to fetch the explanation
string occurs after the SPF record evaluation has been completed.
When I read this, I start feeling like I'm being read the rules for Fizzbin
<http://en.wikipedia.org/wiki/Fizzbin#Fizzbin>. I would appreciate it if this
was re-worded so that there are two clear lists here: the terms that are
included in the "limit of 10", and the terms that are not (and are, presumably,
unlimited). Perhaps something like this:
NEW
Some mechanisms and modifiers (collectively, "terms") cause DNS
queries at the time of evaluation, and some do not. The following
terms cause DNS queries: <list goes here>. SPF implementations
MUST limit the total number of those terms to 10 during SPF
evaluation, to avoid unreasonable load on the DNS. If this limit
is exceeded, the implementation MUST return "permerror". The other
terms (<list goes here>) do not cause DNS queries at the time of
SPF evaluation, and their use is not subject to this limit.
END
If you think it's necessary (I don't):
NEW+
The other
terms (<list goes here>) do not cause DNS queries at the time of
SPF evaluation (the "exp" modifier causes a lookup at a later time),
and their use is not subject to this limit.
END
Then in the next two paragraphs, I think it would improve clarity to make a
change such as this:
OLD
When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. The evaluation of
each "MX" record MUST NOT result in querying more than 10 address
records,
NEW
When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. In addition to
that limit, the evaluation of each "MX" record MUST NOT result in
querying more than 10 address records,
END
(And similarly for the "ptr" paragraph.) I know you say this in a paragraph of
its own ("These limits are per mechanism..."), but it's helpful if people can
understand things as they read them, and then to emphasize it later... rather
than having them scratch their heads for a few paragraphs until they get to it.
-- Section 4.7 --
It is better to use either a "redirect" modifier or an "all"
mechanism to explicitly terminate processing. Although the latter
has a default (specifically "?all"), it aids debugging efforts if it
is explicitly provided.
I'm not sure what "the latter has a default" is trying to say. Do you mean
that "?all" is the default if you fall off the end, but you shouldn't rely on
that? Or do you mean that if you say "all", then "?all" is taken as the
default (I would think "all" would mean "+all")? Will you try re-wording this,
please?
-- Section 5 --
What does "(do not publish)" mean next to "ptr" in the sender mechanisms list?
Ah; I see; it matches the "do not use" in Section 5.5. You should probably
change this to "(do not use; see the note in Section 5.5)".
It would help, I think, to add to the end of the second paragraph, "The basic
mechanisms are as follows:", and to the end of the third paragraph, "The
designated sender mechanisms are as follows:". Otherwise, there are just these
disembodied lists, and the reader has to infer those introductions.
-- Section 5.1 --
Mechanisms after "all" will never be tested. Mechanisms listed after
"all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be
ignored when there is an "all" mechanism in the record.
This says that the redirect in the following record will be ignored:
v=spf1 redirect=_spf.example.com +all
That's sufficiently odd that it should be called out explicitly, perhaps by
adding "regardless of the relative ordering of the terms" to the last sentence
in the quote.
-- Section 5.2 --
3. The recursive evaluation returns either match, not match, or an
error. If it matches, then the appropriate result for the
include: mechanism is used (e.g. include or +include produces a
"pass" result and -include produces "fail").
4. If there is no match, the parent check_host() resumes processing
as per the table below, with the previous value of <domain>
restored.
A few things here:
1. Nit: "either" is for two things; for more than two, please remove the word
"either" (or replace it with "one of", but that seems awkward here).
2. "If it matches" is not parallel to "returns match", and similarly for "if
there is no match".
3. You don't say what happens if the recursive evaluation returns an error.
Unfortuately, "no match" and "not match" are sufficiently similar to be
confused.
I suggest this:
NEW
3. The recursive evaluation returns match, not match, or an
error.
4. If it returns match, then the appropriate result for the
include: mechanism is used (e.g., include or +include produces
a "pass" result and -include produces "fail").
5. If it returns not match or an error, the parent check_host()
resumes processing as per the table below, with the previous
value of <domain> restored.
END
The "include" mechanism is intended for crossing administrative
boundaries. For example, if example.com and example.org were managed
by the same entity, and if the permitted set of hosts for both
domains was "mx:example.com", it would be possible for example.org to
specify "include:example.com", but it would be preferable to specify
"redirect=example.com" or even "mx:example.com".
The text you eliminated here provided a buffer that's no longer there, making
the "For example," very odd. You talk about crossing admin boundaries and
immediately follow it with an example that does NOT. I think it would be
better to put a sentence in to restore that buffer -- perhaps, "When remaining
within one administrative authority, "include" is usually not the best choice."
-- Section 5.5 --
This mechanism SHOULD NOT be published. See below for discussion.
It's quite a bit below. I suggest "See the note at the end of this section for
more information." It might even be worth putting that note into a Section
5.5.1, so it's highlighted and more easily cited.
-- Section 6 --
Unrecognized modifiers MUST be ignored no matter where in a record,
or how often.
This is missing a couple of words:
NEW
Unrecognized modifiers MUST be ignored no matter where in a record
they appear, or how often.
END
For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record.
I don't usually recommend repeating things, but one thing from earlier probably
does bear repeating here:
NEW
For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record. Any "redirect" modifier MUST be ignored if there
is an "all" mechanism anywhere in the record.
END
I'm a No-Obj on the document itself, but I look forward to seeing the text mentioned in Pete's Discuss about how obsoleting Type 99 in favor of TXT records is not going to be a precedent for other protocols ...
I am voting no objection on the basis of a quick scan indicating that there are no implications for the routing system.
Should s11.3 also provide a mitigation via a reference for the spoofed DNS? Right now it just points to the DNS threats RFC. I guess the reader can infer they should use DNSSEC if they're worried but adding a pointer to the right RFC would be better. Something as simple as adding "... and see [RFCXYZ] for a countermeasure" or something like that.
draft-ietf-mpls-targeted-mldp
- The write-up says an implementation poll was sent out and results would be in "soon" - are they in? - The security considerations just says "nothing new here" which is always a bit offputting for a SEC AD:-) Can you explain why there is nothing new here? (I didn't have time to trace all the references sorry, and I'm not asking that you put in new text but do wonder if there's an easy answer to the question.)
I see Section 1.3 manageability in RFC 6388. Good.
Please add a sentence/a new section such as this one:
Section 1.3 "manageability" in RFC 6388 stresses the need to develop an
additional MIB module, next to RFC3815, to support P2MP in LDP. LDP
multipoint extension for targeted LDP should also be covered by this MIB
module.
draft-ietf-mpls-tp-mip-mep-map
What are the security mechanisms that are "required" to be offered and that we are "strongly adivsed" to use? Don't you need to say - if those are in RFCs 6371 or 6941 then saying which sections you mean should be easy. If those are not in those RFCs then how am I supposed to know what to do?
Surely, you could have worked "mop" in there as well.
I did have one (non-blocking) question on section 4. Requirements and Design Considerations for Internal-MIP Adressing Any solution that attempts to send OAM messages to the outgoing interface of an MPLS-TP node must not cause any problems when such implementations are present (such as leaking OAM packets with a TTL of 0). "... must not cause any problems (such as ..." with one example - is there somel reference that might provide a bit more guidance? I'm looking at the bulleted list under Figure 6 as a very reasonable description of constraints on a solution - would some bullet in that list prohibit "leaking OAM packets with a TTL of 0"?
draft-ietf-ccamp-gmpls-g709-framework
The following comments were made by Tomonori Takeda during his Routing
Directorate review. We need to pick them up and make a few editorial changes
before publication.
1) In Section 5.3., it says the following requirement for GMPLS routing.
- Support different priorities for resource reservation
I think this is a valid requirement, but I do not think this is specific to OTN.
Does this imply the need for protocol extensions or just the usage of protocols?
2) Section 5.4., it says:
Furthermore, since multiplexing hierarchy was not allowed
by the legacy OTN referenced by [RFC4328], ....
By reading RFC4328 section 2, it refers to ODU multiplexing. Am I missing
something?
3) In Section 5.5., it says.
Note that this case is supported by the procedures defined in
[RFC3473] as a different Switching Capability/Type value is
used for the different control plane versions.
I am not sure which part of RFC3473 metions such procedures. Could you please
point it?
o Nits:
Section 4.1
s/Lo ODU/LO ODU/
Section 4.1
s/substitute/substituted
Section 5.6
s/section 5.2.1/section 5.2
Thank you for writing this document, and it is generally ready to move forward. However, I was concerned with one minor detail which seems that there is some unclarity with a term. First, the document says: LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, flex.) represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container. HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area. and then later, it says: With the evolution and deployment of OTN technology many new features have been specified in ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 and ODUflex containers as described in [G709-2012]. But it is unclear if this is referring to LO or HO ODUs or both, or something else. Could this be clarified, or did I missunderstand something?
In 4.1. Connection management of the ODU
In this case, an operator may choose to allow the underlined OCh
Could "underlined" be a typo for "underlying"? I didn't see anything in Figure
4 that looked like underlying ...
layer to be visible to the ODU routing/path computation process in
which case the topology would be as shown in Figure 4. In Figure 3
below, instead, a cloud representing OCh capable switching nodes is
represented. In Figure 3, the operator choice is to hide the real OCh
layer network topology.
Link #5 +---------+ Link #4
+------------------------| |-----------------------+
| +----| ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Figure 4 - OCh Visible Topology for LO ODUj connection management
Later in the same section, the word "underlying" is used, so I'm guessing
"underlined" was a typo.
In the examples (i.e., Figure 3 and Figure 4), we have considered the
case in which LO ODUj connections are supported by OCh connection,
and the case in which the supporting underlying connection can be
also made by a combination of HO ODU/OCh connections.
Is Malcolm's affiliation in the Contributors section correct? I was remembering
him being at ZTE, although people do move.
draft-ietf-mediactrl-call-flows
- Some of the tools page links seem to be broken by the formatting used, e.g. [1] doesn't go to the security considerations. Not sure if that's easy to fix or worth fixing though. [1] http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-13#section-8 - "variegated bouquet of services": heh, not many RFCs have those:-)
I'm intentionally staying with "no position" on this, rather than deferring it, as Richard has assured me that a sufficient number of the right set of eyes have been on it, and as I trust my fellow ADs to have it covered.
I am taking a position of no objection based on a quick look which indicated that this text has no impact on Routing.
s7.2.1: "mess with" could be better phrased ;)
draft-ietf-pim-rfc4601-update-survey-report
Section 3 doesn't say anything, but I noticed that earlier in the document it was mentioned in section 2.3.2 that (*,*,RP) was not implemented in some cases due to security concerns. If those concerns were real, might it be worth mentioning what they were in section 3? There are a surprising number of page breaks in this document... :)
I think it'd be fine to add the information from the response to Sean's earlier discuss (copied below to make that easier) into the security considerations. That is, I'm suggesting to add a paraphrase of: "FWIW, I am aware of at least two implementations (but I expect there are more) where you can use IPsec to protect PIM messages. For at least one of them, IPsec is not part of the PIM implementation at all, you just configure IPsec with SPDs where interface, the ALL_PIM_ROUTERS multicast address etc. can be used as selectors, according to RFC 5796."
Christer Holmberg made a Gen-ART review of this document and had a number of editorial comments. Do the authors want to respond to those comments in some way? From my perspective, the comments seemed very reasonable suggestions.
As Barry said, this is more for IESG conversation and not about this document per se, but I had the same reaction he did: Is there really a reason to publish interoperability reports of this sort as RFCs? Why not just put this information into the writeup for 4601's move to IS? I don't think there's any significant harm in publishing this, but it doesn't seem necessary.
You went into some explanation of the process in 1.2. Even with some history (RFC 2026 versus RFC 6410). Fine. However, I don't understand why you only listed 2 of the 4 conditions from RFC 6410 Section 2.2 of [RFC6410] states that:"(1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (3) There are no unused features in the specification that greatly increase implementation complexity."
I have no objection to publishing this document, I think it's a very fine thing for us to do interoperability reports, and I'd be happy to see more of them. So take the following comments with that in mind, and also with the note that they're mostly meant for the IESG to ponder. Will there be real value to this document a year or two from now? Is there real value in having this as a snapshot, frozen in time, rather than as a wiki page that can be updated with new information and further experience? Mostly, I think we should be publishing these sorts of things in more streamlined ways, and in ways that allow ongoing work on them. But again, this is NOT an objection to publishing this document. Just something I'd like us to think about.
Thanks for addressing my question. I look forward to the advancement of 4601bis.
draft-ietf-v6ops-rfc3316bis
In section 2.9, is there any appropriate way to give more guidance about the
implementation of the default router preferences? My naive intuition would be
that the host should generally prefer to use a Wifi default route over a 3gpp
default route, and indeed I think most phones do this, but that's not what this
section says to do. By implementing a top-level preference for one interface
over another, aren't handsets violating this recommendation?
In section 7:
However, it should be noted that in the
3GPP model, the network would assign a new prefix, in most cases,
to hosts in roaming situations and typically, also when the
cellular hosts activate a PDP Context or a PDN Connection. This
means that 3GPP networks will already provide a limited form of
addressing privacy, and no global tracking of a single host is
possible through its address.
Changing prefixes doesn't address the privacy issue that temporary addresses
address. Do the host bits change in this situation, or just the prefix bits?
If the former, it would be worth saying so to avoid conclusion; if the latter,
then the statement is simply wrong.
- Section 3 no longer really discusses IPsec since that's now in 6434, and doesn't mention TLS at all (nor does 6434 really) so that bullet in section 7 should probably be fixed.
It might help to note that EPS/EPC is the packet service for LTE.
- Section 2.5 says "MLD is needed for multicast group knowledge that is not link-local." It would be clearer to re-state (or reference) section 5.10 in RFC 6434. The level of MLD support is dependent upon the types of multicast applications supported on the cellular device. - Is there any need for time synchronization on cellular devices?
draft-ivov-xmpp-cusax
Did this document get a secdir review?
The Abstract says... This specification does not define any new protocols or syntax ...but it is not a specification!
I would like to hear why this is being put forward now as informational instead of bringing this to STOX (or a different WG) and doing the proper work to do either a BCP or standards track document. There are quite a few problems still in this document that should get proper review, and I'm afraid that the instructions in here will be taken as IETF consensus to do these things, statements about not being normative notwithstanding. As far as technical concerns: Section 2: Because many of the features that a CUSAX client would prefer in one protocol would also be available in the other, clients should make it possible for such features to be disabled for a specific account. Disabled by whom? I believe in Jingle there is a way for the client to discover whether or not voice or video features are available; I presume that SIP has something similar to indicate the lack of IM/presence features. Are you simply saying that clients should be able to track which features are available per protocol, even if they show the combination of features on a per-remote-user basis? Section 3.1: I understand the desire for the server to pre-populate XMPP vcards with the SIP URI it knows about, but that's no different than the server pre-populating any fields (e.g., email address, web page) that it knows about because the server is providing all of those services, so I'm not sure why this case is special. But I don't get this: To ensure that the foregoing approach is always respected, service providers might consider (1) preventing clients (and hence users) from modifying the vCard "tel" fields... That encourages horribly unfriendly server behavior. It's one thing for a server to keep it's own particular locked field in a vcard for information that it knows about, and it's fine for server policy _independent of CUSAX_ to be that users can't change their contact information, but this suggestion amounts to "If you have been letting users change *any* of their vcard telephone information (be it their lab extension, their home phone number, their fax number), and you decide to provide CUSAX services, lock down the tel fields in their vcards completely." That's terrible advice and harmful to users. Applying validation is the only good advice to give here. Section 3.3, second paragraph, does not take into account out of band information. If you had stuck to the first part of the sentence, where it's only talking about using the information as a hint, I would not complain, but what appears in the roster entry is far from the only place this information is gleaned by clients. (I wish clients would update the rest of the vcard in rosters from directory information they possess, but they often don't.) Don't say things that will encourage clients to *take away* functionality. Section 3.4, last paragraph. I don't get this. You seem to be talking about the case where I have an XMPP roster entry with a tel URI in it, and I am on a CUSAX client that is also talking to a SIP service. Assuming I (the user) have not configured the client to only use SIP, I'm *always* going to offer XMPP telephony if it's available and I don't have a pre-existing relationship configured between the URI and a particular service. I don't understand what the last sentence adds. Section 4, first paragraph: s/would normally be disabled/might be disabled. Also, the same problem exists here with figuring out who is providing the information. Do you mean that a CUSAX-aware SIP conference server can provide an XMPP MUC and a CUSAX-aware MUC server can provide a SIP URI?
Figure 2 has all sorts of implications that I don't get. Why is that User Directory a single box, and why is there an arrow *to* it from the Provisioning Server? What's the expectation there? Section 3.4, second paragraph, s/XMPP and SIP/telephony-capable. That there are multiple accounts of a particular protocol doesn't affect this issue; it's only telephony-capable accounts, whatever the protocol. Section 3.5, first paragraph: It was confusing to figure out which client was which. The first and second "clients" refers to clients that *receive* calls. AFAICT, the last "clients" in that paragraph refers to *calling* clients providing that data to avoid effort on the part of *receiving* clients. Right? Section 3.5, second paragraph: s/a vCard entry/a vCard entry in the roster. Section 4, third paragraph: Please make clear at the beginning of the paragraph that you've switched from talking about clients to talking about servers. I was very confused for a few sentences. Section 5, second to last paragraph: A CUSAX service can't provide a user interface warning; only the client can.
References to SIMPLE (say, [RFC6914]) and Jingle [XEP-0166] would be helpful.
I have to say that in this case I do not share the concerns of my distinguished colleague from Urbana. I find this document mostly reasonable, by way of considered advice to those trying to deployed a mixed SIP/XMPP application environment. I do agree that saying more strongly that this is just that -- considered advice -- and no more, would be good. You missed an opportunity to give examples using John, Joan, Bill, and Susie (a bunch of CUSAX). Pity. Three non-blocking comments; feel free to chat with me about them if you please: -- Section 2 -- Because many of the features that a CUSAX client would prefer in one protocol would also be available in the other, clients should make it possible for such features to be disabled for a specific account. In particular, it is suggested that clients allow for audio and video calling features to be disabled for XMPP accounts, and that instant messaging and presence features should also be made optional for SIP accounts. Hm. This document is talking about how to use SIP and XMPP alongside each other, not at different ends of the same pipe. So, isn't it likely that, say, John might want to make voice calls to both Joan and Susie, where he needs SIP to talk with Joan and XMPP to talk with Susie (and similarly for IM services)? Wouldn't it, therefore, be better to allow preference settings for calling features, which might be customizable by user or overridable by instance? -- Section 6 -- I agree with the idea that the document should be clearer about these recommendations being very soft, and the first paragraph of Section 6 would be one good place to say that. As it is, the two non-bullet paragraphs make it sound pretty close to BCP advice. -- References -- I'm a believer that Informational documents do merit normative references, and for this document I think SIP and XMPP are normative references. I'm not putting this at DISCUSS level, so it's non-blocking, but I strongly urge you to make that change.
This looks a lot like work that someone already did e.g. at jitsi. I am curious if they could reference that work. becuase that takes it from the realm of "here's what you can do", to "here's what we did"
conflict-review-dolmatov-gost34102012
Using "/=" for "not equal" is a little counter-inuitive, "!=" would be more common. Similarly, "\\" as used in section 7, is more often done with just a "\". But if this notation was used in other GOST RFCs then its probably better to be consistent with those.
conflict-review-pfaff-ovsdb-proto
- I assume that Stewart's comment about asking the WG's named has been handled. - Seems odd to just say "use TLS" but not define or pick a mechanism for client authentication, normally in that case I'd expect one mechanism at least to be picked for that to get interop.
No objection to the classification, but objection to the text (not sure if that
makes it a no objection or a discuss)
"The IESG has concluded that this work is related to IETF work done in WGs
TRILL and NVO3, but this relationship does not prevent publishing."
There is related work in I2RS, with the difference that OVSDB management
protocol focuses on switches and I2RS to routers. This is appropriate to
mention if someone would think to extend OVSDB management protocol for routers.
There is also related work in NETCONF, as this protocol, which is RPC based is
similar to NETCONF. In the industry, there is a conflict with OF-CONFIG, which
is NETCONF and YANG based. NETCONF and YANG are the preferred configuration
protocol and data model in the IETF. However, this can't change the conflict
review conclusion.
NEW:
"The IESG has concluded that this work is related to IETF work done in WGs
I2RS, NETCONF, TRILL and NVO3, but this relationship does not prevent
publishing."
Some more feedback.
- [DB-SCHEMA]
"Open vSwitch Database Schema",
<http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf/>.
This points nowhere!
-
Creation, modification and deletion of OpenFlow datapaths
(bridges), of which there may be many in a single OVS instance;
OVS instance definition in the terminology would be useful
- opensource:
The abstract mentions that
Open vSwitch is an open source software switch designed to be used as
a vswitch (virtual switch) in virtualized server environments.
However, it's not clear if the "OVSDB management protocol" is open source as
well. My research seems to indicate that this is the case. That seems an
important point to clarify in the draft. I thought about it when I wonder
whether "VMware" should be added in the RFC title, like for many independent
submissions.
There's a lot of JSON stuff in there, so I had a look, and it all seems fine from an App Area point of view.
However I think that we should look at a process a bit. Surely before we name specific WGs in the deconflict list we should consult the WG chairs lest they know of impacts that we are not aware of.