IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-01-05. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and Susan Hares (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:
2.1.2 Returning Items
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
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
Telechat:
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1215 EST break
1300 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1401 EST Adjourned
(at 2012-01-05 07:31:17 PST)
draft-ietf-sieve-include
I spent some time thinking about whether I want to say something or not.
But I'll join others in worrying about the issue of recursion, but raise some of
the comments to a level of a Discuss.
I should also say that developing a programming language is difficult,
particularly when you add tiny features one at a time (like subroutines). For
instance, the recursion discussion is difficult because you've conflated the
concepts of module references and actual invocations of those modules during
execution time.
It might have been better to think about an upgrade of the sieve model in a more
architectural manner. Or maybe the WG already did and I am just not aware of it.
In any case, this is just a comment and not a part of my Discuss.
The Discuss is the following. First, as Adrian noted you must define what you
mean by recursion, because otherwise implementations are likely to miss that
they need to track indirect inclusions as well: A includes B, B includes A. I
wonder if it would have been easier just to have the concept of nesting levels
and maxing out on them. That's how I would implement this if I was implementing
it. No need to track recursion in specific ways.
Second, I think your minimum requirement of three levels is a bit too small. If
people actually start using this they are likely to engineer script structures
that need more, and if not all implementations support that number of levels
there will be breakage. I'd say five or ten would be a more reasonable minimum
level. But I'm not asking you to put any specific number but rather I'm asking
you think about this and make a rational decision based on some basis. (And
again, maybe you already have and you just need to tell me what the basis of
that decision was.)
I also think that the active/other script definition for checking recursion is
broken, but that was already raised by Russ' Discuss.
I think it would be helpful if you spent more time explaining what you mean by recursion. Direct recursion is (of course) a lot easier to spot than general (by menas of indeirections) recursion. But it is the general case you need to protect against and that is potentially considerably more complicated for an implementation to police. Since the consequences are just as bad, and since it may be harder for the coder to realise that they have transgressed, I think you should call it out explicitly. Perhaps add a definition of recurssion to Section 2, and then note the implication for tracking all nested script names in 3.1
Is SIEVE turning into a fully-fledged programming language? I guess I wonder if that's happening by design or by accident. (Not that I know which would be better;-)
The Gen-ART Review by Reviewer: Ben Campbell on 13-Dec-2011 raises
some points, the authors have responded to them, but the discussion
has not completed yet. I believe the document needs to be updated to
at least address Ben's first point:
>>> -- section 3.1, paragraph 4: "Implementations MUST NOT generate
>>> errors for recursive inclusions at upload time, as this would
>>> force an upload ordering requirement upon script authors /
>>> generators. However, if an active script is replaced with a
>>> faulty script and would remain the active script, an error MUST
>>> be generated and the upload MUST fail."
>>>
>>> These two statements seem contradictory on a quick reading. In
>>> particular, how can the latter assertion avoid an upload ordering
>>> requirement? Or do you mean faulty in some way other than being
>>> recursive?
>>
>> If you're replacing an active script, it has to be correct all the
>> time, and uploads are atomic only on a per-script basis. There's a
>> risk that if you're uploading a set of scripts that include one
>> another, at some intermediate stage while some scripts are uploaded
>> but not others, they are in an invalid state. The managesieve spec
>> says that scripts must be validated at upload time. The language
>> above is trying to say that you can upload all of the scripts that
>> may include one another in any order without generating errors
>> immediately, however, if you're replacing an active script or a
>> script included by the active script, then you DO have to upload a
>> correct script right from the get-go.
>
> Is this just a question of whether the script(s) are replacing
> active scripts? That is, the license to create a transient invalid
> state is suspended if if you are replacing an active script? If so,
> how would one go about updating a set of linked scripts when one or
> more of them replace active scripts? Should one somehow deactivate
> the old ones, load all the scripts, then activate them?
Section 3.1 states: An error MUST be generated when such a script is executed. However, Section 3.2 states: Implementations MUST NOT generate an error if an "include :once" command names a script whose inclusion would be recursive; in this case, the script MUST be considered previously included and therefore "include :once" will not include it again. These two are in conflict. I suggest changing the text in Section 3.1 as follows: An error MUST be generated when such a script is executed, except as noted under Section 3.2. In Section 3.2: The ":optional" parameter indicates that the script may be missing. I'd change "may" to "MAY" or (to avoid confusion with "might be missing") say "is allowed to be absent" or somesuch. Section 3.4.1 states: If a "global" command is given the name of a variable that has previously been defined in the immediate script with "set", an error MUST be generated either when the script is uploaded or at execution time. Does that impose an ordering requirement on script uploads?
1) s3.2: Contains the following: The "include" command takes an optional "location" parameter, an optional ":once" parameter, an optional ":optional" parameter, and a single string argument representing the name of the script to include for processing at that point. Shouldn't the "optional"s be "OPTIONAL" to ensure they match they ABNF? 2) s3.2: Contains the following: Note: It is RECOMMENDED that script authors / generators use the ":once" parameter only when including a script that performs general duties such as declaring global variables and making sanity checks of the environment. Can you rephrase this so the requirement isn't in a "note"?
draft-ietf-6lowpan-nd
I agree with the points that Adrian makes.
I have added a placeholder to this Discuss to ensure that Pascal Thubert's last
call comments are resolved (one way or the other).
---
This is a really small Discuss and easily fixed. The way that
[I-D.ietf-6lowpan-hc] is used in Sections 1.4 and 3 make it a
normative reference.
---
Section 3.4 seems to contain a lot of options and sub-options with the
over-arching assumption that "all 6LRs in a network are configured to
perform these functions homogeneously." This seems like a lot of
configuration complexity for very simple nodes in an environment where
users will not be sophisticated. Moreover, it seems highly likely to me
that misconfigurations will arise and homogeneity will be lost.
The latter suggests that the assumption of homogeneity cannot be
trusted. You will need to handle (at least at the level of fault
detection) mixed mode configuration.
The former suggests that you should have some form of automatic
arbitration (i.e., something more sophisticated than fault detection) so
that the network can become homogeneous across the sub-options.
---
Table 1 in Section 4.1 demands an IANA action. In Section 12 there is a
brief statement:
This document also requests IANA to create a new registry for the
Status values of the Address Registration Option.
This text needs to be beefed up to show:
- which is the owning registry
- what the name of the sub-registry should be
- either a pointer to section 4.1 or (preferably) all of the relevant
information
---
Section 6.1
A router SHOULD NOT send Redirect messages in a route-over topology,
but MAY send Redirect messages in a mesh-under topology.
The use of 2119 language here may be correct, but leaves some holes.
In route-over, under what conditions MAY a router send Redirect
messages?
In mesh-under, what is the normal behavior? Presumably "SHOULD NOT". But
why MAY a Redirect be sent in mesh-under?
---
Section 12
Please remove the following text from the I-D before advancing it to the
RFC Editor
For the purpose of protocol interoperability testing of this
specification, the following values are being used temporarily:
o TBD1 = 31
o TBD2 = 32
o TBD3 = 33
o TBD4 = 155 XXX
o TBD3 = 156 XXX
(There is, in any case, a typo s/TBD3/TBD5/ on the last line)
---
Section 8.2.1
A node MUST silently discard any received Duplicate Address Request
and Confirmation messages that do not satisfy all of the following
validity checks:
I suspect you mean "...message that does not satisfy any of the
following..." Since you have written that only the messages that fail
every one of the checks must be discarded.
A strict reading of one sentence in the Abstract may be misleading...
The traditional IPv6 link concept and heavy use of multicast
make the protocol inefficient and sometimes impractical in a low
power and lossy network.
This reads as though it is IPv6 that is inefficient/impractical. Maybe
NEW
The traditional IPv6 link concept and heavy use of multicast
make the Neighbor Discovery protocol inefficient and sometimes
impractical in a low power and lossy network.
END
---
"LoWPAN" is not yet in the RFC Editor's registry of "well-known"
acronyms indicated by an asterix at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
(Actually, it is not on that page at all!)
You may want to encourage your AD to lobby for it to be added. In the
meantime, please expand it on first use (by adding it in the first
sentence of the Abstract, and by expanding it in the second sentence of
the Introduction).
A reference to a wider and more detailed definition of a 6LoWPAN might
also be helpful.
---
The language in section 1.2 describing the differences between mesh-
under and route-over introduces some ambiguity by slightly careless
use of language. The problem arises from trying to distinguish between
routing (at the IP layer) and link-layer routing. Similarly by saying
that in mesh-under all "hosts" are on the same link, yet that forwarding
is handled by a link-layer mesh routing protocol.
I don't think there is anything here that is unusual to people familiar
with layered networking. You might make the text crystal clear by
explaining the existence of layers and then refering always to "links in
the IP layer" and "routing in the Ethernet layer".
While a lot of my gripe is my own sensitivity to mesh-under being
proposed for environments where IP routing is more appropriate, I do
think you may add value to the document by some clarification in this
section.
Similarly, a little more tightness in Section 2 might help. For example,
a 6LR is defined as a router in a 6LoWPAN that can communicate with
another router in the 6LoWPAN. This doesn't really say very much. What
is routed? What is the ocnnectivity between the 6LRs?
(By the way, I am not sure that the term "host" adds any clarity. For
example...
In both types of configurations, hosts do not take part in routing
and forwarding packets and they act as simple IPv6 hosts.
#1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is
ambiguous - does it mean each 6LR registers with some 6LBR or
s/each/all/ or s/some/all/ or both? Assuming that all 6LRs are
registered with all 6LBRs would seem to be too difficult and unwise
so I think this needs fixing.
#2 1.4 - Why would probabilistic uniqueness of non-EUI-64-derived
addresses not be sufficient in some networks? If it is, then the
"must be either assigned or checked" seems wrong.
#3 3.2 - Does this mean that if I can pretend to be a router I can
force (some) nodes to change their addresses? If so, why is that
not mentioned as an attack in the security considerations? (If
IP-address based node reputation ever evolved for nodes like these
then this would be serious attack - misbehave as addr1, pretend to
be a DHCP server and then force addr1 on some other innocent node.)
#4 3.3 - How long is a sleeping node expected to say awake when
sending a registration message? Is that long enough to get an error
saying its chosen address is in use already? If not, then what
prevents that node constantly re-awakening and using the duplicate
address (or many identical such nodes doing that all the time)?
(Saying "A host retransmits...until..." later in that section isn't
clear enough really - there's no 2119 language there at all so I
don't know if that's a MUST or MAY.)
#5 8.1.4 - Is the last sentence here really optional, (everything
in section 8 should be optional, right?) or is that behaviour meant
to apply to all cases? If the latter, it really ought be in 4.2
shouldn't it? Also there are two 6CO's mentioned there, but its not
clear to me at what point the 2nd is sent (T+5 presumably?)
#6 What does "expects" mean in the security considerations?
(Section 11, 2nd para.) That's not 2119 language. Are you saying
this protocol MUST NOT be used if layer 2 security isn't
sufficiently strong or is missing? If not, then what?
#7 How can "Using link-layer indication for NUD" be a SHOULD deploy
but only a MAY implement? (Table 2, in section 13.)
General - The logic as to why mesh-under and route-over are the most important topologies is not explained here and I don't see why its most valuable to tackle this problem in a topology-specific manner. It's also a shame that 1.3 needs to have all nodes implementing this to get any benefit and that each node must be part of only one network. (The latter is particularly unfortunate given that sleeping node wake times might cause such a condition over time.) However, this is maybe not actually a problem since the protocol doesn't seem to be really specific to those topologies - is that right? If so, then I'd suggest weakening the language to say that e.g. the authors or WG are more interested in those topologies, but that the protocol might work in other contexts too. Various places: - What's a non-transitive wireless link? Abstract - is a bit awkwardly written, some polish could usefully be applied. 1.1 - I don't get the relevance of the "primarily two types" of lowpan topology on p5. Only the last sentence of that paragraph seems relevant or necessary. Similarly with section 1.2 which, other than introducing terminology seems unnecessary. 1.3 - A number of the goals say "optimize" - is that meant to mean "improve" or "make the best"? In the latter, case, that would seem to require more work, e.g. to be able to compare approaches via metrics or something. Since I don't think that's really needed, I'd say s/optimize/improve/g would be more correct. (Similarly for s/minimize/reduce/) 1.4 - I don't know why the following assumption is needed: "A 6LoWPAN is configured to share one or more global IPv6 address prefixes to enable hosts to move between routers in the 6LoWPAN without changing their IPv6 addresses." Why is it necessary to say this? (The spec would be clearer if that were clear I think.) 1.4 - please don't use the reference as part of the sentence "[I-D.ietf-6lowpan-hc]" being the one that stood out - surely that has a name? 1.5 - I can't parse the first sentence. 3.2 - s/required/REQUIRED/g? and is it clear what it means to "REQUIRE" something of a lowpan? (Rather than a node) 3.3 - "suspects" seems too vague, suggest giving at least one precise (common) condition, and if necessary saying there may be others too 3.3. "The registration can fail (an ARO option returned to the host with a non-zero Status)..." the parenthetic clause isn't clear there. Suggest splitting the sentence. 3.4 - What's context dissemination? Maybe needs a forward ref? 3.5 - How does packet loss impact on "successfully registers with"? (Just wondering.) 4.3 - where is "sequence number arithmetic" defined? 5.3 - What are "theses packets"? Maybe a way to get a few PhDs? That'd be nice:-) 5.3 - Where is "binary exponential backoff" defined? 5.4.3 - Where is the Default router lifetime defined? 5.5.3 - What does "no more default routers" mean? 5.8.1 - seems wrong to say a host should consider how quickly topology changes, how'd it know in general? 6.2 - initialising an interface "more or less" like something is a vague for a spec. 8.1.2 - "similarly" seems vague 13 - The introductory text here is confusing - what's this section for really? Does "deploy" mean "use"? I'd prefer the latter term.
The Gen-ART Review by Richard Barnes on 30-Dec-2011 raised one suggestion. Please consider it: > > The phrase "transitive link" is unfamiliar to me. A definition > would be helpful.
Adrian Farrel expressed better than I could my concerns about the complexity of this technology, especially given the target environment. The phrase "IP-over-foo document" is a bit vague and breezy. Could you at least provide an example of such a document?
draft-ietf-6man-exthdr
This document updates RFC 2460, but I will let Adrian hold that DISCUSS.
I agree with Adrian and Ron that this document updates RFC 2460.
I also agree with Stephen that additional discussion
is needed regarding how this document
updates RFC 2460 regarding middlebox inspection
of extension headers. That discussion might be as simple
as "middleboxes perform extension header inspection
today in contradiction of RFC 2460." The document needs
to make the point explicitly so the IETF is aware of and can
discuss whether or not to officially sanction such behavior.
Extension headers are sensitive to ordering, partial deployment, and other issues. I don't think the guidelines in this document mitigate these in a meaningful way (e.g. due to the fact that it remains unknown the intermediate nodes whether unrecognized extensions earlier in the chain should alter later extension header or upper layer protocol processing), HOWEVER, I don't think the guidelines are harmful either, and can see that it's desirable to have a recommended base extension header format. For some time, high-rate DPI that I have seen has used heuristics rather than actual protocol processing. I do not think adoption of the guidelines in this document will alter that, though "helping" such devices seems to be a goal for this work. It seems undesirable to me, in general, to restrict protocol formats in order to aid layer violations ... but in the case of this particular document, I believe no harm is done.
Doesn't this update RFC 2460 such that the format of future extension
headers is predictable?
- RFC 2460 says that "a receiver must not scan through a packet looking
for a particular kind of extension header and process that prior to
processing all preceeding ones" (end of p6), whereas this is saying that
we need a way to skip unknown extensions. Those seem to be in conflict.
Does that matter? If not, then saying *why* not would be good. (Simply
saying "we need DPI" doesn't answer this question IMO.) If that conflict
does matter, then what's the resolution? I don't understand how
resolving that conflict can be "future work" in any normal sense if that's
what's meant by section 6.
- Doesn't this update rfc 2460?
abstract: s/past/beyond/ (past can also mean previous; the intro has more context for the usage) intro: s/absolutely essential in the Internet-Draft proposing the new option with hop-by-hop behavior./absolutely essential./
The Gen-ART Review by Kathleen Moriarty on 4-Dec-2011 suggested some editorial changes, and the author agreed to make them. However, the changes have not been made yet.
My colleagues have raised a well-rounded set of questions about this document. In addition, I think it could say more about the impact on interoperability and Internet operations (these issues are mentioned in the introduction but not described in detail).
1) s4: Contains the following:
Next Header 8-bit selector. Identifies the type of header
immediately following the Extension header.
Uses the same values as the IPv4 Protocol
field.
Don't you need a reference for the values? Maybe:
[IANA_IP_PARAM]
IANA, "IP Parameters",
<http://www.iana.org/assignments/ip-parameters>.
2) Where do I get a ticket for the "doesn't this update 2460" bandwagon?
draft-ietf-storm-rddp-registries
The draft has several places where it says:
Assignment policy: If the requested value is not already assigned,
it may be assigned to the requester.
This was a bit confusing because the allocation policy (e.g., Standards Action)
came much later in the Section, and I was wondering if the above meant "FCFS".
I would replace all of these with one statement at the beginning of Section 3:
Allocation requests for the below registries may come with a suggested numerical
value that should be assigned. Such suggestions are useful when early
implementations have already chosen particular code points before the final RFC
comes out. If the allocation request in general is accepted, such suggestions
may be honored if the suggested value is still free to be assigned.
Or some words to the same effect.
I agree with Pete that the RFC 2119 language is in general unnecessary. In some of the registries, providing an experimental value for testing and development purposes would be useful, IMHO. Look at RFC 5872 Sections 2.1 and 3 for an example and RFC 3692 for general guidance. For instance, I would reserve one RDMAP operation code value (0xF) as an experimental value. And 0xFFFF for SCTP Function Codes for DDP Session Control. But whether you want to make such a reservation depends of course entirely on your understanding of the needs of the RDDP community and how the protocols might evolve.
I think the 2119 language is unnecessary and ought to be removed. Some of it belongs with the protocol that defines the field. Some of it is giving instructions to IANA about their processing, which seems an inappropriate use of 2119.
draft-ietf-dhc-vpn-option
I still think that using the terms "relay-agent-information sub-option" and "relay sub-option" interchangeably adds confusion
- NVT ASCII could do with a reference. - Last sentence of section 5 is odd. (just before start of 5.1)
1. From section 5, "A relay agent which receives a DHCP request from a DHCP
client on a VPN SHOULD include Virtual Subnet Selection information in the DHCP
packet prior to forwarding the packet on to the DHCP server unless inhibited
from doing so by configuration information or policy to the contrary." This
reflects an implicit requirement; that requirement should be made explicit. -
"DHCP relay agent implementations MUST provide a configuration knob to inhibit
this behavior." (I'm not sure how you expect policy to be specified, but with
the configuration knob, a policy might use the knob to enforce a policy.)
2. In section 5.1, "In some cases, a DHCP server may use the Virtual Subnet
Selection sub-option or option to inform a relay agent that a particular DHCP
client is associated with a particular VPN. It does this by sending the Virtual
Subnet Selection sub-option or option with the appropriate information to the
relay agent in the relay-agent- information option for DHCPv4 or the Relay-reply
message in DHCPv6. If the relay agent cannot respond correctly to the DHCP
server's requirement to place the DHCP client into that VPN (perhaps because it
has not been configured with a VPN that matches the VSS information received
from the DHCP server) it MUST drop the packet and not send it to the DHCP
client."
if a relays requests a specific VPN, but the server returns an
address not
within that VPN, then the relay should drop the packet. Should the
relay let the
server know that it dropped the packet and why? (maybe sending a release
packet?)
Otherwise, Won't the server assume the address has actually been
assigned to the client, thus reducing the
pool of available addresses? Could an
attacker, masquerading as a relay-agent use this behavior to create a DoS
attack?
The Gen-ART Review by Roni Even on 1-Jan-2012 includes some editorial suggestions. Please consider them. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07005.html
This is a fine document. There is one issue I'd like to mention, namely, the term "NVT ASCII VPN identifier" is underspecified. This term might refer to something like "an identifier containing characters only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using the Network Virtual Terminal (NVT) encoding [RFC5198]". If that is more accurate, feel free to use the text or initiate a conversation about appropriate changes. Also, please expand "NVT" on first use.
I modified this discuss to add some more nits I found: I'm curious about the answer to David's discuss. Nits: s3.2: r/see Section 35./see Section 3.5. s3.3: r/This sub-option only only/This sub-option only s5: r/DHCPvr4/DHCPv4
draft-ietf-ippm-metrictest
s/Pseudo WIre/Pseudowire/
I have just one small editorial comment. I can't parse this test from
Section 2; it might need some clarification:
o The error induced by the sample size must be small enough to
minimize its influence on the test result. This may have to be
respected, especially if two implementations measure with
different average probing rates.
A useful document, thanks.
I think that the use of 2119 language in here is superfluous, if not just wrong. I don't see what difference it makes to a reader of this document to say, e.g., "The conditions for which the ADK test has been passed with the specified confidence level must be documented" instead of "MUST be documented."
Overall this is a fine document. I concur with those who have commented regarding RFC 2119 language -- in many places I think you could just as easily change the text to use "needs to", "ought to", and "might" with no harm to the meaning. (For example: "The methods proposed here *might* be generally applicable....")
I support each of Dan's discuss points, and with Sean's observation about code
components.
There are several places where 2119 keywords are used in non-meaningful ways. It
would strengthen
the document to review and remove the instances that are not
truly needed. (The use of RECOMMENDED
at the top of page 10 is a particularly
strong example.)
When you update the document to take RFC 6410 into account, please note
that
while interop reports are no longer required in general, if you have consensus
to do so, you can still require them for advancing these metric definitions. If
you
chose not to require them, please consider text strongly encouraging them.
There are several places where you REQUIRE something "whenever possible". That
leaves a lot of vagueness in the specification (is "it costs too much" a
reasonable excuse for
"not possible"?). Please consider removing the exception
clause, or at least explicitly discussing
what to do or what it means when
meeting that requirement is not possible.
The first paragraph of 3.1 (stating an implementation MUST implement all the
MUSTs in a specification)
is vacuous - please remove it.
Or perhaps the intent of the whole section was to clarify what's required to be
reported in an
implementation report and you were asking for an explicit
statement that the implementation
implemented all the MUSTs - if so, please
clarify. That would be consistent with the second paragraph
of 3.1 which appears
to be asking that the report document which options were supported in
"sufficient
detail". But what defines sufficient, and for what purpose? Please
consider continuing that sentence
("in sufficient detail to <achieve this
documented goal>").
Please consider addressing the following nits.
The string "state of the art" isn't adding anything useful to the text - please
remove it.
The third paragraph of section 3.5 does not parse - should "by" be deleted?
Why is there a link to xml.resource.org in the first paragraph of Appendix A.
draft-daboo-webdav-sync
Downref: Normative reference to an Experimental RFC: RFC 5842
I don't see RFC 5842 in the downref registry and I don't see any reference to
the downref in the Last Call Text.
I support Russ's DISCUSS, particularly wrt the 2nd item noted in David Black's review, regarding atomicity.
I have no objection to the publication of this document as an RFC. A minor nit... Section 3.1 s/since one point in time/between one point in time/
I wondered if the result truncation scheme in 3.6 implies that the token is not really opaque.
The Gen-ART Review by David Black on 27-Dec-2011 raises two major
issued and one minor issue. They deserve a response. The review
can be found at:
http://www.ietf.org/mail-archive/web/gen-art/current/msg06994.html
1. I am concerned enough about the atomicity issue that I need to note my own
DISCUSSion point. I'm not convinced that David Black's proposed solution is
correct: If none of the items you have retrieved have changed before you ask for
the next token, you *do* have a consistent copy of the collection, albeit old.
There is no indication in the document that the mere taking of a report and
return of a new token invalidates the old token (and I think the text should be
clear about the expected behavior of the server; see #2 below), so I think this
might be sufficient and David's solution might be overkill. Either way, I think
this topic needs serious discussion in the document.
2. The expected semantics of the server are way underspecified and I'm worried
you are going to get into an IMAP-like debacle where servers are allowed in the
protocol to do random crap. The document says:
(DAV:valid-sync-token): The DAV:sync-token element value MUST be a
valid token previously returned by the server. A token can become
invalid as the result of being "out of date" (out of the range of
change history maintained by the server), or for other reasons
(e.g. collection deleted, then recreated, access control changes,
etc...). [3.2]
That is *way* under-specified. If you get into the nonsense of "the server can
invalidate the token whenever it feels like it", you will have a completely non-
interopable system. The server needs to have reasonable expectations of the kind
of cache it needs to keep, and the client needs to have reasonable expectations
of what a server is required to do. At least one of those expectations MUST be
that the act of using a token and getting a new one does not in itself
invalidate the old one.
I am willing to clear this DISCUSS if I am told that the consensus in the WebDAV
community is that this sort of random server behavior has always been acceptable
to the community, but I would prefer if the spec was tightened to give more
guidance to implementers.
The security consideration is really a performance consideration. Though it can be used for nefarious DoS attacks, it can also be used by legitimate though stupid clients. I don't think it belongs in security considerations.
draft-gregorio-uritemplate
Please run the nit-checker over this document. It appears to have a couple of unused references.
This seems to be a very useful and well-written document.
I have no objection to the publication of this document as a Standards
Track RFC. I have a few very minor comments you might look at.
---
You may note that you use RFC 2119 language in Section 1.1 but do not
include the explanation until Section 1.5.
---
Should you provide references for WSDL, WADL, and OpenSearch in section
1.3?
---
In section 1.5 there is a minor notational discrepency.
You have:
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
That means that HEXDIG has a mixed mode of hex notation and quoted
letters. It might have made more sense to write...
HEXDIG = DIGIT / %x41-46 ; 0-F
But I struggle to see this as in any way an important comment! Maybe
more interesting is to check that you really intended to exclude lower
case alpha from the representation of hex numbers used in pct encoding.
---
While Appendix A begins with a helpful note that the body of the
document is normative text, it doesn't actually comment on whether the
appendix is normative or not. It would be nice to make this explicit.
- End of p12 says "If a value provided by a user" which implies that
all the usual injection attacks need to be countered in at least some
deployments. Why doesn't that need to be mentioned in the security
considerations? I don't think 3986 envisages that kind of issue. (Esp.
if templates were combined with OAuth v1 or something else that
authenticates the URL after expansion, meaning that the user at the
browser could not have produced the URL herself.)
- Can expressions be nested?, e.g. "{foo{bar}baz}" 1st sentence of 3.2
implies not, but in any case it might be worth adding a sentence
saying that nesting like that is not supported.
- Expressions can be obfuscated. That could provide a new attack
vector: expression author convinces webmaster that template is safe
when its not. Not sure if that's worth a mention or not.
- Seven operators; lists of variable with optional modifiers (esp
"explode") - that all seems to me like too much to be universally
useful and safe. Just an opinion, not a discuss.
The Gen-ART Review by Vijay Gurbani on 1-Jan-2012 raised two minor
issues. I have not seen a response to this review, but I believe
it deserves a response. The two issues are repeated below.
- S3.2.1, first paragraph: "A variable defined as an associative
array of (name, value) pairs is considered undefined if the
array contains zero members or if all member names in the array
have undefined values."
Here, do you mean "if all member names in the array have no
values."? That is, "undefined values" implies that values are
present in the template, but are not understood. On the other
hand, "no values" implies the absence of any values at all. In my
reading of the text, it appears that "no values" conveys more
context than "undefined values".
- S4, general comment: I am not sure where the template expansion is
done --- at the client (browser) or at the origin server (the draft
does not enunciate this, and if it does, I may have missed it). If
the expansion is done at the origin server, I suspect that one can
keep it a bit more busy by asking it to perform unnecessary
template expansion for a resource that may be accessed normally
even without template expansion. Is it worth documenting this at
all in the Security Considerations section? (Clearly, if the expansion
is done at the client, then it is the client incurring the expense
of expansion. Insofar as the client is malicious, it is best to
let it expend as much effort as necessary.)
2.2: I'm not clear from what is said in section 3 or Appendix A what happens
when an op-reserve appears in a template that is being processed where the
processor doesn't recognize these operators, in particular '$', '(', and ')'.
Are they all treated as error conditions? If so, where in the algorithm.
2.3: Do you really want varnames to be able to end with "." or "_" or begin with
"_" or pct-encoded? If you want only internal ".", then you want:
varname = varchar *(["."] varchar)
If you only want internal "_" and pct-encoded as well, then:
varname = ALPHA / DIGIT *(["_" / "." / pct-encoded] / ALPHA / DIGIT)
I don't care, but the current construct (can't begin with ".", but otherwise
anything goes) seemed like an odd choice.
2.4.1: An upper limit on max-length might be a useful addition.
3.2.1: The current text says:
...If the value
contains multibyte UTF-8, care must be taken to avoid splitting the
value in mid-character: count each Unicode codepoint as one
character.
The admonition in 1.6 seems equally useful for the values variables: Though they
might exist as encoded, all contents of variables are assumed by the spec to be
Unicodes, and must be appeneded by UTF-8ing them and pct-encoding as necessary.
I think it's worth adding text on this.
draft-ietf-sipclf-problem-statement
I think we need a log file format. And it needs to work on application level, because, as noted, layer 3 or 4 security makes it impractical to read off the contents of SIP messages. I'm less convinced about the specific proposal here. The text on wireshark for instance seems to indicate some lack of information on various logging mechanisms in the Internet. (Wireshark is just a tool that operates on the more general pcap http://en.wikipedia.org/wiki/Pcap interface.) I would guess that there are multiple needs in this space. One is for detailed SIP message logging for debugging and statistics purposes. For that purpose, a pcap-like recording of exact messages at the application layer might be more appropriate. Another need is for more high-level, CDR/billing/high-level statistics collection type of needs. There some summary of SIP events would be more appropriate. This would not necessarily record every message, and could even record some non-message events such as when the SIP entity gives up on trying to contact someone. The current design seems to be some mixture of these two kinds of approaches.
I would like to discuss with the authors whether the data model is an example or
is definitive? If it is definitive why is it in an informational draft, and
indeed why is it not in an IANA registry?
If it is not definitive, then please can this be made clearer in the document.
The exact purpose and intended use of this document is not clear to
me. The document name include "problem-statement," the title includes
"Framework and Data Model," and the abstract concludes with the
sentence:
We propose a common log file format
for SIP servers that can be used uniformly by user agents, proxies,
registrars, redirect servers as well as back-to-back user agents.
I don't know if the text in section 4 is referring to the standards
track CLF as defined in this document or an hypothetical CLF to be
defined based on the problem statement in section 3 and the data model
in section 8. In fact, it seems that section 8 defines something more
than just a data model, as it defines mandatory elements in CLF
records, etc.
The document needs a clear statement about whether or not it is
defining the operational abstraction for the standards CLF. If it is
defining that standards CLF, it needs to be a standards track document.
Editorial observation: "CLF format" is redundant. Process comment - the IESG Writeup Working Group Summary consists of one sentence: "The problem statement was not contentious." I can't tell if this sentence refers to just the problem statement in section 3 or the entire document. I note that the document name includes "problem-statement" while the title includes "Framework and Data Model." Perhaps the goals and purposes of the document changed during its development? It would be helpful if the Working Group Summary gave more detail about the background, development and purpose of the document. Niggling irritation - the first couple of motivations listed in section 6 are relevant to the development of a CLF. The remainder don't actually depend on a CLF; a CLF might ease the development of solutions to those problems. Which representation format is used in the example in section 9.1, or is the example an abstract representation independent of any specific format like the one defined in draft-ietf-sipclf-format-03?
I support Stephen & Ralph's DISCUSS points
Although this document does not define a CLF for SIP, I am not clear why the data model here is not normative as a Standards Track document. --- I wonder if you could consider adding to Section 7 a discussion of the migration / backward-compatiblity issues. Maybe these are no worse than today, but it will certainly be the case that a log file will need to contain some indication that it is in the CLF.
This seems like a lot more than a problem statement. I'm not clear
whether the security and privacy considerations here will be relied
upon in the format spec or not. At present, -05 of the format
draft says that this document says all that needs to be said, which
is not something with which I agree. So, for now, I'm treating the
security considerations here as those that will be provided as the
final output of the sipclf WG. (Were this only a problem statement
then that'd not be the case.)
#1 While this document might not be able to say how files are to be
protected, both locally and in transit, it could easily, and IMO,
should, state requirements for that using 2119 MUSTs and also
include some examples of how to meet those, e.g. REQUIRE mutual
authentication, confidentiality and integrity for transfers with
the example that use of mutual auth TLS between nodes accomplishes
this. (Note: I'd be fine if this were instead handled in the format
document since that's I guess what most coders will read.)
#2 IP src&dest and SIP to&from are mandatory - that's not very
privacy friendly. Did the WG consider this? Did the WG consider
defining an additional (less sensitive, more easily shared) format
where those are obfuscated (but so as to still allow correlation?)
If so, why wasn't that adopted? If not, doesn't that warrant
consideration? (As-is sharing CLF files is likely to be tricky from
at least an EU data protection p-o-v if there are some cross-border
nodes involved.)
- What does "trace a call from one entity to another mean"? I do hope we're not proposing that lawful intercept is the primary reason for this work. - You say a few things the CLF is not at the end of section 4, would it be reasonable to add "The SIP CLF is not a tool for supporting lawful intercept." - Public access to the log is worse than network sniffing in at least two respects - log access trumps TLS and also network sniffing is more restricted in time and place (topology).
1) I agree with the other IESG members who think this exceeds the scope of a
problem statement.
2) I agree with the DISCUSS that the shepherd writeup is lacking in useful
detail. In my opinion this writeup is woefully inadequate to reflect the nature
of the discussions that occurred, some contentious.
3) The document fails to include any summary of WG discussions of using existing
IETF protocols.
There was significant contention in the WG about whether existing IETF standard
data modeling languages, such as syslog structured data elements [RFC 5424] or
ipfix Information Elements [RFC5655] could have been used for SIP logging. If
this document is going to discuss why Apache CLF and Wireshark do not meet
sipclf needs, which I believe it should, then the document should also explain
the WG considerations for using syslog, ipfix, and psamp data models for SIP
logging. This gap between existing standards and the problems prompting a new
sipclf approach should be documented as part of the problem space.
There was contention about whether the logging should be designed only for
logging locally, or for local use and for being transported between systems. The
WG discussed the need for secure transport of logged information. Existing
standards already address this, e.g. syslog/TLS [RFC5425] and ipfix RFC5101].
This should be documented as part of the problem space.
The WG debated whether pre-filtering was a desirable feature, to control log
growth rates, and bandwidth needed for transporting logs, and whether existing
standards could be utilized for this purpose (ipfix offers a template approach
that controls what data gets logged, and what data gets transported). This
should be documented as part of the problem space.
4) The document describes wireshark as inappropriate because the wireshark
libraries would need to have sipclf functionality implemented across multiple
OSes and configurations. But the proposed solution seems to be to develop a
whole new format, so any tools for parsing this new format would need to be
developed from scratch, across multiple OSes and configurations. That strikes me
as an odd problem statement to justify a new sipclf approach.
5) I support the Discusses about whether the sipclf mandatory fields in section
8 is normative. If this is not normative, then RFC2119 language is probably
inappropriate. If it is normative, then it belongs in a standards track
document.
6) Security considerations discusses the threats associated with stored logs.
Existing standards for logging include capabilities for signing logs and
detecting deletions and modifications [RFC5848], whether at rest or in transit.
The potential need to secure logs at rest and in transit is part of the problem
with logging SIP, and should be documented as part of the problem space.
1) section 6 strikes me as marketing claims for the wonderful things that a sipclf can provide. But these tools are not part of the scope of sipclf development. I question whether these claims of tools that could be developed really is part of a problem statement. 2) RFC 3444 describes the difference between Information models and Data models. If section 8 is not a normative data model, then it should probably be called an Information model, rather than a data model.
Seems like others have the DISCUSS points well in hand.
It seems a bit goofy in section 8.1 to call out fields as "mandatory" and even
say that they are "minimal information that MUST appear in any SIP CLF record",
and then go on in section 9 to point out for some items: "When a given mandatory
field is not applicable to a SIP entity, we use the horizontal dash ("-") to
represent it." That would make the field pretty clearly non-mandatory.
In the 'Operational guidance' section: > SIP CLF log files will take up substantive amount of disk space depending on traffic volume at a processing entity and the amount of information being logged. As such, any enterprise using SIP CLF should establish operational procedures for file rollovers as appropriate to the needs of the organization. I suggest to replace the word 'enterprise' with 'organization'. The issue is certainly present in all type of networks, not only in enterprise deployment as it may be mis-understood here.
I'd like to chat about internationalization. Section 8 mentions draft-ietf-
sipclf-format as an example of a representation format that provides an ASCII-
based encoding scheme. Are there any examples of encoding schemes that allow
code points outside the ASCII range? More generally, what are the
internationalization requirements for SIP logging? The requirements might be
"none" if SIP messages cannot contain, say, UTF-8 encoded Unicode characters,
but if so then it would be best for the specification to make that explicit.
The document states that the Wireshark format cannot be used because "if the SIP messages are exchanged over a TLS-oriented transport, Wireshark will be unable to decrypt them and render them as individual SIP headers." Is there a reason why SIP servers cannot use the Wireshark *format* as a CLF even if they cannot use the Wireshark *application* on the data sent over an encrypted channel? A true nit: there is no such thing as "12:00 PM". Another nit: I have never seen "pend" as a verb. I suggest "can be in a pending state" or somesuch. When talking about URIs in Section 8, an informational reference to RFC 3986 would be appropriate. The allowable values for the Message type field are 'R' (for Request) and 'r' (for response). Is it really a good idea to use values that differ only by case? (Also, the Directionality field has a value of 'r' -- another source of possible confusion; you might consider "o" and "i" for outbound and inbound instead of "s" and "r" for sent and received.)
draft-ietf-rtgwg-lfa-applicability
Nice doc!
In Section 3.8, under "Intra Area Destinations", the Node Protection evaluations use "Full" rather than "yes", which is inconsistent with the explanation of terms at the beginning of the section and with the terms used for the next subsection for "Inter Area Destinations".
I have cleared my Discuss and moved to a Yes ballot. Thanks for addressing some of my comments. I still wish the I-D would spend more time looking at the security (are rpf checks commonly used in the topologies that are discussed, and if so what will be done to improve security when rpf checks are disabled) and management (what will be the consequences for management of turning on LFAs in the topologies discussed). But I don't think this is a blocking concern. --- Section 2 starts with... In this document, we assume that all links to be protected are point- to-point. The introduction has not mentioned the need to protect any links (nor what the concept of a protected link is). --- ISIS and OSPF should have references in Section 2.
The Security Considerations say: " This document does not introduce any new security considerations." I am sure this is true, but it does not really help the reader. Please add a sentence pointing the reader to security considerations from IP/MPLS. The late Gen-ART Review by Suresh Krishnan on 4-Jan-2012 includes a good suggestion. Suresh suggests: This draft needs an informative reference to RFC5286. Without this reference it is very difficult to get the context required to understand this draft. Please consider adding the reference.
Personally I found this document to be nearly impenetrable, but that's probably because the air is so thin up here at the application layer. :) I am balloting "No Objection" on the assumption that our Routing ADs have performed up to their usual high standard of excellence.
draft-arkko-ipv6-only-experience
Thank you for an informative and readable document. If you were to have time to provide some additional words about management (in addition to the brief paragraph in section 8) it would be enlightening. - What was the user's experience of performing manual configuration where necessary? Is it the same as for v4 or messier? - What was the user's experience of running diagnostic tools to determine configuration and connectivity problems? Are the tools up to the same standard as for v4?
Good to see stuff like this. general: - A timeline would help readers understand the level of effort, e.g. if you could give dates for when stuff happened related to a specific user's home being added, or anything else that gives the right flavour for the level of effort. - Some ascii art n/w diagrams would be nice if you've time. - Some version numbers (esp. for stuff that didn't work) would be good for someone reading tihs in a few years time or who wants to try replicate your results - It'd be good if you added your wget scripts as an appendix or put 'em at some URL (again so folks can replicate) - 3rd last para of 6.2 seems to imply that'd be useful (and that matches my own experience too) - Is the DNS64/NAT64 setup you're recommending not more "wiretap" friendly than a currently typical IPv4 or dual-stack network where DNS and NAT are less coupled? Either way, that'd be worth noting I think in section 9. specific - be good to point out that you don't in general need to add new APs (3.1, 1st para) - saying it "becomes crucial" that you can find DNS servers doesn't explain why that's harder which may be worth saying (3.2 1st para) - s/a year and half/a year and a half/ (s4, 1st para) - You mention Ercisson and Skype (negatively in the latter case) but are coy about the mobile OSes (presumably IOS and Android). I'd say do one or the other. - s/only couple of times/only a couple of times/ - 5.1 - expand RA on 1st use - s/result require/results require/ or /result requires/ in 5.4 - which year is "next year" in section 8? s/next year/YYYY/ - s/cleaned from/cleaned of/ IPv4 literals
draft-ohye-canonical-link-relation
I support Russ's discuss and wonder if "Canonical" is actually the correct term. Canonical normally implies a more precise equivalence than the author describes in the document. I think that the text is describing the preferred link relation.
In Section 5, the first and third recommendations may be very difficult to use practically for sites where the majority of content is generated dynamically. I don't think this document makes clear/strong enough statements on how this would/could/should be used for dynamic versus static resources, however, I defer to the judgement of the ADs closer to this topic.
I cleared my Discuss after an exchange with the AD. --- Building on Brian's review in Russ's Discuss... If URIs are identical there is surely no isse to designating one of them as preferred. They are the same, and selecting any one is the same as selecting any other. I suspect this is just loose language since it is obvious from the content (versus the Abstract) that you mean that it is the identical nature of the content returned by URIs that is what you define as making the URIs identical. Maybe you could go over this with a pedant's eye? --- Section 3 contains some examples of "SHOULD NOT". The subsequent paragraphs got my hopes up by starting with "MAY", but actually they do not address the exception cases of the "SHOULD NOT." Since you have chosen "SHOULD NOT" rather than "MUST NOT", you need to explain the option for varying the rule. --- Section 5 Before adding the canonical link relation, verification of the following is recommended: Is that "RECOMMENDED"?
- A non-compromised site might also well lie about which URI is "canonical" for various purposes.
The Gen-ART Review by Brian Carpenter on 14-Dec=2011 raised one
minor issue that deserves a response. The review says:
> The canonical link relation specifies the preferred URI from a set
> of URIs that return identical or vastly similar content, ...
I don't understand the phrase "vastly similar". I don't understand
what algorithm tests for vast similarity.
The same applies to "extremely similar" in section 3 and "similar to"
in section 5. Also, "similar to" is weaker than "vastly similar" or
"extremely similar"; so does section 5 intend to weaken the earlier
text? It seems that exactly the same phrase should be used in each
case (not just a vastly similar phrase).
This doesn't matter so much when it's a human designating the
canonical relation. But it can only be a matter of time before code
starts to do this (which page is canonical among a set of generated
pages?). A vague word like "similar" turns this into an AI problem.
Please consider adding text explaining when a user might choose to go against the SHOULD NOTs in section 3. It might help to cast the last 4 bullets in section 3 as requirements on maintaining the link relation, rather than just creating it. You might also make it clear whether transient errors are of concern in the 3rd bullet.
I too tripped over the concept of canonical being used in the same sentence as vastly/extremely similar; therefore, I support Russ' discuss.
draft-kucherawy-dkim-atps
Thank you for advancing this work as Experimental and for taking the time to describe the experimental process.
IANA suggests that the registry be created now, even if it will not
be used for some time. Thanks to Alexey Melnikov for asking the
question in his Gen-ART Review.
1. "ATPS" is never expanded in the text before its use. Please do so in the intro. 2. The ABNF for atps-query should put an upper limit of 63 for the number of BASE32 characters: atps-query = 1*63BASE32 %x2e.5f.61.74.70.73.2e domain-name 3. Is there reason to believe that, in practice, the hashing is really needed? Do we really believe that the combination of the two domain names will exceed 255 characters? 4. Given that this is an experiment, is there any reason not to give this a go with a new DNS query type? (Yeah, yeah, I know. But I thought I'd ask.)
This is a fine document. It's especially helpful to describe how the experiment will be run. I have one small comment: please consider adding a brief sentence about internationalized domain names (IDNs). I realize that RFC 6376 specifies encoding of IDNs as A-labels, but it might be good to reinforce that message here, such as (in Section 4.2): "domain-name" and "key-h-tag-alg" are defined in [DKIM]. Note that according to [DKIM] internationalized domain names are to be encoded as A-labels, as described in Section 2.3 of [RFC5890]. This would necessitate adding an informative reference to RFC 5890, if you decide to make such a change.
draft-amundsen-item-and-collection-link-relations
I agree with Adrian's comments
The usefulness of this was not really clear to me, and the references are either just webpages or works-in-progress, so it's unclear to me whether it's really in-use or will actually be used. However, I'm not personally concerned with the tidiness of this registry and trust the judgement of the ADs closer to it.
I have no objection to the publication of this document as an RFC, but
I have a couple of Comments you could look at along the way.
---
I found it odd that this "specification" is Informational since it does
define things.
---
The RFC Editor will want you to remove the citation from the Abstract.
If you are providing a revised version, please fix this.
---
I would have preferred you to explicitly name the registry in which you
want new entries recorded.
Would it be worth saying whether both item and collection can occur in the same href?
The Gen-ART Review by Mary Barnes on 2-Jan-2012 raised a
point that deserves a document update:
ID nits indicates that "You're using the IETF Trust Provisions'
Section 6.b License Notice from 12 Sep 2009 rather than the newer
Notice from 28 Dec 2009."
For the secdir reviewer: s4: r/are not believed to/do not