IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-11-21. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Barry
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
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
Telechat:
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
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
3.4.2 Returning Items
Telechat:
1253 EDT break
1258 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1342 EDT Adjourned
(at 2013-11-21 07:30:14 PST)
draft-ietf-l2vpn-vpls-mcast
In 3, the acronym "PE" is used several times without definition. It is
defined in 4761, but you use it so frequently that it seems like it would be
worth defining it here despite the reference to 4761.
Also in 3:
A "Selective tree" is a single multicast distribution tree in the
Service Provider network that carries multicast traffic belonging
only to a specified set of IP multicast streams, and all these
streams belong to the same VPLS instance on a given PE.
could IMO be made clearer by adding:
A selective tree differs from an inclusive tree in that it may
reach a subset of the PEs reached by an inclusive.
I propose this addition because when I first read this section it wasn't clear
to me what the distinction between selective and inclusive trees was; this was
made clear in section 5.1, so the change isn't strictly necessary, but it would
save the new reader some speculative effort when reading the glossary. Of
course, the text I've proposed for addition is probably incorrect—I propose it
to illustrate the point, not as some kind of demand that it be included
verbatim. If you think something along these lines would improve this
definition, please include it; otherwise feel free to ignore it, since the
point is ultimately resolved in 5.1 anyway.
There are a number of cases throughout the document where "needs to" is used
where a direct verb would (IMO!) be more clear. For instance, in 5.1:
is termed Aggregation. The tree needs to include every PE that is
could be:
is termed Aggregation. The tree includes every PE that is
This is a really minor style issue and also a matter of opinion, so please
ignore it if you don't see it as an improvement. There are also a number of
cases where the document says "needs to know," which is correct and shouldn't
be changed.
5.1, paragraph 5:
OLD:
trees, as previousely state, must be used only for IP multicast data
NEW:
trees, as previously stated, must be used only for IP multicast data
5.2, paragraph 1, this is hard to parse:
In order to establish Inclusive P-Multicast trees for one or more
VPLS instances, when aggregation is performed (with either mLDP or
P2MP RSVP-TE as the tunneling technology), or when the tunneling
technology is P2MP RSVP-TE
If this means the same thing, it might be clearer:
In order to establish Inclusive P-Multicast trees for one or more
VPLS instances when the tunneling
technology is P2MP RSVP-TE, or when aggregation is performed,
The bit about mLDP is repeated later in the paragraph, so I think this covers
all the cases you are trying to cover. The reason I suggest this change is
that it's less text and more easily parsed, so if it's wrong, or doesn't seem
clearer to you, please ignore this suggestion.
Same paragraph:
OLD:
must be able to discover the other PEs that have membership of these
NEW:
must be able to discover the other PEs that have membership in these
right? or:
must be able to discover the other PEs that are members of these
In section 6 and subsequently, writing A-D instead of auto-discovery probably
makes the document a bit shorter, but also makes it harder to read. You could
also make the document a bit easier to read by writing pseudo-wire instead of
PW. Particularly in section six, so many acronyms are introduced so quickly
that it is a lot to juggle as you read. You're not getting a ton of value out
of abbreviating auto-discovery and pseudo-wire. Also, why the dash in A-D but
not P-W? The document also abbreviates Route Target as RT, but this is
introduced several times, and used as an abbreviation only a few times. There
seems to be little value in this abbreviation as well. To further nitpick,
VSI, PMSI, ASBR and NLRI are used throughout the document, but not mentioned in
the Terminology section, so the reader is forced to hunt in order to find the
initial use of these acronyms so as to remember what they stand for (in the
case of ASBR, there is no expanded version). Likely not a problem for a
domain expert, of course, but for a new reader this will be a problem.
It might be worth expanding the P2MP TE LSP acronym once in 8.2.1. You have
the reference to RFC 4875, so this isn't strictly necessary, but it took me a
while to figure out the connection. Whether you expand the acronym or not,
you should really add a reference to RFC4875 on the first occurrence in 8.2.1
for completeness.
Speaking of which, there's what looks like a typo in this reference:
[RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to
Multipoint TE LSPs", RFC 4857, May 2007.
The actual RFC reference appears to have the last two digits transposed.
The acronym "VE" as in "VE ID" is never expanded.
A brief discuss that I'll soon clear since I'm sure that this probably isn't the right document in which to tackle this problem, but I'll ask anyway... The security considerations say that if you know the labels, you can eavesdrop, and that I guess applies to all ASes that are neighbours and maybe more. (Or does it? If not, saying why not here would be good.) Given recent developments, maybe assuming that all ASes are "composed of trusted nodes/links" might not be so credible anymore so where/how might this be addressed? (Like I said above, I'll clear once we've chatted briefly about this.)
- 5.4: This is based on rfc 6074, the security considerations of which say that automated security mechanisms are recommended as a future work item. Did that happen? If so, should there be a reference to the results? If not, what's the impact on this spec? - 5.6: nit: where's option (d)? Be nice to exaplain a bit for the uninformed reader. - 9.1.1 - just wondering: does that mean that if I guess a VLAN ID then I get to join a MC group? Aren't they only 10 bits long? Does that mean that any other AS can try search all the MC groups that exist?
I gave this document a cursory scan for applications issues and finding none I will simply No Obj.
This should be a short discussion for clarity (I intend to clear no later than after the IESG telechat). This document does not explicitly state if this proposed approach impacts the IP multicast model. So, does this approach support both ASM and SSM models? Is it applicable to both IPv4 and IPv6? It is unclear since only IGMP (IPv4) is mentioned in passing.
1. It would be useful to explicitly reference the IGMP (and MLD?)
specifications.
2. ID-nits complains about a few issues:
** There are 4 instances of too long lines in the document, the longest one
being 3 characters in excess of 72.
** The abstract seems to contain references ([RFC4761], [RFC4762]), which
it shouldn't. Please replace those with straight textual mentions of the
documents in question.
-15 addressed the opsdir review comments thanks
draft-ietf-tls-oob-pubkey
Good to see this getting done. Thanks. - The write-up sez experts to be added by AD. Just noting that in case there's some urgency and a ball-drop, I'm fine if that's done when there's a request to handle. - Section 1, 1st para: I could quibble and say that self-signed certs are just as traditional in TLS. Not as common, but just as traditional. Shouldn't they get some kind of mention? - Figure 1: is 2^24-1 still a good max length? Just checking in case there's a reason now to prefer smaller over same-as-others. - Section 3: definition of SPKI - did you take a look at DANE to see if there's any text there to copy or reference? I'm sure you did, but just in case that's not been done with the final DANE RFC, in which case it'd be worth a quick check now. - Figure 3/algs: Did you think about the curve 25519 equivalent for signatures (ed25519 is it?) - should that use the ECDSA OID or be a new certificate type? Just curious. - 5.1: Be nice if the example made clear that this can work with DH for forward secrecy as well. (As part of a general tendency to want more DH and PFS.) - section 6: "the identity and public key" phrase is a little ickky - wouldn't it be better to talk about identifiers and not identity at least when discussing binding to the public keys? - section 6: what happens if a spec wants to use this but also wants to punt to yet another spec as to how to bind keys/identifiers? (Such as arguably CoAP.) Are you asking that we drag CoAP back to the core wg? I guess not. Maybe that MUST needs some more consideration? I'd suggest s/MUST/need/
Section 1:
"does not require codepaths for the ASN.1 parser"
That's not really true, since you're still using SubjectPublicKeyInfo, right?
Likewise, if you are ultimately going to authenticate the key (as discussed in
the Security Considerations), you're going to validate something like a trust
chain, e.g., via PKIX or DNSSEC. So I'm not sure you actually get the code
size savings you claim.
Section 3:
"... is represented in a DER encoded ASN.1 format ..."
It would be better to say that the subjectPublicKeyInfo value in the
Certificate payload MUST contain the DER encoding of the SubjectPublicKeyInfo
structure. Just in case someone decides to put BER, XER, etc. in there.
Figure 4:
Both "select()" statements are missing opening "{" characters.
Just a few editorial comments on this fine document, all purely at the nit level. Accept or reject as you see fit, and no need to respond unless you want to. -- Section 1 -- OLD Alternative methods are available that allow a TLS clients/servers to obtain the TLS servers/client public key: NEW Alternative methods are available that allow a TLS client/server to obtain the TLS server/client public key: END Probably also best to change the first bullet to "The TLS client" also, so all is consistent (the other bullets start that way). Some other minor grammar/usage editing, if I may: OLD This document introduces the use of raw public keys in TLS/DTLS. Raw public key thereby means that only a sub-set of the information found in typical certificates is utilized, namely the SubjectPublicKeyInfo structure of a PKIX certificates that carries the parameters necessary to describe the public key. Other parameters also found in a PKIX certificate are omitted. A consequence of omitting various certificate related structures is that the resulting raw public key is fairly small (compared to the original certificate) and does not require codepaths for the ASN.1 parser, for certificate path validation and other PKIX related processing tasks. NEW This document introduces the use of raw public keys in TLS/DTLS. With raw public keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure of a PKIX certificates that carries the parameters necessary to describe the public key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public key is kept fairly small in comparison to the original certificate, and the code to process the keys does not require paths for an ASN.1 parser, for certificate path validation, and for other PKIX related processing tasks. END The "This document is structured as follows" paragraph oddly omits an explanation of Section 6. If you find the paragraph useful, you should probably add "Section 6 describes security considerations with this approach," or some such. -- Section 6 -- Is the indentation of the third paragraph intentional and significant, and, if so, what does it mean?
draft-ietf-mmusic-rfc2326bis
I have not completed (read: barely started) my review of this document, hence
my "No Record", but I did have an overall question to ask. The writeup says:
Working Group Summary
The document has been work in progress for an extended period of
time dating back to 2002. Earlier versions saw decent WG
participation however the later versions have primarily been driven
by the document authors with limited overall discussion in the
group, especially towards the end of the process.[...]
Document Quality
[...]
There is one known implementation of the specification, and many of
the extensions compared to RTSP 1.0 have been implemented separately
as well.
And the document says:
RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that
specification. This protocol is based on RTSP 1.0 but is not
backwards compatible other than in the basic version negotiation
mechanism.
This combination sounds worrisome to me. You are obsoleting 2326 with a
non-backwards-compatible new version, there is only one known implementation,
and it sounds like the WG has tuned out. Are you saying that anyone who is
about to implement RTSP should ignore 2326 as obsolete and go straight to this
document? And you're saying that they're going to be able to interoperate with
anyone? That sounds...unlikely, at least given that combination of information
given here. What am I missing?
I have not finished reviewing yet: I'm just about to start Section 10 as I post
this, so I have well over 250 pages yet to read, and I'm sure I'll have many
more comments. But I want to get some of this out here now, so the authors
aren't entirely blindsided at the last minute. I also might ask that we defer
this one telechat, though I'm holding off on that for now.
What I have so far follows, in both the DISCUSS and COMMENT sections.
-----------------------------------------------------------
1. This first point is for some discussion with the responsible AD, and I'll
clear it after we have that discussion:
The grammar, punctuation, and English usage in Section 2 and its subsections is
at times very hard to sort through. I'm going to call out in the comments some
bits that I found particularly troublesome, and will try to suggest
alternatives. I also suggest that the responsible AD put in an RFC Editor note
asking the editors to pay particular attention here and to give it some heavy
editing for language clarity. This is a complex document, and a good overview
in clear English will really help.
2. This point falls into the "URI/IRI follies" category:
-- Section 3.2 --
IRI: Internationalized Resource Identifier, is the same as a URI,
with the exception that it allows characters from the whole
Oh, my; please don't say that it's "the same as a URI". It'd be reasonable to
say "is similar to a URI, but allows characters [etc]."
-- Section 4.2 --
The RTSP URI and IRI are case sensitive, with the exception of those
parts that [RFC3986] and [RFC3987] define as case-insensitive; for
example, the scheme and host part.
Clumping URIs and IRIs together in such a vague way with respect to case
mapping is a dangerous thing. And unless there's a particular reason to say
otherwise, it's easy to avoid that by specifically saying that the scheme and
host parts are the *only* case-sensitive bits (which is true of generic URIs
and IRIs anyway). Is there really a reason not to be clearer, this way?:
NEW
The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987]
are case-insensitive. All other parts of RTSP URIs and IRIs are case-
sensitive, and SHOULD NOT be case-mapped.
END
3. The paragraph in Section 4.4.2 that explains npt-hhmmss notation and npt-sec
notation has some internal inconsistencies that have to be fixed. See my
suggestions in the comments section below, which goes beyond the blocking point
(the inconsistency) and tries to make the paragraph more readable as well.
4. I'm disturbed by this combination in Section 9.2: it appears that
Content-Encoding is optional (the first paragraph doesn't say it MUST be
included, and the second paragraph uses lower-case-"may" to describe its
inclusion), but the second paragraph says that there is no default encoding.
So what does it mean to have a message body with no Content-Encoding header?
These are non-blocking, but many of them address readability issues and go
beyond simple editorial points. Please consider them carefully, and feel free
to talk with me about them.
-- Abstract --
The Real Time Streaming Protocol, or RTSP, is an application-level
protocol
"application-layer", maybe? Also in the Introduction.
-- Section 2.2 --
The RTSP client can request the establishment of an RTSP session
after having used the presentation description to determine which
media streams are available, and also which media delivery protocol
is used and their particular resource identifiers.
What is the antecedent to "their"? The only thing here that's plural is "media
streams", so I guess it has to be that, but the sentence isn't clear there. I
suggest rephrasing it this way:
NEW
The RTSP client can request the establishment of an RTSP session
after having used the presentation description to determine which
media streams are available, which media delivery protocol is used,
and the resource identifiers of [what, "the media streams"?].
END
In the SETUP request the
client also includes all the transport parameters necessary to enable
the media delivery protocol to function in the "Transport" header
This sounds like the media delivery protocol functions in the Transport header.
Maybe this?:
NEW
In the "Transport" header of the SETUP request, the
client also includes all the transport parameters necessary to enable
the media delivery protocol to function
END
OLD
The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter
specifications are acceptable.
NEW
Upon receiving a SETUP request, the server determines if the
media resource is available and if any of the transport parameter
specifications are acceptable.
END
A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media
resource under common control with the already present media
resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multi-media
content. However, aggregating resources from different content are
likely to be refused by the server.
I had a lot of trouble sorting through this. Let me suggest some rephrasing,
to see if I understand; if you like the rephrasing, please take some or all of
it, correcting as needed:
NEW
When a SETUP request references an existing RTSP session but
identifies a new media resource, it is a request to add that media
resource under common control with the already present media
resources. This is called an "aggregated session". A client can
expect this to work for all media resources under RTSP control
within the same multi-media content, but attempts to aggregate
resources from different content are likely to be refused by the
server.
END
The RTSP session as aggregate is
referenced by the aggregate control URI, even if the RTSP session
only contains a single media.
I couldn't figure this out at all; can you try rephrasing it, please?
-- Section 2.3 --
The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6).
Where is the value in making up alternative things to call these operations?
Why not just call them "Play" and "Pause", to match the method names? Having
"Halt" and "PAUSE" mean the same thing only seems to invite confusion, no?
The support for positioning/searching within a content depends on the
In plain English, "content" is a collective noun, and can't really have an
indefinite article with it. I suggest that changing "a content" to "media
content" (or "a content stream") will work, and I suggest that you make sure
the document is consistent with respect to that usage.
These are expressed using
one or several independent attributes. A first attribute is Random
Access, which expresses if positioning can be done, and with what
granularity.
Using "one or several" is a bit oddly phrased, and one is likely to read it as
"one OF several." Perhaps, "using one or more independent attributes,"
expresses what you mean?
Then, how can one have random access without being able to do positioning? So
is "IF positioning can be done" really correct?
-- Section 2.5 --
The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with
RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP
connection.
The first sentence says that media delivery doesn't happen through RTSP. The
second sentence seems to say that RTSP can deliver media (it appears to be a
third option). Which is it?
-- Section 2.5.1 --
Scale = 0 is equal to pause and is not allowed.
If it's not allowed, it's not equal to anything. I suggest just saying, "Scale
= 0 is not allowed."
An example
is fast forward where only the independently decodable intra frames
are included in the media stream.
What are "intra frames"?
-- Section 2.7 --
o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
change. A new version of the protocol must be registered through
an IETF standards track document.
Which is, clearly, what you're doing with this document. It would probably be
good to stress that doing this is really a last resort and is extremely
disruptive to deployed products. It should only be used when the designed
extension mechanisms have failed.
-- Section 3.1 --
Since a few of the definitions are identical to HTTP/1.1, this
specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification ([RFC2616]).
Ah, but 2616 is about to not be the current HTTP/1.1 specification; the httpbis
set is likely to be approved by the IESG before this RFC is published. It
would be nice to refer to the httpbis set of updates instead, but that would be
too disruptive. I guess just take out the word "current", please.
-- Section 4.4.2 --
The syntax is based on ISO 8601 [ISO.8601.2000]. Two different
notations are allowed. The npt-hhmmss notation are using a ISO 8601
extended complete representation of the time of the day format
(Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators
between hours, minutes and seconds (hh:mm:ss). With the exception
that it expresses duration since presentation start rather than time
since midnight and the hour counter is not limited to 0-24 hours,
instead up to nineteen (19) digits of hours are allowed. ISO 8601
time format requires all digits to be used for each format, and all
format required needs to be included, e.g. if one use a hh:mm:ss
format, then that requires two digits for hours, two digits for
minutes and two digits for second, a time value such as 7 minutes and
0 seconds, is expressed as 00:07:00. The npt-sec notation is
expressing the duration since presentation start in seconds, using
one to nineteen (19) digits. Both notations allows decimal fractions
of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with
the limitation of at maximum of 9 digits and only allowing "." (full
stop) as separator. Due to RTSP 1.0 and the fact that the highest
values are expanded beyond two digits, all implementations MUST allow
the highest value to be single digit and SHALL NOT send leading zeros
for hours in the npt-hhmmss notation and leading zeros for seconds in
the npt-sec notation. The hours and the seconds in the npt-hhmmss
notation SHALL be sent using leading zeros, but receivers SHALL
accept values without leading zeros.
This is too long to have in one block, combines too many things, and has some
grammatical problems that make it hard to cope with. May I, please?:
NEW
The syntax is based on ISO 8601 [ISO.8601.2000] and expresses
the time elapsed since presentation start, with two different
notations allowed:
o The npt-hhmmss notation uses an ISO 8601 extended complete
representation of the time of the day format (Section 5.3.1.1
of [ISO.8601.2000]) using colon (":") as separators between
hours, minutes and seconds (hh:mm:ss). The hour counter is not
limited to 0-24 hours; up to nineteen (19) digits of hours are
allowed.
In accordance with the requirements of the ISO 8601 time format,
the hours, minutes, and seconds must all be present, with two
digits used for minutes and for seconds, and with a least two
digits for hours. An NPT of 7 minutes and 0 seconds is
represented as "00:07:00", and an NPT of 392 hours, 0 minutes,
and 6 seconds is represented as "392:00:06".
o The npt-sec notation expresses the time in seconds, using between
one and nineteen (19) digits.
Both notations allow decimal fractions of seconds as specified in
Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and
allowing only "." (full stop) as the decimal separator.
END
OK, now that leaves this bit at the end, which conflicts with some of what's
above and even with itself (you said "00:07:00" above, and now you say no
leading zeroes in hours, and then you say SHALL use leading zeroes; which is
it?), and which doesn't make much sense to me anyway (what does "Due to RTSP
1.0" mean, for example?):
Due to RTSP 1.0 and the fact that the highest
values are expanded beyond two digits, all implementations MUST allow
the highest value to be single digit and SHALL NOT send leading zeros
for hours in the npt-hhmmss notation and leading zeros for seconds in
the npt-sec notation. The hours and the seconds in the npt-hhmmss
notation SHALL be sent using leading zeros, but receivers SHALL
accept values without leading zeros.
I'll leave that part for you to re-word, because I can't hope to do it right.
-- Section 4.7.2 --
The following different media retention policies
are envisioned and taken into consideration where applicable:
What is that meant to be saying, really? Please rephrase it (I have no idea
what "and taken into consideation where applicable" might mean).
Time-Duration: Each individual unit of the media will be retained
for the specified duration.
What does "each individual unit of the media" mean?
-- Section 4.7.3 --
Dynamic: Between explicit updates the media content will not change,
but the content may change due to external methods or triggers,
such as playlists.
This sounds like doubletalk: it won't change, but it may change. I think it
needs re-wording.
-- Section 4.7.4 --
It may be updated at
any point in the content due to content consisting of spliced pieces
or content being dynamically updated by out-of-band mechanisms.
I'm not sure what this is trying to say, but I *think* you mean this:
NEW
The list may be updated at
any point in the content, because the content may consist of
spliced pieces or may be dynamically updated by out-of-band
mechanisms.
END
-- Section 4.7.5 --
It appeas that you're mixing example headings (which contain colons) on the
same line as header fields (which contain colons), making the whole thing
unclear. If I'm right, I think this sort of presentation would work lots
better:
OLD
On-demand: Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: Unlimited or Time-Limited.
Dynamic On-demand: Random Access: Random-Access=3.0, Content
Modifications: Dynamic, Retention: Unlimited or Time-Limited.
Live: Random Access: No-seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0
Live with Recording: Random Access: Random-Access=3.0, Content
Modifications: Time-Progressing, Retention: Time-Duration=7200.0
NEW
Example of "On-demand":
Random Access: Random-Access=5.0, Content Modifications:
Immutable, Retention: Unlimited or Time-Limited.
Example of "Dynamic On-demand":
Random Access: Random-Access=3.0, Content
Modifications: Dynamic, Retention: Unlimited or Time-Limited.
Example of "Live":
Random Access: No-seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0
Example of "Live with Recording":
Random Access: Random-Access=3.0, Content
Modifications: Time-Progressing, Retention: Time-Duration=7200.0
END
-- Section 5 --
Requests contain methods, the object the method is operating upon and
parameters to further describe the method.
You switch from plural to singular after the first comma. Assuming that each
request contains a single method, this is better:
NEW
A request contains a method, the object the method is operating upon,
and parameters to further describe the method.
END
(Side question: This implies that every method has an object; is that correct?)
-- Section 5.1 --
RTSP messages consist of requests from client to server, or server to
client, and responses in the reverse direction.
I would say that RTSP *sessions* consist of requests and responses. RTSP
messages don't consist of requests and responses: they *are* those requests and
responses:
NEW
An RTSP message is a request from a client to a server or from a
server to a client, or a response in the reverse direction.
END
In the interest of robustness, agents MUST ignore any empty line(s)
received where a Request-Line or Response-Line is expected. In other
words, if the agent is reading the protocol stream at the beginning
of a message and receives a CRLF first, it MUST ignore the CRLF.
What's a "Response-Line"? I also presume the last sentence above is applicable
recursively (you want to ignore any number of leading CRLF sequences), yes?
Might be good to be clear about that.
-- Section 8.2 --
A new or experimental
header MAY be given the semantics of response-header if all parties
in the communication recognize them to be a response-header.
This seems an incorrect use of 2119 MAY... It is not describing an optional
protocol feauture. I'd make it "can", in this context.
-- Section 9 --
Request and Response messages MAY transfer a message body, if not
otherwise restricted by the request method or response status code.
This is a trickier one, but is really *not* a 2119 MAY: it's not a purely
optional thing for a message to transfer a message body. It either does, or it
doesn't, based on what the message is doing. But if a particular nessage uses
a message body, that can't be omitted as an implementation option.
This statement needs to be re-worded to reflect the actual requirement here. I
think "Some Request and Response messages include message bodies," is
sufficient. If you want, it'd be reasonable to add, ", depending upon the
request method and response status code."
You'll similarly need to dispose of the MAY in the first sentence of the second
paragraph. The rest of the MAYs in that paragraph look correct: they truly are
describing optional behaviour.
-- Section 9.3 --
HTTP and email have both historically had horrendous problems with inaccurate
or missing Content-Type headers. It's good that you use MUST for Content-Type;
that has to help. I would be happier (though not at DISCUSS level) if you
should say a few more words about Content-Type here: something about how it
MUST accurately specify the type and subtype of the content, that there are no
defaults for type or subtype, and that attempts to use heuristics to
second-guess this are Very Bad.
I have reviewed this text solely looking for impact on the routing system and see no such impact.
I'm not going to be able review this one in time sorry
draft-ietf-ccamp-gmpls-ospf-g709v3
The security considerations section here seems like a cut and paste from rfc 3630, which is referred to from here. But 3630 does not actually seem to "suggest mechanisms" so the reference seems wrong and when in any case did "suggestion" become a useful form of specification? This reads as if the minimum cursory amount of text that might satisfy was added. Having said that, I don't have time to analyse this sufficient to turn this into a discuss-worthy point, so I'm committing the same sin with this cursory comment.
There is continued discussion of the modifications from the Gen-ART review. I'm not sure if the IANA change has been implemented. Please check the mail thread!
-- Section 1 -- Routing information for Optical Channel Layer (OCh) (i.e., wavelength) is beyond the scope of this document. Is "i.e." correct here? Is wavelength the only factor? -- Section 2 -- For example, if a multiplexing or example a multiplexing hierarchy like the following one is considered: This doesn't make sense. Is there a copy/paste error in there? -- Section 4 -- In contrast with most usage, we don't usually expand "IEEE". I actually found it quite odd to see it done. "IEEE floating point format" should be fine. -- Section 4.1.1 -- The values of the fields shown in figure 4 are explained in section 4.1.3. That should be "figure 3". -- Section 9.1 -- You should have a note to the RFC Editor to replace the "TBA by IANA" in Section 4. -- Section 9.2 -- You should have a note to the RFC Editor to replace the "TBA by IANA" in Section 4.1.
with resecept to stephens comment, it seems unlikely that noodling with the security considerations text will have any effect at all on the outcome. I can live with it as written
draft-ietf-netext-pd-pmip
DISCUSS item 1: In 3.2.2, paragraph 2, the text doesn't really describe what's happening in the diagram. Not only is this a usability issue for vision-challenged readers, you're glossing over some very weird behavior here. I would suggest the following change: OLD: Once the mobile access gateway gets the set of delegated prefixes from the delegating router function running on the local mobility anchor, it conveys it in a proxy binding update. This ensures that the local mobility anchor properly routes the traffic addressed to the delegated prefixes via the PMIPv6 tunnel established with the mobile access gateway, and that mobility is provided to these prefixes while the mobile router roams within the PMIPv6 domain. NEW: If the client did not request Rapid Commit, or the LMA doesn't support it, the relay agent on the MAG will behave normally in accordance with RFC 3315 in handling the Advertise message from the DR and the Request message from the RR. However, the MAG does not strictly follow RFC3315 in its handling of the Reply message. When the MAG receives the DHCPv6 Reply message from the LMA, it extracts the DMNP from the Reply message and sends a PBU to the LMA containing the DMNP from the Reply message. When the PBA comes back from the LMA containing the DMNP, the Reply message is forwarded to the client. I realize that the intention here was to gloss over this and leave it for the interworking stuff that isn't specified in this document, but what you are doing to the relay function in the MAG here is sufficiently weird that I think you need to call it out explicitly. You can resolve this DISCUSS item by making the change I've proposed above, or explaining why that's not the right thing to do. I am also concerned that you haven't accounted for any of the things that can go awry during this process, but I am reluctant to demand that you fully flesh out the interworking, and that is what you would have to do to address this problem. You do not need to address this point to clear the DISCUSS, but I'm mentioning it here because it concerns me and is related to the first DISCUSS item. DISCUSS item 2: I'm noticing in 5.1.3.2 that you are talking about IPv4 prefixes, but of course RFC3633 does not support IPv4 prefixes. What's the intention here? To resolve this DISCUSS item you need to explain what was intended here and possibly negotiate a fix. DISCUSS item 3: You never talk about how the identity of the MR that is presented over DHCPv6 will be correlated with the identity of the MR that is presented over PMIPv6. This seems like an important detail. Have you thought about it? Why isn't it described here? To resolve this DISCUSS item, you need to answer these questions and possibly add some text, with which I will be happy to help.
In Section 1, paragraph 1, this isn't a complete sentence:
In this context, the mobility management support that
is enabled for an individual IP host, which is the mobile node.
I don't know what was intended here, but please figure it out and fix it. :)
The use of the term "mobile network" to mean the network that is moving around
is _really_ confusing. I get why you chose this terminology, but every time I
see "mobile network" I think of the upstream network, rather than the
downstream network.
In 3.2.1:
The Advertise and Request messages are optional, and they
are not used if a two message client-server exchange is used.
This is a really vague way of saying something that is sort of true. The
right way to say this is:
If the requesting router includes a Rapid Commit option in its
Solicit message, it is preferable that the MAG respond directly
with a Reply rather than with an Advertise message, as described
in RFC 3315, Section 17.2.3.
In 3.2.2 paragraph 2, the relay agent behavior is described in RFC 3315, not
RFC 3633.
In 4.1, given that at least 8 of the sixteen bits of the DMNP are going to be
zero, wouldn't it make sense to only include the bits that are included in the
prefix length, and default the rest to zero?
In 5.1.3.1:
o In case the Proxy Binding Update signaling with the local mobility
anchor is not completed successfully, for example because the
local mobility anchor is not authorized for delegated mobile
network prefix or the requested prefix is in use, the DHCPv6
Delegating Router will send a Reply message to the Requesting
Router containing the IA_PD with the lifetimes of the prefixes in
the IA_PD set to zero.
This text only makes sense after the MR has successfully gotten a prefix
delegation. Before that, there won't be any prefixes in the IA_PD. You
would do better to just defer to RFC 3633:
o In case the Proxy Binding Update signaling with the local mobility
anchor is not completed successfully, for example because the
local mobility anchor is not authorized for delegated mobile
network prefix or the requested prefix is in use, the DHCPv6
Delegating Router will send a Reply message to the Requesting
Router with no IA_PREFIX suboptions and with a Status Code
option as described in RFC 3633, section 11.2.
The same advice applies to the equivalent paragraph in 5.1.3.2.
Next paragraph:
The standard DHCPv6 considerations will be applied with respect to
the interactions between the Delegating Router and the Requesting
Router. The Delegating Router is provided with the delegated
prefix(es), which can then be then advertised in the mobile network,
and therefore used by the locally fixed nodes to auto configure IP
addresses allowing to gain access to the Internet.
The last sentence should probably start with "The Requesting Router," since
it's the requesting router that's in the MR, not the delegating router.
I'd like to be able to use an MR that can do this, so thanks for working on this. I expected to see a security consideration to the effect that there could be DoS issues e.g. for the LMA caused by a large set of LFNs being behind an MR. Doesn't something like that warrant a mention?
From the ops-dir review I don't see these as blockers but I'd like to seem some dicussion on them, thanks. ... However, the document doesn't provide much guidance in general in terms of logging/reporting. For e.g., in Section 5.1.2 Signaling Considerations - Is there a mechanism to inform the mobile router with some status in the event that the MAG receives a REQUESTED_DMNP_IN_USE or NOT_AUTHORIZED_FOR_DELEGATED_MNP message? ... Also, in some cases it is not clear if packets should be silently discarded (e.g. section 5.1.4 Packet Forwarding) or logged and discarded. I'd imagine that the latter might be beneficial from an operational point of view. Not sure if there was any discussion regarding this. ...
draft-ietf-ecrit-unauthenticated-access
The abstract is too long to be useful—it's more like an introduction. It's a little late to be correcting that now, but I'd like the authors to consider it. You could probably winnow it down to something like this: This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. You might need more than the above, but surely you don't need four paragraphs. Of course, if you make a change along these lines, you will need to define some of the terminology now defined in the abstract in the terminology section instead. Introduction, paragraph 2, this sentence doesn't make sense: Roughly speaking, the IETF emergency services architecture (see [RFC6881] and [RFC6443]) divides responsibility for handling emergency calls between the access network (ISP), the application service provider (ASP) that may be a VoIP service provider (VSP) and the provider of emergency signaling services, the emergency service network (ESN). Are you possibly missing an "and" after the last comma? The sentence starts off fine, but I can't tell what the last dependent clauses is trying to do. Section 5, second bullet, it might be worth exploring a bit further how DHCP happens in this case; it's not unusual for an ISP to configure a DHCP server to only communicate with known clients. Also, is this an IPv4-only document, or is this intended to also work for IPv6 networks? If so, shouldn't SLAAC be mentioned as well? Cool stuff, thanks for working on it!
If you resolve Pete's discuss by making this informational most of my discuss points will become comments. (1) section 5.1.1, says you MUST use DHCP all the time to ever make an unauthorized emergency call (to get the LoST server address). That seems wrong. Why can't a static IP host get an emergency call? Did the WG consider this? (2) Given (1) above and the fact that the note commented on below implies that this spec is somewhat speculaive, should this one be experimental and not standards track? (3) If the l2 solution from section 6 works, then why is anything else needed? (4) Section 6.2 - what is there here that could be implemented that would give interop? This seems like a hodge-podge of possible ways of attaching to a network, none of which are sufficiently detailed here.
- The note at the end of p4/start of p5 seems odd to me. I'd say delete it. - section 6: expand acronyms please, e.g. STA, NAI
I don't understand how this document is appropriate for standards track. It strikes me as almost entirely Informational. Sections 1 & 2 are introductory and definitional. Section 3 lays out the use case categories, but doesn't introduce any new protocol. It simply points to sections 4, 5, and 6. Section 4 says that it is only describing the regulatory environment, and section 6 describes itself as non-normative. In fact, it's not clear to me why the discussions in section 4 & 6 are within charter for the WG. The only "normative" text in this document appears in section 5, but it does not appear to me to be normative with regard to protocol. For example: 5.1.1. LoST Server Discovery The end host MUST discover a LoST server [RFC5222] using DHCP [RFC5223]. 5.1.2. ESRP Discovery The end host MUST discover the ESRP using the LoST protocol [RFC5222]. As far as I know, both of those are technically not true. An end host could just as easily have a pre-configured LoST server for these purposes, or might discover the ESRP out of band. There is no protocol requirement for these steps. There *may* be a policy/regulatory reason to perform those steps, but that's not a proper part of a standards track protocol document, certainly not with "MUST" in front of them. If the claim is that a host MUST do these things in order to be compliant with 6881, that's also not a proper use of "MUST", and is not a protocol requirement. In it's strongest interpretation, this section is all operational guidance, not appropriate for standards track. But overall, I think this document should be Informational, and the "normative" language should be removed.
-- Abstract --
With features provided by the Public Switched Telephone Network
(PSTN) there is precedence for some of these use cases
That should be "precedent", not "precedence".
-- Section 1 --
New devices and services are being made
available that could be used to make a request for help, which are
not traditional telephones, and users are increasingly expecting them
to be used to place emergency calls.
That's awkward. Making it, "those devices are not traditional telephones" will
fix it.
divides responsibility for handling
emergency calls between the access network (ISP), the application
service provider (ASP) that may be a VoIP service provider (VSP) and
the provider of emergency signaling services, the emergency service
network (ESN).
Also awkward. I can't figure out how many items are in the list, nor where
they're divided. I *think* you want this:
NEW
divides responsibility for handling
emergency calls among the access network (ISP); the application
service provider (ASP), which may be a VoIP service provider (VSP);
and the provider of emergency signaling services, the emergency
service network (ESN).
END
We distinguish between three conditions:
Total nit: Between two, but "among" three or more.
These three cases are not mutually exclusive. A caller in need for
help may find himself/herself in, for example, a NAA and NASP
situation, as explained in more details in Figure 1.
Total nit: "himself/herself" is really awkward, and, oh, so unnecessary. Try:
NEW
These three cases are not mutually exclusive. A caller in need of
help may, for example, be in a NAA and NASP situation, as explained
in more detail in Figure 1.
END
-- Section 3 --
On a very high-level, the steps to be performed by an end host not
being attached to the network and the user starting to make an
Does "not being attached" mean "that is not attached"? If so, please change
it, for better English.
-- Section 6 --
since the relationship to the IETF emergency is only indirect, namely
via some protocols developed within the IETF (e.g., EAP and EAP
methods) that require extensions to support this functionality.
"to the IETF emergency"? Something missing here (maybe "services
architecture")?
-- Section 6.2 --
The details
are incorporated into the not yet published 802.11-2011
specification.
Given that 802.11-2012 has bee published:
http://standards.ieee.org/findstds/standard/802.11-2012.html
...I'm skeptical of this statement. Care to amend it?
In one case (e.g., WiMAX) an EAP method is performed. However, no
credentials specific to either the server or the device or
subscription are used as part of the authentication exchange. An
example for this would be an EAP-TLS exchange with using the
TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly
available static key for emergency access could be used. In the
latter case, the device would need to be provisioned with the
appropriate emergency key for the IAP/ISP in advance. In another
case (e.g., IEEE 802.11), no EAP method is used, so that empty
frames are transported during the over the air IEEE 802.1X
exchange. In this case the authentication state machine completes
with no cryptographic keys being exchanged.
The "in one case, e.g." and "in another case, e.g." stuff reads very oddly.
Further, the whole paraagraph seems raambling and not fully connected. I'm not
really cleaar about what you're trying to say. Please re-word this.
at least the device identity (e.g.,
the MAC address) can be authenticated
Again, I wonder about the "e.g.": either you mean that the MAC address *is*
what identifies the device, in which case you should just drop the "e.g.,", or
you mean that the MAC address is one way to determine the device identity, in
which case you should word it differently, perhaps as, "at least the device
identity (determined by a mechanism such as the MAC address) can be
authenticated". As it's written, it's not at all clear which you mean.
-- Section 7 --
If the ISP runs its own LoST
server, it would maintain an access control list including all IP
addresses contained in responses returned by the LoST server, as well
as the LoST server itself. (It may need to translate the domain
names returned to IP addresses and hope that the resolution captures
all possible DNS responses.)
What is "it" in the parentheses? The ISP? The LoST server? The access
control list? Please replace "it" with something specific.
Finally, a number of security vulnerabilities discussed in [RFC6280]
around faked location information are less problematic in the context
of unauthenticated emergency since location information does not need
to be provided by the end host itself or it can be verified to fall
within a specific geographical area.
I'm having trouble understanding the point here, perhaps because of the long,
run-on sentence. Can you try re-wording this, please?
I would be OK publishing this doc as Informational, if that's where Pete's discussion ends up. I'm not wild about publishing an emergency services spec as Experimental unless we think there's an actual experiment happening someplace. I have a couple of questions I'd appreciate help with. In this text: 5.1.4. Emergency Call Identification To determine which calls are emergency calls, some entity needs to map a user entered dialstring into this URN scheme. A user may "dial" 1-1-2, 9-1-1, etc., but the call would be sent to urn:service:sos. This mapping SHOULD be performed at the endpoint device. could you help me understand why a SHOULD is appropriate? Is there a good reason a conformant implementation wouldn't do that, or is this text trying to accommodate legacy implementations that don't do the mapping now? I may be more confused than usual because I'm not sure whether this text means "[SHOULD be performed] at the endpoint", or "SHOULD be [performed at the endpoint] if it's performed at all". In this text: 5.1.5. SIP Emergency Call Signaling Regarding callback behavior SIP UAs SHOULD place a globally routable URI in a Contact: header. is this text specifically asking for the GRUU mechanism defined by RFC 5627, or something broader? If you told me there were good reasons why this is a SHOULD and not a MUST, I'd believe you, but if this really is a SHOULD, giving some examples of why not doing this makes sense would be helpful. Are there good reasons that you wouldn't provide a callback URI, or is the text accommodating legacy gear that doesn't do this now?
Color me supportive of the DISCUSS points raised by Pete and Stephen.
5.2.2. Location Determination and Location Configuration The ISP is responsible for location determination and exposes this information to the end points via location configuration protocols. The considerations described in [RFC6444] are applicable to this document. This assumes a level of coordination which might exist, but may not. there's a significant level of un-coordination here if you in fact cannot expose this.
draft-ietf-mmusic-duplication-grouping
3.1: The "a=group:DUP" semantics MUST be used to group the redundant streams except when the streams are specified in the same media description, i.e., in the same "m" line (See Section 3.2). Don't you mean "is" instead of "MUST be"? I don't understand what the MUST means in this context other than "is". 3.1 & 3.2: ...the order of the listed redundant streams does not strictly indicate the order of transmission, although it is RECOMMENDED that the stream listed first is sent first, with the other stream(s) being the (time-delayed) duplicate(s). Is there any downside to doing them out of order (or any upside to doing them in order)? If yes, why isn't it a MUST? If no, why the RECOMMENDation?
In his OPS-DIR review, Fred summarizes pretty well the operational impacts stemmed from this specification. I would be worth the extra couple of paragraphs IMHO. A new section "operational impact" would be ideal. For completeness, Fred's review is included below: The operational impacts of the duplication mechanism (which is in use operationally, if I'm not mistaken) are three-fold: - impact on total traffic load - impact on routing - impact on receiving system The impact on traffic load is obvious: if I duplicate every packet among a set of packets, I double its total traffic load. The impact on routing is somewhat glossed over by the document, although it is hinted at in comments about using different addresses and so preferring different routes in at least parts of the path. Sending separate packet streams that use the same route subjects all of the traffic streams to the same set of potential failures; if a packet from stream 1 is subject to loss at a congested interface or a place where routing is unstable, so will its counterpart in stream 2. If a given interface en route is heavily loaded, doubling a component of its service load won't reduce that. An important characteristic of these separate streams, therefore, is disjoint routing, and ideally routing along paths unlikely to experience simultaneous failures (e.g., using different lambdas in the same fiber doesn't help if the fiber is cut). The impact on the receiving system is that something one might consider architecturally unusual, such as duplication or reordering of packets and the implied processing, suddenly becomes normal. Duplication is obvious. Reordering would happen when traffic on one stream consistently arrives earlier than that another, and a packet is lost on the first. The arriving packet on the second stream will be perceived as a packet out of order. One can hopefully expect RTP's application to recognize the matter and resolve it, but it would be nice if that could happen as early in packet processing as possible. So one has an increased interrupt and processing load on the receiving system, and the algorithms used to deal with duplicated or reordered traffic may need tuning. I don't know that I would request any changes to the document. If I did, it would be to highlight these issues and point to other RFCs or operational procedures that could be used to mitigate them.
-- Section 3.3 -- (1) with an answer that ignores the grouping attribute or (2) with a refusal to the request (e.g., 488 Not Acceptable Here or 606 Not Acceptable in SIP). SIP? Or should that be "SDP"?
draft-ietf-mmusic-delayed-duplication
Section 1: "Furthermore, delayed duplication must not be used in cases where the primary cause of packet loss is congestion" Like Benoit, I agree that this sentence is confusing. Do you really mean something like the following? """ Delayed duplication (or duplication at all) is harmful in cases where the primary cause of packet loss is congestion, rather than network than a network outage due to a temporary link or network element failure. Duplication should only be used by endpoints that want to protect against network failures; protection against congestion must be achieved through other means. """
This may be obvious to SDP folks but if the media are cryprographically processed does the duplication happen before or after the crypto? I assume its before, as it'd otherwise be a layering pain. Is that right? Anyway, the discuss is: has someone looked at how this might interact with security for media? For example, did anyone think about whether this kind of duplication could give an attacker who could manipulate the SDP but not the media an advantage since that attacker could affect the plaintext in deterministic ways. Or if SDES is used with a human memorable string as a key and if the media were essentially random, then this would give a dictionary attacker a nice quick way to verify guesses of the key. I'm not sure what security considerations text ought be added though, since you'd want someone who's much more familiar with SRTP options etc. to have done that analysis first. And the answer might come out the same as well - that there's no real change worth noting.
- The ABNF allows for infinite numbers of delays and infinitely large delays. Wouldn't it be better to limit both? - The fact that "a=duplication-delay: 50 100" means that the 2nd re-tx is 150 ms after the initial tx is only explained in the 2nd example and you never say that otherwise. That could lead to interop problems since my initial assumption would have been that the 2nd re-tx would be 100ms after the initial tx for the above example. I think you should say something about that in section 3. - What if the delay indicated is less than a packet, say if every packet has 20ms of media but 5ms is indicated in the SDP?
Furthermore, delayed duplication must not be used in cases where the primary cause of packet loss is congestion, rather than a network outage due to a temporary link or network element failure. Duplication can make congestion only worse. I'm missing something. What is the use case? I don't know of any operators who would say: I know I have some temporary link or network element failures, but this is not my absolute highest priority, so let me focus on this mmusic-delayed-duplication trick instead. Also, what kind of temporary link or network element failure would be solved below a reasonable duplication delay, where my guess is that we speak about seconds, right? I see that you wrote: In this specification, we are not concerned about how the sender should determine the duplication delay. Bottom line: from an operation point of view, I have no clue when to apply this specification.
1. Compared to draft-ietf-mmusic-duplication-grouping, do I understand correctly the packets are sent over the same path in this document, and across different ones in draft-ietf-mmusic-duplication-grouping? If yes, please specify it. 2. Like https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping/ballot/#benoit-claise, the equivalent section in both drafts would be ideal. Note that the answer to the point 1 will determine if "The impact on routing" should be present. I guess no. 3. "In the second example below, the multicast stream is duplicated twice." Duplicated twice seems funny, at least with my French speaking background.
-- Section 3 -- Where does the new ABNF production, "delaying-attribute", fit into other ABNF? Should this be extending an existing ABNF element to add "delaying-attribute" as a new possible value (from a formal ABNF point of view)? Is a dupliation delay of 0 semantically valid?
I think that this draft needs to provide guidance on appropriate use cases. I can imagine some, for example during mobile device handover, but I think the authors really need to discuss or otherwise refer to the use cases, and describe how the sender knows that it is in a situation where it should burn the additional network bandwidth using this method.
draft-ietf-sidr-origin-ops
I support the publication of this document. The rest of this Comment is pointless nits: --- Please expand CRL on first use. --- s/an hierarchic/a hierarchic/ (although qualifies for :-) --- Section 3 "seriously affects the performance" is ambiguous. Of course... s/affects/improves/ --- Page 4 For redundancy, a router SHOULD peer with more than one cache at the same time. Peering with two or more, at least one local and others remote, is recommended. Upper case RECOMMENDED? --- Page 6 An environment where private address space is announced in eBGP the operator MAY have private RPKI objects which cover these private spaces. This will require a trust anchor created and owned by that environment, see [I-D.ietf-sidr-ltamgmt]. In an environment.... ?
- Nice bcp, thanks. I like that you flag that it'll evolve in the abstract. - section 5, 5th last para: Does "the latter" here mean "NotFound or Invalid" or just "Invalid"? If it just means invalid, is there a danger this might cause someone to not acceopt NotFound announcements too soon?
Section 3: The document uses the phrase "validated cache" (and "valid cache") without defining what the word "validated" means in this context. If I understand correctly, the following text after "... rcynic [rcynic]." would be helpful to explain: """ A validated cache contains all RPKI objects that the RP has verified to be valid according to the rules for validation RPKI certificates and signed objects [RFC6487][RFC6488]. Entities that trust the cache can use these RPKI objects without further validation. """ Section 3: "... an operator MAY choose to synchronize quite frequently." In these comments on cache synchronization, it may be helpful to note that while synchronization with public caches is expensive (requiring validation), synchronization with a trusted validated cache is much cheaper. Section 3: "a router SHOULD peer with more than one cache" Just to be clear, you're talking about peering over the RPKI-RTR protocol, not rsync, right? Section 3: "all sub-allocations from that block which are announced by other ASs, e.g. customers, have correct ROAs in the RPKI" Note that the holder of the super-block can fix this problem, e.g., by issuing the necessary ROAs or issuing de-aggregated ROAs instead of a single one for the super-block. Do you mean to have the holder of the super-block be gated on customers? Or do you want to suggest one of these fixes?
I second Al Morton's OPS-DIR feedback: The effort to prepare this BCP should be greatly appreciated in the OPS community. Thanks Randy. Editorial: For example, a router should bootstrap from a chache which is s/chache/cache
This was a nice read; thanks for a clear, concise document.
Absolutely support the publication of this document. Just a few quick points... 1. Would the 2nd paragraph of the Introduction be strengthened with a reference to the IAB statement on the RPKI (http://www.iab.org/documents/correspondence-reports-documents/docs2010/iab-statement-on-the-rpki/)? 2. The use of 10.0.666.0/24 is classic. I hope it remains. 3. In section 6, I think the discussion of loosely consistent data could be enhanced. It may be worthwhile to mention that never-before-seen prefixes and ASes appearing in the routing system is not a common event. The growth rate of those two variables seem to indicate that the loose synchronization of RPKI caches should not be a problem.
draft-ietf-opsec-ip-options-filtering
This is a great document. Thanks for working on it!
Thanks for this document. I support its publication. --- I agree with Pete that the value of using RFC 2119 language in the "Advice" sections is questionable. For me it just disrupts the flow of the text and is somewhat ambiguous - what does it mean to advise that you MUST do something? But this is just my opinion. --- It is possible that some of your Informational references are really normative. For example, 6398 is used to define some terms that you use and also to describe some environments that you reference. This is not very important, but perhaps you could take a quick look at your references to see how you feel about them.
A question: Are router vendors already adopting these recommendations? If not, are we sure they're going to? That is, is this document aspirational or is the actual ops community on board with this? Overall editorial comment: It might have been nice if the "Advice" sections got reduced to one or two keywords. You could have defined up at the top of the document "DROP", "FORWARD", "CONFIGURABLE", "DEFAULT DROP", "DEFAULT FORWARD", "LOG", and then just used those terms. You could have even made a handy-dandy table of options and advice and saved people the read if they just wanted to take the advice without caring why. Also, I think the 2119 use in this document is unnecessary. You're only using "SHOULD" and "SHOULD NOT" throughout, and in all those cases you really mean "This is the best plan" or "This is not the best plan", not really what 2119 says. But it's up to the WG whether either of those editorial issues are worth addressing.
So I'm not sure if this really needs fixing but 4.23.1 notes that RFCs 1122 and 1812 say you MUST ignore unknown options, but 4.23.4 here says that you SHOULD have a configuration knob with a "drop & log" setting. If that knob is set to "drop & log" then that node would seem to no longer be compliant with 1122 or 1812. Yet this document doesn't update those, nor say why that's ok. Why is that ok? If even a small percentage of nodes turn that knob to "drop & log" wouldn't that mean that no new IPv4 option with very broad impact could ever be introduced in future?
- 4.12 and 4.13 seem to have a lot of duplicated text so it wasn't clear to me how they differed if at all.
We also note that while this document provides advice on dropping packets on a "per IP option type", not all devices may provide this capability with such granularity. Additionally, even in cases in which such functionality is provided, the operator might want to specify a dropping policy with a coarser granularity (rather than on a "per IP option type" granularity), as indicated above. Finally, in scenarios in which processing of IP options by intermediate systems is not required, a widespread approach is to simply ignore IP options, and process the corresponding packets as if they do not contain any IP options. The first paragraph speaks of device, while the second speaks of intermediate systems. So what's a device? I guess you only mean an intermediate system and not an end host, correct? I see later, for ex. in section 4.1.5 that you have advice for Routers, security gateways, and firewalls. Please expand in the intro what you have in mind with "device". For example: the advice in this document focus on routers, security gateways, firewalls As I conclude from ongoing discussions, this document targets operators and "routers, security gateways, firewalls" vendors. I also see that you want to add this paragraph below. Fine, but s/implementers/routers, security gateways, firewalls implementers + Finally, in addition to advice to operators, this document also + provides advice to implementers in terms of providing the capability + to filter packets with different granularities: both on a "per IP + option type" granularity (to maximize flexibility) as well as more + coarse filters (to minimize configuration complexity). - Section 4.6.5 Routers, security gateways, and firewalls SHOULD drop IP packets containing a Stream Identifier option. This option is obsolete. Either it's a MUST, or if you keep a SHOULD, then you should log the event if you see this option. We could debate what to do with "SHOULD drop" advice when the option is not obsolete (4.9.5, 4,11.5, and maybe others) but IMHO, the event must be logged. So the Routers, security gateways, and firewalls MUST provide the ability to log the event. Potentially a generic requirement - This option probably has more deployment now than when the IESG removed this option from the IETF standards-track. Can you please expand on this counter-intuitive observation.
One small editorial comment: -- Section 4.3 -- RFC 791 states that this option should appear, at most, once in a given packet. Both commas are spurious, and should be removed.
I wish we produced docs like this more often. Thanks for working on it. I agree with Pete that the 2119 language seems odd, but whatever works for him will work for me.
This is a useful piece of work. I only have two nit-like comments that you can take or leave... 1. The end of section 3 suggests that operators should take a device's IP options filtering capabilities into account when making deployment decisions. Should a similar statement be made that this document is focused on recommendations for vendors to provide filtering support/capabilities for IP options? 2. A little pedantic, but if an option is obsolete wouldn't its presence in a packet indicate a possible covert channel? If that is the case, options like the one described in 4.6 should have a covert channel listed as a possible threat.
From a purely historical point of view I think that the following is a little late: "From about 1995 onwards, a growing number of IP routers have incorporated specialized IP packet processing silicon (i.e., FPGA, ASIC), " The processing split that you are concerned about happened much earlier that this. For example Cisco launched the AGS+ using this forwarding model in1989, and thereafter it was pretty much the only way to design a high-speed router. The person that knows most about the history is Scott Bradner who provided the definitive router bench tests in those days and thus tracked the architectural changes in some detail. ============== However, at present, the particular architectural and engineering details of the particular IP router being considered are important to understand when evaluating the operational security risks associated with a particular IP packet type or IP option type. "important" or "not important"? ============== I am surprised that the advice for new implementations is not MUST drop the obsolete (and maybe experimental) options. There surely cannot be any of them in deployment by now. At the least it should surely be MUST default to drop. ==============
draft-ietf-avtext-multiple-clock-rates
- The secdir review [1] raised a question that wasn't afaik answered. I'm not sure if there's any change needed but be good to see an answer to that just in case. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04299.html
Should the abstract say another few words about *what* clarification is being made? Please expand "SSRC" and "SR packets" on first use. -- Section 3.1 -- This is not different than what happen at the beginning of the RTP session but it can be more annoying for the end-user. Can you say this a different way, so that it's more usefully explanatory? Or perhaps even omit it, if it doesn't really add anything. -- Sections 3.2.1, 3.2.2, and 4.2 -- I found myself looking for the tables. If you really don't want to include them in the sections that cite them, it would help to explicit say, "Table 2 in Appendix A" and so on. Though, as a reader, I'd rather see them inline, so I can refer to them without having to scroll to the bottom of the document and back. -- Section 4.1 -- To accelerate lip synchronization, the next compound RTCP packet sent Checking: is "accelerate" really the right word here? Just thinking in plain English, I don't thinking of lip synch happening at a rate of speed. "Facilitate", maybe?
In this text: 3.2.2. Non-monotonic timestamps The advantage with this method is that it works with the jitter calculation described in RFC 3550, as long as the correct clock rates are used. It seems that this is what most implementations are using. Is there a pointer you can include for "what most implementations are using"? I see that you mention SIPit later in the document - if this statement is based on Robert's summary from a specific SIPit, for example, I'd be fine with that.
draft-ietf-6man-oversized-header-chain
DISCUSS: RFC 1981: IPv6 nodes SHOULD implement Path MTU Discovery in order to discover and take advantage of paths with PMTU greater than the IPv6 minimum link MTU [IPv6-SPEC]. draft-ietf-6man-oversized-header-chain: Hosts MAY discover the Path MTU, using procedures such as those defined in [RFC1981] and [RFC4821]. So bug, or is the intend for this document to update RFC 1981?
1.
Please engage in the discussion for this one if you disagree.
Abstract
In those scenarios in which the IPv6 header
chain or options are unusually long and packets are fragmented, or
scenarios in which the fragment size is very small, the first
fragment of a packet may fail to include the entire IPv6 header
chain.
I was confused by or in "IPv6 header chain or options".
The options are the hop-by-hop and destination header options, right?
So these are part of the Extension Header, so the IPv6 Header Chain already, no?
Proposal:
OLD:
IPv6 header chain or options
NEW:
IPv6 header chain (including options)
Same remark for
This document updates the set of IPv6
specifications to create an overall limit on the size of the
combination of IPv6 options and IPv6 Extension Headers that is
allowed in a single IPv6 packet.
2.
OLD:
This specification allows nodes that drop the aforementioned packets
to signal such packet drops with ICMPv6 "Parameter Problem, IPv6
first-fragment has incomplete IPv6 header chain" (Type 4, Code TBD)
error messages.
NEW:
This specification allows nodes or intermediate systems that drop the
aforementioned packets to signal such packet drops with ICMPv6 "Parameter
Problem, IPv6 first-fragment has incomplete IPv6 header chain" (Type 4, Code
TBD) error messages.
3.
In section 4, it would nice to add: "not an issue for statefull middleboxes"
For this comment, take it or leave it
It's probably a good idea to put in an RFC Editor note that asks the RFC Editor to replace "TBD" in Sections 5, 6, and 7 with the value assigned by IANA, to mae sure they get all three occurrences.
Whilst I think this is a useful document, I found the security section a little strange. The authors make it clear that they reduce the security risk of the existing protocol. However normally a security section discusses any additional risk of deploying the technology compared to the base protocol, and it is not clear to me as a reader whether or not the author examined this aspect to the problem.
This is non-blocking ... How often does this happen? I'm asking because I'm curious if there's now going to be huge surge in ICMP error messages indicating discards. Also, I guess I'd reword this: Whether a host or intermediate system originates this ICMP message, its format is identical. to The format for the ICMP message is the same regardles of whether a host or intermediate system originates it.
observation that whatever tool generated this went over the top on page breaks to the point where it would be unreadable as formatted were it broken across pages.
draft-ietf-mile-sci
Two relatively easy-to-handle things, or at least I hope so:-) (1) Please define or refrain from using the term "cybersecurity" - I'm not just being pedantic here (I hope:-) the term is often used to mean different things. And please define "cyber attack" (used in the intro) as well. If you have a favourite definition then just pointing at that would be fine. (2) section 7: Is the content you suggest for the new registry actually conformant to the rules you're setting up? "xml" might syntactically be a hostname but "http://xml/..." is not really a good HTTP URI is it? And what if ICANN auction off "xml" as a gTLD? And what does "readily... available" mean? (Esp since one of the URIs you use is apparently not available at least for me, at least right now;-)
- section 3, last para: does this mean we're putting up IODEF as an alternative to NEA and/or SACM? I think it'd be better to drop that use-case or if not to distinguish it from other IETF protocols that do the same thing. (Or maybe I'm confused?) - 4.1: I get weirdness when I try to de-reference the 1st reference URI [1], is that just me? I get a directory listing for the 2nd. [2] When I look at [2] and load the xsd file I find there, I don't find the string "AttackPattern." How is that IANA registry entry going to be useful? It confuses me mightily;-) [1] http://standards.ieee.org/develop/indconn/icsg/mmdef.html [2] http://grouper.ieee.org/groups/malware/malwg/Schema1.2/ - 4.1: I don't understand the last para at all - 4.3: s/This draft/This specification/ (Same thing at the start of section 5) - section 5: Are you really asking that receiver's do XML schema validation? You say "MUST be able to" which is not quite the same, but generally doing schema validation on the fly is very dangerous and error prone. Maybe you mean that they MUST be able to process inputs that conform to the relevant schema and fail-safe for other inputs that don't conform? But at what level? Say if an XML document is received that has a Remediation element with no SpecID - should the entire input Document be ignored or what? - section 6: "URGED" in caps is odd, and saying "areas of concern" but then only having one subsection seems odd too. - section 6 generally: I support Barry's discuss - section 6: Isn't this missing something about access control and filtering outbound documents? Maybe all that's needed is a reference to some other RFC, but won't it be common to do such authorization and filtering? - section 6: You mention signatures - do you mean use of XMLDSIG? If so, a reference would be good and it'd be even better to say which element might be signed, and to check that that element has an ID so the signature Reference can point to the to-be-signed data. - section 7: In the absence of a definition of Cybersecurity, I think its a bad idea to have an IANA registry with that term in the title. (Just a personal opinion.)
I note that the all-caps "URGED" in Section 6 is defined in neither RFC 2119 nor RFC 6169. Might it be better to say "RECOMMENDED" here?
I just have two small points, both of which should be easy to address. -- Section 5 -- The shepherd writeup is silent about review by any XML schema experts. How confident are we that the XML in here has had sufficient review? -- Section 6 -- I question whether what's here is sufficient. Yes, it's important to ensure confidentiality (etc.) of this sort of payload. But apart from that, are there really no security or privacy concerns involved with reporting such things as incident attack patterns, what software platform the attacks are being made on, what vulnerabilities were exploited by the attacks, and so on? Is there really nothing further to say here?
-- Section 1 -- The number of cyber attacks is growing day-by-day Nit: You're not using "day by day" as an adjective here, so you shouldn't hyphenate it. Similarly with "machine readable" in a few places: "machine-readable information", but "the information is machine readable". -- Section 4.5.1 --- It is recommended that Method class SHOULD contain the extension elements whenever available. 2119 usage point: "RECOMMENDED" and "SHOULD" mean the same thing, so why the lower-case "recommended"? Why not this?: NEW It is RECOMMENDED that Method class contain the extension elements whenever available. END This applies to subsequent sections, as well. You're inconsistent about whether you include "SHOULD", but you are consistent in lower-case "recommended", leaving me a little unsure. I prefer my version throughout, but whatevere you choose, please make it consistent.
I support Barry's DISCUSS points.
draft-ietf-ipfix-data-link-layer-monitoring
The wording in the Acknowledgements is a little odd. s/IPFIX members/IPFIX working group participants. --- Section 7 Surely the more granular the data that can be reported, the greater the risk of DoS attacks on a collection point. This document appears to significantly increase the data that could be reported by node and so increase the possiblitiy of congesting the collector through one (possibly accidental) configuration event. I think you should briefly mention this and highlight the mitigations.
Strangely, I agree there are no new security or privacy considerations here, even though I did expect there would be;-)
I've a few non-blocking comments that I'd like you to consider. Feel free to
chat with me about any of them if you want to. This is all editorial.
-- Section 1 --
While these innovations provide flexibility, scalability, and
mobility to an existing network architecture, it increases the
complexity of traffic measurement due to the existence of various
Ethernet header formats. To cope with this, a more sophisticated
method is required.
"they increase" the complexity. And a more sophisticated method of what?
Traffic measurement? Please say that: "a more sophisticated method of
[whatever] is required."
layer, e.g., Ethernet header forms. This document describes the
Information Elements related to data link layers that enable a more
sophisticated traffic measurement method.
Does this document only describe "the [existing] Information Elements"? Or
does it also define new IEs?
-- Section 2.2 --
Also, the lack of
management scalability and flexibility: increasing the number of VMs
Make it "Another is the lack of [...]".
-- Section 3.1.2 --
*However, when the sectionOffset field corresponding to this
Information Element does not exist, the octets MUST be from the
start of the data link frame.*
Take this or leave it (also in the various subsections of Section 4): What
you're really saying here is that the default for sectionOffset is 0, and I
think it's actually clearer if you say it that way (and, in fact, you do, in
Section 3.2.2):
NEW
* If no corresponding sectionOffset is present, an offset of
0 is used. *
END
-- Section 3.2.2 --
If multiple sectionOffset IEs are specified within a single
Template, then they apply to the packet section IEs in order. ie,
the first sectionOffset applies to the first packet section, etc.
The combination of "IE" and "ie" (which should be "i.e." (note that throughout
the document)) actually seems confusing, and isn't necessary. May I suggest
this?:
NEW
If multiple sectionOffset IEs are specified within a single
Template, then they apply to the packet section IEs in order:
the first sectionOffset applies to the first packet section,
the second to the second, and so on.
END
The "less" a couple of sentences later should be "fewer".
-- Section 8 --
I suggest that you add a note to the RFC Editor, reminding them to change all
the "TBDnn" notations in the document, according to the IANA allocated values.
Less likely to fall through the cracks if there's an explicit reminder.
I have no objection to the publication of this document, or the technical description of each IE. However the purpose of this document is to update or populate the IANA registry which is now the definitive repository of IPFIX IEs. Therefore for each entry there needs to be a one to one mapping between the items in the definition and the headings in the IPFIX registry. This mapping has not been provided for all items. Also where an entry is changed, an explanation needs to be provided for why the change was made together with text addressing any backwards compatibility issues, which hopefully is a note that there is no backwards compatibility issue.
status-change-adsp-rfc5617-to-historic
As Barry pointed out on the IETF list, there's been a good deal of "input" on the IETF list regarding this status change, so the IESG should be aware of that and see if any of the conversation concerns us. At this point, I am satisfied with Barry's call of the consensus, hence my YES. But folks should be aware of the discussion.
draft-ietf-appsawg-malformed-mail
Thanks for a useful document. I would have loved to have seen text about S/MIME and PGP issues, but I guess that might require another equally long document all by itself. It might well be worth looking though to see if there's a reference to which you could point that has relevant guidance about those. Separately, it might also be worth pointing out that some of the handling guidance you give if applied to some S/MIME or PGP messages is likely to break signatures or make decryption impossible. But those are just suggestions to take or leave, this is already useful enough as-is.
Nothing that would stop me from endorsing this document going forward, but please do take the following into consideration: 1.1 - The 5th paragraph seems redundant with previous paragraphs in this section. The last paragraph seems redundant with section 1.2. Suggest striking. 4 - It seems worth pointing out somewhere in this section that the prepending of Received fields is the safest thing to do if changes must be made to the message to pass information between modules. 7.1 - "A message using an obsolete header syntax" You might consider adding a direct reference to 5322 section 4 to define what's meant by "obsolete". 7.1.6 - Why is the second example not obviously better? I have a hard time imagining circumstances where an unterminated quoted-string that contains an angle-bracketed thing that looks like an addr-spec is in fact a local part. 7.4 - "acceptance grammar" is a weird construction, not used in 5322. Suggest "obsolete syntax" (with the reference to section 4) instead. 7.5 - Third paragraph: Reference to DKIM would be useful. Fourth paragraph: I find the word "enacted" a bit weird. I suggest changing "can be enacted" to "can be used" or "strategies can be used" What's the difference between 3 & 4? Or maybe I don't know what "compound instance" means in 3. 7.5.3 - What's the harm in more than one Return-Path? Only one of interest is the top-most. --- Finally, a gedankenexperiment, or maybe fodder for a real experiment: What would happen if, upon receiving a malformed message that was determined to not be otherwise malicious, a receiving SMTP system both returned a 5xx to the message *and* processed and delivered the message (i.e., give the receiver what they want, but push back on folks who generate crap)? Would it help? (I am not asking for a discussion of this in the document. Just an interesting thought.)
I quickly skimmed this draft and it looks fine to me. I'm balloting no objection, but I'm sure it would have been a YES had I had more time to review it - my fault mind you.
10 appears to have addressed many of the ops reviewers concerns. Thanks!
draft-ietf-nfsv4-labreqs
- general: some systems have a requirement that some labels are visible in clear, whereas others are encrypted, when passed over the network at least. Is that a requirement you want to impose/meet here? Either way, it might be good to say. - 3.2: s/Privacy/Confidentiality/ would be better here and elsewhere. - 4.3: the term foreign label is not used in 3.3 - 5.3: Whis is a US-specific section included here? Surely this ought be more international? This section should really be generalised or deleted. - 5.4: You could explain what "legal hold" means. I assume its where someone is suing someone and a court says "don't you go changing X" - is that right?
The case is well made without cases
5.3. International Traffic in Arms Regulations (ITAR) . . . . . 12
5.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13
Traditionally the IETF stays well away from such areas, are we sure we want to
make any comment on them in this text?
1) There's some SHOULDs in s3.2 that I'm not sure I follow: MAC security labels and any related security state SHOULD always be protected by these security services when transferred over the network; as SHOULD the binding of labels and state to associated objects and subjects. If a system doesn't provide the services to keep the binding between the label and the object or the user's identity and it's privileges how are you going to get MAC to work? 2) s3.3: I think it's noble that clients reject anything it doesn't understand, but I gotta admit that if I was a bad guy I'd kind of ignore that requirement and keep on accepting whatever data I wasn't supposed to get. Would a better requirement be to check that before allowing access a common policy MUST be negotiated? Oh wait that's in s3.4 - should the concept of before allowing access be worked in to s3.4? 3) s3.5: I don't follow why this isn't a MUST: The server is allowed to translate the label but SHOULD NOT change the semantic meaning of the label. If the server changes the semantic meaning of the label will the client still know what it means and then doesn't that conflict with an earlier requirement: a security label MUST always mean exactly the same thing on every system. Doesn't it have to be "MUST NOT change the semantic meaning of the label"?
0) Note RFC 4949 has a definition for MAC that you might refer to. 1) In s3.1, there is a discussion about the security attribute of the subject. Isn't this more commonly referred to as the client's privileges? And it might make sense to add this to the Definitions section. 2) s3.1 #4: Ever heard of a SPIF or looked at ISO 15816? The were attempts to do just that. 3) s4: Reads a little awkward: Labeled NFS SHOULD support that the following security services are provided for all NFSv4.2 messaging. These services may be provided by lower layers even if NFS has to be aware of and leverage them: maybe: Labeled NFS or the underlying system on which the Labeled NFS operates SHOULD provide the following security services for all NFSv4.2 messaging: 4) s3.2: Could you better define strong mutual authentication - is that certificate-based mutual authentication? Or is it that MD5-based security shouldn't be used ;) Also: r/will be required/is required 5) s3.3: Instead of: MAC models base access decisions on security attributes bound to subjects and objects. I would have said: MAC models base access decisions on security attributes and privileges bound to objects and subjects, respectively. 6) s3.3: I'd probably add the following to the end of this sentence: With a given MAC model, all systems have semantically coherent labeling - a security label MUST always mean exactly the same thing on every system. add: because otherwise the label cannot be properly interpreted. 7) s3.3: What does the "this" in this sentence refer to the binding of stuff to objects/subjects or to having labels mean the same thing: While this may not be necessary for simple MAC models it is recommended that most label formats assigned an LFS incorporate this concept into their label format. 8) (no action required) s3.3: I think you're more likely to get weighed down by corner cases than a global scheme :)
Comments from mehmet during the ops dir review. ** The document lacks an IANA Considerations section. http://www.ietf.org/id-info/checklist#anchor4 says: “If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." == Outdated reference: A later version (-20) exists of draft-ietf-nfsv4-minorversion2-19 Mehmet
draft-ietf-sidr-bgpsec-threats
I support Barry's DISCUSS as well.
Section 8. Really? No-one provided useful or notable individual input? Sigh.
Stylistically: The "* are considered a threat" phrases seem singsongy and unnecessary. The use of the verb "to effect" seems antiquated and, well, affected.
This should be easy: It seems to me that... 1. PATHSEC is a term in this document that needs a clear, concise definition. 2. The definition at the beginning of the Introduction is vague, and is, in any case, based on the SIDR WG charter. 3. I don't think it's wise to use charters as references for definitions. Charters are mutable, and charters don't have proper community consensus. They were never intended to be cited in this way. How hard would it really be to have a paragraph in the document, perhaps in the Introduction, that properly, concisely, and clearly defines PATHSEC?
-- Section 3 -- "Hacker" isn't defined, and I think there are many senses that different people have about just what a hacker is. The other threats aren't defined either, of course, but I don't think there's really a question of what a network operator is, what a criminal is, what a nation is, and so on. As the whole purpose of this document is to discuss threats and attacks, I suggest that it's important to define what a hacker is, at least to the extent that it's clear what distinguishes a hacker from, say, a criminal. Is a hacker a type of criminal? Are *some* hackers criminals? Are there hackers who are not criminals? You see.... (This isn't a DISCUSS point, because I think we have enough agreement on the concept of a hacker that I shouldn't block the document on this issue. Also, the discussion of the attacks don't actually seem to depend on the discussion of the types of threats.)
I support the publication of this document and I only have two quick points... 1. I agree with Barry's DISCUSS point on providing a definition of PATHSEC in the document rather than referencing the WG charter. 2. It may be worthwhile to mention in section 3 that "inaccurate" is a subjective term when discussing network operators' views of a BGP Update. Given the flexibility noted in section 4 about local policy, it is difficult to externally judge whether the result of a network operator's action is inaccurate or simply a change in local policy.
The distinctions in the threat characterized seems somewhat arbitrary, and appear to have conflated motivation with methodology. e.g. hacker crimnal isp nation-state and so on seem somewhat arbirary categories, nation states might easily for example employ the methodologoies of the other(s) and vice-versa.
draft-sin-sdnrg-sdn-approach
Overall, I like this - it should be useful input for people designing SDN stuff. I do wonder why it isn't just an IRTF SDNRG document though, since it might fit better there. But doing it this was is fine by me. - 3.3 says that some s/w modules might be controlled by external entities - surely that would raise some additional security and privacy consideratons in an SDN deployment? I'd say that would be worth a mention in section 6. - Section 6 could probably also mention s/w update requirements, if that's not already covered in Sam Hartman's draft that's referenced. (Can't recall.)
I would like to hear why this draft is put forward as AD sponsored, as this looks like a fine thing for the ISE track.
I agree with my esteemed colleagues that this document would be far more appropriate on the Independent stream. Or, as I expected from the draft name, the IRTF stream. I do have to admit, though, that this document could fit through the same loop hole I suggested for RTMFP -- it is a product of the IETF in the sense that the IETF thought it was a good idea to publish. That concern aside, thanks to the authors for a readable, thoughtful document. In Section 3.1: "(references can be added if needed)" This can probably be deleted at this point.
While I agree with many of the points raised in this document, I cannot support its publication as an IETF stream RFC. This type of opinion piece is much better suited as a corporate whitepaper or an Informational RFC via the ISE. Given that view, I am abstaining on this document.
I disagree with Brian, in that I think that it is fine for such RFCs to be published although it feels more like an ISE document. Indeed the content is mainly useful in getting readers to understand the wider issues of SDN. I would like the opportunity to discuss this publication approach with the IESG. There are two shortcomings in the text that I would like to discuss with the sponsoring AD. Firstly when I can across the topic of bootstrapping I was quite excited that there was going to be a serious discussion of how you bring up and manage an SDN, whether an IGP was required to create a base topology, and if not how this all worked. Unfortunately this did not seem to be addressed by the authors. Secondly, there was no discussion of OAM or other test and verification tools that I could see, which is also a topic that deserves consideration in such a document. The document fulfills the roll of a primer on SDN within the IETF, and would be significantly improved with text on those topics.
Regardless of what stream it gets published through I think it ought to clear say which service provider's opinion this draft documents. The title of the draft is: A Perspective From Within A Service Provider I assume the provider to which this draft is referring is France Telecom because the authors are both form the same company? Wouldn't a better title be: France Telecom's Perspective on Software-Defined Networking With that title change then it would be like every other draft we "discuss" that comes through the IESG that is an organization's protocol, view, profile, etc. ?
The section on flexibility 2.2 essentially says we're not going to define it (flexibility), but imagine a case where signaling is used to twiddle cos/packet treatment. I would characterize that as deeply unsatisfying. section 3.5 seems like a poorly targeted screed on openflow and I don't think it particularly appropiate as written to include such things in IETF documents.
draft-resnick-on-consensus
This draft has already been very useful in several occasions. Whether people follow the advice in the document or not, it should be strongly recommended reading for every IETF participant.
I'm setting aside the issue of whether AD-sponsored is appropriate for
this document. It is somewhat ironic that this document about consensus
has debatable consensus on its content because it is basically Pete's
views.
But we need to have the wider debate about this issue and not pin it to
any one I-D in the pipe.
So here is my "No Objection".
---
Thanks to Pete for some long conversations about this document. It
leaves me with a list of issues that I think are basically editorial
and can be worked through. I trust Pete as author to make the necessary
changes, and I believe he and I understand the changes necessary.
---
It may help to draw out (further) the disctinction between issues and
people. That is, consensus is not just the agreement of people to
continue on a specific path (e.g., publish this document whatever its
contents) but also requires that issues have been recognised and
handled.
As an example, if tourist who really doesn't care about the fate of the
work raises an issue. It is not enough for the tourist to say "I don't
care" - that might give consensus to move ahead, but the issue also
needs to be addressed.
---
I do feel that the document mixes (confuses?) the decision-making
process with the decision-evaluation mechanism. While the two are hard
to separate, I think that it would be very valuable to do so.
This is really a question of how we reach/drive consensus, how we
track and address issues, and how we listen to opinions.
I'm afraid I can't come up with a specific change to help with this.
but maybe it would help to talk about what chairs should be doing to
help the WG reach consensus.
---
The statement of intent for this document in the Abstract is altogether
too wishy-washy. Contrast with the final paragraph of the Introduction
that is much more clear (although see separate comments about it).
My main concern with the Abstract is that you have nothing here we can
build consensus around. Does "it is a collection of thoughts" mean that
the IETF has consensus that it is a collection of thoughts? I don't
think that is what you want - I think that, per your note (to be
removed) is much more helpful about describing the purpose which is
that "this document contains a collection of principles about rough
consensus and how it can and does operate within the IETF."
I also think that "this Infomational document does not change any IETF
processes" is important to retain in the Abstract.
---
Section 1
Almost every IETF participant knows the aphorism from Dave Clark's
1992 plenary presentation [Clark] regarding how we make decisions in
the IETF:
I actually doubt this, and I bet you have no evidence for it. Maybe just
a simple re-wording such as "A well-known aphorism..."
---
Section 1
s/(kings and presidents)/(king or president)
---
Section 1
I would replace
nor should decisions be made by a
simple vote of the majority
with
nor should decisions be made by a
vote
since "simple vote" implies decisions can be made by complex vote,
and "of the majority" implies decisions can be made by some other
portion of the whole.
---
Section 1
This document attempts
Maybe a bit more positive to strike "attempts"
to explain some features of rough consensus,
explain what is not rough consensus, discuss some new ways to think
about rough consensus, and suggest ways that we might achieve rough
consensus and judge it in the IETF. Though this document describes
some behaviors of working groups and chairs, it does so in broad
brushstrokes and it does not proscribe specific procedures. Rather,
this document is intended to foster understanding of the underlying
principles of IETF consensus processes. While it may be of general
interest to anyone interested in the IETF consensus processes, the
primary audience for this document is expected to be those who have
Strike "expected to be"
experience working in the IETF, and it is particularly aimed at
generating thought and discussion among those who might lead a
consensus discussion. Although most of the examples in this document
talk about working group chairs, these principles are meant to apply
Strike "are meant to"
to any person who is trying to lead a group to rough consensus,
whether a chair, a design team leader, a document editor, an IESG
area director, or any community member who is facilitating a
discussion or trying to assess consensus.
Just a specific quesiton on this: While you might be happy for anyone in
the IETF to read this document, it is not your intent to be specifically
providing guidance to IETF participants trying to participate in
consensus-building processes nor to understand how consensus might have
been judged?
---
In section 2 I found that
We might have to compromise processor speed for lower
power consumption, or compromise throughput for congestion
resistance. Those sorts of compromises are among engineering
choices, and they are expected and essential. We always want to be
weighing tradeoffs and collectively choosing the best set.
Did not sit well.
I think it was "best set" that caused me trouble. "Best" has become the
enemy of "compromise" and I would recommend dodging that bullet by
cutting the last sentence after "tradeoffs".
---
In section 2 you say...
the word "compromise" gets used in two
different ways
...and then you list three ways
---
Section 3 final para
A technical error is always a valid basis for an appeal.
s/error/objection/
---
I don't think your use of "appease" is right in Section 2. And I don't
think capitulation is necessarily involved either. Both of those words
seem more in line with the "horse-trading" than the walking away.
How about saying
"walked away for whatever reason"
---
Section 3
If the chair finds, in
their technical judgement, that the issue has truly been considered,
and that the vast majority of the working group has come to the
conclusion that the tradeoff is worth making, even in the face of
continued objection from the person(s) who raised the issue, the
chair can declare that the group has come to rough consensus.
That'll be a vote, then :-)
Let me pretend to be an insufferable pedant for a moment. Is "vast
majority" more than 65%? More than 75%?
It isn't really a matter of the vastness of the majority. Rephrase?
---
I don't think that saying that "in the rough" comes from golf and is a
play on words helps people understand the meaning. How about...
("In the rough" is terminology from golf. The rough is the longer
grass at the side of the fairway, and if your ball has landed in the
rough you are off course and away from the normal direction of play.
The phrase gets used quite a bit in the IETF as a play on words to
complement "rough consensus" meaning that you are in the rough if you
find yourself not agreeing with the rough consensus.)
---
Section 3
In order to do this, the chair will need to have a good idea
of the purpose and architecture of the work being done, perhaps
referring to the charter of the working group or a previously
published requirements document, and use their own technical
judgement to make sure that the solution meets those requirements.
What can't happen is that the chair bases their decision solely on
hearing a large number of voices simply saying, "The objection isn't
valid." That would simply be to take a vote. A valid justification
needs to me made.
Pete and I debated "technical judegment" quite a bit. We agreed (I
think) that sometimes this judgement extends to delegated judgement. We
also agreed that the appealability of that judgement is important to
highlight.
---
I snarf when I see "traditional".
It is important to recognize that this view of rough consensus is a
change from the way it has been traditionally characterized in the
IETF. Rough consensus in the IETF is often talked about as the
"dominant view" of the group, as RFC 1603 [RFC1603] described:
Note that RFC 1603 and Dave Clark's "we reject voting" are almost
contemporaneous. Yes one says "ballot good" and the other appears to
say "ballot bad".
Can I suggest cutting the first sentence.
Furthermore, in...
The above does say that "volume" is not the basis for a determination
of consensus, but over the years many IETF folks have thought of
rough consensus as being primarily about the percentage of people who
agree with a decision.
...I think you have misinterpretted how 1603 meant "volume". I believe
it was talking about loudness. That is why "volume" is grouped with
"persistence". It is saying that rough consensus is not about how loudly
Adrian shouts, but about how the bulk of the WG feels. In other words,
it is closer to the percentage argument than you make out.
[Not that I am saying that a straight percentage is all that counts, and
neither are you in this section (notwithstanding the fact that you
talked about the "vast majority" in earlier text). But I am saying that
it is a factor.]
---
One of the strengths of a consensus model is that
minority views are addressed
I do struggle with "addressed". I think it has more of an implication
of accommodation than is intended. I think "properly considered" is a
better forumlation.
---
The chair (or whoever is responsible to hear an appeal)...
It counds like you are saying that the chair hears the appeal, but you
haven't said that (and you would have been wrong). Why not...
The chair in making the consensus call (or whoever is responsible to
hear an appeal)...
---
I like section 5. It stands against some of the other text, especially
the first sentence of section 6 which jars quite badly coming
immediately after section 5.
The fix would be to try to reflect the message of section 5 into the
rest of the text.
---
The whole concept of humming applies, AFAICS, only to physical meetings.
The document could use consideration of humming on mailing lists and
how that kind of temperature guage can be used so that we don't have to
wait four months to move a discussion forward.
Curiously, Stewart just raised this exact question and a couple of ADs
made suggestions about how they have handled this.
---
Section 10 : something broken in
> [Clark] Clark, D., "A Cloudy Crystal Ball - Visions of the
> Future", July 1992.
>
> In
---
The RFC Editor will object to you including references without citing
them from your text. [IETF24] seems to be missing.
---
I appreciate you referencing Sheeran, but I note that there is no over-
riding intent in the IETF to reach consensus. Maybe that is a serious
lack in the IETF. But, of course, we typically care more about our jobs
and welfare than about perfection of consensus and the welfare of the
Internet :-)
Maybe you also need to discuss timeliness of decisions in this context.
Should the IETF strive for consensus (rough or otherwise) in the face of
immediate need for a solution. Some might argue that our process is
already slow enough (partly because of consensus). Others might argue
that quick and good are not usually compatible.
In discussing this point, Pete and I concluded that it may be helpful to
note that an acceptable way of moving forward with unresolved issues is
to note them in the RFC and have a plan to revist and resolve.
- I think the note below the abstract should be kept, somewhere. - s/factious/fractious/g ? - s/proscribe/prescribe/ - section 2 title: s/disagreement/valid technical disagreement/ would be better, if longer. - s2: "Can anyone not live with..." That can also be problematic since its hard to do multi-valued (cf httpbis at IETF-88). I think it only really works well for binary choices and then quickly gets counterprodutive. Bit wary of saying its just ok. - s2: saying horse-trading "has no place" in consensus decision making seems a bit idealistic - s3: "file an appeal" maybe add a reference there to whatever says "start with a maili to wg chair, then..." in case this encourages folks to go straight to the IETF chair or something. - s4: s/nearly impossible/impossible/ ? in para 1, ignoring IESG etc. might be better
Now, a conclusion of having only rough consensus relies heavily on
the good judgement of the consensus caller. The group must truly
consider and weigh an issue before the objection can be dismissed as
being "in the rough". ("In the rough" is terminology from golf. The
phrase, which gets used quite a bit in the IETF, is just a play on
words.)
As a non native speaker, I had someone explained to me the "to be in the
rough" meaning. And believe me, I searched the web. So, just telling it's a
play on words without being precise on what it means is misleading, at the very
minimum. One might get it from "participant is not in the "rough" part of a
rough consensus", but this document needs an explanation/definition within the
IETF context.
-
The chair in this case needs to understand what the responses mean;
only sufficiently well-informed responses that justify the position
taken can really "count".
Not sure I understand "well-informed".
I'm well-informed (because I'm the marketing guy for the feature I prefer), and
my view is "I prefer A" is not what you mean. You're after responses with
- well-argumented responses
or even better:
- well-argumented responses with new objections that have not addressed
before.
"well-argumented" is better but I'm not totally happy with it ...
-- Section 1 -- Though this document describes some behaviors of working groups and chairs, it does so in broad brushstrokes and it does not proscribe specific procedures. While it may be true that this document "does not [prohibit] specific procedures," I don't think that's what you mean here. I think "prescribe" is the word you meant.
Ten bonus points for the Lao Tzu quote!
loudly humming ;)
draft-housley-smime-oids
I have no objection but I note that according to 5226:
The required documentation and review
criteria for use by the Designated Expert should be provided
when defining the registry.
This document gives the review criteria (thanks) but is silent on
"documentation". Possibly silence means no documentation is needed, but it
would be nice to make that explicit.
Just minor suggestions, feel free to ignore: - General: Maybe say that changing these OIDs would have a bad effect on interop, since there are some folks who don't seem to get that? - section 3: Do you mean the expert should only accept stuff that'd have been ok with some historical charter for the smime wg? "Strongly related" seems somewhat vague. Given the very broad range of existing OIDs, what would not fit? Would some more guidance help the expert?
There is, however, a good comment from Suresh Krishnan on his Gen-ART review. Please make sure it is handled before we pass the document to the RFC Editor.
conflict-review-jabley-dnsop-anycast-mapping
DNSEXT does not exist. This should get the simple "No conflict" message.
To Pete's point: DNSOP would be more appropriate anyway, since this document is talking about stuff happening in the real live Internet of today.
I get what Pete is saying in his DISCUSS, but didn't we just say something like "related to IETF work done in the concluded DNSEXT working group" the last time we talked about this for a similar case? I don't care, but if the difference between the proposed response and Pete's suggested response matters, I'd lean towards having a different response for a core Internet protocol that we're not actively working on now, and for some random protocol we've never heard of before.