IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-10-30. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (John)
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:
Number Description Whois Reference Registration Date
0 Reserved [RFC-ietf-idr-as0-06]
1-6 Assigned by ARIN whois.arin.net
7 Assigned by RIPE NCC whois.ripe.net
8-27 Assigned by ARIN whois.arin.net
28 Assigned by RIPE NCC whois.ripe.net
and I do not see the RDAP URLs there. Only WHOIS URLs. Does filling out the RDAP URLs require IANA to contact the people who have made registrations, and ask what the proper URL is? Or am I missing something?
Telechat:
2.1.2 Returning Items
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Value | Description | Reference
-----------+------------------+---------------
TBD1 | OPTION_4RD | this document
TBD2 | 4RD_MAP_RULE | this document
TBD3 | 4RD_NON_MAP_RULE | this document
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
3.4.2 Returning Items
1306 EDT break
1311 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
Telechat::
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::
7. Agenda Working Group News
1328 EDT Adjourned
(at 2014-10-30 07:30:01 PDT)
draft-ietf-avtcore-srtp-aes-gcm
Before I move to a yes ballot, I want to chat about two things... (1) There are perhaps too many choices being offered here to be useful. It is very possible so much choice can harm interop and hence security. Do we *need* the 256 bit key options now? Is CCM really *needed* here? (Surprised the IEEE or h/w argument applies tbh) And why so many auth. tag lengths? Who really *needs* all of those? The DISCUSS point here is to validate that all of those options really *need* (as opposed to can) be defined, which may have been done already or may (and we have seen this) simply be a case of defining everything in the hope that something gets used. That can cause potential harm to interop. if different coders pick up different options. And the "but the USG will use all of these" is not IMO a sufficiently good argument for defining all of them - we also have experience with PKI that adding every option that the most complex deployments may want is not the recipe for success (e.g. with enrolment protocols). (2) Unless discuss point (1) results in there being only one remaining option, (which I doubt:-), which of the options specified here are MTI, and if you argue that that needs to be done elsewhere, then where will that be done? (We already had a major extended discussion about SRTP MTI things in general.) I would suggest that saying something like "128 bit GCM with a tag length of 16 MUST be implemented by any general purpose implementation of this specification" or something similar.
As mentioned by KK in his OPS-DIR review. This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. I feel that this document is well written and ready. I just have one minor suggestion. Section 13.2., second sentence, just to be consistent with the rest of the document, replace ‘Block Chaining Message' with 'Block Chaining-Message'
Thank you for addressing the SecDir review comments: https://www.ietf.org/mail-archive/web/secdir/current/msg05182.html
draft-ietf-mpls-ldp-ip-pw-capability
I have no objection to the publication of this draft, but I do have a couple of non-blocking comments/questions... 1. The Length field in Section 4.1 is under-specified. One can discern that the Length covers the S bit, the Reserved field, and any included State Advertisement Control Elements from the text, but there is no explicit definition of how to compute the Length field. That lack of definition goes back to RFC 5561 as well. 2. Will 7or 8 App types be sufficient for future expansion? Should the type values in section 4.1 be maintained in a registry?
I can think of a whole bunch of circumstances in which advertising my non-interest in receiving messages would be useful. bravo on this being done.
draft-ietf-softwire-map
I don't have any specific objection to this document. I agree with others that there are too many options and potential solutions being published. While there is a good chance that the market will decide and winnow this down to just a very few practical solutions, I believe the IETF (and specifically the Softwire working group) is letting down the industry. Vendors will be unclear which solutions to implement and operators are unlikely to give early direction. This will result in multiple implementations that either do not interoperate or that increase the net cost of equipment. And in the end, who pays? I wish more effort had gone into reducing the options.
[updated with one question at the end of the ballot] 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? Adding another question: RFC6346 A+P is used throughout the document and I believe an implementer has to read RFC6346 and understand the A+P sharing mechanism in order to get the implementation of this draft right. Or isn't any knowledge about RFC 6346 required?
The SecDir review raised a few points that should be discussed. I didn't see a response to the message from Brian and will highlight his findings here as well as include a link to the thread for the editors to respond to this review: http://www.ietf.org/mail-archive/web/secdir/current/msg05147.html The Security Considerations section lists several attacks. The text seems reasonable. It would be helpful if there was a reference to "Address-Dependent Filtering", which might be RFC 4787. The main risk to the mapping method seems to be a threat of overlapping address mappings, such that return packets are delivered to the wrong user. This would be a security consideration if users received other users traffic. The algorithm seems designed to avoid this, at least Appendix B indicates this as a requirement. If this is in fact believed to guarantee non-overlapping mappings then this should be stated in this section. The only statement I can find is in Section 5.1, where it is stated that "Different PSIDs guarantee non-overlapping port-sets." But if I'm not mistaken, the PSIDs are also computed so this might not actually be a guarantee. If there was a proof of correctness ensuring that a correct implementation will ensure non-overlapping mappings then this should be mentioned as well.
I've had a quick look, and nothing stands out. I trust my distinguished colleagues from Vermont and Maryland to duke it out.
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.
This is perhaps more a comment for the ADs, but it seems that the mechanism specified in this document provides a high degree of configurability in terms of the size of port sets without providing any guidance or explanation about the impact on application stability/breakage of choosing different set sizes. Is there a document somewhere in the softwire document suite that provides this background or advice to service providers about minimizing application impact when choosing port set sizes? RFC 6269 points out the problems, but doesn't provide any detail about how tuning the kinds of knobs available in this spec may affect applications one way or the other. If such a document does not exist, it seems like at least the deployment of the mechanism specified here, if not other variations that make use of restricted port sets, would benefit from it.
draft-ietf-softwire-lw4over6
I don't have any specific objection to this document. I agree with others that there are too many options and potential solutions being published. While there is a good chance that the market will decide and winnow this down to just a very few practical solutions, I believe the IETF (and specifically the Softwire working group) is letting down the industry. Vendors will be unclear which solutions to implement and operators are unlikely to give early direction. This will result in multiple implementations that either do not interoperate or that increase the net cost of equipment. And in the end, who pays? I wish more effort had gone into reducing the options.
Section 7 suggests a number of additional provisioning mechanisms:
In addition to the DHCPv6 based mechanism described in section 5.1,
several other IPv4 provisioning protocols have been suggested. These
protocols MAY be implemented. These alternatives include:
o DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4
messages over an IPv6 only service providers network. This
enables leasing of IPv4 addresses and makes DHCPv4 options
available to the DHCPv4 over DHCPv6 client.
Cui, et al. Expires April 17, 2015 [Page 12]
Internet-Draft Lightweight 4over6 October 2014
o PCP[RFC6887]: an lwB4 MAY use [I-D.ietf-pcp-port-set] to retrieve
a restricted IPv4 address and a set of ports.
In a Lightweight 4over6 domain, the binding information MUST be
aligned between the lwB4s, the lwAFTRs and the provisioning server.
How do we achieve interoperability if each implementation can choose different
provisioning mechanisms? Especially, given that synchronization is critical,
and is dependent on the provisioning mechanism used?
From the OPS-DIR review (David Black and David Harrington)
The lw4o6 specification results in significant operational change from the
current DS-Lite, so that does raise the question of how to manage lw4o6. From
the document:
This document focuses on architectural considerations and
particularly on the expected behavior of the involved functional
elements and their interfaces. Deployment-specific issues are
discussed in a companion document. As such, discussions about
redundancy and provisioning policy are out of scope.
...
The consequence of this architecture is that the information
maintained by the provisioning mechanism and the one maintained by
the lwAFTR MUST be synchronized (See figure 2). The details of this
synchronization depend on the exact provisioning mechanism and will
be discussed in a companion document.
David Black:
The consequence of this architecture is that the information maintained by
the provisioning mechanism and the one maintained by the lwAFTR MUST be
synchronized (See figure 2). The details of this synchronization depend on
the exact provisioning mechanism and protocols that are in use by the
operator. If no automated process for this synchronisation is in use, then
information in the provisioning systems and the lwAFTR MUST be synchronised
manually, e.g. by copying aligned configuration files to each of the
elements.
Ted's answer
It might be better to simply say "the precise mechanism whereby this
synchronization occurs is out of scope for this document."
Like David (who expressed: my primary concern was the reference to a "companion
document" which lead to an obvious "where is that???" question), I really
prefer Ted's proposal. As OPS AD, I don't want to force for the OPS solution at
the time of publishing the protocol spec. However, we have to set the right
expectations for the (OPS) readers.
Additionally, as David wrote:
2) I have a related concern: I don’t see discussion of how the
implementation should be operated and monitored, remotely. Since this
implementation is expected to reside in customer premises equipment, having
a remote monitoring and management capability seems important. And since
this is being developed in the IETF, where interoperability is important,
it would seem an IETF standardized monitoring and management solution would
be desirable. A MIB module would provide monitoring capability, but none is
defined or suggested here. This is an extension to DS-LIte, and there is a
DS-Lite MIB. There is no discussion of whetherr that DS-Lite MIB module
would be applicable to lw4o6, or whether that MIB module would require
changes to be applicable to lw4o6 monitoring.
Bottom line: the operational aspects for this new solution should be carefully
looked at by the responsible AD and OPS ADs. Without an OPS-related
specfication on how to manage this protocol, I'm afraid the solution is not
complete. Potentially a new entry in the charter, potentially involving the
early OPS-DIR review.
The SecDir review brought up a few good points to see if additional text is needed on DoS attacks and secure provisioning in addition to some nits. Could you please respond to that discussion and we'll figure out if text is needed (it looks like it may be). http://www.ietf.org/mail-archive/web/secdir/current/msg05163.html Thanks!
I've had a quick look, and nothing stands out. I trust my distinguished colleagues from Vermont and Maryland to duke it out.
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.
= Section 4 = "The solution specified in this document allows the assignment of either a full or a shared IPv4 address requesting CPEs." I think this sentence is missing a word -- maybe "to" requesting CPEs? = Section 5.2 = "The lwB4 is responsible for performing ALG functions (e.g., SIP, FTP), and other NAPT traversal mechanisms (e.g., UPnP, NAPT-PMP, manual binding configuration, PCP) for the internal hosts." I would suggest adding "if necessary" at the end of this sentence. At least for SIP, we have IETF guidance (in BCP 127) recommending that SIP ALG functionality be disabled by default. = Section 9 = It seems like the mechanism specified in this draft basically trades off the user's security (in the case where contiguous ports are used) in favor of efficiency/cost savings for the service provider. It seems like that should be stated more clearly -- at best there is no benefit of this solution to the user, and at worst it increases the attack potential. Or is there a place in the softwire document suite where this is explained more generally for other mechanisms that also use contiguous ports in port sets?
draft-ietf-ospf-security-extension-manual-keying
Thanks for this work. I am happy to ballot Yes, but have a couple of minor points I think would benefit the document. --- It would be good to add a very short note on backward compatiblity. I don't find anything in 2328, but I assume that a legacy implementation receiving an unknown AuType is supposed to fail authentication. Could you state this with the appropriate reference? --- The Abstract needs to be updated as: s/draft/document/ s/proposes/defines/ --- Section 1 para 1 s/propose/define/ --- Section 1 final para s/proposes/defines/ --- Section 1.2. The RFC Editor will move this sections to be consistent with their editorial guidelines. --- I think it is a mistake to quote the whole OSPF header in Figure 1. This opens up questions of editorial mismatches and future changes etc. It would be better to model this on Appendix D of RFC 2328. Additionally, it may be better to name the packet-trailing field as "Extended Authentication Data" to avoid confusion with the field in the generic packet header shown in RFC 2328 and called "Authentication"
I'm happy to recommend the document move forward. However, Suresh Krishnan pointed out that the reference to RFC 4222 regarding snmpEngineBoots seems incorrect. Can that be fixed? Thanks.
It seems that this document should be marked as "updates 5709", but it isn't. Why not?
I support the publication of this document, but agree with Adrian's suggestion to include some discussion on backwards compatibility.
= Section 3 = s/This section of this/This section/
If the non-volatile storage is ever repaired or upgraded such that the contents are lost or the OSPFv2 router is replaced, the authentication keys MUST be changed to prevent replay attacks. or if you ever replace the router... part of the reason manual keying is used is changing the authentication is quite hard particularly in cases where there are multiple neighbors on the same subnet.
draft-ietf-rtcweb-data-channel
These are not DISCUSSes because I'm betting they get answered in some other document, but be good to have answers here too maybe. - In 6.2, what does "typically" mean for DTLS state shared between SCTP streams or SCTP associations or data channels or PeerConnections? Don't you need to use some 2119 terms and be more specific about that? Maybe that's just me not being so familiar with BUNDLE though, and what equivalent is meant here? - Where do I find text that will show me that it's not possible to cut'n'paste anything from one SCTP stream to any other anywhere?
A few comments/nits: - Section 1, page 3, 1st paragraph reads: "source authentication, and integrity protected transfers. This data transport service operates in parallel to the SRTP media transports, and all of them can eventually share a single transport-layer port number." It is not not clear for me, what transport-layer the port refers to? SCTP or UDP or both? - Section 5, page 6, reads in one sentence: "SCTP association. In the WebRTP context, the PPID is used to" This should for sure read WebRTC instead of WebRTP, isn’t it? - Section 5, page 8, reads: " In general, the lower layer interface of an SCTP implementation SHOULD be adapted to address the differences between IPv4 and IPv6 (being connection-less) or DTLS (being connection-oriented)." The SHOULD here isn’t looking right, as this is not about protocol interworking, but advice for the implementers. Better to say "should be adapted to".
[Sorry for the resend; forgot to cut/paste one bit into my ballot.] 3/4: I don't understand what the point of putting these two sections into the document. They don't add anything to the discussion of the protocol, AFAICT, and are referring to a document that is still in IESG Evaluation and IMO has some serious problems. Please delete these sections. 6.5 - If it attempts to re-use a stream which is part of an existing data channel, the addition SHOULD fail. What does an implementation do if it *doesn't* fail? That is, why is this a SHOULD, and under what circumstances would you ignore the SHOULD? In addition to choosing a stream, the application SHOULD also determine the options to use for sending messages. The application MUST ensure in an application-specific manner that the application at the peer will also know the selected stream to be used, and the options for sending data from that side. I don't understand what the SHOULD and MUST here mean. Don't you just mean "will" in both cases? 6.6 - OLD The following PPIDs MUST be used (see Section 8): NEW Only the following PPIDs MUST be used (see Section 8): or better yet: This specification uses the following four PPIDs (see Section 8). Other PPIDs MUST NOT be used for WebRTC data channels. 6.7 - s/MUST/is 8 - Why are you re-using (and renaming) previously registered values instead of creating new ones, given that this is a FCFS registry?
Req. 1: Multiple simultaneous data channels MUST be supported.
Note that there may be 0 or more SRTP media streams in
parallel with the data channels in the same PeerConnection,
and the number and state (active/inactive) of these SRTP
media streams may change at any time.
Multiple simultaneous data channels from different "modes" (unreliable,
partially or fully reliable), or even from the same mode? "modes" in double
quotes, because, if I recall correctly SCTP delivery mode is per message, not
per stream. However, I don't have a better word.
Then I started to wonder... I've see those requirements before.
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14
----------------------------------------------------------------
F22 The browser must be able to receive streams and
data from multiple peers concurrently.
----------------------------------------------------------------
So I should not be commenting on the requirements again!
Why do you repeat, with different wording, the use cases and requirements in
this document? Note that this document contains RFC 2119 keywords for the
requirements, while draft-ietf-rtcweb-use-cases-and-requirements doesn't. Does
it imply the requirements in this document are more important? This is
confusing.
Disclaimer: I have not done a 1:1 comparison of the requirements in both
documents. A discrepancy would be another DISCUSS reason.
Referring to draft-ietf-rtcweb-use-cases-and-requirements is the way to go.
Even if [I-D.ietf-rtcweb-use-cases-and-requirements] is an informative
reference, progressing this draft while
[I-D.ietf-rtcweb-use-cases-and-requirements] still has issues is not
appropriate. I'll trust the responsible AD on that.
Ah, I just realized that Pete has got a similar feedback.
The draft looks good, thanks for your work on it. There is a tiny nit in the security considerations section that would likely be caught anyway: Last sentence should start with "It" instead of "I". I should be noted that a receiver must be prepared that the sender tries to send arbitrary large messages.
I'm a Yes on this one, but there are a few things I'd like the authors to look
at. In particular, the 6.6 comment may require a bit of additional text.
In this text: 6.4. Data Channel Definition
One strong wish is for the application-level API to be close to the
^^^^^^^^^^^^^^^
API for WebSockets, which implies bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
The realization of a data channel is a pair of one incoming stream
and one outgoing SCTP stream having the same SCTP stream identifier.
How these SCTP stream identifiers are selected is protocol and
implementation dependent. This allows a bidirectional communication.
I wonder how this will sound after this RFC and the WebRTC API have been
published. Could this be a bit more concrete? Perhaps something like
The realization of a data channel is a pair of one incoming stream
and one outgoing SCTP stream having the same SCTP stream identifier.
How these SCTP stream identifiers are selected is protocol and
implementation dependent. This allows a bidirectional communication,
and allows the application-level API to be close to the API for
WebSockets, which provides bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
In this text: 6.5. Opening a Data Channel
When one side wants to open a channel using out-of-band negotiation,
it picks a stream. Unless otherwise defined or negotiated, the
streams are picked based on the DTLS role (the client picks even
stream identifiers, the server odd stream identifiers). However, the
application is responsible for avoiding collisions with existing
streams. If it attempts to re-use a stream which is part of an
existing data channel, the addition SHOULD fail.
^^^^^^
My understanding of SHOULD says that if the addition doesn't fail, that's
discouraged but legal under this specification. Is that OK? Or ought this be a
MUST?
In this text: 6.6. Transferring User Data on a Data Channel
No more than one message should be put into an SCTP user message.
This statement doesn't use uppercase 2119 language, and the Conventions section
doesn't say anything about whether lowercase 2119 wording is to be interpreted,
so at least some implementers will say that The spec doesn't prohibit it.
If a sender puts more than one message into an SCTP user message, is that OK?
If the sender does that, what does the receiver do?
It would be helpful to include a sentence about why this restriction is
included. The specification has a nice explanation of why non-interleaved
connections should be limited to 16-Kb maximum message sizes. That's the level
of detail I'm asking about here.
In this text: 7. Security Considerations
I should be noted that a receiver must be prepared that the sender
^
tries to send arbitrary large messages.
is likely "It".
= General comment =
I'm assuming Sections 3 and 4 are included here because data channels can be
used outside the context of WebRTC or when no media is being exchanged. It
would help to make that clear and only enumerate the use cases and requirements
that are not already covered in draft-ietf-rtcweb-use-cases-and-requirements.
= Section 5 =
s/WebRTP/WebRTC/
= Section 6.1 =
OLD:
The dynamic address reconfiguration extension defined in [RFC5061]
MUST be used to signal the support of the stream reset extension
defined in [RFC6525], other features of [RFC5061] are not REQUIRED
to be implemented.
NEW:
The dynamic address reconfiguration extension defined in [RFC5061]
MUST be used to signal the support of the stream reset extension
defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL.
("not REQUIRED" does not make sense)
= Section 6.4 =
OLD:
One strong wish is for the application-level API to be close to the
API for WebSockets, which implies bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
NEW:
Data channels are defined such that their accompanying application-level API
can closely mirror the API for WebSockets, which implies bidirectional
streams of data and a textual field called 'label' used to identify the
meaning of the data channel.
(I didn't understand "One strong wish".)
draft-ietf-rtcweb-data-protocol
4 - I think you could clarify the following sentence: OLD The side wanting to open a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams are unused and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. NEW The peer that initiates opening a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams are unused and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. On this one: Note: The opening side can send user messages before the DATA_CHANNEL_ACK is received. s/can/MAY That's a protocol option, and one of which implementers should be made acutely aware. Question: Regarding who gets evens and who gets odds, you say, "When using SCTP over DTLS...". That seems to imply that there might be an instance where you *wouldn't* use SCTP over DTLS. That's not true, is it? You already say in the intro that "the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transport Layer Security (DTLS) [RFC4347] as described in [I-D.ietf-tsvwg-sctp-dtls-encaps]", so I take it as given. Assuming that's true, perhaps a better (and simplified) version of that paragraph might be: To avoid collisions where both sides try to open a Data Channel with the same Stream Identifiers, the side acting as the DTLS client in the underlying DTLS connection MUST use Streams with even Stream Identifiers, while the side acting as the DTLS server MUST use Streams with odd Stream Identifiers. If you *do* mean to imply that there are other possible underlying protocols, you had better define how to avoid collisions that don't depend on DTLS. 6 - Second paragraph: Re-word similar to section 4. Third paragraph: s/can/MAY, as in section 4. After the DATA_CHANNEL_ACK or any other message has been received on the Data Channel, messages containing user data MUST be send ordered on ordered Data Channels and MUST be sent unordered on unordered Data Channels. s/send/sent But really, I don't understand what the above MUSTs mean. What does it mean to send unordered data on an ordered Data Channel, or vice versa? Doesn't the fact that it's an ordered Data Channel mean that, whatever data I send on it, it will arrive ordered? I don't get it. Therefore receiving a message containing user data on an unused Stream indicates an error. The corresponding Data Channel MUST be closed as described in [I-D.ietf-rtcweb-data-channel]. Therefore? I don't follow. Fourth and fifth paragraphs: Seems to me these belong *before* the third paragraph.
Nits: Please run the nit-checker over this document to catch a few small issues (e.g., an obsoleted normative reference).
Linking in the SecDir review, which had the same conclusion I did from reading this in that there were no additional security considerations to add. The draft looks good, thanks for your work on it. http://www.ietf.org/mail-archive/web/secdir/current/msg05164.html
This could have been a small Discuss - please consider it!
In this text: 8.2.2. New Channel Type Registry
Please note that if new Channel Types support ordered and unordered
message delivery, the high order bit SHOULD be used to indicate
^^^^^^
whether the message delivery is unordered or not.
I'm having a difficult time understanding why this is a SHOULD. If it's
violated, that's still legal, so you can't actually be sure that the high order
bit is meaningful.
If this is going to matter, doesn't it need to be a MUST?
draft-ietf-pce-pcep-mib
Barely a skim. No obvious apps issues.
Thanks for the detailed security considerations section.
I trust the shepherding AD and his review of this document.
draft-ietf-6lo-lowpanz
Given that the link-layer address has so little variability to it, does it make sense to explicitly specify how DUIDs are formed when DHCPv6 is used? This discuss is intended to stimulate discussion; I will clear after we have discussed the question.
I've no objection to the publication of this document. Please note that section 1.1 has "ABR: Authoritative 6LBR ([RFC6775])" without defining "6LBR", but 4.4 has "authoritative border router (ABR)"
I cringed at just about every MUST. Brian can explain why. Whether the WG actually does anything about it is between you and your AD. :-)
In Section 2.3: s/section Section 3/Section 3/
Thanks for the detailed security and privacy sections. This all looks good, I just have a question that we should be able to resolve very quickly. In the privacy considerations, you have the following text: While intended for central address management, DHCPv6 address assignment also decouples the IPv6 address from the link layer address. Addresses may be made dynamic by the use of a short DHCP lease period and an assignment policy which makes the DHCP server hand out a fresh IP address every time. Should there also be a recommendation that DHCP addressed assigned should not be logged or that the life of such logs is short? If it's the case that operational practices is such that this information is not logged often, but if it's possible a recommendation would be very helpful, otherwise rotating the assigned IP addresses doesn't really offer any anonymity as was intended.
= Section 5 = o Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>" o Replace "802.15.4 PAN ID" with "G.9959 HomeID" Neither of the terms "802.15.4 short address" nor "802.15.4 PAN ID" appear in RFC 6282 or draft-ietf-6lo-ghc (although "short address" is used in 6282). I think exactly what is being substituted should be made more clear. I was looking because it didn't seem to me that the HomeID is used at all in the format described in this document (right?). So I don't really understand why it would need to be compressed if it is not included at all in the format. But then I looked in the documents about compression and could not figure out what it is supposed to correspond to since the PAN ID does not appear. If the HomeID is used somehow, then I think the privacy considerations text (which is generally great!) need to be extended to cover that, since the claims made about uniqueness/persistence of the NodeID do not apply to HomeID+NodeID.
draft-ietf-softwire-map-dhcp
This is only marginally a Discuss, but I think it needs to be addressed. [I-D.ietf-softwire-map-t] is definitely used as a normative reference. I have a feeling that [I-D.ietf-dhc-sedhcpv6] is also normative, but I'm less certain.
I've had a quick look, and nothing stands out. I trust my distinguished colleague from Vermont from there.
* I am surprised that some of the option formats do not do a better job of aligning fields on 32-bit boundaries. Re-arranging a few fields (and possibly adding a Reserved/Padding field) would make parsing easier for the S46 Rule Option and the S46 DMR Option. * I will note that since each of these options provides a single IP address, there is no mechanism in place to handle a failure with service hosted at that IP address. For example, what would a client do if the address signaled via the OPTION_S46_BR was no longer reachable?
draft-ietf-weirds-rdap-query
Point 1: In section 3.1.1, it's not clear which of three alternative things you may have been specifying: (1) the ASCII representation of the IP address is intended to be converted to binary before use, (2) the ASCII representation is intended to be used directly, or (3) whether the IP address is converted to binary prior to use is an implementation choice. If (1) is what's intended, you should say so explicitly. If either (2) or (3) is intended, then the representation that's used needs to be in some canonical form, and the text as written does not ensure that it will be. So to address this discuss, you should either update the text to say that (1) is what's intended, and it won't work otherwise, or you need to require, not suggest, a canonical representation. If you go with the second option, your reference to RFC 5952 isn't adequate: you need to specifically reference section 4, and specifically exclude section 5. I have no preference as to how you resolve this. Point 2: In 3.1.3, the instructions as given don't really guide implementations toward interoperability. Why not just say that servers SHOULD either convert a-labels to u-labels, or u-labels to a-labels, and be done with it? It's not like it's a difficult conversion, and they have to do the conversion to do the comparison, unless for some reason they store both A- and U-labels as keys in their database, which seems really unlikely. The recommendations are written are so vague that I would expect interoperability to only be likely in the case of queries that contain no IDN labels. I wouldn't mind this in an Informational document, but it's pretty sketchy in a standards-track document. It's particularly weird that in one place you say "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup" and then in the next paragraph you say "The server MAY perform the match using either the A-label or U-label form. Using one consistent form for matching every label is likely to be more reliable." I'm not sure how to resolve this. I think there's some underlying decision the working group has made that led to this language, but the lack of consistency I mention above leads me to wonder if either that decision wasn't very clear, or the document failed to reflect it. Interestingly, 3.1.4 is written as if 3.1.3 gives clear guidance as to how IDNs are represented. [point 2', which I forgot to label as a separate point, has been moved moved to a comment] Point 3: In 4.1, you don't actually specify the syntax for partial string matches. I think I can intuit what you mean, but you should be explicit, and you shouldn't suggest using POSIX regex searches unless that's what you really mean; if that's what you really mean, then you need to do a lot more work than you've done. I _think_ what you intend is to simply say that if one or more asterisks appear in a label, then when the search is done, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of each asterisk would match. But you don't actually say that, so I'm not sure what you actually intended. The text could be read to mean that any arbitrary search mechanism is allowed, but if that's the case then you need to go into a lot more detail about the caveats, such as the '.' character in posix regexps and the start and end markers. The text on partial matches for unicode also seems unnecessarily complicated, and likely not implementable without massive knowledge of all the various unicode character sets, which I would not expect an implementation to bother with. It seems relatively harmless to allow searches on combining characters, particularly since it would be a lot of work to prevent it. For example, a search for *ཀ་ would not find all instances of a syllable that starts with the sound "ka" because ka can be either a head letter or subjoined, but a user might search first using the head letter and then the subjoined letter if (as is not unlikely) he or she were unsure of the correct spelling. It would be a shame if such a search were rendered impossible by an overly-thorough implementation of the current text. As I say, I don't really know what was intended here, so I can't make a definite suggestion as to what the right thing to do is to fix this; I think we just need to discuss it, hence the discuss point.
Point A: In 3.1.2: For example, the following URL would be used to find information describing autonomous system number 12 (a number within a range of registered blocks): http://example.com/rdap/autnum/12 The following URL would be used to find information describing 4-byte autonomous system number 65538: http://example.com/rdap/autnum/65538 The examples don't really seem to illustrate what is said in the text. The syntax for both examples is the same, and we don't see any return results. So to say that one example is an example of a number within a range of registered blocks, while the other is a 4-byte number, doesn't make sense because the query formats are identical. The preceding text is clear, if I understand it correctly: a number in the path element following 'autnum' is an autonomous system number, which references a block of one or more numbers. If there are additional semantics, e.g., byte size boundaries for AS numbers, that are also encoded in the query, those should be described explicitly. But IMHO that doesn't make sense: in _this_ context, these are just decimal numbers of arbitrary precision, and how many bytes they are, or whether any particular number references a block or just a single number, is not something that should be mentioned in the examples. Point B: Section 6 appears to be confusing presentation and representation. A client might well present a UI that shows U-labels, but use A-labels on the back end. The text as written here really doesn't make sense. What are you trying to say? I think that you shouldn't confuse what's presented to the user with what's sent on the wire. Possibly this is related to the confusion over A-labels and U-labels that I called out in Point 2 of the discuss. Former discuss points: Point 2' from my initial discuss has been moved here because although I don't know of a mitigation strategy for the privacy concern I raised, I do see the valid use case, and so I don't feel like I have any action item to propose. It would be great if the authors could address this in the security considerations section, but I won't hold them to it. Point 2': In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches are for spammers to identify related domains, and for eavesdroppers to do the same. What's the motivation for including these capabilities? At a minimum, the privacy considerations for this search ought to be discussed in a privacy considerations section or in the security considerations section.
- Using https schemed URIs in the examples would be better. Mind you, https://example.com does get you a fairly odd certificate, so I can see why you might push back on that;-) - I think the privacy considerations from the json response draft might be better here.
"Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported queries." Shouldn't this go in -using-http? Also, the wording here could use tightening. It seems like you want to use 501 for query *types* that you don't support, vs. 404 for things where you just don't have an answer. So sending a query for "bbc.co.uk" to the ".youtube" server would result in 404, but sending it to the ARIN server might result in 501.
-- Section 3.2.1 -- None of the syntaxes begin with "/", and then you have a examples that do. Probably should take the "/" off the examples, no? But I see that the json-response document also uses the leading slash. But but, the bootstrapping document says that the URLs MUST end with slashes, because query specifications are appended to them (therefore the query specifications don't begin with slashes). This all seems somewhat inconsistent.
-- Section 1.1 -- You have some repetition repetition in the definition of REST. I suggest adding a little to the definition of IDNA, to make it clear that it's not just a handy abbreviation, but a pointer to something specific: "Internationalized Domain Names in Applications, a protocol for the handling of IDNs." Also, some of these terms (such as NFC and NFKC) have references where they're used down below. It wouldn't be a bad idea to cite those references up here as well. -- Section 3 -- Queries are formed by retrieving the appropriate base URL from the registry This may seem picayune, but I think it should be "an appropriate base URL", not "the". There may be more than one, and the bootstrap doc says that if one doesn't work, try another. It also doesn't give any guidance on selecting from among multiple https URLs, or multiple http ones. -- Section 3.1.3 -- IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, all internationalized labels in an IDN SHOULD be either A-labels or U-labels. You think the bit after the "that is" clarifies, but I don't. I suggest that this does: NEW IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels. END -- Section 4.1 -- Partial matching is not feasible across combinations of Unicode characters because Unicode characters can be combined with another Unicode character or characters. Servers SHOULD NOT partially match combinations of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters. It should be noted, though, that it may not always be possible to detect possible cases where a character could have been combined with another character, but was not, because of the way combining characters can be combined with many other characters. I'm not going to try to re-write that myself (don't try this at home!), and I did understand it... but I have to say that it's a truly convoluted paragraph. Please see if you can say this and the subsequent paragraph in a different way without the "combined combining character characters with combined character combinations" feel to it.
= Section 3.2.3 = If I'm reading the document correctly, when searching for an entity, the search pattern is expected to represent an entity using the syntax specified in Section 6.1 of draft-ietf-weirds-json-response. But when the path segment is provided, rather than a search, Section 3.1.5 says this: The <handle> parameter represents an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider. For example, for some DNRs contact identifiers are specified in RFC 5730 [RFC5730] and RFC 5733 [RFC5733]. This makes it seem as if an entity in a path segment uses different syntax (actually, non-standard syntax that is up to the registration provider) than an entity that someone might search for. Is there some specific field in the entity definition in draft-ietf-weirds-json-response that <handle> is supposed to correspond to? Aren't HTTP GETs for both path segments and searches meant to provide responses based on the same underlying data? If so, I don't understand why there is a specified syntax for entities in one but not the other. This also seems inconsistent with the following text in Section 6.1 of draft-ietf-weirds-json-response: The entity object class appears throughout this document and is an appropriate response for the /entity/XXXX query defined in Registration Data Access Protocol Lookup Format [I-D.ietf-weirds-rdap-query]
= Section 3 = "The query URL is constructed by concatenating the base URL to the help path segment specified in either Section 3.1.6." The "either" is extraneous, or there is some other section missing at the end of this sentence. = Section 4.2 and Section 8: I think it would be helpful here to point out that the identity/authorization of the searcher may be a relevant factor in determining how broad the response set should be for any particular query (and not just a single static policy that applies to all searchers equally).
draft-ietf-weirds-json-response
Point 1: In 4.3: It is the job of the clients to determine line breaks, spacing and display issues for sentences within the character strings of the "description" array. Each string in the "description" array contains a single complete division of human readable text indicating to clients where there are semantic breaks. What do you mean by "semantic breaks"? Paragraph breaks? Sentence breaks? Dependent clause breaks? This doesn't make sense. I'm not going to raise a discuss on it because I don't think it affects interoperability, but I have no idea how to implement a client to display this in a way that will make sense to the user. Point 2: A general question that occurred to me in reading 5.5, which also applies to 5.4: should you have some text talking about how the link member of a network or autnum object is generated? Both networks and autnum objects, as I understand it, can be gotten by querying any number in the range they enclose. But of course the link member isn't going to enumerate all the possible queries that could return the particular object containing that link member. So how is the value that's returned chosen? Is it the lowest number in the range? The number that was used in the query that returned the object? Some other number? I don't think you need to change anything, but it might be worth discussing this in sections 5.4 and 5.5.
- I support Alissa's discuss point that jCard is too rich a syntax and the specific jCard members intended to be used here ought be specified and the spec should say to not use others. The example on p18, with gender, dob, and other privacy sensitive fields should be adjusted to not include such. - I think it would have been a fine thing had the WG decided to do a more comprehensive privacy analysis of RDAP but I don't see that in this document set at least. I do like Kathleen's suggested text better than that currently in the privacy considerations section though. - Figure numbers are used inconsisently, some examples have them and, for no apparent reason, some don't. That needs fixing. There's also a lack of clarity about the specification style here - you need to be clearer as to what is just and example and what is not. - p21, the list following the example contains items that were not in the example - this is unclear writing. Are you saying that the list is normative or not? If so, you need to say so. If not, why go beyond the example? The same point applies to the lots of other examples that follow. - 10.2.X: there's a lot of stuff here that wasn't described. I wouldn't be surprised if that causes interop problems.
Thanks for your work on this draft and including options for privacy
protections. I do support Alissa's discuss on the -sec draft and as such, my
discuss here is specific to this draft and values set forth in it for privacy.
The general security and privacy considerations would be good to reference from
one place.
I think it would help to have the explicit guidance or recommendations for
privacy included directly in the privacy section. While the example in the
appendix is good, I'd prefer to see explicit recommendations for each of the
relevant status codes from section 10.2.2. How about something along the lines
of the following:
Current Privacy Considerations section:
This specification suggests status values to denote contact and
registrant information that has been marked as private and/or has
been redacted or obscured. See Section 10.2.2 for the list of status
values. See Appendix A.1 on guidance to apply those values to
contacts and registrants.
Suggested Privacy Considerations section:
This specification suggests status values to denote contact and
registrant information that has been marked as private and/or has
been redacted or obscured. See Section 10.2.2 for the complete list of
status values. A few of the status values indicate that there are privacy
concerns associated with the object instance. For the following status
codes, the RECOMMENDED actions include:
7. private - The object is not be shared in query responses, unless the
user is authorized to view this information.
8. redacted - The data has already been redacted, and may be returned
in a response in the data redacted form. This is a safer option to
choose to prevent unauthorized access to associated object instances
than marking them as private.
9. obscured - The data has already been obscured, and may be returned in a
response in the obscured form. This option may reveal privacy
sensitive information and should only be used when data sensitivity
does not require a more protective option like "private" or
"redacted".
See Appendix A.1 or an example applying those values to
contacts and registrants.
Thanks for addressing the SecDir review and including information on a possible cache poisoning attack. http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html Some nits were included as well that might be helpful.
In section 9 it might be worth saying a few more words about how responses can be truncated. Until I saw the example, I was thinking that the JSON itself might be incomplete. The example made me realise that you're talking about limiting what is returned, not actually truncating what used to be a complete response. I'm OK with referring to it as "truncated", but I'd like to see just a little explanation of the situations you're talking about, so it's clear you don't just mean snipping it in the middle.
I think this document is missing a discussion of the fact that while jCard was selected as the format for entity representation because it can flexibly accommodate the spectrum of the kinds of entities that require representation in RDAP, the full jCard specification includes many fields that are unrelated to the uses of the RDAP protocol and therefore not expected to be stored or made available by servers. This is a different point than the point made in Appendix A.1 (which should really be in Section 14 IMO) about the use of status values, which implies that the fields exist in the server-side database but are not shared in certain circumstances.
= Section 3.2 = I love an idiom as much as the next person, but it would be better to use names in examples that are not culturally specific. = Section 4 = The reference to I-D.ietf-jcardcal-jcard should be replaced with RFC 7095, I think. = Section 6.1 = Following on from my DISCUSS, I know the example in this section is just an example, but it includes all kinds of information about Joe User that no registry should be asking for and no registrant should willingly provide (gender? anniversary? really?!). It would be nice for the example to reflect what reality might/should actually be like.
draft-ietf-weirds-bootstrap
I support Barry's DISCUSS, but I think this is a good idea in principle.
- p4, where does it say what time is the publication time? Is it when the record is created/sent to IANA or when IANA get it or what? - section 9, 1st para: I'm not clear what cache expiry expectations we're setting here for IANA and dislike that that is essentially a form of dynamic data intended to be related to registry content that I don't believe IANA has previously been asked to serve up. I think that's a bad plan. - section 11 - this ought call for TLS as a MUST
Everyone should be aware though that we are creating a live database that would
be queried by software, not by implementors.
Anyway, I think that is fine, but I have a question mark. This could be due to
my lack of understanding of WEIRDS. But as far as I can see, the document asks
IANA to create a newly formatted view based on the contents of the existing
registry database. I understand how most of the data is filled in, but I do not
understand how the URLs are created. For instance, for ASes the document says
to generate something like this:
[
["2045-2045"],
[
"https://rir3.example.com/myrdap/"
]
],
but if I look at the existing registry, it does not have these URLs, it has
something else. E.g., from
http://www.iana.org/assignments/as-numbers/as-numbers.xhtml:
Number Description Whois Reference Registration Date
0 Reserved [RFC-ietf-idr-as0-06]
1-6 Assigned by ARIN whois.arin.net
7 Assigned by RIPE NCC whois.ripe.net
8-27 Assigned by ARIN whois.arin.net
28 Assigned by RIPE NCC whois.ripe.net
and I do not see the RDAP URLs there. Only WHOIS URLs. Does filling out the
RDAP URLs require IANA to contact the people who have made registrations, and
ask what the proper URL is? Or am I missing something?
Suresh Krishnan had this comment in his Gen-ART review: * Sections 5.2 and 5.3 -> The document uses some non-documentation addresses (AFAIK) in some of the examples. e.g. 28.2.0.0/16 for an IPv4 prefix and 2600::/16 for an IPv6 prefix. Is it possible to rewrite these examples using reserved documentation addresses? Strangely enough, idnits does not seem to catch them either.
I'm a little unclear as to why this document is necessary. It seems like given
the use of 30X redirects in -using-http, you could just start with an IANA root
server and redirect your way down the tree. It may appear that this bootstrap
mechanism saves queries to the root, but you could achieve the same effect or
better using 301 redirects with appropriate caching.
The use of JSON in this syntax is slightly disappointing. Generally, using
JSON arrays to contain items of different types is not a great idea. It seems
like the "services" entries should actually be objects, with entries indicating
the semantics of the inner arrays, e.g.:
OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] ]
NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls":
["https://rir1.example.com/myrdap/"] }
This should not be hard to describe in the notation of Section 10.2, and it
only uses a few more bytes on the wire.
This draft looks fine and adds the appropriate set of security considerations for what it does, however, shouldn't there be a reference to the draft-ietf-weirds-rdap-sec draft to say where everything else should be covered? Thanks
DISCUSS point 1, on the clarity of the text about matching: -- Section 4 -- The matching is of labels from right to left... You and I know that, but will every reader understand that? With gTLDs upon us, will it always be clear to everyone that a registry entry of "nyc" matches "coffee.nyc", but does not match "nyc.com"? Will everyone understand that a registry entry of "example.com" matches "good.example.com", but does not match "goodexample.com"? There's also nothing said about what happens if there are multiple matches at the same specificity. What if there are two Entry Arrays that both contain "example.com"? More likely, what if someone makes an error in specifying AS numbers, we get one entry for 10000-12000 and another for 12000-14000... and then we query for 12000? It might be good to be clearer about exactly what matching is intended, and what doesn't match. Feel free to use my examples above, if that helps. ----- DISCUSS point 2: the scope of what we're asking IANA to do, and the question of whether it's really clear both to us and to them what it is, what it will entail, and what it will cost: -- Section 8 -- Clients SHOULD cache the registry, but use underlying protocol signalling, such as the HTTP Expires header field [RFC7234], to identify when it is time to refresh the cached registry. Now you're putting another requirement on IANA, which I'm not sure has been part of the discussion: they have to present the registries in the right format AND manage the TTL of the queries with the Expires header. Please, please make sure that IANA is very clear about the entire scope of what we're asking, and signs off on it. -- Section 12 -- IANA is expected to generate the RDAP Bootstrap Services Registries data from these above mentioned registries, according to their own registration policies. I presume "their" refers to the registries, not to IANA, but that's ambiguous, and should be fixed. The above-mentioned registries do not have RDAP URLs, do they? Whence is IANA meant to get that information, in order to generate these new registries? If IANA generates these by periodically re-processing the source registries to pick up changes, how current are the RDAP registries expected to be? Is it OK for them to be updated once a week? Once a month? Are we setting up any SLAs for the timeliness and reliability of these registries?
-- Section 1 -- This document requests IANA to make an augmented version of the existing registries available for the specific purpose of RDAP use I presume that IANA has agreed to do that. Where will the URIs for those augmented registries be published. That is, how will a bootstrapping application know where to find them for the bootstrapping? -- Section 3 -- The JSON object for each registry will start with a series of members that contain metadata "Start with" implies ordering, but members within JSON objects are explicitly unordered. Do you actually care about the ordering, or should you just change "start with" to "contain" (and similarly change the subsequent "Following that")? Each item of the array contains a second-level array, with two elements, each of them being a third-level array. The first third-level array, named 'Entry array', contains all entries that have the same set of base RDAP URLs. The second third- level array, named 'Service URL array', contains the list of base RDAP URLs usable for the entries found in the 'Entry array'. There is no assumption of sorting except that the two arrays found in each second-level array MUST appear in the correct order: The entries array are followed by the service URL array. This is just an editorial comment, but this description seems unnecessarily complicated, and the "no sorting, but certain things have to be in the right order" is just odd. May I make a suggestion that gets rid of the "third-level array" awkwardness (and also corrects some wording errors)?: NEW Each element of the Services array is a second-level array with two elements: in order, an Entry Array and a Service URL Array. The Entry Array contains all entries that have the same set of base RDAP URLs. The Service URL Array contains the list of base RDAP URLs usable for the entries found in the Entry Array. Elements within these two arrays are not sorted in any way. END Any unknown or unspecified JSON object properties or values should be ignored by implementers. 1. Implementers don't ignore the unrecognized things; implementations do. 2. What does it mean to ignore an unspecified thing? It's not there to be ignored. 3. The "should be" makes people wonder whether it's supposed to be a 2119 key word, and why it's not. I suggest just using "are" -- that's simply the way it is. So, maybe: Any unrecognized JSON object properties or values are ignored by implementations. -- Section 4 -- The domain names authoritative registration data service is found by doing the label-wise longest match of the target domain name with the domain values in the arrays in the IANA Domain Name RDAP Bootstrap Service Registry. The values contained in the second element of the array are the valid base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. You have names for these arrays in Section 3; why don't you use them? NEW The domain names authoritative registration data service is found by doing the label-wise longest match of the target domain name with the domain values in the Entry Arrays in the IANA Domain Name RDAP Bootstrap Service Registry. The values contained in the Service URL Array of the matching second-level array are the valid base RDAP URLs as described in [I-D.ietf-weirds-rdap-query]. END And similarly for other times when you say "first element" or "second element". I'm also thinking more and more that "longest match" should instead be "most specific match", especially for the IP address numbers. -- Section 5.1 -- Doesn't "CIDR format" need a reference? -- Section 7 -- The registries may not contain the requested value or the base RDAP URL value may be empty. Nothing up in Section 3 said that a Service URL Array could be empty. If that's legal, that fact should be specified up there. -- Section 10.2 -- In the definition of "rdap-bootstrap-registry" you should note that the "description" member is optional, probably by saying, "and an optional MEMBER description and...".
draft-ietf-weirds-rdap-sec
As far as I can tell, this specification effectively relies on HTTP authentication as its sole MTI mechanism, and leaves things like OAuth as sort of "you could do this, but we aren't saying how." I am deeply uncomfortable with this, because HTTP authentication really sucks when you are trying to make it work in a context where authentication is optional. I think if you want to rely on this mechanism, you need to give the reader more guidance on how to make this work. What I mean is that in order to trigger the client to send authentication, you have to send back a 401 Unauthorized HTTP response. But that assumes that authentication _is_ required, and it's not. So how does the server know to send back the HTTP unauthorized response? The answer is that it does not, and so you need to somehow signal to the client that it should send more authentication info if it wants better information, while still returning information in case the client has no credentials to offer. This is probably doable, but simply relying on RFC 7235 without explaining how to make it work isn't sufficient.
- I strongly support Aliss's discuss on privacy. That would be even more important should registrars/registries in future require that personally identifying information be available for all registrants, which I believe is a policy that at least some are arguing for. - Isn't it sad that HTTP basic and digest still have to be the MTIs here for client auth. (I would suggest HOBA [1] but that's not quite done, being just finished WGLC, and would be self-serving, though it would be far better than basic or digest;-) [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba-05 - Why not just say "TLS MUST be used" in all cases? Is there a real need to not use TLS for weirds ever? - TLS client auth - I think you could easily make this MTI (to implement, not to use) as its basically there in most codebases.
I support Alissa's comments about privacy. It would be good to clarify those considerations and provide some good recommendations about what not to send.
Thanks for your work on this draft and improving security for the whois function in weirds. There are a lot of options now and the work is appreciated. I have a lot of comments and suggestions that should be pretty easy to resolve. You may find a discuss and comment on the same section, so I've tried to label the start of each item with the draft section numbers. Section 3.1 Could you also include a reference to RFC5280? If the use of PKI and CAs is listed, a pointer to the security considerations would be very helpful to the reader. The pointer should be to the full draft, not just the security consideration section as it covers important things like the need for path validation. Path validation includes checking the certificate validity, the path/chain (root is trusted), etc. I'm not looking for you to add much text, just to punt off to the existing documents if people are interested in the security behind these recommendations for federation, authentication, authorization, etc. Section 3.2 Could you expand on the details here a bit? Between this draft and the response draft, I don't see enough information or guidance on how one might leverage value settings on objects and what are the right actions to take based on those values. My discuss on the response draft is specific to that draft, but the same concept applies here. If the guidance belongs in the response draft, then recommended actions or a list of options if it varies from administrator to administrator would be helpful at the start of the sections that provide the lists of values that can be set on objects. This section of the sec draft should then reference the response draft letting the reader know where to look for authorization and access control options and guidelines. Section 3.4 Since the protocol allows for the use of values to mark objects as private, obscured, redacted, this should be mentioned in this section with a pointer to the response draft section 10.2.2 and the recommended actions in the (hopefully) updated Privacy Considerations section of that draft. For confidentially, leaving out the data with the "redacted" value set if possible will do a lot more than trying to protect it with TLS, so I think it's important to note that in this section. The "private" value should limit access (I'd like to see some mention of how that is accomplished, but probably in the Response draft). The "obscured" value is interesting, but since it is only obscured, it may to be the best option for confidentially protection. Possible new section for Access Controls - Since user based access is possible, I'd like to see a section added to cover that as well. Is access tied to the roles designated in 10.2.4 of the Response draft? Should it be? Having the combination of user roles and data object values gives a lot of flexibility, but that is talked about enough in the drafts (IMO). Security consideration section: It's good that you are recommending against use of the Null cipher, but could you add a reference to the UTA TLS best practices draft here as well? That will cover quite a few bases with out having to repeat stuff here. https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
I support Alissa's discuss for a privacy threat model. Section 3.1 As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done. There are a few minor updates and the security considerations in the updated documents spell out the remaining issues. Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options. There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts. If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls. https://datatracker.ietf.org/wg/httpauth/documents/ Section 3.1 I'm a little uneasy with just having a pointer to TLS to fix everything in OAuth and OpenID. Could you put in pointers to main framework documents like RFC6749 with a statement that says security considerations are included in those drafts? The security considerations differ between token types (bearer vs. Holder of Key) and that is out-of scope for this draft, so punting to the OAuth drafts would be very helpful instead of just pointing to TLS (but please do leave that in). This is just a comment the references do appear at end of the Security considerations section, & I'd recommend you move those up to section 3.1 as it will be a lot easier for the reader. Section 3.1 Just a question, should SAML 2.0 be listed as an option since this is a RESTful interface and we are talking about client authentication via a federated identity scheme or is that not an option? Thanks.
-- Section 3.1 -- This section describes security authentication mechanisms and their need for implementation by authorization policies. It took me a few readings to get what I think you mean. I think you mean this: NEW This section describes security authentication mechanisms and the need for authorization policies to include them. END
= General comment = I'm not exactly sure which document this remark is directed at, but I'm putting it in a DISCUSS here and we can figure that out later. I feel like the RDAP document suite is missing an overall explanation of the privacy threat model associated with registration data, the policy choices that are left up to registry providers, and the mechanisms included in RDAP to help protect registrant and client/user privacy and facilitate those policy choices. There are mentions of some of this here and there, but even those are not necessarily consistent with each other (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would be beneficial to capture this in one place and articulate it explicitly, rather than implicitly across the documents. Some of the salient points for starters: * WHOIS data has historically included personal information about registrants, has been made public, and has not had the benefit of authentication or access control mechanisms to gate access to it. In part as a result of this, proxy and privacy services have arisen to shield the identities of registrants. * The standardization of RDAP does not change or impact the data that registries may require to be collected from registrants. However, RDAP data structures allow servers to indicate when data returned to clients has been made private, redacted, obscured, or shielded by a proxy. * RDAP uses the jCard standard format for entity representation, but many of the jCard fields are irrelevant for registry operation purposes and their use should be minimized. * RDAP includes mechanisms that can be used to authenticate clients, allowing servers to support tiered access based on local policy. This means that all registration data need no longer be public, and personal data or data that may be considered more sensitive can have its access restricted to specifically privileged clients. * [Something about confidentiality of requests and responses ... see my other DISCUSS point below.] * etc. = Section 3.4 = "If the policy of the server operator requires encryption to protect client-server data exchanges (such as to protect non-public data that can not be accessed without client identification and authentication), HTTP Over TLS MUST be used to protect those exchanges." It is unclear to me that a server policy that allows unencrypted access should be allowed, particularly in the cases of entity-related requests, but perhaps also in the case of other requests. The fact that the registry data may be public is orthogonal to the question of whether a particular query for that data should have confidentiality protection. I'd like to understand why RDAP does not require HTTP over TLS to be used in all cases and instead allows unsuspecting client users to send their queries in the clear in cases where server policy does not mandate use of TLS. I'm especially curious about this since clients are required to support HTTPS anyway.
= Section 3.1 = "RDAP's authentication framework needs to accommodate anonymous access as well as verification of identities" I would suggest s/anonymous access/unauthenticated access/ since generally it can be pretty difficult to remain anonymous when accessing anything over IP. Similar comment for 3.2, I would delete "or anonymous."
draft-ietf-weirds-using-http
- As I said on the sec draft, I see no reason why RDAP could not only be defined for use with https URIs. - 5.5 seems to conflict a bit with one of the notices defined in the json-response draft where you say to do the same thing in the payload. I don't think it's a big problem but could be better to say which to use when. - I'm also not sure the CORS thing is quite right if cookies might get sent to the wrong places.
Might be worth noting in Section 3 that this protocol should be forward compatible with HTTP/2.0.
It looks like the SecDir review was considered when provided last year, thanks. http://www.ietf.org/mail-archive/web/secdir/current/msg04151.html
-- Section 1 --
2. A client issues an HTTP (or HTTPS) query using GET [RFC7231]. As
an example, a query for the network registration 192.0.2.0 might
be
http://example.com/rdap/ip/192.0.2.0
A small point, but, strictly speaking, that is not a query: it's a query URL.
The query is the full HTTP GET protocol. So either put in the HTTP query, or
make it "As an example, a query URL for...". (The rdap-query document actually
is careful to call them URLs every time.)
Another small point: in bullet 4 you expand the abbreviation "URL". Good, but
you've used "URL" twice, earlier in the document. You should expand it the
first time it's used.
-- Section 2 --
Yet another small point: I see that someone asked you to expand "SSAC". Cool,
but that now screams out for noting that it's a committee of ICANN (which then
raises the question of whether ICANN should be expanded). I'm going to duck
and cover now, and just let you do what you think best here.
-- Section 3 --
First, each query is meant to require only one path of execution to
obtain an answer. A response may contain an answer, no answer, or a
redirect, and clients are not expected to fork multiple paths of
execution to satisfy a query.
Do clients "satisfy" queries? I thought that clients make them, and servers
satisfy them.
-- Section 5.2 --
For example, if the client sends
http://serv1.example.com/weirds/domain/example.com
Again: strictly speaking, the client doesn't "send" that. You could say, "if
the client uses".
-- Section 5.3 --
Clients
MAY retry the query based on the respective response code.
What you probably want to say here is
NEW
A client
MAY retry the query if that is appropriate for the
respective response code.
END
-- Section 9.1 --
Thank you! It's always been my contention that IRIs are not part of wire
protocol, and should never be sent around as IRIs.
= Section 5.6 = "When responding to queries, it is RECOMMENDED that servers use the Access-Control-Allow-Origin header field, as specified by [W3C.CR-cors-20130129]. As the use of RDAP is for public resources, a value of "*" is suitable for most cases." What is the use case for cross-site RDAP queries? Also, I am confused by the claim in the second sentence. The message that I got from draft-ietf-weirds-rdap-sec and draft-ietf-weirds-json-response is that one of the motivations for using HTTP for RDAP was that its authentication features could be leveraged to provide tiered access to data on the server, such that some of the data would not be public but would be restricted to specific users (from draft-ietf-weirds-json-response, Appendix A.1: "In many use cases, it is necessary to hide or obscure the information of a registrant or contact due to policy or other operational matters."). So it seems like if cross-site requests are justified at all, there should be some text here explaining when that might be the case and when not.
draft-ietf-bmwg-sip-bench-meth
It seems like it might be worth noting for the media-on-DUT cases that the degree of SIP performance degradation due to media might differ depending on factors like what the DUT does with the media (e.g., relaying vs. transcoding), the type of media (audio vs. video vs. data), and the codec used for the media. There may also be cases where there is no performance impact, if the DUT has dedicated media-path hardware.
Since this is a set of benchmarks for use in a lab environment, I agree with the security considerations section statement that there are no considerations when used in the way described. Thanks.
I trust the shepherding AD and his review of this document.
= Section 4.1 =
"It is best
; off to start with the defaults (w = 0.10 and
; r >= 10)"
I thought the default was r = 100?
draft-ietf-bmwg-sip-bench-term
I agree with Alissa's comment on media. Suggest: OLD: "Any media protocol MAY be used." NEW: "The format of the media is determined by the SDP attributes for the 'm' line in question." The phrase "media control protocol" is used in Section 3.1.3. I assume this is meant to mean RTCP? If so, it would be useful to note this.
The security considerations look fine, but in reading the draft, it takes up until that section to learn that the tests are not performed on a production network and the follow on draft says they are intended for a lab environment. I think it would be useful to add this assumption into section 2.1 of this draft - that the benchmarks are intended for lab environments or not intended to be used on production networks as a DoS attack is possible using these methods. Thanks.
I trust the shepherding AD and his review of this document.
= Section 2.1 =
"A DUT MAY also include a B2BUA, SBC functionality."
This seems like a strange use of normative language (especially because the
"must" earlier in the same bullet is not normative). I think the intended
meaning here was actually "may."
= Section 3.1.4 =
"Any media protocol MAY be used."
Same comment as above -- what other choice is there if any media protocol is
acceptable? I think this should be "may."
= Section 3.3.2 =
"Following the default value of T1 (500ms) specified in
the table and a constant multiplier of 64 gives a value of 32
seconds for this timer (i.e., 500ms * 64 = 32s)."
Is this just meant to be an example? Not sure what its purpose is. And it seems
really long.
draft-ietf-v6ops-mobile-device-profile
I'm entering this as a Discuss as input to the debate the IESG will have on this document. I do not expect any action from the document authors at this stage. I will either update the Discuss to show the appropriate actions, or will remove it. It is clear to me that a number of people working across a broad set of network operators have driven this work, and also that there is consensus in the WG as reported by the chairs. Also I see the consensus called by the AD for IETF last call. The document doesn't use RFC 2119 language (although the first paragraph of Section 1.3 was a surprise to me, if just weird IMHO, and would probably best be removed). But I agree that it is unfortunate to have developed this document in isolation from 3GPP. That is not to say that the IETF should not publish such a document. But to do so without even notifying 3GPP of the work in progress and giving them the chance to comment seems to be regrettable. While it is clear that there is a perceived need for a profile that is different from what the 3GPP previously developed, it would have been good to hear from 3GPP what concerns they have with this new profiles.
I am balloting Abstain: I do completely support Brian's DISCUSS that this document is not in the right place, given the current situation of not having 3GPP involved in this. The IETF cannot IMHO set requirements for other SDO's devices, unless there is explicit input from such SDO in writing such I-D/RFC.
There are several requirements, in particular A_req#1 and A_req#4 that should be referenced from the security considerations section. The security consideration section just points to another RFC for IP address privacy (also referenced in the A-req#1), but the explanation in the requirement is helpful and I think it should be referenced as well or instead. Thanks for addressing the SecDir review coments: http://www.ietf.org/mail-archive/web/secdir/current/msg04190.html
in support of Brian's point: I find it curious that we are publishing a profile for 3GPP usage that differs from what 3GPP has produced. I'll let Brian pursue this...
* Updated text based on feedback on other ballot positions and private e-mail from the authors * This is a DISCUSS for the IESG for the time being. No need for author/chair actions at this time... I believe that this document will be harmful if it is published. It portrays itself as a viable product profile for 3GPP networks. However, this was done without interactions with 3GPP and creates a situation where user-equipment vendors may be confused as to what profiles are valid for their 3GPP devices. Despite referring to itself as a set of recommendations, it uses 2119 keywords to turn these recommendations into requirements. Given that RFC 7066 exists and that this type of profile should be developed within the GSM Association, I don't believe we should be publishing this document. The following was sent to me from one of the authors: I can eventually understand the resistance to see a profile document published, but I thought this first sentence from the draft would softened that: This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). The above text clearly illustrates why this document is a problem. How broad is this "number of operators"? Does it go beyond the 4 operators listed as document authors? If a vendor implements this profile, will they be capable of operating on a 3G/4G/WLAN network managed by some other operator? As Adrian noted, the convoluted use of 2119 keywords is troubling and having them couched in an Informational profile document is dubious at best. I support Adrian's notion that 3GPP should at least be notified of this work formally. The previous work, like RFC 3314, was driven by a partnership between 3GPP and the IETF (https://datatracker.ietf.org/documents/LIAISON/file725.txt) and we should continue that partnership *if* the consensus is to publish this document as a consensus-based RFC. It is also unclear if the people who raised earlier concerns feel that their concerns were addressed. I spoke with several of them and they do not think their concerns were addressed, but were tired of fighting over fundamental differences. If a group of operators wants to document a profile that highlights what they want vendors to implement, that should be documented somewhere else besides the IETF. At best, I could see this documented as an ISE document (with all the appropriate warnings).
draft-ietf-l2vpn-ipls
The draft looks good, I just have a question I'd like to discuss to see if one more consideration should be added to the Data Plane security considerations. The section starts off as follows: The data traffic between CE and PE is not encrypted and it is possible that in an insecure environment, a malicious user may tap into the CE to PE connection and generate traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit. If it's possible to tap the connection to generate traffic, couldn't it also be tapped for monitoring purposes? This would leave the possibility of active attacks (you've already described one) and passive attacks, which we see with pervasive monitoring. If this is possible, how about the following text to include this consideration (or some other variation is fine too if you'd like to propose something): The data traffic between CE and PE is not encrypted and it is possible that in an insecure environment, a malicious user may tap into the CE to PE connection and could conduct an active or passive attack. An example of an active attack would be generating traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit and a passive attack could include targeted or pervasive monitoring [RFC7258] between the CE and PE. Thanks.
Thank you for addressing the SecDir review comments: https://www.ietf.org/mail-archive/web/secdir/current/msg05146.html
draft-ietf-dmm-best-practices-gap-analysis
Thanks for this document. It is very readable.
Thanks for your work on this draft.
1. It looks good, but I'm wondering if a mention of privacy could be added.
This should have been in RFC7333, but it looks like that didn't happen (Stephen
recommended some text in his comments to add it in that draft, now RFC). Maybe
this was discussed and there was a reason not to add it. I don't remember the
outcome, so I'll make a couple of suggestions of where I think it might be
important in this draft.
In Gap 1-3, does the listed solution (or others for address discovery) lead to
privacy concerns that should be mentioned?
Dynamic Home Agent Address Discovery (DHAAD): the use of the
home agent (H) flag in Router Advertisements (which
indicates that the router sending the Router Advertisement
is also functioning as a Mobile IPv6 home agent on the link)
and the MAP option in Router Advertisements defined by
HMIPv6.
Also, I don't see a mention of privacy in this gap analysis or RFC7333. Could
you add it in 5.7. Security considerations - REQ7? I know this comes from
RFC7333, so that would have the text
Change from:
In addition, with security taken
into consideration early in the design, a DMM solution cannot
introduce new security risks, or amplify existing security risks,
that cannot be mitigated by existing security protocols and
mechanisms.
To:
In addition, with security taken
into consideration early in the design, a DMM solution cannot
introduce new security risks or privacy concerns, or amplify existing
security risks, that cannot be mitigated by existing security protocols and
mechanisms.
2. In Section 6, Security Considerations of this draft, should there be a
reference to RFC7333 for the detailed requirements?
Thank you.
Nice document; thanks. I think that, in addition to 7333, 5213 and 6275 are also normative references, as they're used for terminology.
draft-ietf-softwire-map-t
I don't specifically care to object to the publication of this document and I don't feel strongly enough to abstain, but I do find it hard to understand why it is being published even as experimental. It feels to me like a consolation prize for not being the WG's selected solution. Maybe it would have been better to pursue publication either as an historic record of an idea not adopted, or as an informational record of some existing implementation and deployment. That way it would have been less confusing to the market. Anyway, given that it is positioned as an experimental RFC, I wish this document explained why and how it is experimental in nature. It is not a requirement to do this, but it would make a lot of sense. - How is the Internet kept safe from the experiment? - What feedback do you want from experimentation? - How will you judge the success of the experiment? - How do you plan to move the experiment to standards track?
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.
For the same reasons as Brian.
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 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.
draft-ietf-softwire-4rd
I could not parse the IANA considerations section of this document.
IANA is requested to allocate the following:
o One DHCPv6 option codes TBD1 for OPTION_4RD of Section 4.9
respectively (to be added to section 24.3 of [RFC3315].
Encapsulated options of OPTION_4RD, 4RD_MAP_RULE (TBD2) and
4RD_NON_MAP_RULE (TBD3) should also be recorded into the DHCPv6
option code space.
Value | Description | Reference
-----------+------------------+---------------
TBD1 | OPTION_4RD | this document
TBD2 | 4RD_MAP_RULE | this document
TBD3 | 4RD_NON_MAP_RULE | this document
I think it is just jumbled words. You are asking for three new DHCPv6
option codes from the "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" registry "Option Codes" sub-registry.
Now, that sub-registry is marked "Expert Review and Standards Action"
which is slightly ambiguous. So I went to RFC 3315 where I found...
New DHCP option codes are tentatively assigned after the
specification for the associated option, published as an Internet
Draft, has received expert review by a designated expert [11]. The
final assignment of DHCP option codes is through Standards Action, as
defined in RFC 2434 [11].
So, you can't have code points for an Experimental RFC.
Rather than move this document to the Standards Track, I suggest you
take advantage of draft-ietf-softwire-map-dhcp which is on the Standards
Track and is already in the pipe. If you update that document to ask
for these code points, and include a normative reference to this I-D
everything should work out fine.
Just like draft-ietf-softwire-map-t, I don't specifically care to object to the publication of this document and I don't feel strongly enough to abstain, but I do find it hard to understand why it is being published even as experimental. It feels to me like a consolation prize for not being the WG's selected solution. Maybe it would have been better to pursue publication either as an historic record of an idea not adopted, or as an informational record of some existing implementation and deployment. That way it would have been less confusing to the market. Anyway, given that it is positioned as an experimental RFC, I wish this document explained why and how it is experimental in nature. It is not a requirement to do this, but it would make a lot of sense. - How is the Internet kept safe from the experiment? - What feedback do you want from experimentation? - How will you judge the success of the experiment? - How do you plan to move the experiment to standards track?
I'm with Brian and Adrian on this draft: It is not clear to me why the softwire WG is publishing this document. It could have been submitted via the ISE, if there is the desire to document the existence of a different approach.
For the same reasons as Brian.
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 ... ?
Could you please work through the suggestions made in the SecDir review on the
SecDir list with Derek, I don't see a response on list yet. I agree with Derek
that the first section in the security considerations section on anti-spoofing
is difficult to understand as written:
Spoofing attacks
With IPv6 ingress filtering effective in the Domain [RFC3704], and
with consistency checks between 4rd IPv4 and IPv6 addresses of
Section 4.5, no spoofing opportunity in IPv4 is introduced by 4rd.
I'm not exactly sure what is meant, otherwise, I'd suggest text.
Here is a link to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05134.html
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 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.
I don't see a lot of positive outcomes from advancing additional transition mechanisms I find myself altogether better off when I can avoid using any of them.
draft-ietf-dart-dscp-rtp
Thanks for making this cross-area piece of work so well. I had a little bit of a private mutter about whether it is the reliable transport protocols themselves or the implementations that are intolerant to out of order packets. Maybe the text here is a little too kind to the implementations and a little too critical of the protocols. But it is not a big issue in this document.
Thanks for addressing the SecDir review comments. https://www.ietf.org/mail-archive/web/secdir/current/msg05151.html The draft looks good, thanks for your work on it as well.
Nicely written... and thanks for getting this document out early in the WG's life cycle.
Thank you for doing this work. It's excellent, and valuable. I have a small number of editorial questions. In this text: 1. Introduction The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple (e.g., reordering) have transport protocol interactions, particularly with congestion control functionality. This is probably perfectly accurate, but I find it confusing. I think my problem is that the sentence sounds like the sender's goal was to cause problems with transport protocol mechanisms. I think it means - senders use multiple DSCPs to obtain different QoS treatments within a 5-tuple - a side effect of using multiple DSCPs is that packets with different DSCPs will often be reordered - this side effect causes problems with transport protocol mechanisms that expects largely in-order delivery, particularly with congestion control functionality Am I reading this correctly? In this text: 2.1. RTP Background The STUN and TURN protocols were originally designed for use of UDP, I’m not sure what “for use of UDP” means. Is this “to use UDP as a transport”? however, TURN has been extended to use TCP as a transport for situations in which UDP does not work [RFC6062]. When TURN selects use of TCP, the entire real-time communications session is carried over a single TCP connection (i.e., 5-tuple). http://tools.ietf.org/html/rfc7350 has been published recently, defining DTLS as a transport for STUN. Is that in any way relevant to this section? I feel horribly pedantic for even asking this, but in this text: 3.2. Traffic Classifiers and DSCP Remarking DSCP markings are not end-to-end in general. Each network can make its own decisions about what PHBs to use and which DSCP maps to each PHB. While every PHB specification includes a recommended DSCP, and RFC 4594 [RFC4594] recommends their end-to-end usage, there is no requirement that every network support any PHBs would this be “support any PHBs beyond Default Forwarding”? In this text: 5.1. DiffServ, Reordering and Transport Protocols Transport protocols provide data communication behaviors beyond those possible at the IP layer. An important example is that TCP [RFC0793] provides reliable in-order delivery of data with congestion control. is there a better reference for TCP than RFC 793? Isn’t that a version of TCP that does NOT have congestion control? Perhaps draft-ietf-tcpm-tcp-rfc4614bis-08 ... Alternatively, if you dropped “with congestion control”, you might still be making your point … reliable, in-order delivery is beyond what IP does.
... So, for two arbitrary network endpoints, there can be no assurance that the DSCP set at the source endpoint will be preserved and presented at the destination endpoint. Rather, it is quite likely that the DSCP will be set to zero (e.g., at the boundary of a network operator that distrusts or does not use the DSCP field) or to a value deemed suitable by an ingress classifier for whatever network 5-tuple it carries. ... In general operational experience is it is unsafe if you are going to employ dscp marking in your your network, to not sanitize other dscp marking on ingress, which leads to a really fun tautology in that in order to use it you have to break it first.
draft-ietf-6man-why64
Section 4.2
o Router implementations: Router implementors might interpret IETF
standards such as [RFC6164] and [RFC7136] to indicate that
Maybe avoid any accidental confusion by using "specifications" rather
than "standards"
The SecDir review looks good, thank you for your work on the draft. https://www.ietf.org/mail-archive/web/secdir/current/msg05118.html
This is a nice document, thanks for taking the time to write it. = Section 1 = "The bits in the IID have no meaning and the entire identifier should be treated as an opaque value [RFC7136]." I understand what this means based on RFC7136, but it seems like it would be a little more clear to re-use the language from that document directly, e.g., "The bits in the IID may have significance only in the process of deriving the IID and once it is derived the entire identifier should be treated as an opaque value [RFC7136]." = Section 4.5 = This is probably not worth mentioning in the draft, but I'll write it down since the thought occurred to me: it's conceivable to argue that there could be a privacy benefit of shortening the IID, if it became so short that a hardware address could not be embedded in it. This benefit is quite obviously outweighed by the drawbacks you already describe in this section I think, but just food for thought.
draft-ietf-weirds-object-inventory
I think there is no harm at all in this being an RFC and using abstain to nitpick doesn't seem right (or at least, I don't understand why the stated abstains aren't nitpicking).
I'm with Benoit and Alissa here. Not everything needs to be an RFC.
I don't see any mention of privacy concerns with ant of the elements suggested for the RDAP model in this draft. Although I think the sec and response drafts should be the ones to state what actions can be taken, this one describes the elements that should be in the data model (but apparently doesn't match up exactly), so noting which are privacy sensitive might be helpful. I would have thought that was one of the motivators for this work, but that wasn't included in the description for section 1. I do think this change should be made, but also think the changes are more important in the sec and response drafts.
I see no value in publishing this document as an RFC. I think it would be great to keep the information in the wiki for all to peruse, but I don't think anyone will want to read the RFC a year from now, much less several years from now. But I understand that this has been discussed and decided, so I will accept that I'm in the rough, and will abstain.
I'm with Barry -- this seems like it would have made more sense if published on a wiki, as a research paper, or in a slide deck. If the choices made in the protocol documents actually linked back to these findings for justification, I might see it differently, but at present there does not seem to be much connection between these findings and some of the design decisions made in the protocol. The data formats in the protocol don't seem to support every field that was discovered in this study, nor does there seem to be any consistent metric that was used for deciding whether to include a particular field based on its prevalence in these findings.
conflict-review-donley-behave-deterministic-cgn
I'll go with Spencer's assessment
Taking into account that draft-sivakumar-behave-nat-logging, referred to in the draft, is now draft-ietf-behave-ipfix-nat-logging-04, I wonder whether we shouldn't add BEHAVE in " that this work is related to IETF work done in the SUNSET4 WG". On the other hand, BEHAVE is now closed. Not too sure. Regards, Benoit