IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-09-04. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Cindy
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
1146 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
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
5. IAB News We can use
6. Management Issues
Telechat::
7. Agenda Working Group News
1157 EDT entered executive session
(at 2014-09-04 07:30:01 PDT)
draft-ietf-pwe3-mspw-er
Ok - sorry for the confusion.
Need to pick up the nits from Meral's GenArt review > [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in Section 1" > > [Page 6],"but each node MUST attempt to determine a loop-free path", > if the only method to detect a loop is http://tools.ietf.org/html/rfc6073#section-7.6, > then perhaps a reference to this RFC would be useful. > [Page 8], Section 5, typo :"consesus"---->"consensus"
- I'm not sure to what extent this may be a significant threat, but want to check. This new mechanism seems to create a new way to attempt to DoS or probe a MS-PW if one is allowed to send any traffic on that MS-PW as an S-PE (or a zombied S-PE) - any such sender can nominate the path for traffic. Why is that not a new security consideration? If it is, (and I think it is), then at least noting that in the security considerations section would seem right. And how might one detect or otherwise mitigate such a nasty S-PE? - To be honest, I found 4.1 and 4.2 very hard to take in. I'd suggest maybe a re-write but IFF others have had similar difficulty. (If its just me, then ignore me.) Some examples below. - 2nd sentence of 4.1 - who is selecting when? (Passive voice?) - "MUST attempt" is very odd, is that the same as "MAY not bother"? :-) - "If a loop free path cannot be found..." by whom? - "If the L bit is not set in the first ER Hop and if the node is not part of the abstract node described by the first ER Hop (i.e it does not lie within the prefix as determined by the prefix length specified in the ER-Hop TLV), it has received the message in error, and MUST reply with a Label Release Message with a "Bad Initial ER Hop Error" (0x04000004) status code." Does that *all* really have to be one and only one sentence?
Looks ok from a security standpoint, interested to see the clearer language from Alia's review.
Wondering if any of the mays and musts in Section 4.2 should be MAYs or MUSTs. I noted that in 4.1, the text says "Processing continues as per Section 4.2, where a new explicit route TLV MAY be added to the Label Mapping Message," but the behavior specified in 4.2 is not described normatively.
draft-ietf-forces-model-extension
I would like to suggest that the authors consider the following as a replacement abstract: This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 to allow complex datatypes for metadata, optional default values for datatypes, and optional access types for structures. It fixes an issue with Logical Functional Block (LFB) inheritance. It also introduces two new features: LFB properties, and a new event condition, BecomesEqualTo. This is really none of my business, so feel free to ignore this suggestion. The reason I make the suggestion is that the purpose of an abstract is to help people who would be interested in a document to find it, and for people generally to understand specifically what the document does. The current abstract is really just a shorter version of the introduction, with a lot of text explaining things a person interested in the document would already know, and that a newcomer could find out by reading RFC 5812 and other ForCES documents. This text obscures the information that would allow the reader to identify the specific purpose of this document. I think the above paragraph conveys what needs to be said, and is easier for both domain experts and newcomers to digest. Otherwise the document looks good—thanks for doing this work!
- abstract and intro: I bet the "two years now" is no longer true - yep, its 4 years;-) - 2.1 - How does supporting more complex metadata stack up with RFC 7258? Is that worth a mention in the security considerations? By "that" I mean the potential for additional more complex structured metadata to "better" leak private information? - maybe the above 7258-related point applies to 2.4 as well, though that might be a bit of a stretch? What I'm wondering is if this means I can now add a kind of privacy unfriendly trigger that I couldn't previously. That'd be something like "<do more logging> if <person/addr/whatever> BecomesEqualTo <AdrianFarrel>" Note: for both of the above points, I don't remember enough about forces to be honest, and you should definitely not take this to be something where you have to placate the AD. And additionally, this is a minor extention of exactly the kind envisaged in 7258 itself so we ought not go overboard. In other words, feel free to respond with one or both of: a) "no that's just silly, what have you been smoking?" or b) "yeah maybe, but this isn't the right place to think about the privacy impact of forces."
Please take a look at the nits from the Sec-dir review and respond: http://www.ietf.org/mail-archive/web/secdir/current/msg04993.html
Moved from "discuss"; this is now non-blocking. If we can get an appsdir XML review "soon enough", that would be nice. I have a small concern, as it's full of modified XML, and the shepherd writeup already notes a copy/paste error in that area (albeit in a caption). It's possible that a substantive error also got through, but I'm satisfied enough with the level of review that this shouldn't block the progress of the document if appsdir can't produce a review right away. -- Section 1 -- The last sentence puzzles me: I get what you mean by saying what XML libraries (why capitalize "Libraries"?) shouldn't generate, but I don't understand what you mean about parsing the library. I think you mean "unable to parse the generated XML," yes? -- Section 5 -- IANA has registered a new XML namespace, as per the guidelines in RFC 3688 [RFC3688]. It doesn't appear that they have. Am I missing something? -- Section 6 -- Thus the security considerations defined in [RFC5812] applies to this document as well as the changes proposed here are simply constructs to write XML library definitions, as where in [RFC5812] and clarifies the inheritance issue of the initial model and both have no effect on security semantics with the protocol. I'm afraid I can't make any sense out of that sentence. Can you please rewrite it? (Really, I honestly can't figure it out, though I'm pretty sure you're saying that there are no new security considerations here.)
draft-ietf-forces-protoextension
In the IANA section, given that the forces WG is finishing up, would it be better to use Expert Review and provide guidance instead of requiring a specification? In Sec 3.2.3: Instead of "We do not propose the cause string be standardized.", what about "The cause string is not standardized by this document."
The abstract doesn't really say what the document is about. It would be nice to note what extensions are being created here.
You may want to expand FE on first use of the acronym in the introduction. I do see it comes later in the definitions, so it's up to you(non-blockng comment/nit), but may be easier for the reader. Thanks for the discussion on the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg04953.html
-- Section 2.1 --
Note that "monotonocally" does not imply incrementing by one, which is what you
appear to mean. I suggest:
NEW
o Send up to 10000 ForCES PL requests, incrementing the index by
one each time, and stop when the needed 2000 entries are
retrieved.
END
In the last sentence of the section, please change the dash to a comma.
-- Section 3.2.3 --
It appears that you intend the cause string to be consumed by humans, and not
to be machine-readable. Is that correct? It would be good to add a sentence
to say that explicitly. That sets expectations appropriately, and avoids
questions about comparing strings and other such ugliness.
-- Section 3.3 --
The last message which carries the EOT flag to go the CE MUST NOT
carry any data.
This is an important English usage point that affects the clarity of that
sentence: is there only one message that carries the EOT flag, and it's the
last one (case 1)? Or can multiple messages carry the EOT flag, and you're
talking about the last one that does (case 2)? I think you mean case 1, but
it's unclear. You need one of these instead (and pay attention to the commas):
CASE 1
The last message to go to the CE, which carries the EOT flag,
MUST NOT carry any data.
CASE 2
The last message to go to the CE that carries the EOT flag
MUST NOT carry any data.
END
-- Section 4 --
Pearl Liang is not a programming language; her name has an "a" in it.
-- Section 5 --
Commenting on Alia's comment, actually, Specification Required is an
appropriate policy, which also requires a designated expert. The specification
can be an RFC (in the IETF stream or otherwise), or a document published
elsewhere... even on a web site.
That said, this section does have to provide guidance for the designated expert
about what to consider when evaluating a registration request. Please don't
leave that out.
Just one question. In this text: 3.3. Large Table Dumping The protocol document [RFC5810] does not adequately describe how a GET response to such a large message is delivered. The text in this section clarifies. We limit the discussion to a table object only. Is this about a GET response to a large message, or a large GET response to a message? The following paragraph seems to be about a large GET response.
Just checking on some of the IANA actions. The current TLV types registry shows 0x117 and 0x118 as unassigned. Can I assume that since those values are explicitly listed in 3.1 and 3.2 that IANA and the designated experts have approved those values for this document?
draft-ietf-6lo-lowpan-mib
I have no objection to the publication of this document, but here are a few
thoughts you might want to factor in before publication.
---
Of course, I have to ask the question: why a MIB module? As noted in the
Introduction, SNMP might not be a good choice in a constrained
environment and a different protocol might be used to carry MIB data.
Why, if SNMP might be abandoned, do you continue to consider a MIB
module instead of going straight to YANG? You presumably are dealing
with a new class of device that does not have SNMP or ASN.1 support.
I don't think that the previous MIB modules listed in Section 4 actually
provide justification because I doubt that this new class of device
includes the MIB support as listed.
I suppose my question is really: Who has made the decision about how
objects will be managed in 6LowPANs? Is this a documented decision or
are we sleepwalking to MIB modules?
---
Not sure "IMPORTS" should be in upper case in Section 5.
---
I don't think
ORGANIZATION
"Jacobs University Bremen"
is correct.
Maybe "IETF" or the 6lo working group?
---
DESCRIPTION
"Initial version, published as RFC XXXX."
-- RFC Ed.: replace XXXX with RFC number and remove this note
::= { mib-2 XXXX }
You need an editor note for this second XXXX.
Of course, it would save some confusion if you used different letters
for different meanings.
---
I don't find any discussion of wrapping. i know you have relatively low
throughput devices, but I consider a device with multiple interfaces and
that you have used counter32 (correctly, IMHO). One packet per second
would wrap at 136 years. So 12 packets per second on each of 12
interfaces would wrap in one year (if my maths is working today).
IMHO you do not need larger counters, but you do need to add some text
to describe wrapping and consider a discontinuity timer. (Actually, you
probably need a discontinuity timer anyway.)
- Section 4 - is "typically used" for the CoAP etc stack in Figure 1 really correct or a sort of wishful thinking? - Figure 1 - why no RFC numbers on the left hand side? - FWIW, Figure 2 doesn't tell me anything really. But not suggesting you change unless there are loads of similarly challenged folks in addition to me:-)
Do not forget that the document needs a small change per Gen-ART review comments and as agreed in discussion.
For the record (this is a COMMENT, not a DISCUSS, even if I've been hesitating
a lot), I'm not happy about the intended status of this document. Note that
this is in line with Adrian's COMMENT on why SNMP for constrained devices.
I was asked to provide my feedback a few months ago regarding the intended
status, and was pushing for EXPERIMENTAL if the document organization remained
the same.
First of all, the charter mentions:
2. Information and data models (e.g., MIB modules) for these
adaptation layers for basic monitoring and troubleshooting.
So what is this document focusing on? An information model or a data model
(read MIB module). As it is right now, clearly the latter. This document could
have focused on a information model, and providing the MIB module as an
example. Such a document with title "Information Model Specification for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs)" would be fine with
PS intented status.
Second, will constrained devices be managed via SNMP? At this point in time I
don't know, but my gut feeling tells me that it won't be the case. So this
document sends the wrong message to the industry. It's true
(http://www.ietf.org/mail-archive/web/6lo/current/msg00561.html) that:
But as Jürgen pointed out correctly to me, the MIB module itself is just an
API (similar to the IP MIB module), not necessarily tied to SNMP, and the
data model itself is useful.
This is a subtle way to say: I specify a MIB module, but consider it as an
information model, so SNMP might not be used by constrained devices. This is
way too subtle. And yes, I've seen that sentence:
While a MIB module provides a direct binding for accessing data via
the Simple Network Management Protocol (SNMP) [RFC3410], supporting
SNMP may not always be affordable on constrained devices. Other
protocols to access data modeled in MIB modules are possible and
proposals have been made recently to provide bindings to the
Constrained Application Protocol (CoAP) [RFC7252].
The two reasons why it's not a DISCUSS are
- Brian mentioned to me: "there was a discussion during the 6lo session in
Toronto where the consensus changed on what the status should be." - This set
of counters is easy to map to a different data model language.
To summarize: unhappy about the intended status, but will not go against the WG
consensus!
I am fine with the security considerations of this draft, but do have a question. Is it practical to have a strong recommendation for SNMPv3 for the constrained devices for which this draft is intended? I of course like the considerations, but if it's not practical for SNMPv3 and the additional security provided to be enabled, that would be good to know. If it is, that's great. Thanks.
Tiny point: we're really trying to get away from "this memo" stuff... Can you call it "document" instead?
I wondered the same thing Kathleen is wondering about devices that wouldn't be running SNMPv3. I also wondered if there was any guidance for devices that don't run SMTP at all. If you choose to say anything about Kathleen's question, you might think about text that would also be applicable for a device being managed over CoAP.
draft-ietf-ippm-lmap-path
I have no objection to the publication of this document, but I really struggled to get a grasp of the term "reference path". It seems to be a fundamental term in sections 1 and 2, but doesn't get a lot of explanation until section 3.1. But even 3.1 is hard I suggested for me to grapple with. A reference path is a serial combination of routers, switches, links, radios, and processing elements that comprise all the network elements traversed by each packet between the source and destination hosts. The reference path is intended to be equally applicable to all networking technologies, therefore the components are generically defined, but their functions should have a clear counterpart or be obviously omitted in any network technology. I think may be it is your use of articles (definite vs. indefinite) and plurals (singular vs plural) that has me confused. "A reference path" or "The reference path"? "traversed by each packet" or "traversed by a packet" or "traversed by each packet in a flow"? "The reference is intended" or "A reference path is intended"? When you say "all networking technologies" in the context of "the path of a packet" I wonder whether all networking technologies know what a packet is. I do wonder whether this key term could be defined in a clearer and more comprehensible way. Furthermore, the discussion in Section 4 seems to be discussion far wider scoped elements in the reference path than is implied in the section 3.1 definition (networks and access devices versus router, switches, links and radios).
- I'm wondering if this works ok for a scenario where I use my phone as a hotspot? From one POV there could then be 2 subscriber devices in the ref. path (with diff service providers) and I'm not sure if that's allowed or not by section 4. (Actually it might mean that network number 0 isn't a good plan?) - How is this intended to be used when tunnels of various kinds are in use? E.g. we've deployed stuff using openvpn a number of times and it might be good if this stuff could be used for measuring such deployments. - Good that you have the privacy consideration here and the pointer to the framework draft. (Which I've not read yet, sorry.) That pointer means that privacy does need to be substantively dealt with in the framework, but I guess that'll be fine.
I'd like to thank Elwyn for the Gen-ART review and authors for addressing the issues. However, the edits I believe are still to be applied to a -06. Is a new version forthcoming?
I just have a question on the security considerations section to see why there are no security considerations and why the described path is only a privacy issue. Maybe this is fine, but I think there are some possible security considerations, please let me know if I am missing something that prevents this from being an issue. In the referenced framework draft, the list of privacy-sensitive items in 8.2 makes sense. Since the reference path is the path traversed by a flow of data (if I have the definition correct per the other questions), couldn't an attacker use the path information to perform a DoS or other attack at one or more points along the path? Wouldn't this be both a security and privacy consideration? I can see that all of the information about a device in the path could reveal privacy related data, but the host information could be used to take out (DoS) or compromise a point in the network as well. Current text: When considering privacy of those involved in measurement or those whose traffic is measured, there is sensitive information communicated to recipients of the network diagrams illustrating paths and measurement points described above. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [I-D.ietf-lmap-framework], which covers active and passive measurement techniques and supporting material on measurement context. Perhaps adding in a sentence between those to highlight that attacks, such as DoS or other attacks, are possible along the Reference Path or identified measurement points.
For the first paragraph of the Security Considerations, did you intend to say that there is no threat to an implementer of this draft? It sounds odd to say there is none for the reader and the Internet. Although with my question above, maybe this changes a bit more (or is deleted with a consideration added in the second paragraph).
Tiny point: we're really trying to get away from "this memo" stuff... Can you
call it a document instead?
I had the same problem as Adrian with the definition of "reference path", and
I'm glad to see that Al is working on that. For the record, here's the comment
I'd composed offline, before I saw that conversation: I'm not a performance
metrics guy, I don't know what a "reference path" is, and there's no citation
for it, though it's in the document title, abstract, introduction, and purpose
and scope section. I thought I could find it in RFC 2330, but it's not there
("path" alone is). Where can I find a definition? Please provide a reference
and citation on first use in the intro.