IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-09-17. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
Telechat:
2.2 Individual submissions
2.2.1 New items
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
Telechat:
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1036 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
7. Working Group News
Amy: no BoF proposals yet, deadline tomorrow; coordination call Tuesday; currently five WGs working their way through process; do any of them need BoF slot?
1052 EDT Adjourned
(at 2015-09-17 06:06:32 PDT)
draft-ietf-mpls-mldp-node-protection
Thanks for adding the new security consideration text. If you change again please consider this tweak: s/(a PLR or a MPT)/(e.g., a PLR or a MPT)/
The shepherd writup says that there has been no explicit discussion of the two IPR disclosures. It's probably too late to worry about that for this draft, and both disclosures have the fairly common "we won't assert if you don't" terms. But I think we should encourage working groups to have more explicit discussion for IPR disclosures. -- 2.3, last paragraph: "Along with the PLR MP Status a MP FEC TLV MUST be included" Does that mean that both MUST be included, or if the first is included, the second MUST also be? -- 4.1.3, last paragraph: Just “recommended”? Is link flapping a minor enough that it doesn't justify a MUST? -- 6: It would be nice to show your work a bit more in the security considerations. This draft adds new protocol elements and procedures. If the working group has determined that those new bits add no new security concerns, it would be good to say why. Editorial and Nits: A (probably first) paragraph in the intro that defined exactly what the draft means by "protection" would be helpful. (The existing first paragraph talks about how you provide protection, but one must infer what this protects _against_. -- 1, 2nd paragraph: Lots of the terms here could use (informative) citations. -- 2.1, first paragraph: Consider s/"we are describing"/"we describe" -- 2.1, last paragraph, 2nd to last sentence, "See section 5": unbalanced parentheses. -- 2.2, 1st paragraph: s/"we are describing"/"we describe" -- 2.2, last paragraph: "protection mechanism don’t" -- Noun/verb disagreement (singular/plural) s/ help restoring/help restore -- 2.3, 2nd to last paragraph: I suggest the “A node N” phrase be moved to the first mention of N in this paragraph. "Removing a PLR address is likely due to a link failure, see the procedures as documented in Section 4.1. ": Comma splice. Consider a semicolon. "MUST encode PLR Status Value Element": Missing article. -- 3, 2nd paragraph: "Ln that was assigned to N via the normal mLDP procedures, and Label Lpx that was assigned for PLR (LSR1) for the purpose of node protecting MP LSP via node N." I can’t parse this sentence. (Incomplete sentence?) -- 3, 3rd paragraph: "For this reason, the FEC Label Mapping (FEC <R,X> : Lpx) sent by the MPT over the tLDP session to the PLR MUST include a Status TLV with MP Status including a new LDP MP status Value Element called the "Protected Node Status Value Element"." Convoluted sentence. Consider breaking into multiple, simpler sentences. -- 5, 1st sentence: s/we are organizing/we organize/
How long has this document been sitting around? The shepherd writeup says "Adrian Farrel is the responsible AD".
draft-ietf-trill-pseudonode-nickname
This was an easy document for me to read through (I have some exposure to TRILL
but am not skilled in the art). Thank you for that.
I did have some questions, but nothing at Discuss level.
In this text:
Introduction
Other methods are possible; for example the
specification in this document and the specification in [MultiAttach]
could be simultaneously deployed for different AAE groups in the same
campus. It is RECOMMENDED that only one method be adopted in a TRILL
^^^^^^^^^^^
campus. For example, if the method is [MultiAttach] is used, TRILL
switches need to support the capability indicated by the Capability
Flags APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the
method defined in this document is adopted, TRILL switches need to
support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a
TRILL campus that deploys both AAE methods, TRILL switches are
required to support both methods.
I'm not thinking that RECOMMENDED is an RFC 2119 RECOMMENDED, but more broadly,
I THINK this paragraph is saying, "using multiple methods on a TRILL campus
will work, but if you use multiple methods, all of the TRILL switches on the
campus MUST support both methods". Did I get that right?
If so ... you might give some justification for adopting only one method (my
guesses were capital expense? operating expense? complexity in
troubleshooting?), and perhaps even some explanation why you might adopt more
than one method (I was guessing that you'd use more than one because some of
your equipment doesn't support the method you want to use, but if TRILL
switches have to support both methods, that isn't the reason, is it?)
In this text:
3. Virtual RBridge and its Pseudo-nickname
Since RBv is not a physical node and no TRILL frames are forwarded
between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be
created for an RBv. RBv cannot act as a root when constructing
distribution trees for multi-destination traffic and its pseudo-
nickname is ignored when determining the distribution tree root for
TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST
be set to 0, and this nickname SHOULD NOT be listed in the "s"
^^^^^^^^^^
nicknames (see Section 2.5 of [RFC6325]) by the RBridge holding the
highest priority tree root nickname.
what happens if this SHOULD NOT is ignored? Do things still work?
I have two questions where it's not clear to me if this specification does or does not introduce new vulnerabilities. It could well be that it does not and these are handled elsewhere, but I'm not sure so... (1) How is authorization for being a member of an RBv handled? (2) If a rogue RB can add itself to an RBv can it arrange things so the rogue RB becomes the DF for the RBv? (If so, that would seem to create new DoS opportunities at least.)
-- section 12, last paragraph: Elaboration on the details would be useful. This draft adds new procedures; what analysis was done to show those new procedures have no new security impact? Editorial: -- 1.1, definition of AAE, "AAE is also referred to as edge group or Virtual RBridge in this document" Why use multiple terms for the same thing? This seems to create awkward wording in several places, where the text repeats things like “In an AAE group (i.e. RBv)…”
Agree with Spencer's first comment.
draft-ietf-pals-vccv-for-gal
A minor question ... I was somewhat surprised to see this statement.
1. Introduction
o Some operators are concerned that the inclusion of the PW CW will
increase the PW packet size.
It seems like the working group would know whether that's true (so, something
like "The increase in PW packet size due to the inclusion of the PW CW will
cause problems X, Y, and Z"), or it's not.
Is it true? If so, the issue isn't that operators believe there's a problem,
but that there's really a problem.
1) In the last paragraph of Section 3: " Note that the inclusion of a GAL following the PW LSE over a label switched path subject to Equal-Cost Multi-path (ECMP) load balancing can cause the OAM packet to take a different path through the network from the corresponding PW data packets. If that is not acceptable, then an alternative VCCV type needs to be used." Since the GAL is a Reserved label, it should not be included in a hash done for load-balancing. This is described in RFC 7325 Sec 2.4.5.1 bullet 3 " Special-purpose labels (label values 0-15) MUST NOT be used. Extended special-purpose labels (any label following label 15) MUST NOT be used. In particular, GAL and RA MUST NOT be used so that OAM traffic follows the same path as payload packets with the same label stack." Please correct the paragraph to add this reference. I know that there may be old implementations out there that do the wrong thing - but an RFC should refer to the correct behavior. The sentence in Section 7 " Attention is drawn to the possible absence of fate sharing between PW data packets and VCCV CC Type 4 packets described in Section 3 and Section 4." will also need updating. 2) The use of LSE as an unintroduced abbreviation is slightly confusing. Can you please expand it the first time to Label Stack Entry?
Is there a particular reason to request that the assigned MPLS VCCV CC Type be bit 3?
draft-ietf-dhc-access-network-identifier
I do support Alissa's and Stephen's Discusses.
(1) Did the DHC working group consider how this information, when sent without adequate protection between relay and dhcp server, could help in pervasive monitoring? If so, what was the conclusion reached? We have seen http header field information sent between infrastructure nodes being intercepted for that purpose, so this has to be similarly at risk. If the answer is that this is only to be used within a single network operator's setup (or a roaming arrangement) then that needs to be justified (as practical) and, if it can be justified (I'm not sure tbh), also made explicit. (2) I had a DISCUSS on the draft that became rfc 6757 about protection of this kind of data. In that context I think I was assured that everything (in PMIPv6) was IPsec protected so it was fine. Why, in what we now know is a more threated environment, is it ok to now have weaker protection when I was assured then that IPsec was in fact quite usable in PMIPv6? I think you maybe need to put in a MUST use IPsec requirement for this to be as safe. (3) section 7: MAY store - this is possibly sensitive information so you ought say that it SHOULD NOT be stored unless needed, and if stored, SHOULD be deleted as soon as possible. Storing sensitive information when not needed just shouldn't be considered acceptable anymore I think - is that reasonable?
- I (strongly) support Alissa's DISCUSS and will be interested in watching how that is resolved. Some of my DISCUSS points do overlap though so from my POV feel free to mix'n'match the discussions. Or to process first one then the other, whatever you think is best. - RFC6757 defines exactly this for PMIPv6. That implies that PMIPv6 should not be used to illustrate or motivate this, as that problem is solved. Perhaps you would be better off if you limited the scope of this to be used for networks that are some kind of extension to PMIPv6 only? (You'd need to define what kind I think.)
-- 4.3.2 The name of an 802.11 access point can imply the users location with a fair bit of precision, making it effectively count as location data. The draft needs more discussion of the privacy implications of that. -- 6: This section seems underspecified. There seems to be a missing discussion about interdependencies among options. For example, For example, network name is meaningless without the technology type. What is the minimum needed to be coherent?
I support Stephen's and Alissa's discusses, and look forward to their resolution. -- 4.3.1: This mentions how to interpret the network name for 802.11, 3GPP, and 3GPP2 networks. Is the use of this sub-option limited to those technology types? How should it be interpreted for other types? -4.3.2, Access-Point Name The paragraph refers to the MAC address of a device. Which device is it talking about? (e.g. end-device, base station, DHCP relay) -- 4.4.1: [SMI] probably needs to be a normative reference. -- 7, first sentence: This seems to be making a MUST level requirement for servers that do not implement this draft. Is this a new MUST, or is already specified elsewhere? (If the latter, then citation?) Editorial: -- 1, paragraph 2, First sentence: Missing article for DHCP relay agent s/add/adds/ -- 2, 2nd paragraph: Lots of missing articles for MAG. -- 3, SSID definition: s/the IEEE/an IEEE/ s/one network to the other/ one network from another/ -- 5.1, reserved: The reader’s “now” may be years from the authors' “now” :-) I suggest something to the effect of "At the time of this writing"
I would like to discuss the following point.
You define the "Vendor ID" and then the Operator Enterprise ID. Why don't you
reuse the RFC 6757 Operator-Identifier?
Operator-Identifier
The Operator-Identifier is the Structure of Management Information
(SMI) Network Management Private Enterprise Code of the IANA-
maintained "Private Enterprise Numbers" registry [SMI]. It
identifies the operator running the network attached to a specific
interface of the mobile access gateway.
I'm been confused by the following text and the figure 1, as it doesn't mention the dhcp relay-agents and servers The PMIPv6 extension as specified in [RFC6757] defines PMIPv6 options to carry access network identifiers in PMIPv6 signaling from Mobile Access Gateway (MAG) to LMA. MAG can learn this information from DHCP options as inserted by DHCP Relay agent before MAG. If MAG relays DHCP messages to LMA as specified in [RFC5844] this information can be inserted by MAG towards LMA in the forwarded DHCP messages. Figure 1 illustrates an example Proxy Mobile IPv6 deployment where Access Points (AP) acting as a DHCP relay agent inserts access network identifiers in DHCP messages relayed from the connected clients. The mobile access gateway learns this information over DHCP and delivers the information elements related to the access network to the local mobility anchor over Proxy Mobile IPv6 signaling messages. In this example, the additional information could comprise the SSID of the used IEEE 802.11 network and the identities of the operators running the IEEE 802.11 access network infrastructure. Discussing with Sri and Mark, I discovered my source of confusion. There are two cases, as discussed in https://tools.ietf.org/html/rfc5844#section-3.4: This specification supports the following two DHCP deployment configurations. o DHCP relay agent co-located with the mobile access gateway. o DHCP server co-located in the mobile access gateway. Either the DHCP server is on the LMA, and the MAG just forwards the DHCP message to the LMA. The LMA receives the access network identifiers from DHCP (the MAG just forwards the DHCP message, modified by the AP) Or the DHCP server is on the MAG, and then the PMIPv6 extension carries the access network identifiers to the LMA, learned with DHCP from the AP. However, in the context of WLAN-EPC interworking, the only supported mode is DHCP server collocation on the MAG. Hence the figure 1 focuses on this case. The text and the figure should be improved IMO. - I agree with Al Morton, in his OPS-DIR review. This draft specifies the optional capability in DHCP to identify access network ID and operator ID for the possible application of policy on operator-specific handling, traffic management, or differentiated services. Often these are carefully planned and controlled networking capabilities, so some form of ID integrity protection would be welcome. Thus, it's worrisome when the authors remind us in the Security Considerations section (9): ...DHCP itself is inherently unsecure and thus link-layer confidentiality and integrity protection should be employed to reduce the risk of disclosure and tampering. maybe s/should/SHOULD/ ? or stronger? Other solutions or explanation welcome.
Thanks for addressing the questions raised int he SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05811.html There was mention of IPsec use when relaying this information and then a question from Stephen if this was actually used. I'm guessing the answer is no since the protection is not mentioned in the draft, but wanted to confirm as that wasn't clear to me from the email thread. Additionally, is there any advice given (possibly in other related specs, but I suspect having it here for the new values could be helpful) to assign obscure names to several of the values like the Access Point Identity (Name, BSSID) and Operator Id/Realm? Obscuring only helps a little, but having names that don't necessarily advertise the usage of the associated network might be helpful. Thanks.
I have some questions about this draft. They derive from the position that some
of the values in the options specified can reveal sensitive information about
the mobile user. I would put access network name (especially when it's SSID,
since people put identifying information in SSIDs), access point name, and
BSSID in that category at a minimum.
The draft specifies DHCP options for downstream use in PMIPv6 scenarios, but
makes no mention about actually limiting the use of these options to those
scenarios. It's not clear to me whether those limits could be achieved in any
case, since an AP won't know a priori whether it is being deployed in a
service-provider-WiFi or cellular context or not. So what is the authors'
expectation about the breadth of deployment of these options? Every DHCP stack?
Something less than that? Furthermore, are any of the individual fields
required or optional? RFC 6757 indicates that within PMIPv6 only the ATT is
required.
Given the drawbacks discussed in Section 9, why was DHCP the protocol chosen
for this? Is there no other protocol that APs speak to MAGs that has
confidentiality, integrity protection, and authentication support? If DHCP is
the only choice, why are none of the security fixes normatively required
("confidentiality and integrity protection should be employed," "DHCP server
administrators are strongly advised to configure DHCP servers ... using IPsec,"
"administrators have to consider disabling the capability specified")?
Why would an LMA need the MAC address of the AP? Are there examples of policies
that mobile networks have in place that apply differently to two devices
connected to the same SSID but different APs, for example? I looked for this in
RFC 6757 too but did not see it. Given the potential sensitivity of this field
it seems like a justification for sharing it in an eavesdroppable way needs to
be provided.
draft-ietf-pcp-anycast
Say if PCP authentication is supported and the PCP client can authenticate with various different PCP servers, e.g. at home and in the office. Imagine further that the secrets for the home PCP authentication leak (or are guessed). Wouldn't we want the PCP client in the office in such a case to not accept a PCP server that uses the home secrets? Is that scenario possible? If so, and if the PCP client has some way to know that it is at home or in the office, (could it?), shouldn't there be some security considerations text saying to not accept authenticated responses that come from the "wrong" PCP server? That would probably mean extending the last paragraph of 5.2 to say "if the client knows what server it expects to authenticate to it after the anycast request was sent, then the client MUST check that the response is authenticated from that server (and not some other)." Separately, I hate one of the arguments used (twice!) in 5.2. What you are saying is "I don't need to do stuff because worse things can happen." If all protocol developers made that argument then we would never improve security or privacy. It's a bad argument. You need instead to argue that there's really nothing practical than can be done and that would be used and that would improve over doing nothing.
I think items 2 and 3 from Robert Spark's Gen-ART review deserve more consideration: https://mailarchive.ietf.org/arch/msg/ietf/I7D6wPEGZ5lxqHCzFSfi7qC55qo Editorial Comments: 2.1, "The PCP anycast addresses ... are added..." Added by what? 2.2, 2nd paragraph: Same as the anycast address? It seems odd to embed the “iana-assigned” bit in this sentence. That fact deserves it’s own sentence. 5.2, first paragraph: s/"... require to impersonate..."/" ... require the attacker to impersonate..."/ ; or "require the impersonation"
I'm surprised by the lack of RFC 2119 keywords in a spec like this.
For example:
The PCP anycast addresses, as defined in Sections 4.1 and 4.2, are
added after the default router list (for IPv4 and IPv6) to the list
of PCP server(s)
MUST?
...
A PCP Server can be configured to listen on the anycast address for
incoming PCP requests.
Is this a MAY or SHOULD?
What is the rationale for not using the RFC 2119 keywords?
Question to my fellow ADs. I'm so used to RFC 2119 keywords for such type of
specifications that I now wonder: what are the guidelines for may/should/must
use the RFC 2119 for standard track spec? At this point, it's preferable for
the authors to wait for guidance from the responsible AD and IESG.
Thanks for addressing the SecDir review questions. Filtering and setting a TTL seem like the best options to prevent leakage, but I do agree with the reviewers that it may not happen on many networks. I do appreciate the warning and advice though for the gateway.
Given the issue described in 5.1, I'm curious about this text: "PCP clients usually send PCP requests to these addresses if no other PCP server addresses are known or after communication attempts to such other addresses have failed." Would it make more sense to make a normative recommendation about the order in which addresses should be tried, to help minimize the frequency of cases where PCP requests to the anycast address(es) leak out unnecessarily?
draft-ietf-homenet-dncp
This should be an easy Discuss to ... discuss ... I'm looking at this text: If keep-alives specified in Section 6.1 are NOT sent by the peer (either the DNCP profile does not specify the use of keep-alives or the particular peer chooses not to send keep-alives), some other existing local transport-specific means (such as Ethernet carrier- detection or TCP keep-alive) MUST be used to ensure its presence. and wondering if using TCP keep-alive for liveness detection is realistic in the use cases this specification is expecting to address. Unless I missed something, the default TCP keep-alive interval is still two hours (that's been true since RFC 1122, and also true in the relatively recent version of Linux I'm using). If that's OK, I'll clear. If you're assuming a keep-alive interval that's shorter, lots of implementations allow you to tune this, but it seems like the specification should say something about that. Given that the other example of "transport-specific means" is Ethernet carrier-detection, which would be orders of magnitude faster, I thought I should ask.
- 8.3 generally: I think this could be the basis for something quite good but that'll only become clear really (to me) when I go over it in a real protocol and not in the abstract. I'd also speculate that you might end up changing this if it gets more security review, but again that's hard to get in the abstract. Basically: be prepared for changes as this is made concrete and if that would be a problem please yell now. If you do yell, I'm fine with making this a DISCUSS so we're sure to resolve it. (I nearly did make this a DISCUSS, as I'm not sure this is all fully worked out, but I'm ok that we can fix that later. And you have enough DISCUSS ballots;-) - The write up notes various drafts were input to what became this one. I assume that none of those had associated IPR that hasn't trickled through to being noted as applying to this one? If not, as I expect, that's fine, no response is needed, I'm just noting this since I didn't see any "replaced by" entries in the history and it's those that cause IPR to be transitively visible. - section 2 - it's not clear to me why all node identifiers need to be the same length - some protocols using DNCP could I guess have variable length identifiers. IPv4 and IPv6 and Ethernet for example all have different lengths. - 4.2: seems to contradict itself. 1st para says that MC is not used for anything sensitive, but 2nd-last para of section says that network state TLVs can be sent "now and then." (Reason to ask is that (D)TLS won't work if sensitive data is sent via MC.) - 4.4, 2nd para: what is a "valid" address? - 8.1: do you mean one PSK per network or per pair of nodes? Better to say. I assume it's the former. - 8.3: This is an example of (a fairly complex) use of opportunistic security (RFC7435). Be good to note that. - 8.3: Calling this "certificate based" is I think a misnomer. I suspect all the same things could be done with raw public keys (RFC 7250). - 8.3: please do note that a concrete protocol might need changes to this distributed algorithm and that this section is guidance and not to be considered entirely fixed (when coding).
In general, I found the text not straight forward or easy to understand. I
support Alia’s DISCUSS on the basis that the document doesn’t seem to be well
structured and some details are missing. As I read, there were
concepts/explanations that required me to read ahead to clarify; that is not a
showstopper in itself, but maybe the fact that the TLVs were defined after the
operation causes some of the confusion and makes the document harder to
understand than what it has to be.
Comments:
1. Abstract. "DNCP is an abstract protocol, and must be combined with a
specific profile to make a complete implementable protocol.” The shepherd’s
writeup claims implementations. The links show that the implementation is of
HNCP. It would have been better to progress both IDs together to better
understand any dependencies, etc.
2. There are several places in the document where time-related actions or
states are described using uncertain, maybe even sloppy language. It would be
ideal if that was cleaned up and the text was as specific as possible. For
instance:
2a. Recent. The phrase "recently bidirectionally reachable” is used in a
couple of places. Note that the definition of “bidirectionally reachable” also
uses “recent": “…if a recent and consistent multicast or any unicast DNCP
message has been received…” What does “recent” mean? A naïve interpretation
may be that the peer was (not long ago) reachable, but not anymore. Knowing
that the keep-alives are optional, what is the criteria for “recent”? Section
4.5. (Adding and Removing Peers) seems to provide some hints related to the
ability to verify that the peer is present — that is a specific criteria,
unlike the use of “recent”. Please be specific.
2b. Now and then. Section 4.2. (Data Transport): “…send Network State TLVs
every now and then, as specified in Section 4.3” Section 4.3 (Trickle-Driven
Status Updates) explains: "Every time a particular Trickle instance indicates
that an update should be sent, the node MUST send a Network State TLV…” If I
got this correctly, rfc6206 talks about updates being needed when the version
numbers don’t match — that is a very specific case and not just “every now and
then”. Please clarify what those triggers may be, or include a reference — in
both places to take away the uncertainty.
2c. Eventually. Section 4.4 (Processing of Received TLVs) “…an implementation
MUST eventually reply to similar repeated requests, as otherwise state
synchronization breaks.” It is clear that “eventually” is really time bound —
what is that boundary?
3. Section 6.1.2. (Per-Endpoint Periodic Keep-Alives), 6.1.3. (Per-Peer
Periodic Keep-Alives) and 6.1.5. (Peer Removal): "the endpoint-specific
keep-alive interval” is used — initially I thought that you meant
DNCP_KEEPALIVE_INTERVAL, but it isn’t until 6.1.5 when the term is defined.
4. Section 7.1.1. (Request Network State TLV) If the Length is > 0, what can
the Value be? Nothing is specified.
5. Section 7.3. (Data TLVs within Node State TLV) Just to clarify, the TLVs in
this section would be carried in the Node Data field of the Node State TLV,
right? If so, then it would be clearer if it was explicitly mentioned.
6. References. I think that both RFC6347 and RFC5246 should be Informational
as the document doesn’t actually mandate their use — it just points at them as
what the profiles may (or may not) specify.
Nits:
A. 4.2. (Data Transport) s/to speeds up/to speed up
B. 4.4. (Processing of Received TLVs) The notation ("H(Node Data)”, for
example) for the hash function is used, but it is defined later in the draft.
Please add a reference.
Other ADs focused on the protocol specific points. So let me focus on something else. The applicability section doesn't answer my questions: when to (re-)use this protocol? Note that the write-up mentioned ANIMA. I see the protocol description: DNCP is designed to provide a way for each participating node to publish a set of TLV (Type-Length-Value) tuples, and to provide a shared and common view about the data published by every currently or recently bidirectionally reachable DNCP node in a network. I see, under the applicability section, under which conditions to use it. Basically, suitable to exchange any TLV tuples, infrequently. However, this applicability section doesn't tell me when to re-use DNCP (or define a profile for it). What about the environment: home network versus LAN versus WAN? How big can the network be? Does the technology matter? Regarding transport, it's basically any transport, unicast or multicast, right? (DNCP can be used in networks where only unicast transport is available. While DNCP uses the least amount of bandwidth when multicast is utilized) All devices in a DNCP network must be DNCP node? I have a DNCP network with profile 1, can I use the same DNCP network with profile 2? IANA and enterprise specific TLVs? UDP is fine as a transport? What if I know my topology already (I see later: "may use multicast for Trickle-based shared state dissemination and topology discovery") etc. Just reading the intro and the applicability, I scratched my head: it's so generic, should I even consider it for ANIMA? A few paragraphs, somewhere in the document, would solve my DISCUSS: - this protocol should be used to exchange the following type of data ... - it's envisioned that this generic state synchronization protocol will be used in the following environments ... - potential DNCP-based protocols include ...
- I would agree with Alvaro, when he wrote: "In general, I found the text not
straight forward or easy to understand." Potentially due to the structure.
- I hope that a document about manageability considerations (see
https://tools.ietf.org/html/rfc5706#appendix-A) will follow.
- As reported by Victor, part of his OPS DIR review:
Found In Nits:
(https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-homenet-dncp-09.txt)
- Use of lower case not with SHOULD statement (see Paragraph 2,
Section 4.5)
- Flagged spacing items (Lines 197, 252, 256 and 260)
Section 3: Overview
paragraph 2: their addresses may be manually configured or they may
be found by some other means defined in a later specification
** This text is not quite clear. Is it the author’s intention that
the reader assume the other means will be part of a specific DNCP
profile specification, a revision of the DNCP document or a
different type of document.? ***
Section 4.2: Data Transport
Paragraph 4 / Part “Multicast+Unicast”
<old> It is used to send Network State TLVs every now and
then, as specified in Section 4.3
<suggested> It is used to send Network State TLVs
periodically, as specified in Section 4.3
<reason> Avoids using an idiom to express sending frequency
in text.
Section 8.1 Pre-Shared Kay Trust Method
** Would it be within the DNCP document to discuss how PSKs are
stored (as to not be externally accessed) or would it be to the
profile to defined that level? ***
I just have one thing I'd like to discuss that should be easy enough to resolve. Section 8 mentions that DTLS or TLS MAY be used and that it is up to the DNCP profile. I'd be interested to see the security considerations that would lead to a recommendation of using session transport for the DNCP profiles. If it is in another RFC, could you add a pointer? If it is not, could this be added to the security considerations section since it could be an important consideration?
Thanks for your detailed work on this draft to provide all of the security related options in section 8.
In the IANA Considerations, we would normally use a normative reference to RFC 5226 to define the "Standards Action" and "Private Use" policies. I suggest adding that.
First, I have a number of specific comments. Some of these are hazards to
technical interoperability; I've tried to include those in my discuss - but the
general point is that it is very hard to tell a number of details because the
structure is assumed. Having read this document, I do not think that I could
properly implement DNCP from scratch.
Obviously, I can guess at the answers - but that doesn't let everyone
interoperate well. Examples include:
a) What is a topology graph? When is it created, modified, or destroyed? Is
it a conceptual artifact constructed from the various TLVs? I think a quick
paragraph describing it would help.
b) How are peer relationships discovered and established and destroyed? I
really can't tell from the draft and even a quick scan of RFC 6206 doesn't give
any hints.
c) It looks like the TLVs are sent one after another in a datagram or stream
across a socket. The closest I see to any detail is "TLVs are sent across the
transport as is".
d) As far as I can tell, Trickle is used to decide basically how often to send
information - but the details of this and the interactions aren't clear to me.
I suspect that there are dependencies on the HNCP draft that would make this a
lot easier to understand but since we want it to progress separately, the
document does need to stand alone.
Although not noted in the Shepherd's report, I did have a thorough Routing
Directorate review done and the draft was improved from that.
8) In Sec 4.6 " o The origination time (in milliseconds) of R's node data is
greater
than current time in - 2^32 + 2^15." Since origination time hasn't yet
been introduced, I'm going
on an assumption that it means when R's node data was originated from R. So -
this requirement is saying that R's node data must have been generated in the
future (but already known by the local node)???
9) In Sec 4.6 "They MAY be removed immediately after the topology graph
traversal" The DNCP nodes can be removed from what?? The topology graph?
From some type of received TLV?? How would they be added back in later?
11) In sec 6.1: "Trickle-driven status updates (Section 4.3) provide a
mechanism for
handling of new peer detection on an endpoint, as well as state
change notifications." Nothing in Sec 4.3 talked about a mechanism for
detecting
new peers on an endpoint. It is entirely possible that Trickle does provide
this (but what about the modes where Trickle isn't used/needed??) but there
needs to be a description of how new peer detection is done - even if it's just
a pointer to Trickle RFCs.
12) In Sec 6.1.4: " On receipt of a Network State TLV (Section 7.2.2) which
is consistent
with the locally calculated network state hash, the Last contact
timestamp for the peer MUST be updated." Could you add some rationale for
why this
is needed? I suspect that part of my confusion is that the "locally calculated
network state hash" could mean two different things. Is it the hash computed
by the local node on the data received in the Network State TLV to validate
that the Network State TLV is not corrupted? Or is it the hash computed by the
local node on its arbitrarily wide 1-hash tree that represents the local node's
network state? Since the term is never defined, it's hard to guess here. The
bottom of Sec 7.2.2 uses "current locally calculated network state hash" to
refer to, I believe, the latter.
13) In Sec 6.2: "normally form peer relationships with all peers." Where is
forming a peer relationship defined? Is this tied solely to Trickle instances?
What about with reliable unicast where presumably Trickle isn't used between
peers as the Overview states "If used in pure unicast mode with unreliable
transport, Trickle is also used between peers"?
14) In Sec 7: " For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78)
is
encoded as: 007B 0001 7800 0000. If it were to have sub-TLV of
type=124 (0x7c) with value 'y', it would be encoded as 007B 0009 7800
0000 007C 0001 7900 0000." In this case, the padding between the TLV's
value
and the sub-TLV is included but the padding after the sub-TLV is not. What
would happen if there were multiple sub-TLVs?? Would the padding between those
sub-TLVs be included?
Also related :"In this case the length field includes the length of the
original TLV, the length of the padding that are inserted before the embedded
TLVs and the length of the added TLVs." Here, the phrase "length of the TLV"
means different things. In the first case, "length of the original TLV" means
the "length of the value in the encapsulating TLV". In the second case,
"length of the added TLVs" appears to mean the length of the sub-TLVs including
the type/length header. As I mentioned above, I can't tell what happens to the
padding in between sub-TLVs.
1) In Sec 4.1, I think it would be clearer if you moved the sentence "These leaves are ordered in ascending order of the respective node identifiers. " to after the first sentence with appropriate text changes. I was left confused by why the leaf would be represented by a node's sequence number. I think it's that a leaf represents a node and is ordered based upon that node's identifier. The value of a leaf is a tuple of the node's sequence number and the hash value... 2) In Sec 4.2, it says "As multicast is used only to identify potential new DNCP nodes and to send status messages which merely notify that a unicast exchange should be triggered, the multicast transport does not have to be secured." There aren't attacks from processing fake potential new DNCP node or triggering lots of unneeded/unterminated unicast exchanges? 3) In Sec 4.3, it says "Imin, Imax and k. Imin and Imax represent the minimum and maximum values for I" I believe this isn't quite accurate. Imax is a max multiplier of Imin for I and not a maximum value. I've seen this error in another draft also; I think it's important to be correct & clear here. 4) There are multiple references to different unintroduced TLVs. There is also the idea that each DNCP protocol can have its own TLVs. It'd be very useful in the Introduction to simply state what TLVs are required by DNCP and conceptually what they are for. 5) In Sec 4.3, it says "The Trickle state for all Trickle instances is considered inconsistent and reset if and only if the locally calculated network state hash changes." but I have no idea yet what a Trickle instance is, when a Trickle instance is created or associated with a node? an interface? or something else? 6) I think it would be more useful to describe generally at least what is in a DNCP profile earlier in the document. This may be bringing Section 9 forward or it may be listing it earlier. I'm seeing numerous forward references. 7) Start of Sec 4.6 talks about the topology graph - but there's been absolutely no introduction of what the topology graph is or how it was created, updated, etc. 10) In Sec 5: This is a helpful section. It tells me that a Trickle instance is per interface. I don't see anything like a topology graph in it. It clarifies origination time slightly. It talks about "For each remote (peer, endpoint) pair detected on a local endpoint" but I still have no ideas how that detection is done. It implies some policy restrictions "Set of addresses: the DNCP nodes from which connections are accepted." but has no details on whether that is created via multicast messaging or via local configuration or something else. 15) Also, in Sec. 4.6, the terminology for the fields of the Peer TLV is different than defined in Sec 7.3.1 - just "Endpoint Identifier" instead of "Local Endpoint Identifier". 16) In Sec 7.3.2: " Endpoint identifier is used to identify the particular endpoint for which the interval applies. If 0, it applies for ALL endpoints for which no specific TLV exists." Is this the Local Endpoint Identifier or the remote? The same question applies for Sec 7.2.1.
I have no objections to the publication of this document, but I do have a couple of points that I want to discuss... * The spec says that all TLVs are transmitted every time any value in the TLV set changes. Section 1 says that a delta synchronization scheme is not defined. What is the justification for not using a delta synchronization approach? The ordering of the TLVs needed to compute the hash can be done at the receiver and a delta approach would minimize bandwidth consumption. I think it would be useful to provide some justification in the spec for the design decision made to not use a delta synchronization approach. * Section 4.4 says that all responses are sent unicast, even for requests received via multicast over a multi-access medium. Was consideration given to use multicast responses and supporting message suppression on other nodes? Or, was the design decision made to ensure that all nodes responded with their TLV set to the requester? Either approach may be reasonable, but there is no justification given. * When responding to a multicast request over a multi-access medium, why is the randomization of the transmit time only a SHOULD? I would think that needs to be a MUST.
1. I think the mention of the trickle variable 'k' in section 1 is gratuitous and causes confusion. 2. Why does this document say (section 7) that the hash function is non-cryptographic? Shouldn't that be determined by each profile?
draft-ietf-ccamp-flexigrid-lambda-label
Is there a reason why sections 4.1, 8.1, and 8.2 are telling IANA what values to use in those registries? Is it due to the implementation described in section 6.1 using those values?
Section 4.3 says: "The mechanism defined here MUST NOT be used for other forms of grouping unless and until those forms are defined and documented in Recommendations published by the ITU-T." Perhaps I am being too paranoid, but would it be good enough to say "unless and until those forms are standardized" or something more generic, so that in the event that the ITU-T gets out of the grid definition business some time in the far away future we don't have to update this spec?
draft-ietf-payload-vp8
I agree with the other discusses and comments. I also got the impression this either hadn't been that thoroughly reviewed or else had been so controversial that folks maybe concentrated only on the difficult parts and not on ovrerall clarity. I think it'd be very good to get someone to do a pass over the whole thing to improve clarity. If there weren't so many other discusses I think this would have been one. - section 3: where do I find out how to set up a reference hierarchy? - 4.1: "PID MUST NOT be larger than" 7 surely? Also given the "SHOULD increment" doesn't that mean I can send PIDs 0,3 and 7 only and that's ok? Do you want that? - 4.1: " If the X bit is 0, the extension bit field MUST NOT be present, and all bits below MUST be implicitly interpreted as 0." If X=0 then these octets are not sent so the various flags are not "bits" really. Suggest s/bits/values/ or similar. - 4.1: I assume TL0PICIDX etc are defined somewhere. Where? Adding some references would seem to be needed. - 4.5: Why is this an example? That's confusing. So is the structure of 4.5 then 4.5.1. - Please see the secdir review [1] which raises a couple more minor issues. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04030.html
I'm clearing because my first Discuss point about PID fields was addressed, and
that was my major concern, but I didn't see any response via e-mail or changed
text about my second DIscuss point on wrapping versus restarting at 0.
It's not worth holding the document up for my second Discuss point, but if you
meant to either tell me the Discuss point wasn't a problem or change text to
address it, I missed that.
Which could have happened, of course.
For reference, that was as follows:
TL0PICIDX: 8 bits temporal level zero index. The field MUST be
present if the L bit is equal to 1, and MUST NOT be present
otherwise. TL0PICIDX is a running index for the temporal base
layer frames, i.e., the frames with TID set to 0. If TID is
larger than 0, TL0PICIDX indicates which base layer frame the
current image depends on. TL0PICIDX MUST be incremented when TID
is 0. The index SHOULD start on a random number, and MUST restart
at 0 after reaching the maximum number 255.
KEYIDX: 5 bits temporal key frame index. The TID/KEYIDX octet MUST
be present when either the T bit or the K bit or both are equal to
1, and MUST NOT be present otherwise. The KEYIDX field MUST be
ignored by the receiver when the K bit is set equal to 0. The
KEYIDX field is a running index for key frames. KEYIDX MAY start
on a random number, and MUST restart at 0 after reaching the
maximum number 31.
I'm not quite sure why PictureID says "MUST wrap" and TL0PICIDX and KEYIDX say
"MUST restart at 0". Are these the same thing (I would have thought so, but I'm
not the codec guy). If they are the same, and you could consider using one term
or the other in the document, that would be great. If they aren't the same,
please say more about that.
I would prefer clearly listing the name of the references section as "Normative References", to make clear that all the references are required for understanding/implementation.
Why is this a SHOULD: Applications SHOULD use one or more appropriate strong security mechanisms. Wouldn't it be more helpful to point out why you would use specific security mechanisms for security considerations?
Thanks very much for addressing all my comments. The downref to RFC 6386 was not called out in the Last Call message; that's required in order to support a downref, unless the referenced document is in the downref registry (which 6386 isn't). That means we'd need to re-run a two-week last call for that. I'll leave it to the responsible AD to decide whether to do that or not. No further blocking from me on the point.
In support of Barry's discuss.
-- 4.2: Little confused as to why the I and L behavior is specified twice, e.g.:
"I: PictureID present. When set to one, the PictureID MUST be present
after the extension bit field and specified as below. Otherwise,
PictureID MUST NOT be present."
and
"The PictureID extension: If the I bit is set to one, the PictureID
extension field MUST be present, and MUST NOT be present
otherwise."
-- 4.2: Why would the index values TL0PICIDX and KEYIDX start at random values?
-- 6.1: Seconding Pete's old comment that the normative requirements on use of
max-fs and max-fr should appear somewhere other than the media type definition.
This document would probably be fine were it not for the obvious problems citied in the genart review and the other discusses. imho I have nothing more to add, I wouldn't object to the document were it actually ready.
draft-ietf-idr-as-migration
In the security considerations, isn't there a threat of hijacking traffic (for whatever purpose) if an unauthorised party can migrate?
To the IESG: This document was initially considered by the IESG as version -03 (in Feb/15), but was returned to the WG to avoid it sounding like marketing material and to be precise about what is being specified. I believe the authors have done a very good job! https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-as-migration-03&url2=draft-ietf-idr-as-migration-06
I've cleared my discuss position on the following. I will leave it as a comment for reference purposes: I am confused at the purpose of this draft. The introduction says "This draft discusses some existing commonly-used BGP mechanisms" and "The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results" These words suggest an informational RFC, or maybe a BCP. On the other hand, the draft is labeled as standards track, and updates 4271 (I assume due to Brian's previous comments). Sections 3.3 and 4.2 make heavy use of 2119 keywords in a way that sounds like it is defining a standard (although I question whether these keywords in general impact interoperability per se.) So, I think there is a misalignment. If the intent is indeed to define a standard, then I suggest the abstract and first paragraph of introduction be rewritten to align with that. If not, then it shouldn't be standards track nor update 4271.
It seems like a good idea to document these features. I found a couple of nits you might want to fix: ASN is first expanded in section 1.2. Although it is a well known acronym, you might want to expand it on first use instead. Section 4.1. what is "NB:"?
Just one comment/question on this draft. It would seem logical to me for this document to update 4271. It seems like we want anyone implementing BGP4 to also implement this specification as well.
Section 9: "This could result in a loss of revenue if the ISP is billing based on measured utilization of traffic sent to/from entities attached to its network." Considering loss of revenue in and of itself to be a security issue is a slippery slope that we should probably not start to descend. I held my nose for the revenue-related text in Section 1, but here in Section 9 it seems particularly ill-advised.
draft-wkumari-dhc-capport
Address literal URIs don't play well with https, do they? And using https here is desirable as credentials are likely to be sent. And while a 30x to a https URL can be used, that round-trip could allow for new points of attack, for an adversary not able to insert a DHCP response. (E.g. if the evntual https TLS endpoint is far from the WLAN, then the http URI could be more easily attacked.) Maybe you ought note this issue? Or... Why not send the URI and optionally the address? That way a standard CA could support https, and a client with no DNS could still be ok. Not sure if the client could benefit from standard URL de-referencing code though, so this may be a dumb idea. OTOH, you're already calling for special sandboxing of that (usually) web page, so maybe this could work?
There are lots of TBDs in the shepherd write up. Some are fairly important (i.e. the IPR questions) -- section 2: Are there any rules about the nature of the uri? Scheme? Security? -- section 4, last paragraph: Would it make sense to have a stronger statement about TLS for privacy purposes, given that captive portals often ask for passwords? Also, It might be worth elaborating on the "assure users a portal is not malicious" part.. editorial: -- 4, last paragraph: "By handing out a URI using which is protected with TLS, ..." Looks like an editing error around "using which"
Nothing against the draft itself, but a reflection. I'm sure we all faced this issue: In an airport, with lots of WIFI networks, we connect to each of them one by one, hoping for a free WIFI for a few minutes to exchange emails, and it takes a long time to "test" every network". I can envision the solution in the draft to be used to provide the list of all WIFI networks along with the associated portal page (after a quick DHCP request for each WIFI), to help me select my network. In this multi providers configuration, what is the incentive for the different captive portals to populate this field. All the providers want to attract customers to their portal, and show how great/cheap their services are. So not populating this field might trick me to believe that there is a direct connection to the Internet and influence my WIFI selection. Nits: - RA acronym in the abstract - AUP acronym - idnits complaints about the 'RFC2939' missing reference - remove ">" in "Captive portals are increasingly hijacking TLS connections to force > browsers to talk to the portal." .
I find this paragraph a little confusing an think it could be a bit cleaner: "Devices and systems that automatically connect to an open network could potentially be tracked using the techniques described in this document (forcing the user to continually authenticate, or exposing their browser fingerprint). However, similar tracking can already be performed with the standard captive portal mechanisms, so this technique does not give the attackers more capabilities." I think just a variation of the second sentence is enough as this mechanism doesn't introduce any new tracking mechanism. Just stating that it is possible to track users from a network with a captive portal should be enough. As a side note, I know this is out of scope, it would be interesting as a user to understand policies of captive portals using this mechanism before selecting which to use. Maybe some set of registered policies that go in the URI for the future?
At least some of the authors should know from earlier conversations that I very much support going ahead with this document. Just one teeny comment: -- Section 2 -- In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal, but MAY contain a DNS name if the captive portal allows the client to perform DNS requests to resolve the name. In my continuing effort to eradicate 2119-use problem #1: the SHOULD/but-MAY structure is a bad one; "SHOULD" is strong and "MAY" negates it. It's not really a problem here because your "if" constrains the scope of the "MAY", but I'd prefer it if you'd rephrase it something like this: NEW In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal. If the captive portal allows the client to perform DNS requests to resolve the name, it is then acceptable for the URI to contain a DNS name. END Note that's "I'd prefer it"; if you disagree, that's the last you'll hear of it from me, and there's no need to discuss this point.
Thank you for producing this draft. I hope the mechanism it describes is widely deployed. It's a small thing, but this draft uses "authenticate" in the abstract, and "agree to an acceptable use policy (AUP) and / or provide billing information" in the Introduction, and then talks about "an authentication page" in section 2. Are all those synonyms, for those skilled in the art? If not, more consistency might be helpful, or perhaps adding a definition of "authenticate" that includes things like agreeing to an AUP.
I think you need to specify somewhere that the URIs are encoded following the rules in RFC 3986.
Glad we got the document status thing sorted out.
draft-ietf-dnsop-dns-terminology
No-objection from me regarding the existence of this document, I do think it's helpful, however along with others (Ben, Benoit, Alvaro) I feel the work is incomplete if a revision is required so soon. I would feel much more comfortable if the document was taken back to the WG and completed before being published.
Thanks for this. Is a domain a sub-domain of itself? Do we care? The definition of Alias might imply that we do. Not sure.
This is a very nice, and needed reference. However, I don’t understand why it is being published. As others have pointed out, the Introduction reads: Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions. If a revision is coming soon, why not wait? What does an RFC number give the authors/WG that the ongoing maintenance of an ID doesn’t? The statement above just reads as if the work is not complete. This point has been made by others, so I won’t stand in the way of publication.
I'm balloting "yes" because I think a document like this should exist. But I share the question others have raised about why publish this version if a newer version is coming soon. A few other minor comments: This is listed as informational, but it was last called as a BCP. I'm not sure if that matters, since a BCP would have been held to as high or higher a standard than an informational RFC. The shepherd's answer to question 7 does not address the question about whether authors have confirmed that they have complied with the IPR rules. SoA gets mentioned a few times, but If there is a definition, I failed to find it.
Thanks for this document. - Reading first the write-up, I started to wonder about the rationale to produce a terminology document as BCP? I re-read RFC 2026, and concluded that BCPs should document standardize practive. Then I realized the diff between version 3 and 4 :-) - From the shepherd writeup: "One issue raised by the Working Group was that such a list of definitions would be best served with some sort of Index. The authors and the Document Shepherd agree, but feel it would be better served being handled during the editing process." What/when is the editing process? AUTH48? Why wait? - "Most of the definitions here are believed to be the consensus definition of the DNS community - both protocol developers and operators." I hope we can write: "Most of the definitions here are the consensus definition of the DNS community - both protocol developers and operators.", leaving no doubts about the process. - "Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to, but that are different from the original definitions. Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions." You lost me here. Do you want a new revision of this document, or revisions of early DNS RFCs, or both? And why do you say "That revision will probably have more in-depth discussion of some terms". Does it mean that THIS document is not final? This is the way I read it.
This is a really great resource. Thank you for putting it together.
I had a few points where I wasn't understanding the text as well as I'd hoped.
I offer them, in case you see better ways to explain things, but no response is
needed if the answer is "Spencer just needs to pay attention".
If this
For example, at the time this document is published, the "au" TLD
is not considered a public suffix, but the "com.au" domain is.
(Note that this example might change in the future.)
is intended to say that a subdomain may be a public suffix when its domain is
not, that could be stated more clearly. If it's intended to say something else,
I don't know what that is (and "For example" didn't help!)
In this text
Some servers do not honor the TTL on an
RRset from the authoritative servers, such as when the
authoritative data has a very short TTL.
I wasn't sure what "do not honor" meant - discarding the RRset before the TTL
has expired, hanging onto the RRset after the TTL has expired, or flipping a
coin?
In this text
DNSSEC-aware and DNSSEC-unaware: Section 2 of [RFC4033] defines many
types of resolvers and validators, including "non-validating
security-aware stub resolver", "non-validating stub resolver",
"security-aware name server", "security-aware recursive name
server", "security-aware resolver", "security-aware stub
resolver", and "security-oblivious 'anything'". However, "DNSSEC-
aware" and "DNSSEC-unaware" are used in later RFCs, but never
formally defined. (Note that the term "validating resolver",
which is used in some places in those documents, is nevertheless
not defined in that section.)
so, there's no formal definition anywhere? Maybe that could be the first thing
that this list item says? It's somewhat buried under all the terms that ARE
defined, which seems backwards.
I'm also slightly confused about why "validating resolver" is mentioned in this
list item, instead of appearing in a separate list item. Is the common element
that it's not defined anywhere else, either?
draft-ietf-lwig-cellular
Nice work.
I had a couple of thoughts while reading through it.
This is a very useful draft. Thank you for producing it.
You mention the difficulty of acting as a server behind a NAT. I wonder if you
might also mention the power drain that's often required to maintain port
bindings on NATs when a device is not actively transmitting. That may not be a
problem for sleepy devices, but might be for real-time reachable devices.
In this text
Manufacturer Server
The DNS name of the directory or proxy is hardwired to the
software by the manufacturer, and the directory or proxy is
actually run by the manufacturer. This approach is suitable in
many consumer usage scenarios, where it would be unreasonable to
assume that the consumer runs any specific network services. The
manufacturer's web interface and the directory/proxy servers can
co-operate to provide the desired functionality to the end user.
For instance, the end user can register a device identity in the
manufacturer's web interface and ask specific actions to be taken
when the device does something.
Delegating Manufacturer Server
The DNS name of the directory or proxy is hardwired to the
software by the manufacturer, but this directory or proxy merely
redirects the request to a directory or proxy run by the whoever
bought the device. This approach is suitable in many enterprise
environments, as it allows the enterprise to be in charge of
actual data collection and device registries; only the initial
bootstrap goes through the manufacturer. In many cases there are
even legal requirements (such as EU privacy laws) that prevent
providing unnecessary information to third parties.
The reference to legal requirements under "Delegating Manufacturer Server" made
me think this was only appliable to "Delegating Manufacturer Server", but not
to "Manufacturer Server". Is that the case? Or is it applicable whether the
Manufacturer Server is delegating or not?
I share Stephen's comment on Figure 1.
- intro: is CoAP really "point-to-point"? not sure that is a good term to use here. I get what you mean when I get to the end of page 6 though, but I still don't like the term as used here. - figure 1 doesn't tell me much to be honest, I'd say delete it maybe or add some more text saying what it's there for. - p6, proxies are provided for http yes, but why would they be needed for coap? coap devices are not rendering html so don't have a need for loads of DNS names/pictures/ads. I think that's in the end a misleading conparison to make and would be better omitted. (BTW, I don't mean you're trying to mislead, but that that comparison is likely to mislead the reader into thinking they may get more from coap proxies than is the case.) - p7, at end of section 3, you could (if you wanted), make the point that "higher" layer network protocols like a DTN protocol such as the BP could help (if deployed widely) as then applications wouldn't assume that what they send is (almost) immediately received. More practically, applications can re-invent DTN functionality and get some of those benefits. - section 5, I think it'd be worth noting that there is a need for (but no good solution for) discovery of devices that are manufactured by small manufs (or open source) and deployed in small numbers. That is not the same as when a large vendor is involved but would be worth noting. - section 9: large numbers of esp. small battery powered devices scattered everywhere are a significant polution threat. (When not gathered at end of life.) That arguably ought be noted as a reason to spend more on e.g. PoE devices sometimes - the overall environmental or carbon cost can be lower in the end with a device that uses more power per hour.
I share the comments about figure 1. -- 3, radio technology: Can you elaborate on the meaning of "bundling applications together"? Does it mean bundling the messages together for multiple applications? Something else? -- 7: "If sub-second response time is not needed, a slightly more infrequent checking process may save some power." Perhaps more than slightly? -- 7, paragraph 3: Is the "device" in the 4th sentence the same as the "sensor"?
draft-mm-netconf-time-capability
FWIW, I support Barry's DISCUSS and (as Ben) would like to see something about the experiment expectations.
It would be helpful to see a few words about the nature of the experiment, even if that is just something to the effect of "get deployment experience to decide if this is really a good idea". Or more to the point, is there an expectation that we will learn something from this, and perhaps consider it for standards track in the future?
This really seems to derail this document entirely: -- Section 7 -- This document proposes to register the following capability identifier URN in the 'Network Configuration Protocol (NETCONF) Capability URNs' registry But, as the document shepherd points out, the registration policy for that registry is Standards Action, and this document, with Experimental status, does not meet that requirement. This document cannot make that registration. One way around this is to have a separate, Standards Track document that only makes the registration. Another way around this is to make a separate, Standards Track document that changes the registry's registration policy to IETF Review. The first workaround seems a little silly. Perhaps the second is the better path. If the second path is NOT desired, then perhaps we have a more basic problem here that needs more discussion.
status-change-rfc1984-to-best-current-practice
Having balloted Yes, I note that the question on this ballot is "is this the right thing to do?". There has been more than a little process wonking in the community discussion on this status change. Stephen has done a fairly heroic job in responding to that discussion. I happen to think that our current process really doesn't help us in this case (see: lawyering about whether we're allowed to move an Informational RFC produced by the IAB and IESG to BCP without issuing a new RFC, for starters). There are moments when I wish we were doing a new document that says "the IESG has been treating RFC 1984 as if it were an IETF-stream BCP for a very long time. RFC 1984 doesn't look like a BCP that we would publish in 2015, and it wasn't produced the way we would produce a BCP in 2015, but that hasn't prevented anyone from treating it as if it had been produced and evaluated as a BCP, had that option been possible twenty years ago, so, we're going for it", and publishing THAT as a BCP. But the question on this ballot isn't whether we would approve RFC 1984 unchanged as a new RFC, it's whether recognizing twenty years of reality is the right thing to do. So. I'm a Yes.
As this is on a telechat, and I'm the responsible AD, you know that I think there is rough consensus for this. But the in-place part is a bit rough, so to help you figure out what you think, Robert Sparks nicely summarised the IETF last call for this [1] to which Dave Crocker responded [2] calling out that it was more than just one or two folks with issues. (That said, there were a lot of people at the saag meeting who supported doing just this so to the extent that numbers matter, the ietf@ietf.org mailing list traffic is not the full picture as we know.) [1] https://www.ietf.org/mail-archive/web/ietf/current/msg94632.html [2] https://www.ietf.org/mail-archive/web/ietf/current/msg94635.html
Consensus was clear at the SAAG meeting for this change IMO. The mailing list discussions were very helpful to sort through options and opinions.
For the record I believe that the IETF experience of the interceding twenty years since the original publication reinforces the necessity of this statement.