Stephen Farrell: Discuss [2015-07-08 04:42 PDT]:
This might seem like a lot of discuss points, but it's really two main ones (privacy and use of TLS) broken out into what I think are separable questions that might help us get the discussion done quicker.
(1) I'm not sure I'm following the use-cases for this but clearly this protocol could be used as part of a pervasive monitoring toolkit, to track users or client-devices with very fine granularity. So a) can you explain the main valid use-case(s) and b) did you consider RFC7258 in developing this protocol? The answers here might well result in a few changes to my other discuss points below. I also had a quick peek at 5460, but note that pre-dates 7258 by quite a bit and I'm also not clear how or if this protocol has the same goal of restoring routes. Note also that I am not claiming that there are no good uses for this protocol, I'm just asking what (some of) those are and how you considered the PM issue.
(2) I also think you need to add (or reference) privacy considerations text here - the information accessible via this could have significant privacy impact.
(3) Along the lines of (1) - can you say why all of the various bits of data one could return are needed by the requestor here? If not, then isn't there a good data-minimisation case to be made for profiling down the information returned to the requestor? I think one can validly argue that the answers we arrived at in 2009 (for 5460) might not be those on which we'd reach consensus today, but this draft seems to (quite understandably) assume that 2009's answers are still good enough. Did the WG consider that?
(4) Having TLS is good. But I don't get why you've not reversed the TLS client/server roles to make the requester the TLS server, since it seems to me that authenticating and authorizing the requestor here is the main thing and not authenticating the DHCP server. So why not reverse the TLS roles? (I'll clear this quickly but wanted to check in case it'd not occurred to folks.)
(5) The TLS mutual authentication requirement is underspecified. The sentence in 9.1 isn't really enough I think, you need to say that all TLS sessions MUST be mutually authenticated and then that has administrative consequences that might need more text. For example, the DHCP servers need to trust the set of CAs that requestors use - is it ok to be just silent on that? I also wonder about naming and other things - does there need to be some profile of how the DHCP server is named vs. a TLS certificate?
(6) Why not just make the use of TLS mandatory or RECOMMENDED here anyway - would that really hurt?

Alissa Cooper: Discuss [2015-07-07 21:15 PDT]:
My understanding from the discussions surrounding draft-ietf-6man-default-iids was that RFC 6282 constitutes an exception to the main recommendation ('By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed the underlying link-layer address in the IID') because the header compression scheme in RFC 6282 requires that the IID be based on the link layer address. I see no text that justifies a similar requirement in this document. I think if this document is going to specify generating the IID from the device address as the only address generation scheme for link-local addresses, it needs to provide a justification for that. Otherwise, the default address generation scheme should be one that generates an opaque IID of limited lifetime. The possibility that the device address is generated randomly and refreshed on each power cycle is important to note, but is not by itself sufficient justification given what I assume is the wider deployment of static device addresses. If the v6 address can provide better privacy protection than the device address, it should.
On that point, there also seems to be a discrepancy between Section 3.2.2 and Section 5. Section 3.2.2 states:
'(After a Bluetooth LE logical link has been established, it is referenced with a Connection Handle in HCI. Thus possibly changing device addresses do not impact data flows within existing L2CAP channels. Hence there is no need to change IPv6 link-local addresses even if devices change their random device addresses during L2CAP channel lifetime).'
Section 5 states:
'The IPv6 link-local address configuration described in Section 3.2.2 strictly binds the privacy level of IPv6 link-local address to the privacy level device has selected for the Bluetooth LE. This means that a device using Bluetooth privacy features will retain the same level of privacy with generated IPv6 link-local addresses.'
If the IID remains the same even when the device address changes, then the IID can be used to correlate activities of the device for the full lifetime of the IID, which goes beyond the lifetime of the device address. So the 'privacy level' afforded by the device address is not the same as that of the IID. If this document is going to specify the generation of IIDs based on device addresses, why not regenerate the IID when the device address is regenerated?

Alissa: need to check... bigger picture, recommendation came about after ?? was published... need to accomodate. "in future need to think about compression vs tracking", this is the time... fresh eyes on it... is there something else that would be better? are we stuck for every case of power limitations+?

Brian: this document is only using link layer in IPv6, only seen between bluetooth and ??, not seen as global IPv6 address

Alissa: "they leak all over the place"... not clear to me if that happens with bluetooth...

Brian: every time bluetooth attaches, link-local will change; people who have limited follow some options in this document; don't know we should put bluetooth-LE in same classification...

Alissa: I understand desire to explain which exceptions always make sense... but... there was recent email indicating that in many cases device address isn't changing... seems to be a disconnect how it's actually implemented

Brian: I fully agree we want to make sure the IPv6 address does the right thing

Alissa: if you always had IPv6 address changing randomly, you wouldn't have to trust link layer

Joel: if it's stable at the link layer, you're kind of done... if tagged, it will leak

Alissa: where address are remaining static at link layer, kind-of a short-term thing... I can respond about link-layer addresses... you can do other things...

Stephen: we should push back on "I'm not making it any worse"... we should be making it better

Brian Haberman: Discuss [2015-07-09 05:30 PDT]:
Updated position based on feedback from Int-Dir review (Suresh Krishnan)...
I don't object to the publication of this document, but there are some issues that need to be remedied.
1. Section 5 provides the considerations for selecting prefixes. However, those considerations are incomplete. RFC 7421 provides the analysis for the use of the /64 boundary. The Homenet Architecture (RFC 7368) discusses various Homenet-related issues around not getting sufficient address space to allocate /64 prefixes to links. RFC 6164 discusses the use of 127-bit prefixes on point-to-point links. Why does this section not mention any of these considerations when selecting a prefix?
2. I am raising Alvaro's point about the impact of topology changes to a DISCUSS. I think there needs to be sufficient discussion in the document on the impact of topology changes on the prefix assignment algorithm and the impact of changing prefix assignments on nodes in the network. This ties in to the point raised by Brian Carpenter on the claim in the Introduction that this algorithm can be used in 'fully autonomic as well as professionally managed networks'. This is especially true when convergence is described as occurring 'eventually'.
3. I understand that this document became standalone when the HNCP and DNCP documents split. What dependencies/assumptions does this document have on either one of them? There appears to be some assumptions on the Node ID and the flood algorithm.
4. How does the algorithm deal with prefix delegations that have holes (e.g. RFC6603)? This text seems to preclude such delegations.
5. Section 6 discusses Listener nodes. Does there need to be some discussion/warning about links that consist of all Listeners? The link will not get a prefix assigned to it in such a situation.
6. How does this approach deal with asynchronous link state changes?

Alia: I haven't reviewed all documents... if part of a link fails, that doesn't mean that prefix needs to be redefined; it's not clear how you bootstrap this... in ISIS you get ?? from each of the routers... I'm not concerned about the algorithm, but e.g. how it sees what a link is

Jari: I didn't think we were saying kill-everything-and-start-over

Alia: in order for bootstrapping to work, you need details not in the draft; pieces I'd like to see

Jari: I'll follow up... ultimately you have to do something...

Alia: two pieces: stability and bootstrapping... I want to see dependencies

Jari: think that's reasonable, in my implementation this hasn't been a problem

Alia: the assumptions are not specified; we can talk offline

(audio problem)

Cindy: hope I fixed it...

Amy: Terry has dropped, hopefully he'll rejoin

Alia: I think he wos about to ask if Alvaro had concerns

Brian: let's start the conversation in email, we can pick it up in Prague

Terry: (rejoined, audio problem came back)

Amy: Brian

Brian: let's put this in AD-followup; if we can't clear it up in email, we'll find a time in Prague

Barry Leiba: Discuss [2015-07-07 11:17 PDT]:
This should be a very easy discussion to resolve:
-- Section 2.3 --
"A node SHOULD leave an MPL domain if it receives an updated MPL Parameter Configuration Option without a configuration for the MPL domain, unless it has overriding manual configuration on the MPL domain. In other words, if a node is configured to work as a MPL Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY stay on the MPL domain even if it receives an MPL Parameter Configuration Option without configuration for the MPL domain."
I'm confused by this, because it appears to contradict itself.
Some questions might help he understand:
If I receive an updated MPL PCO that lacks a config for the MPL domain, then there are two possible situations:
Case 1: I do *not* have an overriding manual config for the domain. In this case, the text says that I SHOULD leave the domain. Is that correct? Is it OK in this case for me to decide to stay on the domain anyway, even if I have no manual configuration for it?
Case 2: I *do* have an overriding manual config for the domain. In this case, the text seems to say that it's entirely my choice ('MAY') whether or not I stay on the domain or leave it. Is that correct?
Please discuss this with me, so I can suggest how to make the text clearer, depending upon the answers to those questions.

