IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-02-05. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: Benoit
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
Telechat:
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
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
1158 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1227 EST Adjourned
(at 2015-02-05 07:35:59 PST)
draft-ietf-savi-dhcp
I would like to ensure that the state machine issues raised in the Gen-ART review are resolved. Can the sponsoring AD make sure that happens before the draft is approved?
Thank you very much for addressing my comments on the definition of trust for the trust attribute and on the perimeter scope. The privacy section looks good and I was glad to see the "SHOULD NOT log" for this function.
Thank you SO much for all the work in addressing my comments in version -30.
Sections 6 and 7 make LOTS more sense to me now, and I think there's been a
great general improvement in the document.
These minor comments remain, but they are non-blocking, so handle them as you
think best:
-- Section 8.1 --
Data packets from attachments with the Validating attribute MUST be
checked.
Packet whose source IP address is a link-local address will not be
checked.
So, we will never have a packet whose source address is a link-local address,
and that has the Validating attribute set, right? That doesn't *seem* right to
me, but that's what those two statements imply.
And when you say "checked", what does that checking imply? What is done when a
packet is "checked"?
-- Section 10 --
A few words of explanation would help here: it's not usually a good idea to
throw a list at a reader, cold. Are these recommended values? Required
values? How were they determined (is there operational data that tells us that
these are good values)? Explain what you're giving the reader here.
-- Section 11.1 --
In bullet (1) you say "This constant SHOULD be configured prudently to avoid
Denial of Service attacks." This relates to my comment on Section 10: how can
I know what is "prudent"? Can you give some guidance about how to determine
whether I've chosen a prudent value, and whether and how to adjust my choice so
I can comply with the SHOULD?
(2) The Data Snooping Process may set up wrong bindings if the
clients do not reply to the detection probes.
This would benefit from a reference:
NEW
(2) The Data Snooping Process may set up wrong bindings if the
clients do not reply to the detection probes (see Section
7.5.1.2).
END
* Figure 1 and its supporting text is unclear until the reader gets all the way through Section 4.3.2. It may be useful to put a forward reference to 4.3.2 for the protection perimeter. * Section 4.2 says that a SAVI device does not filter DHCP messages. As the WG considered the interactions with this draft and draft-ietf-opsec-dhcpv6-shield? The filtering done by draft-ietf-opsec-dhcpv6-shield may be useful in bootstrapping the function described in this document. * Section 4.2.4 says "...in some scenarios, a DHCP client may use a DHCP address without the DHCP address assignment procedure being performed on its current attachment." Can you provide an example of such a scenario? * I agree with Barry's comments on sections 8.1, 10, and 11.1.
I have one point I'd like to discuss that shouldn't be hard to resolve. = Section 4.3.4 = "In common deployment practice, the traffic from the unprotected network is treated as trustworthy, which is to say that it is not filtered. ... To configure such a perimeter, at minimum the DHCP messages from unprotected networks MUST be ensured to be trustworthy. Achieving this is beyond the scope of this document." The first sentence says that trustworthy == not filtered, then the later sentence says that messages MUST be ensured to be trustworthy. The implication could be that messages MUST not be filtered, but that seems backwards. On the other hand, it doesn't seem right to have a normative requirement that messages be "ensured to be trustworthy" somehow, using some unspecified mechanism, without really explaining what counts as trustworthy. I would suggest deleting the second paragraph altogether unless it can be made meaningful for a network operator.
In general I question whether calling the procedures in this document "snooping" is prudent. I would have thought something like "checking" or "verification" would have less baggage. = Section 3 = In the definitions of Unprotected link and Protected link, what does it mean for a device to "see" a DHCP message to a host? = Section 4.1 = "Traffic from unprotected links should be checked by an unprotected system or [RFC2827] mechanisms. The generation and deployment of such a mechanism is beyond the scope of this document." I see a few problems with this text. In the first sentence I don't understand the idea that a check would be performed by a system _or_ a mechanism. What about a system that employs the mechanism specified in BCP 38? Furthermore, the text implies that there are cases where BCP 38 doesn't apply, which seems to undercut the actual guidance provided in BCP 38. This is further reinforced by the second sentence that indicates that the generation of a new mechanism (to replace BCP 38? it's not clear) is beyond the scope of this document. It's also redundant to say that deployment is beyond the scope of the document -- deployment is beyond the scope of all protocol specs. And I'm unclear on whether "unprotected system" means the same thing as "unprotected device" as defined in Section 3. I think both sentences could be replaced with the following: "The mechanism specified in RFC 2827 is required in those cases." = Section 7.1 = "This is the case stands when the SAVI device is persistently on the path(s)" I think the "stands" is extraneous? s/one feasible link-layer paths/one feasible link-layer path/
draft-ietf-roll-trickle-mcast
Updated after additional review...
While balloting "Yes" on this document I have a number of small editorials that
I believe should be made to improve the document. These are presented roughly
in order of appearance in the document, you can fix them now or after the rest
of the IESG ballots are in (5th February).
===
Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs.
---
I think the Abstract could be a bit clearer to note the two modes of operation.
Something like
This document specifies the Multicast Protocol for Low power and
Lossy Networks (MPL) that provides IPv6 multicast forwarding in
constrained networks. MPL avoids the need to construct or maintain
any multicast forwarding topology, disseminating messages to all MPL
Forwarders in an MPL Domain.
MPL has two modes of operation. One mode uses the Trickle
algorithm to manage control- and data-plane message transmissions,
and is applicable for deployments with few multicast sources. The
other mode uses classic flooding. By providing both modes and
parameterization of the Trickle algorithm, a MPL implementation
can be used in a variety of multicast deployments and can trade
between dissemination latency and transmission efficiency.
---
Section 2 : MPL Forwarder
Please add...
The term "node" is used within this document to refer to a MPL Forwarder.
---
Section 3
OLD
MPL is parameterized to support different dissemination techniques.
In one parameterization, MPL may utilize the classic flooding method
that involves having each device receiving a message rebroadcast the
message. In another parameterization, MPL may utilize Trickle's
[RFC6206] "polite gossip" method that involves transmission
suppression and adaptive timing techniques. By supporting both
simple flooding and Trickle methods, MPL can be configured to operate
well in a variety of situations [Clausen2013].
NEW
MPL is parameterized to support different dissemination techniques.
In one parameterization, MPL may utilize the classic flooding method
that involves having each device receiving a message rebroadcast the
message. In another parameterization, MPL may utilize Trickle's
[RFC6206] "polite gossip" method that involves transmission
suppression and adaptive timing techniques. [Clausen2013] questions
the efficiency of Trickle's "polite gossip" mechanism in some
multicast scenarios, so by also including a classic flooding mode of
operation MPL aims to be able to perform satisfactorily in a variety
of situations
END
---
4.1 has a little mix of "scope value of nnn" and "scop value mmm".
Since 7346 uses "scop value" I suggest you change all to be in that style.
Ditto 5.1
---
In 5.4 under PROACTIVE_FORWARDING I think you need some simple statement like:
All MPL interfaces on the same link SHOULD be configured with the same
value of PROACTIVE_FORWARDING.
I thought about asking for "MUST", but I think that is too strong. However, if
using "SHOULD" it would also be good to have something like...
An implementation MAY choose to vary the value of PROACTIVE_FORWARDING
across interfaces on the same link if <supply text here>.
---
Section 6.3
The Option Data (in particular the M flag) of the MPL Option is
updated by MPL Forwarders as the MPL Data Message is forwarded.
s/in particular/specifically/
---
Section 13.
Please add a short paragraph on the comparative security implications of
classic flooding mode.
---
Please update the reference to read as follows:
[Clausen2013]
Clausen, T., Colin de Verdiere, A., and J. Yi,
"Performance Analysis of Trickle as a Flooding Mechanism",
November 2013. The 5th IEEE International Conference on
Communication Technology (ICCT2013)
Christer Holmberg's Gen-ART review had some minor editorial suggestions. Please treat these as comments that you may take into account in your editing process. Section 1: ------------ Q_1_1: I assume "LLN" stands for "Low power and Lossy Networks", but there is no extension anywhere. Please insert "Low power and Lossy Networks (LLN)" on first occurance. Section 3: ------------ Q_3_1: In a few places the text says "this protocol". I would suggest to replace that with "MPL". Section 4: ----------- Q_4_2: I would suggest to add something in front of "Overview" in the subject of section 4.3. Overview of what? :)
Thank you for responding to the SecDir review addressing Tero's questions. https://www.ietf.org/mail-archive/web/secdir/current/msg04411.html
Adrian comments: "Globally you should change s/an MPL/a MPL/ as indicated by the ROLL chairs." "Mipple", then? Oy. Ripple trickle mipple. But don't tipple. Dig.
I have two points that I want to discuss that should be relatively easy to address. 1. The document defines MPL Domain Address and indicates that all multicast data dissemination within an MPL domain is sent to that address. The document does not say how that address is selected or negotiated within a domain. One might infer from the 2nd paragraph of section 4.1 that the MPL Domain Address is the ALL_MPL_FORWARDERS address, but the wording of that section would make that an inference. Additionally, point #2 below makes me wonder if that is really the case. This document should be clear on the origin of the MPL Domain Address so that implementations do the right thing and can interact correctly. 2. Section 4.1 talks about devices participating in multiple MPL domains and segregating those domains by using different MPL Domain Addresses. Given the question above about how the MPL Domain Address is assigned/selected/negortiated, using the address to separate zones of the same scope is problematic. This spec should be clear that implementations need to follow the use of scope zone IDs (RFC 4007, Section 6) to keep different zones of the same scope separated.
draft-ietf-mpls-ldp-ipv6
I agree with Joel's (Tim's) question on why a 5036bis was not created. Strictly from a writing perspective, that approach seems straightforward and would make a single LDP specification. But, this is a non-blocking comment and I will happy as long as this information gets published in some fashion.
From Tim Chown's opsdir review. I would like to discuss the possiblility of appendix coving the changes mad by this document or what seems like a minor effort to make this the wholesale replacement of 5036. this does not rise to the level of a discuss, who knows we may get there. Thanks. From Tim Chown: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: this document is Ready with Issues. This document describes updates to the Label Distribution Protocol as described in RFC 5036 (and GTSM elements in RFC 6720), to clarify and correct the described or implied behaviour in IPv4-only, IPv6-only and dual-stack deployments. Issues: * This draft describes a number of ambiguities in particular in dual-stack behaviour, with at least eight such issues being listed in section 1. When reading this draft, in conjunction with RFC 5036, I personally find it quite tricky to apply the updated rules/guidance described here to the existing text in RFC 5036, due to the rather patchy nature of the document. I would therefore suggest that the authors consider a complete revision to RFC 5036 (as happened from RFC 3036), rather than having the clarifications / corrections ‘dangling’ in this additional text. I appreciate that such a revision may be considered overkill, so at the very least this document should include a clear list of changes / updates, perhaps as an appendix. * The general principles of the dual-stack / IPv4 / IPv6 operation should be stated early in the document - these are conveyed piece by piece as you read through the document, but it would be helpful to have them clearly stated up front. * There is an amount of repetition through the document. I suspect that in the 15 revisions there have been changes made which have caused this. If the document progresses as a standalone document, this should be corrected where possible. As it stands, the document feels disjoint in places, and doesn’t flow anywhere near as well as it could. Nits: * The specification language section (section 2) should be moved earlier in the document, given abbreviations described therein are used prior to their definition. * In 5.1 may wish to mention the IANA registry for IPv6 multicast addresses http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml * Last para of 5.1 - why are IPv6 LDP link Hellos to be transmitted first? It would be useful to state the reason. * There are various places in the draft that talk about address selection, e.g. in 5.1 and in 5.2; I think these are all consistent with RFC 6724, so perhaps that RFC should be used / cited here? * The set of rules in 6.1 repeats some parts of the earlier sections, but not entirely, e.g. the rule in the last para of 5.1 is not included in 6.1. * In 6.1.1, para 2, state here that this inclusion of the new TLV is a MUST; this is currently only stated a further page on. * In 6.1.1 point 3a) this is a little confusing because earlier the document talks about sending both IPv4 and IPv6 Hello messages, and part c) seems to duplicate parts a) and b) ? Tim
draft-ietf-httpbis-rfc7238bis
I found the text below a bit confusing:
Note: This status code is similar to 301 (Moved Permanently)
([RFC7231], Section 6.4.2), except that it does not allow changing
the request method from POST to GET.
The issue is that if you permanently cache this redirect, then there is no
request, and hence no request method to change. I think that what you mean is
that if the request that produced the 308 result was a POST, then the redirect
is only valid for future POSTs, and if it was a GET, it's only valid for future
GETs. I'm fairly confident this is what you intended to say, and the text as
is could be read that way, but it might be better expressed this way:
Note: This status code is similar to 301 (Moved Permanently)
([RFC7231], Section 6.4.2), except that it applies only to future
requests with the same method. For example, if the 308 status
code is received in response to a request with a method of
GET, then the redirect only applies to future requests that
also have a method of GET.
This also possibly addresses my other probably naive question, which is whether
this applies to request methods other than GET and POST.
"This specification contains no technical changes from the experimental RFC 7238, which it obsoletes." Then why are we wasting time with a new document?
Thanks for addressing my prior discuss with some text in the security considerations section to explain the following is possible without TLS: Couldn't an attacker substitute the URI that the user gets permanently redirected to a malicious site or a competitor, etc.? The security considerations of RFC7231 are pretty thorough, but I didn't see mention of using TLS to prevent session interception for this type of attack or for the privacy protection section.
Thanks for working through Ted's comments. I shared them.
draft-ietf-tsvwg-sctp-prpolicies
So I assume the ability to say "please re-tx this 2^32-1 times" is said to not introduce any new security consideration, because that is not sent over the wire. However, could there not be a DoS against a kernel from userland? And if that limit is set based on some WebRTC JS (is it? I don't know) then wouldn't that be a way to DoS a browser and possibly the other end of a WebRTC data channel too? So, perhaps noting the above would be good, as well as saying that implementations SHOULD or MUST have a limit that they enforce on the max number of re-tx's? (Apologies if that is there already and I missed it.)
1. Using the Priority Policy allows the sender of a user message to specify a priority. When storing a user message in the send buffer while there is not enough available space, the SCTP stack at the sender side MAY abandon other user messages of the same SCTP association with a priority lower than the provided one. From the same SCTP association or the same stream within the SCTP association? Or is this implementation specific? 2. While reading through the draft, I was actually wondering how I could use those extensions in IPFIX. The first one is not applicable. Then I found in section 3.2: The Priority Policy can be used in the IPFIX protocol stack. See [RFC7011] for more information. This is a little lit light. I believe you should explain the use case you have in mind... because I don't believe this was an IPFIX requirement.
Thank you for addressing the SecDir review questions. https://www.ietf.org/mail-archive/web/secdir/current/msg05262.html
-- Section 3.1 -- The Limited Retransmissions Policy can be used with data channels in the WebRTC protocol stack. See [I-D.ietf-rtcweb-data-channel] for more information. I wonder whether implementors might misunderstand, and think this is meant to be restrictive. Please consider changing the wording (here and in 3.2) to something like this: NEW The Limited Retransmissions Policy was designed to be used with data channels in the WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), and can also be used in other appropriate situations. END ...or maybe... NEW The WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), is an example of where the Limited Retransmissions Policy might be used. END -- Section 3.2 -- When storing a user message in the send buffer while there is not enough available space, the SCTP stack at the sender side MAY abandon other user messages of the same SCTP association with a priority lower than the provided one. The algorithm for selecting the message being abandoned is implementation specific. A minor point: the first part is written as allowing multiple messages to be abandoned, and the last sentence is written in the singular. Should the second part say "message(s)" ? -- Section 4.2 -- The table shows the two policies that come out of RFC 6458 and the two that come from this document. Is it worth it to create a (FCFS?) registry for these names, to document them and provide references?
draft-ietf-ospf-ospfv3-autoconfig
I almost didn't place a Discuss on this document, but as my list of larger comments grew to four, I decided that together they merit some discussion and resolution. ==== Does this document really update 5340? There is no mention of what this update is or why it is considered a part of the standard implementation of OSPFv3 to include the features described in this document. I suggest either dropping the update or clarifying how it works. (Note that idnits should have flagged this to you, but the shepherd write-up says that this document doesn't change the status of any existing RFCs.) --- I think that the effect of sections 4 and 8 is that auto-config as specified in this document is not suitable for deployment in service provider networks. Did I miss something, or are you saying that the best you offer is a single, network-wide password to cover all adjacencies? If this is fine for the home network environment, you should be able to point at a homenet document that says so. If you agree that this is not fine for a service provider (and probably for most enterprises) you need to call this out more strongly and recommend limits on the applicability of this spec. --- Isn't the duplicate Router ID detection an attack vector? If I can inject an LSA purporting to be from the same Router ID but with a numerically larger router hardware fingerprint, I can cause some other router in the network to reset all of its adjacencies. In theory I can do this over and over, and I can do it automatically on receipt of an OSPFv3 Router Auto-Configuration LSA. I think you should at least call that out as a specific risk. Ideally, you would find a way to mitigate it. --- Section 7.4. is titled: Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSAs' Are you really changing 2328? Or are you trying to say that an implementation of this spec will do something different from 2328?
The remaining points are normal review Comments that you can take or
leave as you wish:
---
Section 1 has
OSPFv3 [OSPFV3] is a candidate for deployments in environments where
auto-configuration is a requirement. Its operation is largely
unchanged from the base OSPFv3 protocol specification [OSPFV3].
If you parse this down, it says "OSPFv3 is largely unchanged from
OSPFv3" which may not be as helpful as you intended it to be!
Perhaps...
OSPFv3 [OSPFV3] is a candidate for deployments in environments where
auto-configuration is a requirement. This document describes
extensions to OSPFv3 to enable it to operate in these environments.
In this mode of operation, the protocol is largely unchanged from the
base OSPFv3 protocol specification [OSPFV3].
---
Section 1
The following aspects of OSPFv3 auto-configuration are described:
s/described:/described in this document:/
---
Section 1.2
Is there a reason to diverge fromt he RFC Editor's Style Guide in
placing the Acknowledgements at the top of the document?
---
Section 2 has
2. OSPFv3 SHOULD be auto-configured for IPv6 on all interfaces
intended as general IPv6-capable routers. Optionally, an
interface MAY be excluded if it is clear that running OSPFv3 on
the interface is not required. For example, if manual
configuration or another condition indicates that an interface is
connected to an Internet Service Provider (ISP) and there is no
Border Gateway Protocol (BGP) [BGP] peering, there is typically
no need to employ OSPFv3.
The first sentence is garbled since it says that an interface could be
intended as a router. Do you mean...
OSPFv3 SHOULD be auto-configured on all IPv6-capable interfaces of a
router.
"Optionally an interface MAY" is tautology. Suggest "An interface MAY".
I am wondering why the fact that you have a BGP peering on an interface
configured to connect to an ISP would mean that you would want to run
OSPFv3 on that interface. You are possibly saying that the interface, in
that case, may need to be auto-configured and present in the OSPFv3
advertisements. But this is not what you have said.
---
Section 2
Can you point me to the spec for "vanilla Wi-Fi"? :-)
---
Section 2 bullet 4
Of course, an
identical HelloInterval and RouterDeadInterval will still be
required to form an adjacency with an OSPFv3 router not
supporting auto-configuration [OSPFV3].
Of course, but how is this achieved? How does a router with auto-config
determine that its neighbor does not have auto-config and then discover
the correct intervals to use?
I think you can detect that your neighor is not doing auto-config by the
absence of the OSPFv3 Router Auto-Configuration LSA, but what should an
auto-config router do once this has been detected?
---
Maybe it is obvious, but in the process of selecting a new Router ID in
7.3, the router MUST NOT select a value that it knows (through LSAs
received before the duplicate was detected) is already in use in the
network.
It is even possible that the router SHOULD maintain some memory of
Router IDs seen in the network recently so as to not pick an ID of a
router that is temporarily down or disconnected.
---
7.2
The Router-Hardware-Fingerprint TLV contains a variable
length value that has a very high probability of uniquely identifying
the advertising OSPFv3 router.
So, the first time you run live at a customer site, you know that the
fingerprints will match on two devices and that they will both select
the same Router ID.
I think this is actually all OK so long as you indicate that this case
will be handled as a self-originated LSA and include a forward-pointer
to section 7.4.
---
7.2.1
The TLV
is padded to 4-octet alignment; padding is not included in the length
field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned.
Nice mixture of units :-)
Why 32 bits when everything previous was in octets?
---
7.2.1
The new LSA is designated for information related to OSPFv3 Auto-
configuration and, in the future, can be used other auto-
configuration information.
You already said that.
---
7.2.2
The Router-Hardware-Fingerprint TLV is the first TLV defined for the
OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be
advertised in the LSID OSPFv3 AC LSA with an LSID of 0.
So, if absent... ?
---
7.2.2
The contents of the hardware fingerprint MUST be some combination of
MAC addresses, CPU ID, or serial number(s) that provides an extremely
high probability of uniqueness. It is RECOMMENDED that one or more
available universal tokens (e.g., IEEE 802 48-bit MAC addresses or
IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be
included in the hardware fingerprint. It MUST be based on hardware
attributes that will not change across hard and soft restarts.
I think you mean...
The contents of the hardware fingerprint MUST have an extremely high
probability of uniqueness. It SHOULD be constructed from the
concatenation of a number of local values that themselves have a high
likelihood of uniqueness, such as MAC addresses, CPU ID, or serial
numbers. It is RECOMMENDED that one or more available universal
tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64
Identifiers [EUI64]) associated with the OSPFv3 router be included in
the hardware fingerprint. It MUST be based on hardware attributes
that will not change across hard and soft restarts.
Although I am a little puzzled as to what would happen if I changed my
MAC address.
---
Is there a reason to allow IESG Approval for your new registry? Is this
to make it look like all of the other OSPFv3 registries, or is it
because you anticipate specific problems?
Thanks for including section 4 - I was wondering if you would before I read this:-) - section 4: just saying "password" is likely to lead to password == password or password == 123456. Why not advise that a long higher entropy secret needs to be used? - section 4: I hate to do this to you, but if by saying "password" you also mean "entered by a human and likely a human memorable secret" then aren't there i18n considerations? Non-ascii characters in there are otherwise likely to lead to a lack of interop. If you wanted my advice as to how to avoid that, I'd go for RECOMMENDING that the secret be entered as ascii-hex digits and that 32 such digits be used if possible. - section 8: What "stronger" auth trailer do you mean in the last para? The weakness is that a password is used - the rest (e.g. hmac-sha-256 vs. hmac-sha-1) is in the noise. Maybe re-phrase.
4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and
RouterDeadInterval as specified in Section 3.
Hopefully, an easy DISCUSS.
From a management point of view, we must be able to determine if a router or
interfaces within a router are OSPF-autoconfigured. If I'm not mistaken, you
miss, in the management considerations section, something like this: The OSPFv3
routers MUST flag the interfaces supporting this specification.
Background: I recall one particular tool in the past that would check the
different router configs and flag the HelloInterval and RouterDeadInterval
mismatched values for adjacent routers. This would be equivalent to the
following debug:
OSPF: Rcv hello from 192.168.0.2 area 0 from FastEthernet0/0 192.168.0.2
OSPF: Mismatched hello parameters from 192.168.0.2
OSPF: Dead R 40 C 60, Hello R 10 C 15 Mask R 255.255.255.252 C 255.255.255.252
In case of OSPF auto-config, this check doesn't make any sense.
Thanks for addressing the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg05391.html I support Stephen's comments as well.
I'll note that the RFC Editor will move Section 1.2 to the end. If there's a reason you don't want that, you should let them know. -- Section 10 -- This specification also creates a registry for OSPFv3 Auto- Configuration (AC) LSA TLVs. This registry should be placed in the existing OSPFv3 IANA registry, and new values can be allocated via IETF Consensus or IESG Approval. The current term is "IETF Review" (not "IETF Consensus"), and you should have a normative reference to RFC 5226 here. It would also be good to say when IESG Approval is an appropriate alternative to IETF Review.
I support Adrian's points.
= Section 1 = "OSPFv3 [OSPFV3] is a candidate for deployments in environments where auto-configuration is a requirement. Its operation is largely unchanged from the base OSPFv3 protocol specification [OSPFV3]." The use of "its" here doesn't make a lot of sense -- a plain reading of this is that OSPFv3 is unchanged from OSPFv3.
draft-ietf-l3vpn-acceptown-community
Please consider changing "This memo defines a new BGP community" to "This memo defines a new well-known BGP community"
- section 6: I think I buy the argument that there are no new security issues here but that's only true I think if the security issues with route reflectors are somewhere (and if those cover cases where crypto is not used to enforce the "P" in VPN). Wouldn't a reference to something like that be good here? - I like non-informative appendices:-)
In the ballot: Opposition to the proposal was initially expressed by one contributor, but there was good support for adoption and no particular follow-up from that contributor. I'm glad someone wrote it down, but it's not exactly confidence inspiring. Was this just random opposition without explanation, or did the person have a point and it got addressed to the chairs' satisfaction, or did something get dropped? I expect it's that the concern was addressed reasonably, but the above doesn't exactly say that.
Clearing my DISCUSS on the basis that the following text is added as a RFC editor note, as discussed with Adrian and Ron Bonica: OLD: ACCEPT_OWN handling SHOULD be controlled by configuration, and SHOULD default to being disabled. NEW: ACCEPT_OWN handling SHOULD be controlled by configuration, and if controlled by configuration it MUST default to being disabled
I support Stephen's comment.
Nothing blocking here, but some things to please consider (and chat with me if you think it's needed): Please expand "VRF" and "PE" on first use. -- Section 2.1 -- A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value matches that of the receiving speaker if all of the following are true: Just checking here: 1. The "MAY" means that even if all the following are true, the router might still not accept the route -- it's optional. Is that what's intended? 2. This text says nothing about what happens if *not* all of the following are true. A router might still accept the route (or not). Is that what's intended? Or is a "MUST NOT accept" meant to be implied in that case? A route MUST never be accepted back into its source VRF, even if it carries one or more Route Targets (RTs) which match that VRF. I think "MUST never be accepted" is a bit awkward, because one immediately thinks of "MUST" as a positive command. I suggest "A route MUST NOT ever be accepted...." -- Appendix A -- The title says "Local Extranet Application (non-informative)". Do you mean "non-normative" here?
In Sec 2,2, it says: "This implies that when propagating routes into a VRF, the ACCEPT_OWN community should not be propagated. Likewise, if a route carrying the ACCEPT_OWN community is received in an address family which does not allow the source VRF to be looked up, the ACCEPT_OWN community MUST be discarded." In the first sentence above, it seems like the "should not" should be either "SHOULD NOT" or "MUST NOT". Is there a reason that the text is descriptive instead of normative?
I agree with Alia's suggested text change.
draft-ietf-softwire-map-t
The last call actually ended at midnight, I guess, so I'm dropping my discuss in advance of the telechat.
Thanks for bringing this back around through the process circuitry. I have no objection to publication.
For the same reasons as Brian.
- I support Pete's discuss about IPR - surely this has to go around to IETF LC again for that?
I am balloting no objection on the grounds that this document has been reviewed by the WG and the IETF community at large and apparently "passed" the last calls in terms of having rough consensus. However, the proposed solution looks personally to me like a big hack or in other words this document is creating a cross IP version protocol address translator (including using transport protocols). Actually, the whole work of the softwire working group should be reconsidered from an architectural view. Is this really the long term solution to get the IP transition right or is this just creating the next headache in five years as something out of the networking layer and the transport layer is mixed together as an IPv6 address?
Several people, including a Gen-ART reviewer, have asked about the status designation. I think we have all read about the history of how we got here. I do not personally have an objection for upgrading the document (but of course that would require a new last call). Nor do I think the IESG or reviewers should have a strong opinion in the matter. However, I'd suggest that broad applicability and interest from the working group, in today's context, should be the deciding factor, if someone wants to make a change.
The document has undergone another Last Call regarding the IPR (which was previously declared on an earlier version of a document that had this specification as a part) and the IESG has discussed the change in status. I won't stand in the way of the document.
Exactly like Adrian, I would like some more information on the Experimental status. As examples: http://tools.ietf.org/html/rfc7360#section-1.3 http://tools.ietf.org/html/rfc6614#section-1.3 I believe this should be common practice for experiemental RFCs. Re-reading RFC 3933, and I don't see this. Maybe an IESG statement ... ? Editorial from Victor K. (OPS-DIR review): Section 7.1 Paragraph 2: old text “.. a CE requires an the IPv6 prefix to be assigned to the CE” new text “.. a CE requires an IPv6 prefix to be assigned to the CE.” Section 7.2 Paragraph 3: old text “.. no specific routes need to be advertised externally for MAPto operate, neither in IPv6 nor IPv4 BGP.” new text “.. no specific IPv6 or IPv4 routes need to be advertised externally outside the service provider’s network for MAP to operate.” I added this version of the sentence since it makes more sense to me. Also, you technically don’t need BGP on the ISP side (although I can’t a modern network which does not use it).
The security considerations look good, thank you.
I've had a quick look, and nothing stands out. I trust my distinguished colleagues from Vermont and Maryland to duke it out.
I do agree with Adrian's comments about clarifying how and what the experiment is.
I find it a dis-service to the community for the softwire WG to put forth multiple solutions that solve essentially the same problem (https://mailarchive.ietf.org/arch/msg/ietf/jcscmIHmAQSvXLAlLLvfhnC2P8A). I believe the confusion caused by a myriad of solutions in this space, regardless of whether they are Standards Track or Experimental, will adversely impact vendors, operators, and end-users. My only hope is that this confusion will speed up the transition to IPv6-only operations within the affected networks.
Agree with Brian.
draft-holmberg-dispatch-iotl
I'm not really seeing what it is these are used for, so I'm not sure if the security considerations here are good enough or not. If these values are used for security sensitive purposes then I suspect more needs to be said. For example, I think what you ought be saying in the security considerations is what can go wrong if the various parties involved misbehave and not simply asserting that some of the parties need to trust one another. (Esp since we've seen recent cases where operator network devices were successfully attacked and used to futher attack the network given that information was being sent about in a very "trusting" fashion.) So, apologies that this discuss is a bit vague for now, but can you explain what it is that these values are used for?
- As usual, I dislike that we're making special assumptions about 3gpp networks. I think any stuff like this is liable to leak over so saying "just 3gpp" should not be a get out of jail card. - section 3 does not actually define any uses for the iotl parameter but simply repeats page 4 as far as I can see. - 5.1, last para: I don't get how the "must not" there doesn't apply here and say that this entire idea is busted - can you explain? - section 7: the 2119 terms here are bogus.
There has been a discussion of changes with respect to a Gen-ART review by Robert Sparks. It would be good to ensure that this discussion is finished and the necessary changes are folded in, before the draft is approved.
While reading through the draft I wondered a few times: "but what does iotl stand for?" Maybe I'm stupid, maybe I simply didn't pay enough attention to the document title, or maybe I should stop reading drafts late at night, but a simple reference to "Inter Operator Traffic Leg", next to iotl, somewhere in the intro would have helped me. Thanks Richard for showing me the light :-)
Thanks for your work on this draft, I just have one question: Should this draft have a reference to either the framework or a base SIP RFC that describes security and privacy considerations?
In Sections 5.2 and 6.2, you always show the parameter values in specific case, such as "homeA-homeB", though they're case-insensitive, and could just as well be presented as "homea-homeb" or "HOMEA-HOMEB". I wonder whether it's worth reminding readers of that with a sentence in Section 6.2, just to avoid bad implementations. Or is that simply a well-enough-known thing in SIP that it's not worth bothering? And the error in the ABNF that Spencer points out does matter, and needs to be fixed. I have every confidence that it will be.
I didn't figure out that the values were an enumerated set until Section 5/page
7. That's not horrible, but I'd think it would be easier for first-time readers
if you said something like
This draft defines the following iotl values:
o "homeA-homeB"
o "homeB-visitedB"
o "visitedA-homeA"
o "homeA-visitedA"
o "visitedA-homeB"
early in the document. Not a big deal, just a suggestion. Note that I'm a Yes.
(While typing this, I noticed that " visitedA-homeB" had a leading space in the
ABNF. I'm not wizard enough to know whether that matters, so I thought I'd ask
before AUTH48 ...)
This text appears in both Sections 1 and 2, but only needs to be stated once: "The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible." In Section 7: s/The information/The information in the iotl parameter/
draft-pechanec-pkcs11uri
3.3: In accordance with Section 2.5 of [RFC3986], the data SHOULD first be encoded as octets according to the UTF-8 character encoding [RFC3629]; then only those octets that do not correspond to characters in the unreserved set or to permitted characters from the reserved set should be percent-encoded. This specification suggests one allowable exception to that rule for the "id" attribute, as stated later in this section. and later: The whole value of the "id" attribute SHOULD be percent-encoded since it is supposed to be handled as arbitrary binary data. There's something weird here. If "id" is (or can be) arbitrary binary data, then encoding it "as octets according to the UTF-8 character encoding" and then percent encoding it is going to be a really bad idea. Seems to me that if it's arbitrary binary, you should encode the "id" in BASE64 or something first, or at least be clear in the above that only *textual* data is first encoded in UTF-8, and then percent-encode, except for "id" for which you should percent-encode everything. Is there any other non-textual data that might appear in this URI? Further down: Note that if a URI does carry characters outside of the US-ASCII character set a conversion to an Internationalized Resource Identifier (IRI) defined in [RFC3987] may be considered. As mentioned on the IETF list, please strike this sentence. The use of IRIs as protocol elements is recipe for disaster. I think we came to the conclusion long ago that if you are using something as a protocol element, it had better be a URI, and you had better percent-encode anything that was non-US-ASCII. Normalization is discussed quite reasonably in 3986; 3987 is unlikely to add anything useful, and 3987 is currently in a state of limbo anyway: We're waiting to see what W3C ends up recommending for HTML5, and the IETF is likely to end up referencing that in the long run and not 3987. 6. What is "form-insensitive Unicode string comparison"? I'm not familiar with that term.
3.4:
An application MAY always ask for a PIN by any means it decides to.
Heh. That's not a protocol option. s/MAY/can. And it's probably the same later,
but it may just be backwards:
OLD
A consumer of PKCS#11 URIs MAY modify default settings for accessing
a PKCS#11 provider or providers by accepting query component
attributes "module-name" and "module-path"."
NEW
A consumer of PKCS#11 URIs MAY accept query component attributes
"module-name" and "module-path" in order to modify default settings
for accessing a PKCS#11 provider or providers.
3.5:
o the consumer MUST know whether the URI is to identify PKCS#11
storage object(s), token(s), slot(s), or Cryptoki producer(s).
s/MUST/needs to/ or simply re-work the sentence. I don't know how to implement
a "know".
The consumer SHOULD consider...
s/SHOULD/can/g I don't know how to implement a "consider".
(1) Section 3.3: Please define the PKCS#11 semantics of the various values of "pk11-type". I assume that they map to CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_CERTIFICATE, CKO_SECRET_KEY, and CKO_DATA, but it would be better to be explicit. (2) Section 3.4: The description of how to use pin-source here makes me uncomfortable. It should be possible for an implementation to tell from the value of the parameter whether it can use it or not. I would propose restricting this attribute to a URI or a "|command". The local path option can be accommodated with a "file:" URI, and the vendor specific thing can be addressed with vendor specific query attributes.
I appreciate the spirit of this draft, and I think I might actually have an immediate use for it (configuring a CA). In particular, the text on security of "pin-value" is brief but good. There are several points, however, where this spec is unnecessarily restrictive or complex. Section 3.3: "However, the PKCS#11 URI notation does not impose such limitations..." It seems like what you're trying to do here is defer to PKCS#11. I would suggest being a little stronger here, e.g., "The syntax of the PKCS#11 URI does not impose such limitations. However if the consumer of a URI encounters values that would not be accepted by PKCS#11, it MUST consider the URI invalid." Section 3.3: "depricated" Section 3.3: "object ... "CKA_LABEL"" Why not use "label" for the attribute name here? Section 3.3: "duplicate (vendor) attributes MAY be present" Please clarify whether attributes defined in this specification MAY be duplicated. It seems like it could be useful for some of them to be repeated. For example, module-name / module-path could be used to enable a consumer to search multiple libraries for the desired token / object. Section 3.4: "If a URI contains both "pin-source" and "pin-value" query attributes the URI SHOULD be refused as invalid." Why does a URI with both "pin-source" and "pin-value" have to be invalid? It seems like a consumer could try the provided PIN, and if that's invalid, try to use the PIN from "pin-source". Section 3.4: "the URI consumer MAY refuse to accept either of the attributes" Rejecting the URI seems unnecessarily intolerant. Do you mean that implementations MAY ignore these attributes and fetch the module from elsewhere? That seems like the more charitable thing to do. Section 3.4: "a URI MUST NOT contain multiple module attributes of the same name." As above, this seems unnecessarily strict.
Thanks for answering my questions on the PKCS#11 reference.
In Section 4: An empty PKCS#11 URI might be useful to PKCS#11 consumers. See Section 3.5 for more information on semantics of such a URI. I see nothing in Section 3.5 that gives any information about semantics of the URI "pkcs11:". Can you quote it, so I can find it?
draft-ietf-l2vpn-pbb-evpn
There was a security directorate review from Catherine Meadows <catherine.meadows@nrl.navy.mil> > I don’t see any security concerns with this draft, but I do have some > comments on the Security Considerations section. > It is very short, and all it says that the security considerations in the > EVPN draft apply directly to this draft. I assume that it is also the case > that this draft introduces no new security considerations. If so, you > should say so, and you should also say why. Also, I was wondering if > the mechanisms introduced in this draft, by introducing a greater > degree of organization in the delivery of MAC addresses, makes it > easier to detect duplicated MACs, which were mentioned as a security > risk in the Security Considerations of the EVPN draft. If this is the case, > it would be a good thing to mention here. > > I’d consider the draft somewhere between ready with nits and ready > with issues. I don’t see any real security issues here, just a Security > Considerations section that needs to be expanded a little, but this > seems to be a little more than what the secdir guidelines would call a > nit. This all seems a bit non-specific, but I have asked the authors to have a look and see whether they can generate a response and maybe suggest some text. At the same time, this document is not defining any new protocol per se, so I find it hard to suggest what extra could be written.
Question. Section 8 discusses ARP snooping. Is there a need to discuss IGMP and MLD snooping as well (e.g., by referring to RFC 4541). Note that MLD snooping might affect how packets are forwarded for neighbour discovery in IPv6.
Thanks to Adrian for connecting in the SecDir review. I responded to the thread he restarted as a result of it being included in Adrian's comments already. This may be a repeat to that thread for some. My take on the review is that Catherine was asking if the advantages added by this draft also result in some security improvements over the referenced security considerations section. The referenced section mentions a problem with duplicate MAC addresses and this draft in section 10.1, 10.2, and 10.3 discuss the aggregation of MACs - does this also lead to a security advantage in that the prior concern is mitigated? Then does the advantage in 10.5 that provides more granular forwarding policy support also have a security advantage? If so, it would be good to state this, if not, a simple sentence that says no additional security considerations are added in this draft would be helpful. Here is a link to Catherine's review: https://www.ietf.org/mail-archive/web/secdir/current/msg05400.html
Thanks for doing this without filling the document with 2119 key words. I think it works well without them. Two small comments: 1. Very minor: It probably would be best to change the document's title to "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)". 2. I think the reference to [PBB] has to be normative; how is it not?
Would expanding "PBB-EVPN" in the title be helpful to anyone except me? :-) In section 3, I read Single-Active Redundancy Mode: When only a single PE, among a group of PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in Single-Active redundancy mode. All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in All-Active redundancy mode. and wondered if it would ever be the case that some, but not all, PEs were allowed to forward traffic. I noticed a "the the".
from Melinda Shore's ops-dir review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: this document is ready This draft describes a mechanism for reducing the number of BGP MAC advertisement routes, provide MAC address mobility, and several other MAC handling enhancements, using Ethernet Provider Backbone Bridging combined with Ethernet VPN. This work appears to provide significant improvements to both network resource usage and in MAC address manageability. Overall the document is a bit thin on material on network management, although the material describing the behavior of the mechanisms being used in the context of different kinds of failures is quite good. The document is very clearly written and the material describing protocol operation/behavior is much appreciated. The PBB-EVPN mechanism appears to be an enormous win for very large data centers. Passed the nits tool with only a warning about the publication year not matching the current year. This document was a pleasure to read. Melinda _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-ippm-rate-problem
I have no objection to the publication of this document, but I did
have one observation:
Although section 2 has discussion of the variation of a number of
fields and specifically includes...
o Transport protocol (e.g. where TCP packets may be routed
differently from UDP)
...I was surprised to find no mention of ECMP and the consequences that
it may introduce for the reliability of rate measurement figures.
- I'm not clear why it's a good plan for this document to state a bunch of MUST level requirements on protocol specifications, but I assume if that were problematic then this informational document would be ignored and if it's not a problem that's fine:-). Including that kind of thing can lead to unnecessary arguments though so I wondered. For example, on page 8 it (I think) says that protocols MUST allow for control (by whom?) of payload lengths, which is not something I see in typical speed test tools that'd be used by massive numbers of users, or at least that's not exposed via a UI that I can see. - section 6: surely this needs to note the problem that there can be privacy issues with (esp. multiple uses) of measurement - e.g. if I use my phone in different places to do similar measurements I may be open to some new forms of tracking. Why not note this? Why is there no "MUST NOT" requirement from this? (Assuming you stick with including such.) RFC2330 does recognise privacy for example, so why not here too? BTW I don't think I see privacy issues considered in 4656 or 5357, but I only had a very quick look. (This would be a DISCUSS from me if this were a protocol document, but I'm ok to just leave it as a comment on one like this.)
- Thanks for the "Operational Considerations" new section, as discussed with D. Romascanu - The document tile says problem statement, but it's a mix of problem statement, use cases, and some protocol requirements with RFC 2119 keywords. I believe the title should be modified accordingly. - I agree with Stephen regarding the use of RFC 2119. Service subscribers and authorized users SHOULD obtain their network operator's or service provider's permission before conducting tests. Really, should I have my provider consent before running http://www.speedtest.net/ ? :-) - Current IETF standardized test protocols do not possess the asymmetric size generation capability with two-way testing. Do you mean OWAMP/TWAMP? Please be specific
I'll follow along on Stephen's comments and don't have any others to add. The draft is well-written, thank you for your work on it.
I agree with Stephen's observations about the use of 2119 keywords in this type of document.