Alia Atlas: Discuss [2015-07-08 12:57 PDT]:
In general, this draft is well-written and easy to understand. I do have a few points of technical clarity that I think are important.
First, a minor point on the 'Reserved' bits. In Sec 2.1, it says 'Z (7 bits): Reserved. Should be 0.' and then in Sec 2.2:
' Clients MUST discard the MPL Parameter Configuration Option if it is invalid (e.g., it sets reserved bits).' Frequently, Reserved bits are available for future enhancements - so setting to zero on write and ignoring the value on read is a useful default. If these bits are really always going to be zero and interpreted as an error, then could you rename them to MBZ (Must Be Zero) and indicate in the field definition that a value other than zero is an error. Also, from what I read in the rest of the draft, if an invalid option is received, that could cause the client to be removed from the MPL region. Could you clarify in the document what the expected behavior is if an invalid option is discarded? Is that like having no option? Is that pretending that the client didn't get one and staying with the previous option? It seems like it would be pretty easy to remove a client from the MPL region by flipping a bit. I would also like to see better clarification of how an option is considered invalid; while it may seem obvious, it's these details that impact interoperability. In the write-up, I don't see any indications that there have been interoperable implementations yet?
Second, given that the meaning of the *_IMAX values is based on RFC6206 (as indicated in the update history) and that the *_IMAX and *_IMIN are confusing values, PLEASE have a reference to RFC6206. To continue, it seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - as is explained in RFC6206 where *_IMAX is the number of doublings and *_IMIN is the value in milliseconds. However, in draft-ietf-roll-trickle-mcast-12, Section 5.4, the definition of DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given as:
'DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN has a default value of 10 times the expected link-layer latency.
'DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN.
'CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined in [RFC6206], for MPL Control Message transmissions. CONTROL_MESSAGE_IMIN has a default value of 10 times the worst-case link-layer latency.
'CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined in [RFC6206], for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 minutes. '
Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is only an 8-bit value, they are expected to have different ranges. Additionally, it's quite unclear which actually needs to be divided by TUNIT. The draft describes this as happening for DM_IMIN and C_IMIN, but then goes on to say
' Note that all time values (Trickle timers and expiration periods) are in TUNIT milliseconds precision. For example, if TUNIT is 20 and the data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50.'
Unfortunately, the draft doesn't describe which parameters are time values and apparently draft-ietf-roll-trickle-mcast-12 has some confusion as well. For instance, CONTROL_MESSAGE_IMAX is defined as a time value (5 minutes).
I suspect that the solution here is to clarify/fix draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the parameters are defined, indicate which are considered 'time values', and clean up the language in Sec 2.1.
Thanks! It looks like a useful document to address an operational problem once these clarity issues are addressed.

Brian Haberman: Discuss [2015-07-08 07:15 PDT]:
Some of these points come from Bernie Volz's INT-Dir review...
1. This is one of the few options that is not a singleton, as defined in section 16 of RFC 7227. While the use of multiple options seems appropriate here, it would be best to clarify that clients (section 2.2) and servers (section 2.4) must be able to support multiple instances of this option. Given the discussion around supporting multiple MPL domains in draft-ietf-roll-trickle-mcast, I would expect there to be situations where the option appears multiple times.
2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion of the role of the MPL Domain Address and include a reference to [I-D.ietf-roll-trickle-mcast].
3. In section 2.6 (Operational Considerations), the text is a bit odd. Why should a parameter set not be updated more often than twice the Information Refresh Time? How does the failure to refresh the option play with text in section 2.3 that indicates a missing option means the node should leave the MPL domain? Perhaps defining what 'failure to refresh' means (i.e., I think it refers to lack of a DHCPv6 server response to a Renew or Information Request). Note also that Information Refresh Time is only applicable to Information-Request messages (see RFC 4242) so work may be needed as to how this this sections relate to Renew/Rebind operations? I am also not sure why 2.6 is a standalone section when it appears to be only applicable to clients and should be in either section 2.2 or 2.3.

Stephen Farrell: Discuss [2015-07-09 04:32 PDT]:
I have one thing I'd like to check. Maybe this just works fine, but how does this function work with PCP authentication? E.g. in Figure 1, is the left-most client authenticating to the middle or rightmost server? I think I could imagine either answer being desirable and don't see a way that both could be supported.

Spencer Dawkins: Discuss [2015-07-09 05:14 PDT]:
This should be an easy Discuss to resolve.
I was surprised to see
"In addition, this goes against the spirit of NAT gateways. The main purpose of a NAT gateway is to make multiple downstream client devices making outgoing TCP connections to appear, from the point of view of everything upstream of the NAT gateway, to be a single client device making outgoing TCP connections. In the same spirit, it makes sense for a PCP-capable NAT gateway to make multiple downstream client devices requesting port mappings to appear, from the point of view of everything upstream of the NAT gateway, to be a single client device requesting port mappings."
limited to TCP connections. Is this intentional? https://tools.ietf.org/html/rfc6887#section-2.2 certainly lists other transport protocols.
Is it correct to say
"In addition, this goes against the spirit of NAT gateways. The main purpose of a NAT gateway is to make multiple downstream client devices to appear, from the point of view of everything upstream of the NAT gateway, to be a single client device."
?
Please note that I'm not objecting to the focus on TCP in this text:
"Where this document uses the terms 'upstream' and 'downstream', the term 'upstream' refers to the direction outbound packets travel towards the public Internet, and the term 'downstream' refers to the direction inbound packets travel from the public Internet towards client systems. Typically when a home user views a web site, their computer sends an outbound TCP SYN packet upstream towards the public Internet, and an inbound downstream TCP SYN ACK reply comes back from the public Internet.

Jari Arkko: Discuss [2015-07-08 15:24 PDT]:
This is a small issue but there's something wrong with the references. Noted in Suresh Krishnan's Gen-ART review. Please look at this, so that we are not missing something important:
- RFC 2046 and 2183 are referenced in the text but not defined as references. Please add them as either normative or informative references.
- RFC5322 is never referenced in the text. Is some intended text missing?

Jari Arkko: Discuss [2015-07-08 15:31 PDT]:
Thanks for writing this document. This is a really small thing, but the Gen-ART reviewer (Tom Taylor) noted a couple of things. The one that I would raise as a discuss so that we do not forget to fix is first:
Section 4.2: ~~Oops this is some mistaken text.~~
Please make sure your text is complete here. It was unclear if this was intended as actual example text, or if there was a problem in the draft on this point.
And, please remove or specify the '[CITE]' references.
These are indeed minor things and I'm only raising them (as an easily clearable) Discuss because with them, the draft seems incomplete, and I worry that we have forgotten something.

Kathleen Moriarty: Comment [2015-07-08 17:48 PDT]:
While I agree a wiki would be nice, I do agree with Peter's point that our current setup doesn't make use of wiki's easy as the content can be difficult to locate. It is easier to just refer people to RFCxxxx right now. If we could improve the tools, then a wiki might be a great option.

Barry Leiba: Comment [2015-07-07 12:53 PDT]:
While I see no conflict with IETF work here, I also think this would be better published as a wiki page (perhaps on the working group chairs' wiki) than as an RFC. Perhaps we should have an easily found and well publicised ietf-wide wiki for these sorts of things.

Deborah Brungard (Routing)--- LISP wants to recharter, discussed on list, will discuss at meeting; should this be a joint-IAB agenda item?
Jari: ??
Deborah: identified need...
Jari: what do they want to recharter for?
Deborah: they'd like to go forward with a specific-case
BrianT: is the question whether the IAB should have input since it started in an IAB workshop... it's up to IESG, IAB generally not involved in a recharter
Jari: we can talk about it Sunday at Prague
Joel: we should probably reconsider the output of that workshop
Deborah: they'd like to get on with it
Jari: we'll discuss Sunday; I think it's great to get to standards-track; but should confess you don't have all the answers
audio interrupted with "This call has been disconnected"

*** Substantive Comments: ***
-- I think Robert Spark's secdir comments concerning an intermediary changing
the signaling of extensions deserves some thought.
-- section 5, several example paragraphs:
It's odd to find normative language in example. I _think_ the actual normative
text is all covered elsewhere--if so, it should be written descriptively here.
-- section 5, paragraph 6: ""Agreed parameters" MUST represent..."
That seems more a statement of fact than a normative statement. If it's
intentionally normative, the required condition is vague for a MUST.
-- 6.1, Numbered list entry "2", third bullet (and several similar assertions)
Do I understand correctly that the PMCE needs to know if the next extension
wants frames, in order to determine whether to build them? How would it know
that?
-- 9:
I’m surprised that there’s nothing here about intermediaries. For example, if
an endpoint chooses not to compress because of the mentioned issue with
encrypting compressed data, does it have to worry that some intermediary might
choose to compress it anyway?
-- 12.2, [CRIME]
Seems like this may need to be normative. I’m not sure the reader can fully
understand the security considerations without reading it.
***Editorial Comments:***
-- Section 3, first paragraph, last sentence:
That seems true anytime a draft or RFC defines terms--what is special about
these?
-- 3, third paragraph: "An extension in use next to extension"
The construction "next to" usually connotes adjacency, not order. I suggest
"The next extension in use" (without the "to").
-- 8, 2nd to last paragraph:
While you cited the LZ77 bits earlier, it would be useful to repeat that
citation here. This is where the information actually gets used.
-- 8.2.3.6:
It's odd to refer to anything done by a computer as "manual".

warren kumari's opsdir review (no further action required)
Be ye not afraid.
I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call may be
included in AD reviews during the IESG review. Document editors and
WG chairs should treat these comments just like any other last call
comments.
Document reviewed: draft-ietf-hybi-permessage-compression-22
Summary: Ready, no nits, no comments.
Details:
Well, this is a first -- I have never before performed a review
without finding at least some nits (typos, grammar, etc).
Because I feel bad about not having *any* comments I'll scrape the
bottom of the barrel -- I find the use of underscores jarring in e.g:
'This document references the procedure to _Fail the WebSocket
Connection_. ' and think these could be replaced with quotes instead.
I'll fully admit this is bikeshedding.
Oh, the title on Section 8 also looks a little odd, was the 'p'
intended to be uppercase? Could go either way...
There are no operational impacts that I can see, other than less
traffic on the wire, and more code in network devices if any of them
are websocket servers or clients (e.g for management).
W
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

This might seem like a lot of discuss points, but it's really
two main ones (privacy and use of TLS) broken out into what I
think are separable questions that might help us get the
discussion done quicker.
(1) I'm not sure I'm following the use-cases for this but
clearly this protocol could be used as part of a pervasive
monitoring toolkit, to track users or client-devices with very
fine granularity. So a) can you explain the main valid
use-case(s) and b) did you consider RFC7258 in developing this
protocol? The answers here might well result in a few changes
to my other discuss points below. I also had a quick peek at
5460, but note that pre-dates 7258 by quite a bit and I'm also
not clear how or if this protocol has the same goal of restoring
routes. Note also that I am not claiming that there are no good
uses for this protocol, I'm just asking what (some of) those are
and how you considered the PM issue.
(2) I also think you need to add (or reference) privacy
considerations text here - the information accessible via this
could have significant privacy impact.
(3) Along the lines of (1) - can you say why all of the various
bits of data one could return are needed by the requestor here?
If not, then isn't there a good data-minimisation case to be
made for profiling down the information returned to the
requestor? I think one can validly argue that the answers we
arrived at in 2009 (for 5460) might not be those on which we'd
reach consensus today, but this draft seems to (quite
understandably) assume that 2009's answers are still good
enough. Did the WG consider that?
(4) Having TLS is good. But I don't get why you've not reversed
the TLS client/server roles to make the requester the TLS
server, since it seems to me that authenticating and authorizing
the requestor here is the main thing and not authenticating the
DHCP server. So why not reverse the TLS roles? (I'll clear this
quickly but wanted to check in case it'd not occurred to folks.)
(5) The TLS mutual authentication requirement is underspecified.
The sentence in 9.1 isn't really enough I think, you need to say
that all TLS sessions MUST be mutually authenticated and then
that has administrative consequences that might need more text.
For example, the DHCP servers need to trust the set of CAs that
requestors use - is it ok to be just silent on that? I also
wonder about naming and other things - does there need to be
some profile of how the DHCP server is named vs. a TLS
certificate?
(6) Why not just make the use of TLS mandatory or RECOMMENDED
here anyway - would that really hurt?

- I had a look at the DHCPv4 equivalent - is the plan that those
be as close to one another as possible? If so, then the
"DHCPTLS" vs. "STARTTLS" thing seems odd, as does the
duplication of text in the two - would it not have been better
to develop a separate spec for how to talk to a DHCP v4 or v6
server using TLS? I think that'd be cleaner for all sorts of
reasons, e.g. naming, the roles of the peers, TLS extensions
needed etc.
- sections 8/9: Sending the DHCP REPLY with no status code as a
way to indicate acceptance of TLS seems very hacky. Why is that
a good plan? I don't think STARTTLS works that way in other
protocols for example.
- somewhere: I think it'd be a fine thing if you referred to
RFC7525/BCP195 and said implementations need to follow that in
how they use TLS.
- section 10: why is (the usually mythical:-) 3315 a MUST NOT
here? I don't get that. I could see it being an EDONTCAR but I
don't see the harm if one did go mad and try use 3315. And I
could maybe, possibly, with a lot of a nose-holding, see a
universe in which one might use TLS server auth for the DHCP
server and 3315 to authenticate the requestor, so it seems odd
to rule that out in this way.

-- general:
I understand this to be a way for a third party to "actively" monitor client
DHCPv6 bindings. Does that warrant some privacy considerations?
-- section 8.2:
The selection of secure vs insecure mode MAY be administratively selectable. It
seems like there should a stronger requirement for an administrative option to
force secure mode.

No objection, but if taken into account, Scott's OPS DIR feedback would improve
the document.
=================================
Scott,
We totally agree that this protocol should be able to restrict who
gets the information about what is going on with the DHCP server.
We *thought* that we had that covered...
The current draft has TLS connections as a SHOULD, and includes the
following text at the end of section 9.1:
> In the event that the DHCPv6 server sends a REPLY message without
> DHCPv6 status code option included (which indicates success), the
> requestor is supposed to initiate a TLS handshake [RFC5246] (see
> Section 8.2). During the TLS handshake, the DHCPv6 server MUST
> verify the requestor's digital certificate.
> If the TLS handshake is not successful in creating a TLS connection,
> the server MUST drop the TCP connection.
The intent here is that in requiring the verification of the
requestor's digital certificate that the server would also be able to
restrict connections to requestors that it considered acceptable.
We recently took a lot of words out of the security considerations
section on restricting connections to acceptable requestors because
that would have required using IP addresses, which everyone thought
was useless.
We didn't put more words back in about the TLS certificates, but
perhaps we should have?
Anyway, there are several issues:
1. Does the verification of the TLS certificates allow the server to
be able to determine that a requestor is or is not allowed to access
the active leasequery capability?
2. We believe that there is more than one way to utilize
certificates to decide if a requestor is allowed. We also sort of
assumed that was documented elsewhere and wasn't something that we
needed to detail in this draft. Do you know of a draft we could
reference on how to do that, or failing that, know of text we could
incorporate that explains how to do that.
If #1 is no, then we are confused because we thought that was the
point of verifying the digital certificates (instead of just using
the certificate to ensure that the link is encrypted).
===============================
Scott's answer:
it is always useful to spell out what is on your mind
if you are projecting that the use of certs equals access control you should
just say that
a few extra words would dog a LONG way
Scott

- I strongly support Alissa's DISCUSS and would argue that we
ought really try hard to minimise any privacy leakage being
contributed to by this specification. We basically have one
chance to do this well, after which any leakage becomes yet
another reason to not do the job well in future in other places.
(Based on dodgy but often heard arguments like: "but IPv6/BTLE
already dos this badly, so there's no additional harm in
foo/IPv6/BTLE being just as bad.")
I also note that the fact that some of that leakage relates to
link local addresses doesn't really reduce the damage so much
with a radio based link layer. (Yes, good l2 crypto could help
there, but only if always used everywhere for all packets and I
don't know if BTLE requires that, I suspect it does not.)
- The secdir review in early June made a couple of points that
are worth addressing. [1] I have not seen any response to that
review. (Apologies if I missed it.)
[1] https://www.ietf.org/mail-archive/web/secdir/current/msg05744.html

I also fully support Alissa's discuss points on privacy.
As the draft says, 'when available' for the security and privacy options, so
anything that can be done should be to improve this for IPv6 over bluetooth.
Having done some testing of the ability to monitor bluetooth, it can go up to
70' in certain conditions and much less in other conditions. We were also able
to monitor through windows. This testing was done with an earlier bluetooth
version monitoring point to point sessions in various conditions (it was a fun
day at work). People and their IoT devices are much more exposed than they
realize especially since the security and privacy options hat can be
implemented often are not. That's just a long way of stating that I support
Alissa's discuss.

Because of the history of this document, significant explanation was needed --
and provided -- in the shepherd writeup. Thanks, Gabriel, for the good job on
that. The writeup says:
> This support from BT SIG should address the remaining DISCUSS on
> the original document.
It does, indeed (it was my DISCUSS), and this document looks great. I'm glad
things were sorted out with BT SIG, and thanks to everyone for all the work on
this.

In this text:
New addresses are typically generated each time a
device is powered on. In random addresses all 48 bits are
randomized. Bluetooth LE does not support device address collision
avoidance or detection. However, these 48 bit random device
addresses have a very small probability of being in conflict within a
typical deployment.
is the working assumption that if a random device address conflict does arise,
either a human will recycle power because that's what humans do with electronic
devices that don't work, or if no impatient human is available, the device will
power off and back on eventually and everything will be fine?
I'm looking at this text:
In the rare case of Bluetooth LE random device address conflict, a
6LBR can detect multiple 6LNs with the same Bluetooth LE device
address, as well as a 6LN with the same Bluetooth LE address as the
6LBR. The 6LBR MUST ignore 6LNs with the same device address the
6LBR has, and the 6LBR MUST have at most one connection for a given
Bluetooth LE device address at any given moment. This will avoid
addressing conflicts within a Bluetooth LE network.
and guessing that the Bluetooth LE network doesn't have addressing conflicts,
but does that mean that the device that's trying to use a random device address
that would cause addressing conflicts if it wasn't being ignored will give up
and choose another random device address?

My understanding from the discussions surrounding draft-ietf-6man-default-iids
was that RFC 6282 constitutes an exception to the main recommendation ("By
default, nodes SHOULD NOT employ IPv6 address generation schemes that embed the
underlying link-layer address in the IID") because the header compression
scheme in RFC 6282 requires that the IID be based on the link layer address. I
see no text that justifies a similar requirement in this document. I think if
this document is going to specify generating the IID from the device address as
the only address generation scheme for link-local addresses, it needs to
provide a justification for that. Otherwise, the default address generation
scheme should be one that generates an opaque IID of limited lifetime. The
possibility that the device address is generated randomly and refreshed on each
power cycle is important to note, but is not by itself sufficient justification
given what I assume is the wider deployment of static device addresses. If the
v6 address can provide better privacy protection than the device address, it
should.
On that point, there also seems to be a discrepancy between Section 3.2.2 and
Section 5. Section 3.2.2 states:
"(After a Bluetooth LE logical link has been established, it
is referenced with a Connection Handle in HCI. Thus possibly
changing device addresses do not impact data flows within existing
L2CAP channels. Hence there is no need to change IPv6 link-local
addresses even if devices change their random device addresses during
L2CAP channel lifetime)."
Section 5 states:
"The IPv6 link-local address configuration described in Section 3.2.2
strictly binds the privacy level of IPv6 link-local address to the
privacy level device has selected for the Bluetooth LE. This means
that a device using Bluetooth privacy features will retain the same
level of privacy with generated IPv6 link-local addresses."
If the IID remains the same even when the device address changes, then the IID
can be used to correlate activities of the device for the full lifetime of the
IID, which goes beyond the lifetime of the device address. So the "privacy
level" afforded by the device address is not the same as that of the IID. If
this document is going to specify the generation of IIDs based on device
addresses, why not regenerate the IID when the device address is regenerated?

Why does this draft reference v4.1 of the Bluetooth spec rather than v4.2?
In 3.2.2, I think RFC 7217 should be added to the list in this sentence:
"A 6LN can also use a randomly
generated IID (see Section 3.2.3), for example, as discussed in
[I-D.ietf-6man-default-iids], or use alternative schemes such as
Cryptographically Generated Addresses (CGA) [RFC3972], privacy
extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or
DHCPv6 [RFC3315]."
Similarly, in Section 5, s/[I-D.ietf-6man-default-iids]/[RFC7217]/ in this
sentence: "For non-link local
addresses implementations have a choice to support, for example,
[I-D.ietf-6man-default-iids], [RFC3972], [RFC4941] or [RFC5535]."

from opsdir review by niclas comstedt
Hi,
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
This document is for the Standards Track.
This document defines how IPv6 is transported over Low Energi Bluetooth
leveraging 6LoWPAN techniques for 802.15.4.
I have no real feedback. The document is well written and makes sense to me.
The compression details are a bit outside of my experience so didn’t get into
all the details there. There are no real nits (one single referenced draft has
a newer version) and my only semantical small change would be:
- 3.2.4 first paragraph, remove “in this document”. Header compression as
defined … … is REQUIRED as the basis … … Those two first sentences are a little
repetitive which adds to it
- 3.3, should this just be moved up under 3.2.1 or something? Its only
referenced there unless I’m missing something and doesn’t need the context of
what comes after.

This draft chooses the wrong input to the hash function. Other
specifications, even those that do not otherwise use ASN.1 use
the SubjectPublicKeyInfo ASN.1 structure for that. I raised
that point in the WG and during IETF LC but was in the rough.
Nonetheless, this will I believe need to be done over later
when or if there is a need to identify a public key in a
cross-protocol or similar context. That's a waste of effort
for no good reason. The world won't end though.

-- Section 6 --
This specification adds to the instructions to the Designated Experts
for the following IANA registries, all of which are in the JSON
Object Signing and Encryption (JOSE) protocol category [IANA.JOSE]:
o JSON Web Key Types
o JSON Web Key Elliptic Curve
o JSON Web Key Parameters
Because you're changing the DE instructions, either this document needs to
"update" 7517 and 7518 (where those registries are defined), or it needs to
update the registries to add itself to the reference field
("[RFC7518][RFCxxxx]"). And in either case, it needs to make it clear in the
introduction that Section 6 provides additional instructions to the designated
experts for those three registries. Otherwise, it's too easy for DEs for those
registries not to notice this update. [I know the current DEs are well aware
of it. But that's not the point.]

- section 3: I expected some security text here, not to say that
this all needs to be encrypted but rather to say that because
this is flooding, you can't really encrypt it and that hence
this scheme is only suited for smaller deployments and/or those
with lower layer security already in place. (And hence also
probably small.)
- section 3: Similarly, you could also add some privacy text to
the effect that this scheme only applies where the privacy
characteristics of the various prefixes involved are all
roughtly similar, that is, where there's no real privacy
difference in which prefixes end up with which nodes. (Mind you,
I need to ponder that a bit myself to see if it's really the
case;-)
- sections 4 & 5: I found this impossible to understand in a
(quick) linear reading. I'd find actual code easier tbh. It's
interesting that Barry found this clear though (I did not,
clearly:-) so this isn't a discuss. But why didn't you first
provide an overview of the algorithm?
- Where is the evidence that the algorithm converges? I'd have
thought there would be a reference to an academic publication
that also described the algorithm and a proof for convergence.

I don’t object to the publication of this document, but I do have several
comments that I think should help in making it clearer.
Comments:
(1) Topology Changes. The Introduction reads: "Assigned prefixes do not change
in the absence of topology or configuration changes. . .the algorithm also
ensures that all assigned prefixes. . .remain unchanged, unless. . .the
topology changes and renumbering cannot be avoided.” But later in Section 3.
(Applicability Statement) you wrote that the "algorithm supports dynamically
changing topologies”.
What are then topology changes that may result in renumbering being unavoidable?
(2) To Destroy. The term “destroy” is used in several places, but it is not
defined in Section 2. It looks like Section 4.2. (Overriding and Destroying
Existing Assignments) might define it, but instead it uses “destroy” to to
define “Removing an Assigned Prefix”. Destroy seems to be the local action
that may result in removing a Published Assigned Prefix. Please add to the
terminology.
(3) Unique Node IDs. Having unique Node IDs is important to break ties in the
algorithm. However, the text seems to allow the existence of duplicate IDs for
some (undefined) period of time. Section 3. (Applicability Statement) reads:
"Node IDs MAY change over time and be the same on multiple Nodes at some point,
but each Node MUST eventually have a Node ID which is unique among the set of
participating Nodes.” How long is “eventually”? The sentence is (at best)
confusing, but it reads as contradicting to me: If multiple Nodes can have the
same ID, how can the MUST be enforced? You mention in the Security
Considerations section that an “attacker. . .using a Node ID used by another
Node may prevent the correctness and convergence of the algorithm. . .”
Allowing for multiple Nodes to have the same ID is then an attack for however
long “eventually” is.
The same type of language (“eventually” and “at some point”) is used on other
places. It would be nice to tighten the text up (where appropriate); for
example, the part about “Each Node MUST have a set of non-overlapping Delegated
Prefixes..” seems to be ok as it doesn’t mention that at some point the
Delegated Prefixes may overlap, just that the sets may not be the same.
(4) How is a Node ID defined? What I mean is: is it a number, a string,
whatever? It sounds like the specific definition may be left to the Flooding
Mechanism, is that true? If so, then I think it would be a good idea to call
it out — this also means that as an operator I may have to redefine my Node ID
assignment mechanism if I decide to change the Flooding Mechanism. The
ordering of the Node IDs will also depend on how they are defined.
BTW, “Node ID assignment mechanism” is mentioned in the Security
Considerations, but not defined anywhere. It may of course not be an
in-the-network mechanism and simply a manual assignment of IDs — it would be
nice to say something about what it is (or may be).
Nits:
(A) Consistency in naming.
For example: “Available prefix” is defined, but later “available prefix” is
used (I think) to refer to the same thing. Given that common words are used
(Available, Valid, etc.) it is important to differentiate when the specific
term is used vs just the generic use of the word.
Precedence is defined in Section 2.1, but later not used in Section 4. That is
ok (except for the text in Section 4 that calls it out) given that it looks
like the term is used when defining Best Assignment and Valid — I say it "looks
like it" because “precedence” (not “Precedence”) is used. Should it be
“Precedence”?
Valid (capital V) is also defined but not used later. There are a couple of
places where maybe “Valid” should replace “valid”.
(B) Section 2. (Terminology) In the definition of “Private Link”, I think the
“MAY” should really be “may”. There’s nothing normative about the example.
(C) s/received from the Flooding Mechanism/received through the Flooding
Mechanism

I agree with Alvaro and Brian on the need to clarify topology changes. In Sec
3, I see " The algorithm supports dynamically changing topologies:
o Nodes may join or leave the set of participating Nodes.
o Nodes may join or leave Links.
o Links may be joined or split."
and what isn't clearly stated is that when a link fails (partially or fully) or
comes into existence , is that a topology change?
For instance, if a link fails, surely that shouldn't be a topology change for
the prefix assignment, but rather a matter for routing to handle. I do see in
Sec 4.3 "When a Link is removed, all Assigned Prefixes assigned to that Link
MUST be destroyed." Perhaps a link removal isn't considered a topology change
in this context because it doesn't cause renumbering??
How is a new Link added to be considered? How does a router know that its end
of a link is the same link as on another router? How is a link "removed"
versus merely down?
An assumption seems to be that the flooding mechanism can work without any
prefix numbering. That's fine but would be good to state. I'm a bit twitchy
about the bootstrapping.

Updated position based on feedback from Int-Dir review (Suresh Krishnan)...
I don't object to the publication of this document, but there are some issues
that need to be remedied.
1. Section 5 provides the considerations for selecting prefixes. However, those
considerations are incomplete. RFC 7421 provides the analysis for the use of
the /64 boundary. The Homenet Architecture (RFC 7368) discusses various
Homenet-related issues around not getting sufficient address space to allocate
/64 prefixes to links. RFC 6164 discusses the use of 127-bit prefixes on
point-to-point links. Why does this section not mention any of these
considerations when selecting a prefix?
2. I am raising Alvaro's point about the impact of topology changes to a
DISCUSS. I think there needs to be sufficient discussion in the document on
the impact of topology changes on the prefix assignment algorithm and the
impact of changing prefix assignments on nodes in the network. This ties in to
the point raised by Brian Carpenter on the claim in the Introduction that this
algorithm can be used in "fully autonomic as well as professionally managed
networks". This is especially true when convergence is described as occurring
"eventually".
3. I understand that this document became standalone when the HNCP and DNCP
documents split. What dependencies/assumptions does this document have on
either one of them? There appears to be some assumptions on the Node ID and
the flood algorithm.
4. How does the algorithm deal with prefix delegations that have holes (e.g.
RFC6603)? This text seems to preclude such delegations.
5. Section 6 discusses Listener nodes. Does there need to be some
discussion/warning about links that consist of all Listeners? The link will
not get a prefix assigned to it in such a situation.
6. How does this approach deal with asynchronous link state changes?

* ID-nits complains about the malformed 2119 keywords text in the Terminology
section. It would be good to use the entire boilerplate for the 2119 keywords.
* The terminology section claims that the definitions are ordered to avoid
forward reference, but that is not the case. For example, Link refers to Shared
Link and Private Link, Delegated Prefix refers to Assigned Prefix, etc.
* The definition of Node ID is unclear. What do you mean by "The set of
identifiers MUST be strictly and totally ordered". A node id is a single
identifier, right?

Tim Chown did the opsdir review. I think some of the criticism is well take and
it looks like discussion is ongoing to address it.
I think brians discuss and the outstanding comments are sufficient to address
it.
Tim's review follows
Hi,
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
Overall, I believe the draft is ready with minor issues, mainly around
presentation and clarity.
As one part of the proposed HNCP protocol, having this distributed prefix
distribution algorithm documented is a Good Thing.
Homenet has considered previous work in this area, e.g.both
draft-arkko-homenet-prefix-assignment-04 and
draft-baker-homenet-prefix-assignment-01 have been discussed in homenet. While
those don’t need to be cited, it’s worth noting that homenet has been seeking a
self-configuring prefix distribution mechanism for some time (3-4 years).
General comments:
The draft very much throws the reader in at the deep end. It would be very
useful if a high-level description of the philosophy of the algorithm were
included in the introduction, such that those principles are in the reader’s
mind when they read through the remainder of the document, including the
description of the algorithm.
Related, there is very little content in the draft. It does not cite or mention
that it is used by HNCP, nor does it cite RFC 7368. There is no text describing
(even just briefly) why this approach is favoured, or any rationale why this
approach is most favoured for HNCP (or regarding the claimed convergence). If
those are documented elsewhere, a link/reference would be useful for the reader.
Regarding RFC 7368, the draft could claim compliance with that RFC, in
particular Section 3.4.3, given the support for assigned prefix stability
described within the draft. Given it is a homenet draft, this would seem
appropriate.
Because the draft describes an algorithm, rather than a detailed protocol, many
parts of the document omit specifics, e.g. the format of a Node ID, or of the
flooded messages. If the document aims to provide the means for a developer to
build an implementation of HNCP, this could be problematic. Are these formats
going to be described elsewhere, or are they already described somewhere?
What happens if there are not enough prefixes to assign a prefix to each Link?
Is there still convergence? What is the failure mode here? RFC 7368 considers
this an ‘error’ mode that needs to be indicated to the user. Or would you state
an assumption of enough prefixes? Some brief explicit discussion of this, early
in the text, would be useful. At present it’s hinted at at the end of Section
4.2 and end of Section 6.
The Terminology section could precede the Introduction for clarity.
Specific comments:
Page 1:
What does “or for other private purposes?” mean in the abstract?
Perhaps the abstract can mention that the algorithm can support prefix
stability over reboot given the presence of stable storage.
What does ‘eventually converges’ mean?
Page 2:
Line 3 of introduction, ‘prefix’ rather than ‘prefixes’.
As a homenet draft, should ‘professionally managed networks’ be mentioned here?
Maybe say “as well as other deployment scenarios”?
Page 3:
How is the flooding mechanism made reliable? Or is that down to the method of
implementation?
Page 6:
Is this really an applicability statement? I think of something more general
here, by default, which this isn’t.
Terms such as 'non-overlapping’ and ‘disjoint’ are used - perhaps be consistent.
Page 7:
At the top, perhaps also mention here that in the moment context ULA prefixes
might also be configured by this method, alongside globally unique prefixes.
As an aside - where a moment has two routers advertising a /48 ULA, can this
algorithm be used to pick only one to use, or would it by default create prefix
assignments on each Link for each 48?
Page 8:
The term ‘considered’ is introduced a little abruptly here in the first bullet
point of 4.1.
Page 9:
It may be better for ADOPT_MAX_DELAY and BACKOFF_MAX_DELAY to be explained
earlier, rather than forward referenced to Section 7.
Page 10:
‘is not valid’ - maybe that should be ‘is not Valid’, matching the upper case
used in the terminology section?
Page 12:
So if the upstream ISP goes away, what happens? Do all Links become unnumbered
for global prefixes, continuing to use ULAs if configured? Some clarity here
would be nice.
Page 13:
For Randomness, is there a privacy aspect here, that a homenet or a network
using this algorithm may choose to randomise prefixes internally over time for
privacy reasons (ignoring the complexity that may be introduced elsewhere as a
result)? We have considered IID and link layer address randomisation elsewhere
recently; this could be argued as another tool in that toolbox. Though adding
such text with subsequent comments may lead to delays in publication :)
Page 16:
I don’t think the Node ID assignment mechanism has been described anywhere?
The security considerations do not hint at any solution for the noted threats.
There are of course comparative threats to similar algorithms.
Tim
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

- I don't get the update model - if all MPL forwarders have
to use the same parameters but they don't all do DHCPv6 at
the same time, then won't new parameter settings take a
while to propagate to most of the network? And won't that
cause a problem? Don't you need a "start using this set of
parameters in N seconds" field in the dhcp option to handle
that? This is not a DISCUSS as I think it relats to Barry's
so please try address this when addressing that.
- please do not pretend rfc 3315 is a solution for anything
unless you mean it and I don't think you do. 3315 is I think
the canonical example for mythical security:-(

-- section 2.6, 1st sentence :" A parameter set for an MPL domain SHOULD NOT be
updated more often
than twice of Information Refresh Time"
The preposition "of" is incorrect. Normally I would say leave that for the RFC
editor, but it's not clear to me if this means "twice the information refresh
time" or "twice during an information refresh time (interval)". (I assume the
former, but it could be more clear.)

From the OPS-DIR review done by Menachem:
The document is quite readable.
Section 2.1 could be improved if for each parameter defined a reference would
be given to indicate where the parameter is defined. I found most of them in:
draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the
Proactive_Forwarding flag is used for.
Section 4 discusses Security Considerations but I think that some phrases in
the paragraph are too general. Example: "other methods for security should be
applied" does not indicate what these methods are or where to look for them.
Another Example: "To protect attacks from outside of the network, unneccessary
DHCPv6 packets should be filtered on the border router between the ROLL network
and the Internet" - what is meant by "unnecessary DHCPv6 packets"?
NITS
====
Section 2.3 First Paragraph Second Sentence - Remove 'is'
OLD ==> Note that there may be cases in which a node may fail is to
join a domain SUGGEST ==> Note that there may be cases in which a node may fail
to join a domain
Section 2.3 Last Paragraph is not clear.
Perhaps the last sentence should read "In this case" (instead of "In the case").
Section 2.6 - First Sentence - Not Clear
Is the update rate not to be more than twice the Information Refresh Time? Not
clear to me how many updates are allowed in an Information Refresh Time.
Should the word 'of' be replaced by 'the'.
"more often than twice the Information Refresh Time".
Suggest rephrasing this paragraph.

Thank you for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05835.html
I'll follow along with the discussion from Stephen and Barry's comments, but
don't have any additional to add.

This should be a very easy discussion to resolve:
-- Section 2.3 --
A node SHOULD leave an MPL domain if it receives an updated MPL
Parameter Configuration Option without a configuration for the MPL
domain, unless it has overriding manual configuration on the MPL
domain. In other words, if a node is configured to work as a MPL
Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY
stay on the MPL domain even if it receives an MPL Parameter
Configuration Option without configuration for the MPL domain.
I'm confused by this, because it appears to contradict itself.
Some questions might help he understand:
If I receive an updated MPL PCO that lacks a config for the MPL domain, then
there are two possible situations:
Case 1: I do *not* have an overriding manual config for the domain. In this
case, the text says that I SHOULD leave the domain. Is that correct? Is it OK
in this case for me to decide to stay on the domain anyway, even if I have no
manual configuration for it?
Case 2: I *do* have an overriding manual config for the domain. In this case,
the text seems to say that it's entirely my choice ("MAY") whether or not I
stay on the domain or leave it. Is that correct?
Please discuss this with me, so I can suggest how to make the text clearer,
depending upon the answers to those questions.

-- Section 2.1 --
option_len: Length of the option. It SHOULD be 16 (without MPL
domain address) or 32 (with MPL domain address).
"SHOULD", really? What else *can* it be, and still be valid? Is there any
legitimate reason I might make it something else? Or should this just say
this?:
NEW?
option_len: Length of the option, which is 16 if no MPL domain
address is present, or 32 if there is an MPL domain address.
END

In general, this draft is well-written and easy to understand. I do have a few
points of technical clarity that I think are important.
First, a minor point on the "Reserved" bits. In Sec 2.1, it says "Z (7 bits):
Reserved. Should be 0." and then in Sec 2.2: " Clients MUST discard the MPL
Parameter Configuration Option if it is invalid (e.g., it sets reserved bits)."
Frequently, Reserved bits are available for future enhancements - so setting
to zero on write and ignoring the value on read is a useful default. If these
bits are really always going to be zero and interpreted as an error, then could
you rename them to MBZ (Must Be Zero) and indicate in the field definition that
a value other than zero is an error. Also, from what I read in the rest of
the draft, if an invalid option is received, that could cause the client to be
removed from the MPL region. Could you clarify in the document what the
expected behavior is if an invalid option is discarded? Is that like having no
option? Is that pretending that the client didn't get one and staying with the
previous option? It seems like it would be pretty easy to remove a client from
the MPL region by flipping a bit. I would also like to see better
clarification of how an option is considered invalid; while it may seem
obvious, it's these details that impact interoperability. In the write-up, I
don't see any indications that there have been interoperable implementations
yet?
Second, given that the meaning of the *_IMAX values is based on RFC6206 (as
indicated in the update history) and that the *_IMAX and *_IMIN are confusing
values, PLEASE have a reference to RFC6206. To continue, it seems that
DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - as is explained
in RFC6206 where *_IMAX is the number of doublings and *_IMIN is the value in
milliseconds. However, in draft-ietf-roll-trickle-mcast-12, Section 5.4, the
definition of DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are
given as:
" DATA_MESSAGE_IMIN The minimum Trickle timer interval, as defined in
[RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMIN
has a default value of 10 times the expected link-layer latency.
DATA MESSAGE_IMAX The maximum Trickle timer interval, as defined in
[RFC6206], for MPL Data Message transmissions. DATA_MESSAGE_IMAX
has a default value equal to DATA_MESSAGE_IMIN.
CONTROL_MESSAGE_IMIN The minimum Trickle timer interval, as defined
in [RFC6206], for MPL Control Message transmissions.
CONTROL_MESSAGE_IMIN has a default value of 10 times the worst-
case link-layer latency.
CONTROL_MESSAGE_IMAX The maximum Trickle timer interval, as defined
in [RFC6206], for MPL Control Message transmissions.
CONTROL_MESSAGE_IMAX has a default value of 5 minutes.
"
Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is only
an 8-bit value, they are expected to have different ranges. Additionally,
it's quite unclear which actually needs to be divided by TUNIT. The draft
describes this as happening for DM_IMIN and C_IMIN, but then goes on to say
" Note that all time values (Trickle timers and expiration periods) are
in TUNIT milliseconds precision. For example, if TUNIT is 20 and the
data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
DM_IMIN shall be set to 50."
Unfortunately, the draft doesn't describe which parameters are time values and
apparently draft-ietf-roll-trickle-mcast-12 has some confusion as well. For
instance, CONTROL_MESSAGE_IMAX is defined as a time value (5 minutes).
I suspect that the solution here is to clarify/fix
draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the
parameters are defined, indicate which are considered "time values", and clean
up the language in Sec 2.1.
Thanks! It looks like a useful document to address an operational problem once
these clarity issues are addressed.

In Sec 2.1, it says: "OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet
assigned)" Instead of "not yet assigned", it would be better to use TBD1 and
then reference TBD1 in the IANA section. That makes it easy and clear how to
update the draft as it is prepared to be an RFC.

Some of these points come from Bernie Volz's INT-Dir review...
1. This is one of the few options that is not a singleton, as defined in
section 16 of RFC 7227. While the use of multiple options seems appropriate
here, it would be best to clarify that clients (section 2.2) and servers
(section 2.4) must be able to support multiple instances of this option. Given
the discussion around supporting multiple MPL domains in
draft-ietf-roll-trickle-mcast, I would expect there to be situations where the
option appears multiple times.
2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion
of the role of the MPL Domain Address and include a reference to
[I-D.ietf-roll-trickle-mcast].
3. In section 2.6 (Operational Considerations), the text is a bit odd. Why
should a parameter set not be updated more often than twice the Information
Refresh Time? How does the failure to refresh the option play with text in
section 2.3 that indicates a missing option means the node should leave the MPL
domain? Perhaps defining what "failure to refresh" means (i.e., I think it
refers to lack of a DHCPv6 server response to a Renew or Information Request).
Note also that Information Refresh Time is only applicable to
Information-Request messages (see RFC 4242) so work may be needed as to how
this this sections relate to Renew/Rebind operations? I am also not sure why
2.6 is a standalone section when it appears to be only applicable to clients
and should be in either section 2.2 or 2.3.

1. I support Barry's DISCUSS on the lack of an option potentially forcing a
node to leave an MPL domain.
2. Why is the text in Appendix B not in the Operational Considerations section?
3. Please be consistent with the use of MUSTs and SHALLs. Pick one.
4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a client
discard the option if the reserved bits are set? I would think you'd want to
use a new option if you're changing things drastically? But it certainly is
your choice as to whether you want to do that. Perhaps a better reason is if
one of the not-permitted values is used (such as 0 and 'all-bits-set') where
are clearly reserved? 0 in many of these case could be bad since that would
yield 0 time values? This really is up to you, but do think about what you
might want to do any maintain backwards compatibility. Adding a new flag bit to
the reserved field is probably not going to break things if existing
implementations ignore the bit(s).

- 62 pages! urgh;-) But it's actually a pretty good spec, just
be nice if it were shorter.
- 4.2.1.2 - I don't get why HTTP authentication (401 etc) is
being used here. Is it that you want personalisation but you're
hacking that via HTTP authentication? I'd argue that not trying
for that via the TXT RR scheme would be better, that is, to say
that you don't get personalisation when you use a TXT RR to get
the path. Or just say the server can try set a cookie if it
wants personalisation. I can't see that clients here will
sensibly handle HTTP authentication in any case (well, not
unless you adopt something like RFC7486:-) - for example, how
would a HTTP UA pick a username here? (The same comment applies
to all HTTP authentication uses in the draft.)
- 4.2.1.3 - maybe useful to point forward to section 8 here
and/or say that you can't go from TLS to port 80 via the
.well_known 3xx.
- 4.2.2.1 - it'd have been nice to indicate the amount of data
that'd be downloaded here just so's some developer doesn't make
a bad assumption about when it's ok to do this.
- section 8, 2ndary-primary MUST use TLS - thanks! And for the
SHOULD use for client-server.
- section 9: thanks!

intro: "gold standard" is being a bit too keen IMO, I'd say
toning the language down a bit would be better.
intro: 3DES may be the "only other widely supported" cipher
for IPsec, but that's not true more generally.
section 2 says: "As the ChaCha20 block function is not applied
directly to the plaintext, no padding should be necessary."
That "should" could be confusing as written if a reader thinks
it means their code doesn't have to do padding. It might be
better to e.g. say something like "In theory no padding is
needed for this cipher, however, in keeping with..."
section 3: Is "SHOULD inlude no padding" really right? I'd
have thought a MAY was better there. "MUST accept any length"
is also a bit odd - what if I (try:-) add loads of padding?
Appendices: thanks for those - I assume someone checked them
for you? (I didn't:-)

This is easier than usual to read for this sort of draft :-)
-- Section 1, 1st paragraph:
I concur with Stephen's comment. Furthermore, this entire paragraph pretty much
reads like advertising copy. Can it be toned down a bit?
-- 8.1 (Normative References)
The reference to [RFC7539] is a normative downref. I don't see it on the
downref registry, nor was it mentioned in the last call notice. (For the
record, I think it's a reasonable downref.)

Thanks for addressing an aspect of security in relation to PCP, especially the
Advanced Threat Model from RFC6887.
I have a few comments
1) I'm sure the RFC editor will pick these up, however there is some comma
usage in the document that caused me to re-read some of the paragraphs to
understand. The Abstract is one example of this. I'm certainly no expert so
perhaps have a skim over this: http://www.grammarbook.com/punctuation/commas.asp
2) s 3.1.1, please consider rewording the text "Section 5.1 updates the PCP
request message format to have a result code." to something like "Section 5.1
updates the PCP request message format with result codes for the PCP
Authentication mechanism" ...The wording as it stands seems a little
non-specific.
3) Basic DoS attacks (such as state bloat) are mentioned in the security
section, are there any complex DoS attacks that can be leveraged using the PCP
authentication mechanism itself?

Thanks for getting this done.
- Why didn't you choose to encrypt the PCP payloads after
you've got a shared secret? If the answer here is "oops, we
never thought about that," then this will likely turn into a
DISCUSS, but I expect the WG did think about it, in which case
I reckon my preference for confidentiality doesn't trump the WG
consensus.
- How would this work in a home network where the f/w is not
managed by the ISP and there'd otherwise be no EAP
infrastructure? That could be out-of-scope or require some
new/odd EAP implementation and no change to this protocol, and
that is probably fine, but I do wonder.
- 3.3: Is this really needed? I wonder if we could do without
it. The protocol would be simpler if this wasn't needed and
simpler == more-secure in general.
- 5.11: would s/issued the credentials/issued the EAP
credentials that will be used to authenticate the client/ be
better? As-is, it's a tiny bit confusing maybe.
- 6.2: Maybe this is being overly paranoid, but would it be
worth saying that in all failure cases when you say discard the
message, you mean to not process it's content? With a very
perverse reading of the current text, I might be able to argue
that I could process the message content first and only then
check the authentication afterwards. Yes, that'd be fairly
spectacularly dim, but that kind of thing does sometimes
happen. (If there's a better place in the draft to put some
text on that, that's just fine.)

I have one thing I'd like to check. Maybe this just works fine,
but how does this function work with PCP authentication? E.g.
in Figure 1, is the left-most client authenticating to the
middle or rightmost server? I think I could imagine either
answer being desirable and don't see a way that both could be
supported.

I have these comments and questions:
1) There is no clear definition of what a PCP proxy really is. Section 1. shows
it as a pure signalling entity only w/o any NAT functionality (no mapping
functionality) but the document body itself talks about PCP proxies having a
mapping table (and also the possibility of not -- Section 3.4.1). Adding such a
statement about the PCP proxy is or can be to the intro or the terminology
section is a good thing.
2) Section 3.1 talks about hairpinning:
There is a potential noteable issue in terms of network management: If the PCP
proxy is performing the hair pinning for the Assigned External Address, the
byte counters on the PCP server and the proxy will differ for the Assigned
External Address. This might be worth to note in a network managment section
(or elsewhere in the document).

This should be an easy Discuss to resolve.
I was surprised to see
In addition, this goes against the spirit of NAT gateways. The main
purpose of a NAT gateway is to make multiple downstream client
devices making outgoing TCP connections to appear, from the point of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
view of everything upstream of the NAT gateway, to be a single client
device making outgoing TCP connections. In the same spirit, it makes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sense for a PCP-capable NAT gateway to make multiple downstream
client devices requesting port mappings to appear, from the point of
view of everything upstream of the NAT gateway, to be a single client
device requesting port mappings.
limited to TCP connections. Is this intentional?
https://tools.ietf.org/html/rfc6887#section-2.2 certainly lists other transport
protocols.
Is it correct to say
In addition, this goes against the spirit of NAT gateways. The main
purpose of a NAT gateway is to make multiple downstream client
devices to appear, from the point of
view of everything upstream of the NAT gateway, to be a single client
device.
?
Please note that I'm not objecting to the focus on TCP in this text:
Where this document uses the terms "upstream" and "downstream", the
term "upstream" refers to the direction outbound packets travel
towards the public Internet, and the term "downstream" refers to the
direction inbound packets travel from the public Internet towards
client systems. Typically when a home user views a web site, their
computer sends an outbound TCP SYN packet upstream towards the public
Internet, and an inbound downstream TCP SYN ACK reply comes back from
the public Internet.

A comprehensive document, and only a small comment that should be easy to
clarify if I have misinterpreted.
---
4.14. SSRC
---
It might be my stylistic approach, but I prefer the more complete definition
from RFC3550 (Section 3:) that starts with:
"Synchronization source (SSRC): ..."
I understand that the document is long, but do consider that if a reader finds
this tome the words provided in 4.14 don't seem to fix the opacity problem the
draft is addressing.

While I won't stand in the way of publishing this document, I think that it may
be better suited to live on in a Wiki where it can be updated in a more fluent
fashion. I didn't get a particularly warm fuzzy feeling from phrases like
these: "This document provides *some* clarity..." or "For each concept *an
attempt is made*...". That text can be made firmer, but the point remains: it
is probable that the concepts could be refined and the taxonomy may evolve.

A few editorial comments:
-- section 1: "in Real-Time Transport Protocol"
in _the_ Real-Time Transport Protocol...
"... has previously often been"
has previously been
-- 4.1 and children:
It's confusing figuring out which section references are to CLUE vs to other
sections in this document.

Thanks for this document. I particularly like the figures 1, 2 and 7, as entry
points in the document.
For completeness, you might consider:
- adding a few words about the boundary between analog and digital (in the
Physical Stimulus, I guess) - inserting in figure 7 that a RTP session "is a
group communications channel which can potentially carry a number of RTP
Streams"

Wow, I wish we'd had this document when RTCWeb and CLUE were starting in
parallel! Thank you all for producing it.
Jitter is called out separately from delay in 2.1.16, but not in 2.1.18,
2.1.23, or 2.1.24. Was that intentional?
2.1.16 also calls out inter packet spacings separately. I'm not sure if that's
also relevant in 2.1.18, 2.1.23, or 2.1.24, but wanted to ask.

In an ideal world, my YES ballot for would really be "YES,
sadly I suppose we need this kind of thing but wouldn't life be
much better if DNSSEC was much easier to deploy, ah well, too
late now I guess:-("
- section 1.1: Where is the definition? I see you telling me
what an NTA isn't, but not what it is. I think what you want to
say is that an NTA is a domain name or a pair (a domain name
and a sub-domain of that) represented in a resolver
implementation-specific manner so that DNSSEC validation is
turned off from the higher domain name down (to the subdomain
if we have a pair). Is that right?
- 1.1: RFC5914 is a little misleading as a reference as that
was done for X.509 stuff and is nothing to do with DNSSEC.
Maybe it'd be worth pointing that out just in case some reader
somewhere goes and gets confused.
- section 2: what do you mean happens "once per quarter"?
- section 2: "immediately restores" - well that depends on the
screw-up doesn't it? Or are you saying (where?) that an NTA
must only be put in place when the screw-up is specifically and
only about and because of DNSSEC and where ignoring DNSSEC will
result in things "working"? For example, DNSSEC could fail
because all my nameservers are entirely offline due to a f/w
mis-configuration that blocks loads of port 53, but putting in
place an NTA won't help then. (As it happens, I'm right now
gettting a f/w to re-unblock 53 so I can serve some DNSSEC
records so this issue is one that's close to the bone for me:-)
- Section 6: 1st 2 sentences repeat repeat dnssec-failed.org
too too many times.
- random question: why not have an "I'm just testing" RR that I
could put in alongside my ZSK DNSKEY as I start to play with
DNSSEC? Or maybe that exists already.

-- General:
This is just an observation, since this is informational draft. I do not expect
or suggest any action on it. (But if it had been standards or BCP track, I
might have made it a discuss.) If I understand this correctly, it suggests that
resolvers be configured to stop validating known broken names. This of course
has the risk of circumventing the protection that a domain intended by using
DNSSEC in the first place. The draft does discuss those risks. But I would have
been happier to have seen something with a tone more along "We know you are
going to do this thing, and it's probably better than globally switching to a
non-validating resolver-- so here's the risks, and here's some ways to minimize
those risks" (which I think might have been good BCP material) rather than
"This is a good practice to work around broken DNSSEC configurations."
-- section 1.2, last paragraph, last sentence:
Out of curiosity, has this been an issue?
-- 2, 2nd paragraph:
Can an operator be reasonably expected to be able to confirm that a domain is
being operated by its rightful owner?
-- 2, 2nd to last paragraph:
Since the requirement to limit the time an NTA is used is a MUST, it seems like
the ability to configure that time should also be a MUST.
-- 2, last paragraph:
Why is the requirement not to affect another branch weaker than the requirement
not to affect other names higher up the same branch?
-- 4, first paragraph, last sentence:
This seems to favor erring on the side of keeping the NTA. I think security
would suggest erring on the side of removing the NTA.
Editorial and Nits:
-- If you plan to use capitalized 2119 terms, please add the appropriate
boilerplate and a 2119 reference.
-- section 4, first paragraph: "It is therefore RECOMMENDED that NTA
implementors SHOULD" redundant 2119 keywords (RECOMMENDED and SHOULD )
-- 7, paragraph 4, last sentence:
I suggest adding “At the time of this writing…”, and add additional text to
remind people these may change over time.
-- 7:
This section jumps into 2nd person. I don’t want to stand on formality, but it
would be good to keep a consistent tone across the draft.

= Sec 2 =
"Technical personnel trained in the operation of DNS servers MUST
confirm that a failure is due to misconfiguration"
s/MUST/must/ - seems odd to put a normative requirement on people to do
something in people land
= Sec 4 =
"The lifetime MUST NOT exceed a week. "
Would be good to provide the motivation for where this number comes from.

1.2, last paragraph:
Is this document attempting to place normative requirements on existing
markdown implementations? Or should the 2119 keywords in this section be more
statements of fact (and use descriptive language?)
6.1.2, first paragraph, last sentence:
Does this refer to section 6.1.2, or 6.1 and children? If the latter, and if
there is no expert reviewer, who is expected to perform those checks
(automatically or otherwise?)
Editorial:
IDNits reports a few missing or unused references, please check.
There is at least one occurrence of a word inclosed in slashes like /so/. I
assume that's intended for emphasis--but whether it's for that or some other
reason it would be good to explicitly mention it.
section 1.1, last paragraph: Does "author's intent" refer to the author of this
draft, or of markdown?
Figure 1: The continuation characters and some markup, impinge on the border.

This is a small issue but there's something wrong with the references. Noted in
Suresh Krishnan's Gen-ART review. Please look at this, so that we are not
missing something important:
- RFC 2046 and 2183 are referenced in the text but not defined as
references. Please add them as either normative or informative references.
- RFC5322 is never referenced in the text. Is some intended text missing?

1. From Nevil's OPS DIR feedback:
> 2. The markdown Example (Section 5) is helpful, but it doesn't seem
> to have an obvious end marker - it just runs on into section 6.
> Does markdown have something like an end-of-file marker you could
> use to make that obvious?
And answered by Alexey:
>
> Not really, it is a textual format with no special end marker.
>
> I suppose the whole example can be surrounded by some markers and a note
added that they are not a part of the example?
could we use the <CODE BEGINS> and <CODE ENDS>?
2. "A companion document [MDMTUSES] provides additional Markdown background and
philosophy."
There is more than that. See the draft-ietf-appsawg-text-markdown-use-cases
abstract: "Background information, local storage strategies, and additional
syntax registrations are supplied"
3. Editorial
OLD: [fOo]
NEW: [foo]

I'm not making this a DISCUSS because I think I've raised a similar issue
before (with this same AD and doc shepherd, no less, I think) and lost the
argument, but I don't get why this document is informational. It specifies a
parameter syntax for fragment identifiers. If one implementation follows the
syntax specified here and another implementation uses some other syntax defined
somewhere else, how is this spec helping the two implementations interoperate?

(Sorry I included this in my comments for the other markdown doc
but it relates to this one. I'll take this out of my ballot comment for
that but not re-tx the mail.)
- Please respond to the secdir review [1] which raised a couple
of questions that deserve answers. (Apologies if I missed your
answer to that.)
[1] https://www.ietf.org/mail-archive/web/secdir/current/msg05830.html

I agree with others that mixing the IANA Registrations in the use cases draft
is odd -- specially when the draft-ietf-appsawg-text-markdown document also
exists. Without the IANA Considerations I would also think that use cases
would be better off in a Wiki. [No need to reply to this, as it has been
talked about elsewhere..]
I do have one nit:
Section 2 reads: " [MDMTREG] (draft-05) only defines two parameters: the
charset parameter (required for all text/* media types) and the variant
parameter." I think that is still true in the latest version of that draft;
the "draft-05" reference should be taken out.

Like others have commented, I find it a bit odd to mix the IANA registrations
with the rest of the material in this draft.
Some of the editorial comments (from myself below, from others, and from
IDNits) makes me wonder if this draft was quite finished?
While I don't think it makes sense to change course this late in the process
for this draft, I am skeptical that the material in sections 1 and 2 will
benefit from being in an RFC. I think that it might have made more sense to
capture it in a working group wiki, or similar repository. (But again, no point
in changing now.)
-- 3.3, additional parameters:
I’m not sure I understand why the list is broken in to “stuff to turn off” and
“new stuff”.
Editorial:
IDNits has quite a bit to say, some of which might even be relevant. Please
check.
There are a number of words enclosed in /slashes/ or *asterisks*. I assume this
is intended for emphasis. (Or perhaps as performance art when discussing
methods for formatting text :-) ) But it seems odd for an RFC. If it stays, I
suggest picking one method and sticking with it. (If it means something
different, please mention that in the text.)
-- section 4 refers to Appendix C, but the draft has no appendices.

Thanks for writing this document. This is a really small thing, but the Gen-ART
reviewer (Tom Taylor) noted a couple of things. The one that I would raise as a
discuss so that we do not forget to fix is first:
Section 4.2: ~~Oops this is some mistaken text.~~
Please make sure your text is complete here. It was unclear if this was
intended as actual example text, or if there was a problem in the draft on this
point.
And, please remove or specify the "[CITE]" references.
These are indeed minor things and I'm only raising them (as an easily
clearable) Discuss because with them, the draft seems incomplete, and I worry
that we have forgotten something.

Easy to fix DISCUSS: The RFC 2119 boilerplate is missing:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

- I was surprised by the RFC2119 keywords in a use cases document (which I
first thought of as an applicability document") But, actually, according to the
abstract, it's way more than a use cases document: "Background information,
local storage strategies, and additional syntax registrations are supplied.",
It's really the companion document of draft-ietf-appsawg-text-markdown. Maybe
the title is wrong, and should be something such as text/markdown strategies
and registrations?
" [MDMTREG] (draft-05) only defines two parameters:"
I guess there is nothing special about version 5. The latest version is v8
Editorial:
- section 1, para 4. That confused me until I saw figure 1
OLD: On the formal end of the spectrum is markup
NEW: On the formal end of the formatted text spectrum is markup
- There are a couple of [CITE] reference, including this one: Character set
interoperability is well-studied territory [NB: CITE?] To be completed I guess.

I saw "KARP Design Guide" in the abstract and I had not idea what it was: it is
not explained in the document. Not even in the acronym section. After some
(very quick and easy, I admit) research, I propose
OLD:
This document analyzes the current state of Intermediate system to
Intermediate system (IS-IS) protocol according to the requirements
set forth in [RFC6518] for both manual and auto key management
protocols.
NEW:
This document analyzes the current state of Intermediate system to
Intermediate system (IS-IS) protocol according to the requirements
set forth in Keying and Authentication for Routing Protocols (KARP)
Design Guidelines [RFC6518] for both manual and auto key management
protocols.

For the IESG - the "why isn't this a wiki?" question comes up often enough with
documents like this one and
https://datatracker.ietf.org/doc/draft-secretaries-good-practices/ that perhaps
we should create a process guidance wiki. How long would that take?
If we wanted to do something about this, perhaps asking Nevil to check at
publication time whether we've created a wiki and inserting a pointer to it
would make sense?
I agree with publishing this draft as an RFC, because that's what we've got for
now, I'm just suggesting that we make it easy for the community to maintain the
text on an ongoing basis.

I'm not objecting but it is weird to have IETF process oriented stuff
(even if only advisory) handled via the ISE. For me, that should only
be done in cases where the text is something on which we can't get
IETF consensus (e.g. when the text says the IESG are a**holes:-). If
the text is something where we really should be able to get it done
in the IETF stream, then I think we ought do that.
I'd encourage everyone to think about whether this'd be better as
an IETF consensus RFC or else, as others have suggested, only as
a wiki.
But I'm not gonna try block it on that basis.

While I agree a wiki would be nice, I do agree with Peter's point that our
current setup doesn't make use of wiki's easy as the content can be difficult
to locate. It is easier to just refer people to RFCxxxx right now. If we
could improve the tools, then a wiki might be a great option.

While I see no conflict with IETF work here, I also think this would be better
published as a wiki page (perhaps on the working group chairs' wiki) than as an
RFC. Perhaps we should have an easily found and well publicised ietf-wide wiki
for these sorts of things.