IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-10-25. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Corrections from: Stewart, Barry
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
3.3.2 Returning Items
1203 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
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:
Telechat:
Telechat:
7. Agenda Working Group News
1237 EDT Adjourned
(at 2012-10-25 07:30:11 PDT)
draft-ietf-ccamp-rfc5787bis
- 6.1 says the router IDs SHOULD NOT be zero but I don't get when it'd be ok for zero to be used (just asking as its always good to say when going against a SHOULD NOT is fine). - I wondered if the combination of exporting routing information up, down and sideways, and dealing with not-quite overlapping ASON and OSPF hierarchical concepts might increase the probability of error here to the point where this draft ought say something about that. I don't know the answer, just asking. - Is the definition of looping in 7.2 appropriate? Why are only ASON-specific loops considered? Why not consider anything that causes a routing loop, regardless? - 7.2.1, 2nd last para, should that "must" be a "MUST" in "The RA ID value must be a unique identifier for the RA within the ASON routing domain." - I was surprised not to see the string "ASON" in any of the TLV names defined here. - Section 9, 2nd para: How can message authentication improve security against passive attacks? Seems plain wrong. Adding crypto for integrity/authenticaiton is purely to prevent/detect active attacks. My suggestion is to do s/secure against passive attacks and// - Section 9, 3rd para: Signatures do not by themselves provide stronger security than MACs. That all depends on key management and specific algorithms. I'd argue to just delete that paragraph.
This is a well written document. Since the security of this mechanism is fundamentally associated with the security of OSPF, an informational reference to draft-ietf-karp-ospf-analysis would seem useful to the reader.
draft-ietf-ccamp-gmpls-ted-mib
A number of minor editorial comments wre made in the Routing Directorate review by Young Lee. These will need to be applied before publication. http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01793.html
The *MaxRate settings (on p23) are read-write and allow up to 2^32-1 notifications per second in theory. Should you note that implementations MAY or SHOULD have a limit that they impose on these values so that if someone tries to set them to >LIMIT, an error results? If you wanted to say something about this, that could be done on p23 where they're defined or in section 8 I guess. If this is just some generic MIB thing that's already handled everywhere, then sorry for bothering you with it:-)
No objections to the publication of this document. I'm actually in favor of it.
Dan Romascanu, in his OPS-DIR brought a couple of good points, which I support.
At the very minimum, the point 4 should be addressed
1. In Section 2:
> This MIB module should be used in conjunction with OSPFv2 MIB, OSPF
v3 MIB and ISIS MIB as well as other MIBs defined in [RFC3812],
[RFC3813], [RFC4802], [RFC4803] for the management of MPLS/GMPLS
based traffic engineering information.
It would have been useful to develop this a section that explains the
relation of the TED-MIB with other MIB modules that model MPLS-TE and
GMPLS devices. Are all these MIB modules required on the same device at
the same time? Being more precise here would help implementers and
switch designers in planning the resources required to implement and run
this MIB module.
2. Runing id-nits results in a number of warnings related to unused
references:
== Unused Reference: 'RFC2328' is defined on line 1552, but no
explicit
reference was found in the text
'[RFC2328] J. Moy, " OSPF version2 ", RFC2328, April 1998....'
== Unused Reference: 'RFC4001' is defined on line 1566, but no
explicit
reference was found in the text
'[RFC4001] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
"...'
== Unused Reference: 'RFC4801' is defined on line 1579, but no
explicit
reference was found in the text
'[RFC4801] T. D. Nadeau and A. Farrel, Ed., "Definitions of Textual
C...'
== Unused Reference: 'RFC5340' is defined on line 1587, but no
explicit
reference was found in the text
'[RFC5340] R. Coltun, D. Ferguson, J. Moy, A.Lindem " OSPF for
IPv6",...'
== Unused Reference: 'RFC6340' is defined on line 1593, but no
explicit
reference was found in the text
'[RFC6340] R. Presuhn, "Textual Conventions for the Representation
of...'
== Unused Reference: 'ISO10589' is defined on line 1596, but no
explicit
reference was found in the text
'[ISO10589] ISO 10589, "Intermediate system to Intermediate system
ro...'
== Unused Reference: 'RFC4220' is defined on line 1625, but no
explicit
reference was found in the text
'[RFC4220] M. Dubuc, T. D. Nadeau and J. Lang, " Traffic
Engineering...'
Actually the references are used, but they appear in the DESCRIPTION or
REFERENCE clauses in the MIB module, and in a format (no brakets) that
makes them to pass undetected by id-nits. It would be useful to group at
lease the references that contain MIB modules in a short section prior
to the MIB module, so that implmenters and operators deploying the MIB
have an easy access to the documents that indicate what MIB modules need
to be compiled or loaded together with the TED-MIB. Add to these RFC4802
mentioned in the IMPORTS.
3. The example provided in section 6 is ipv4 only. It would be useful to
add an ipv6 example.
4. Expanding the example to detail what would be a typical or
recommended operational flow used by an operator when working with the
MIB module would have been useful. How is the MIB modules supposed to be
used. What an operator can do with this MIB module? Download the
topology? How often? Verify that the switch was properly configured and
debug problems in the network using the objects in the tedTable,
tedRemoteTable and tedSwCapTable? What is the functionality and how can
be used the tedSrlgTable?
5. Notifications throttling is discussed and implemented and this is a
good thing. However, there is a potential issue here. The notifications
tedEntryCreated and tedENtryDeleted are supposed to be sent when an
entry was created or deleted in the TED table. However, the writeable
object that sets the notifications rate is set by default at 1
notification/minute, a value that many operators will leave as is. This
means that whenever more than one row is created or deleted in one
minute, just one notification will be sent. I think that an explicit
warning should be included about this situation, so that operators are
aware that in order to make sure that all changes were detected when a
notification was received, the whole table needs to be traversed.
6. There is no indication or hints to the operators about using the
objects in this MIB module for faults management or alerting about the
status of the network. For example can the tedUnreservedBandwidth per
priority objects be used to detect problems in capacity or in
configuration?
-- Section 8 -- There is a number of management objects defined in this MIB module that has a MAX-ACCESS clause of read-write. While technically "a number of Xes" is singular, in actual usage that's very odd English, and seems wrong. The RFC Editor can fix this, of course, but if you're editing the document anyway you might change it to plural usage by making it "There are" and "that have". If that bothers you, you can also change "a number of" to "several", and you'll be correct both in common usage and technically.
I am prepared to believe that Adrian has been thorough with this draft.
Isn't the following missing from the security considerations (penultimate para) because it's part of the generic MIB Dr. boilerplate: Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353].
draft-ietf-appsawg-media-type-suffix-regs
I think this document would be better as an Informational RFC.
One question for which an obvious and good answer probably exists, but I just wanted to check in case and I'm fine with pretty much any sensible answer. Some sets of octets can be corrected decoded as either BER or DER. Could I have xxx/yyy+ber+der in that case or what? I guess there could be a generic question there about octets that can be decoded correctly according to multiple entries from this new suffix registry - is xxx/yyy+zzz+www allowed at all and where's that stated?
In support of making this 'Informational'.
Section 3: Author/Change Controller - It seems to me that having the IETF or
IESG be the change controller would make more sense than APPSAWG. The WG can
always be shut down.
3.x:
The syntax and semantics for fragment
identifiers for a specific "xxx/yyy+json"
SHOULD be processed as follows:
For cases defined in +json, where the
fragment identifier resolves per the +json
rules, then as specified in +json.
For cases defined in +json, where the
fragment identifier does not resolve per
the +json rules, then as specified in "xxx/
yyy+json".
I don't actually understand what the above (and the similar in other sections)
means in practice.
3.2/3.3: Shouldn't this document register application/ber and application/der?
Wouldn't that make things easier to reference?
3.6: Should there be a reference to RFC 6713 and appropriate registrations for
gzip and friends?
This document includes completed registration templates for several registration requests, and the document editors feel strongly that these should be normative references -- they are necessary references for the registrations. I feel equally strongly that they should be informative references. They are normative in the IANA registry, but not, as I see it, in *this document* -- there is no reason whatever that someone needs to understand, say, JSON or the Zip file format in order to read and understand this document. I encourage ADs to weigh in on this in non-blocking comments. I don't think this is an issue to block the document over.
- I agree that this document should be Informational - I agree with Barry's point that the references *in this document* can be informative references.
I encourage changing this to Informational. Nit - since 3.1 is pointing to media-type-reqs for definitions of the registration form headings, should that reference be normative?
Updated to fix editorial error on my part. I have the question Stephen has about DER/BER. DER is a valid subset of BER and that might be worth pointing out in the BER section ;) Did the WG consider also including CER (defined in X.690), PER (defined in X.691), XER (defined in X.693) for completeness? I know they're not used nearly as widely as DER and BER, but if this is the bucket to include as many as there are defined shouldn't we throw 'em in?
draft-ietf-pkix-rfc5280-clarifications
Please consider the Gen-ART Review comments from Vijay Gurbani on
16-Oct-2012:
- S1: The fourth paragraph should be put right underneath the second
paragraph since the former continues discussion started by the latter.
- S1: Last paragraph -- it will be good to provide some documentation
regarding the "observed attacks". Especially a link to relevant
papers of archival quality discussing the attacks will be helpful. If
the attacks are related to the Diginotar and Comodo break-ins, then
there is an archival paper [1] at a reasonably high level from IEEE
that discusses this and provides a starting point for those who want
to learn more.
[1] Neal Leavitt, "Internet security under attack: The undermining of
digital certificates," pp. 17-20, IEEE Computer, December 2011.
Glad to see we've finally got this done. Thanks to all involved. All of the updates seem correct and appropriate to me. While there might be other things about 5280 that one could consider wanting to update, at this point there would likely be sufficient difficulty in achieving rough consensus on any such addition that its simply not worth the effort.
Section 3:
Conforming CAs SHOULD use the
UTF8String encoding for explicitText, but MAY use VisibleString or
BMPString.
This is (as was 5280) worded oddly. I can take this to either mean, "UTF8String
is the requirement. However, there are circumstances under which you might
violate this requirement, in which case VisibleString or BMPString are the only
possible alternatives", or "Any one of UTF8String, VisibleString, or BMPString
are acceptable, but UTF8String is preferred." The combination of SHOULD and MAY
makes this ambiguous. I think you should fix it.
I'm glad to see these clarifications, and I'm happy to ballot "yes". A few notes, and one question I'd appreciate an answer to, if you don't mind: Notes: I would have appreciated the use of proper change bars on the paragraphs. When one sentence in a paragraph is changed, it's hard to pick out what changed -- I wind up having to read the old and new paragraphs back and forth, one sentence or one phrase at a time. Harder than it needs to be, and especially bad when there's gratuitous moving of words from one line to another (as in Section 4). That made this difficult to review. -- Section 9 -- The RFC Editor will likely change "versions 00 through 04" to "earlier versions"; they don't like to refer to specific versions of drafts like that. If you really don't want that change, you might have to fight them on it. Question: -- Section 3 -- This changes "MAY use IA5String" to "MUST NOT" use IA5String. This makes some formerly conforming CAs non-conforming... what is the effect of this in actual practice? Are there known CAs that are using IA5String?
draft-ietf-dhc-client-id
I agree with the concern expressed by other ADs that this document makes no comment about why there was mandatory behavior in 2131. Perhaps it was a mistake, or maybe "MUST NOT" was used to indicate that there was no known reason to include 'cleint identifier'. I also agree that it seems likely that the WG would not have supported this document without being OK with this point, so I don't think the issue merits a Discuss, but adding a briefexplanation to the Introduction would be nice. While you have this document open to address the Discusses, could you please consider some tidying... --- Abstract - Please don't include citations (using square brackets) in the Abstract as it must stand alone. - Please s/draft/document/ - s/clairies/clarify/ --- Section 1 para 1 a/server/servers/ --- Section 1 para 2 - s/clairies/clarify/ - s/of 'client identifier'/of the 'client identifier'/ - s/return client identifier'/return the 'client identifier'/ --- Section 2 DHCP relay agents and servers, following these recommendations MAY drop the DHCP packets in the absence of both 'client identifier' and 'chaddr'. It is not clear what "these recommendations" means. The previously quoted text is not a recommendation. And the "MAY" is also not a recommendation. I assume that this text is still describing the status quo ante, not the status after this document, so how about... Furthermore, DHCP relay agents and servers implementing [RFC2131] "MAY" drop the DHCP packets in the absence of both 'client identifier' and 'chaddr'. --- Section 2 para 2 OLD In some cases, client may not be having valid hardware address value to be filled in 'chaddr' field of the packet and hence may set this field as zero. NEW In some cases, a client may not be have a valid hardware address value to be fill into the 'chaddr' field of the packet and hence may set this field as zero. END --- Section 2 para 3 Note that due to above mentioned recommendations in [RFC2131] I don't think it is a recommendation. How about s/recommendation/option/ --- Sections 2 and 3 You want his published as a standards track RFC, so you need to stop "proposing" and start "specifying". --- Section 3 If the 'client identifier' option is set in a message received To avoid exactly the same ambiguity in the future, can I suggest s/set/present/
I support both Brian & Barry's DISCUSS points.
This is a "did the WG think about this?" comment that used to be a discuss. Privacy is much more of a deal now than it was in 1997. RFC 2131 says that the client identifier is opaque and MUST be unique for the subnet and MUST be the same for a while. I believe (but am open to correction) that current clients generally pick a value for this and then pretty much use that for all time for all networks. Would it be reasonable to call that out as a privacy issue if the value chosen is personally identifying information (PII), (or becomes such through repeated usage) and to RECOMMEND that clients don't pick PII as the value for client identifiers and that clients also change the value used when they can? I'm not sure it'd be easy to properly state when its safe to change the value used, but perhaps folks who know DHCP better would be able to figure that out. Ted Lemon suggested maybe adding something like this as a security consideration: "It is worth noting that DHCP clients routinely connect to different IP networks managed by different network providers. DHCP clients have no a priori knowledge of which network they are connecting to. Consequently, the client identifier will, by definition, be routinely shared with network operators and could be used in ways that violate the user's privacy. This is a problem that existed in RFC2131. This document does nothing to address this problem."
*Why* does 2131 say what it says? Is the fix really as simple as this? Is there no danger of any misbehaviour with clients that are not expecting the "client identifier" in the DHCPOFFER and DHCPACK messages? Regardless of the answer to this (I'm expecting that it's safe to do this, or the WG wouldn't have approved the document), these questions should be answered in the document. Why is it currently prohobited to return that option, why is it different in DHCPv6, and why is it safe to make this change?
These are non-blocking, but please consider them, and feel free to chat with me about them: Does this document really need the pre-5378 disclaimer? I presume it means that the first listed author isn't sure he has clerance from Nokia to grant rights to the IETF Trust. But that would surprise me, as Nokia still has a lot of active IETF participants. Or is there some other reason for the disclaimer? The abstract should not use citations. You could also clean up redundancy and verbosity in the abstract, and actually say more, this way: NEW This document updates RFC 2131 -- Dynamic Host Configuration Protocol (DHCP) -- by addressing the issues arising from that document's specification that the server MUST NOT return the "client identifier" option to the client. Despite its brevity, this is a difficult document to read. I think, though, that it's ultimately understandable, and that the RFC Editor will be able to fix the problems without introducing errors, so this isn't worth a major editing pass at this point.
The document says: The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131] provides configuration parameters to hosts on a TCP/IP based network. I think it should say ... hosts on an IP network. TCP may be there, but is not required.
I have no problem with the publication of this document, but I do have a few issues that should be discussed. 1. I find it surprising that the draft's Security Considerations section says "No known security considerations". If a DHCP message contains the client identifier option, are there any potential DoS attacks that could be launched? What about user tracking? 2. Should this draft provide more guidance on the setting of the client identifier field? I did not see anything in 2131 that precluded a device from setting it to zero, which appears to be an issue if chaddr is set to zero.
1. There are several places with subject-verb disagreement and missing
articles. I would suggest an editorial review.
2. The Introduction should either drop mention of the "Problem Statement" or
add a forward reference to that section.
3. I had a hard time parsing the 1st sentence of the 2nd paragraph in Section 2:
In some cases, client may not be having valid hardware address value
to be filled in 'chaddr' field of the packet and hence may set this
field as zero.
Should this be:
In some cases, a client may not have a valid hardware address to
populate the 'chaddr' field and may set the field to all zeroes.
I support Barry's discuss.
The last sentence in the first paragraph of the problem statement looks like it
is putting a normative requirement on DHCP relay agents and servers ("MAY drop
the DHCP packets"). Is it restating something that 2131 explicitly allows? I'm
not quickly finding text in 2131 that says this - could you add a pointer? Or
was the intent to say "some implementations might"?
Is there danger that existing relays (or firewalls) would discard responses
containing the client identifier given that the packet violates a MUST NOT in
2131? If so, the document should acknowledge that deployment consideration.
In the fifth paragraph of the problem statement, the document talks of multiple
DHCP clients running on the same host sharing the same chaddr. Please consider
clarifying whether you mean independent pieces of software (running in
different processes) or if you are talking about a single piece of software
attempting to configure more than one address.
I'm on board with the other discuss holders. Further, I really like Ted's response to Stephen's comment and am hoping the shepherd & authors agree to include it.
draft-ietf-geopriv-local-civic
I have no objection to the publication of this document. I think the Security Considerations section would benefit from a direct reference to RFC 3694 (rather than relying on the cascaded reference though RFC 5139 and RFC 419). In partcular, the addition of new extensions makes the protection of location information by a user a more complex matter and sections 4.3.1 and 5.1 of RFC 3694 could be called out. Essentially, inventors of new extensions need to told to make very clear how naive users of geopriv systems will be able to protect their LI. I agree with Stewart's Comments.
I disagree that there are no new security considerations but these ought be easily fixed. - First, this introduces (namespace) URLs into DHCP messages, and it could be that DHCP clients or servers or relays might de-reference those as part of translating between DHCP messages and XML, and that might result in bad things happening. I think you ought say to not do that. - Second, extensions could be defined that are more sensitive than those that exist in 4776, (room-function=HIV-testing-lab or similar perhaps) which notes that DHCP offers no protection whatsoever for such information, so I think you ought to again say to not do that and that the designated expert should take that into account if someone proposed some particularly sensitive information be included as an extension to civic addresses.
- Can't we use canals.example.com rather than canals.org.uk? (And same for other examples) - 3.2: I assume the length field includes the two spaces so the description below should say "Length is the number of... plus 2" right? - 3.2: I don't get this bit: "This conversion only works for elements that have textual content and an optional "xml:lang" attribute." What is an element doesn't allow an xml:lang attribute - why would that not work? And if there is an xml:lang attribute, then how come that doesn't need to appear in Figure 3? - I also like Figure 6, thanks.
3.2 Using space as a separator means that local name can have no spaces in it. Is that guaranteed by XML? Is there a reason not to use a leading length byte for each of the elements? Easier to parse. The content of a CAtype (after the CAtype code and length) is UTF-8 encoded Unicode text [RFC3629]. So the URL must be US-ASCII. Probably best to say that. The local name also has some limitations I suppose. Saying the whole thing is UTF-8 is not helpful. This conversion only works for elements that have textual content and an optional "xml:lang" attribute. I don't understand why this is the case.
Updated for version -09: Version -08 addresses my DISCUSS points. Version -09 addresses my non-blocking comments. Thanks very much for considering my comments and making changes Leaving one for amusement value: -- Section 5.1 -- Excellent ASCII-art lamp post you got there.
123 Colorado Boulevard is a real address 123A Main Street is likely a real address, there are enough 123Main Streets that one may well have and "A" Shouldn't we be using example addresses? I looked for, but did not see an identifier for a house with no number. Such houses exist: Wentwood House, Upper Clapton Rd, London, Greater London E5 9BY, UK High Farm, Farrar Lane Leeds LS16 7AQ to take two random examples from Google.
draft-snell-http-prefer
-16 addressed my other comments, (thanks), not sure if these were missed or not but don't think I saw any response - Is "relation types" correct in section 4, 1st para? - 4.3, where is delta-seconds defined?
2 Implementations MUST support multiple instances of the Prefer header field in a single message, as well as multiple preference tokens separated by commas in a single Prefer header field. The following examples are equivalent: I think this is worded a bit oddly. The requirement is that the multiple instances be treated as identical to a single instance with multiple comma-separated token/value pairs. That's defining the semantics, not a particular behavior requiring a MUST. Now, maybe the intention was to say that receiving implementations MUST *honor* multiple instances of the Prefer header field, but that's incompatible with the earlier comment that a server is allowed to ignore any preference it feels like. So my recommendation is simply to rewrite this as: A client MAY use multiple instances of the Prefer header field in a single message, or it MAY use a single Prefer header field with multiple comma-separated preference tokens. If multiple Prefer header fields are used, it is equivalent to a single Prefer header filed with the comma-separated concatentation of all of the tokens. For example, the following are equivalent: 4 Registered preference names MUST conform to the token rule, and MUST be compared character-by-character in a case-insensitive fashion. This is not a restriction for *registered* preference names; this is a restriction for *any* preference name. I think this belongs in section 2 (and probably would be fine without the MUSTs). If you are putting it here to give guidelines to the Expert Reviewer, put a back pointer to section 2 by saying, "The Expert Reviewer shall ensure that the registered preference name conforms to the token rule in section 2 and that it is not identical to any other registered preference name (as compared in a case-insensitive fashion). They SHOULD be appropriate to the specificity of the preference; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names remain available for less specific use. That SHOULD is a noop, unless as above this is simply instructions for the Expert Reviewer, in which case the SHOULD is unnecessary. Registered preferences MUST NOT constrain servers, clients or any intermediaries involved in the exchange and processing of a request to any behavior required for successful processing. The use and application of a preference within a given request MUST be optional on the part of all participants. I don't really understand what the first sentence means, certainly not in the context of the MUST NOT. Is this simply saying, "Choose a name such that generic names are reserved for generic operations"? The second sentence belongs in section 2. 4.2 The "return-minimal" and "return-representation" preferences are mutually exclusive directives. A request that contains both preferences can be treated as though neither were specified. This worries me a bit. There are clear instructions for what a server is supposed to do if it sees duplicate preferences: Choose the first one. But here, both occurring means to honor neither of them. I don't get that. If you have mutually exclusive preferences, it seems to me they should simply be values of a single preference. In this case, why not have the preference be: Prefer: return-amount=representation Prefer: return-amount=minimal Then you don't get into questions of anybody having to figure out what are mutually exclusive semantics. 4.4 The "strict" and "lenient" preferences are mutually-exclusive directives Same as above. How about: Prefer: handling=strict Prefer: handling=lenient
Given that the document points to the similarity between Prefer and Expect, consider being explicit about not using tokens defined for Prefer in Expect header fields and vice-versa. You might also provide guidance about whether to use the same token in both if you are defining a behavior that would make sense to use in both places. Did you consider whether a client would ever need to say "I prefer thing X most, Y if you won't do that, and Z if you wont't do that"? Does anything here prevent adding something later that would capture that semantic? (I don't think so, parameters could be added to group preferences and give them weights for instance). Why isn't the SHOULD in "The Prefer header field is end-to-end and SHOULD be forwarded unless" not a MUST? Do you want to say anything about the order of parameters on a given header field value being significant or not? (Do you inherit a not from the base spec?)
draft-gp-intarea-obsolete-ipv4-options-iana
Sections 2.1 thru 2.5 include a sentence that tells where the option was deprecated or that the option was not widely implemented. There is not similar information in Sections 2.6 thru 2.9. As a result, no rationale for deprecating these options is provided.
I believe the scope of this document is only updating the IANA registry. No mention of filtering based on this information should be made in the abstract or security considerations. Doing this makes it questionable why you would later need the referenced opsec document, if you're saying that the IANA registry's state implies what people's security policies should be for packets with deprecated pieces. In other words, please do not confuse tidying up the IANA registry with recommending a security policy. Let that later document you're targetting for BCP get the consensus for that part on its own.
I support Russ' and Wes' DISCUSSes. Since I see that they're about to be resolved (for example, I'm happy with Ron's suggestion to Wes' DISCUSS), no point to have a formal DISCUSS in this case. Regards, Benoit.
As discussed with IANA, the reference fields for the deprecated options will include both the original reference and this document, to provide the full history.
It seems odd to have a normative reference to a document we are obsoleting. Why isn't this reference to 1393 informational?
draft-ietf-precis-problem-statement
- 5.2.2 might have been a good place to explain what normalization means. You can sort of get it from the text, but might be nicer to add a definition.
No objection to the publication of this document, but I would like to have the following points discussed - Why do you have a temporary WG name in the draft title? Who will remember what PRECIS is in 10 years from now? Proposal: 1. either explain PRECIS in the draft. At the very minimum the acronym. 2. Or remove PRECIS: Stringprep Revision Problem Statement 3. Alternatively, replace PRECIS: maybe "Stringprep Revision and IDNA2008 Problem Statement" - Why don't you refer to the latest version of the unicode, i.e. version 6.2? The draft still refers to version 6.1. - You actually never explained what a (Stringprep) profile is, and what it contains. For new comers who don't have the full IDNA background, a couple of extra sentences would be welcome... EDITORIAL: - What's the point to have a reference to [NEWPREP], since you don't mention where they are? During IETF 77 (March 2010), a BOF discussed the current state of the protocols that have defined Stringprep profiles [NEWPREP]. [NEWPREP] "Newprep BoF Meeting Minutes", March 2010.
Well done. I've a number of non-blocking comments: The shepherd writeup says this: Given that the document itself is informative, no normative references were appropriate and all of the references are informative. I think this is wrong. Normative references are those that are necessary to the understanding of the document at hand, and they exist even for Informational documents. In this case, I think the following are normative: Stringprep [RFC3454] IDNA Rationale [RFC5894] You should probaby scrub this for consistent use of "Stringprep" (vs "stringprep"). -- Section 1 -- In the list of known Stringprep uses, I would find it easier to read and more convenient if items based on the same profile were grouped in sub-bullets. Something like this (significantly abbreviating here): o The Nameprep profile o IAX using Nameprep o NFSv4 and NFSv4.1 o The iSCSI profile o The Nodeprep and Resourceprep profiles o The SASLprep profile o IMAP4 using SASLprep o Plain SASL using SASLprep o NNTP using SASLprep o The LDAP profile o PKIX subject identification using LDAPprep o PKIX CRL using LDAPprep o The unicode-casemap Unicode Collation Then you can also note that in the following paragraph like this: NEW Moreover, many reuse the same Stringprep profile, such as the SASL one, as can be seen from the groupings above. OLD This algorithm is based on an inclusion-based approach NEW This algorithm uses an inclusion-based approach -- Section 4 -- For example, Stringprep is based on and profiles may use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15]. Because of the citations and because it's not central to what you're saying, I don't think it's necessary to expand NFKC and NFC. But it might be helpful to say something like, "for example, for normalization Stringprep [...]" a localpart which is similar to a username and used for authentication, a domainpart which is a domain name and a resource part which is less restrictive than the localpart. Because of the complexity of this and the imbedded "and" in the first item, this list really demands the Oxford comma, "domain name, and". I'm not sure the RFC Editor will get it right. -- Section 5.2.6 -- Is "phishing" now a sufficiently common and lasting term that we can use it without explanation? In any case, in the next sentence the issue *is* to be considered (not "are"). -- Section 7 -- To address the SecDir review comment, you might add something like this: "See the Stringprep Security Considerations, [RFC3454] Sevtion 9. See also the analyses in the subsections of Appendix B, below.'
The list of Known IETF Specifications in the introduction is presented as a complete list. I believe it is already a little stale (see RFC6063 for example). Should the list be updated to those known specifications at the time the RFC is published (and a datestamp added to qualify the statement), or should the statement be softened to "Some known"?
draft-ietf-softwire-dslite-deployment
General ======- A major flaw of this document is that it - restates protocol details that are described normatively in other documents - offers implementation advice - recommends new features for implementations Once all of that is stripped away, I wonder whether the remaining document will be worth publishing Section 2.1 =========== Recommends that operators deploy two interfaces, as opposed to a single, dual-stacked interface. The only rationale offered is "to segregate the functions". Could you explain why segregation is desirable? Section 2.2 =========== Doesn't appear to say anything that isn't already said by Section 6.3 of RFC 6333. Beyond that, it offers no deployment advice. A good piece of deployment advice would be to do everything possible to eliminate the need for fragmentation. Even if fragmentation is possible, it will adversely impact performance. Section 2.3 ========== Appears to be implementation advice, and not a deployment consideration. However, I am not sure that I agree with the advice that it offers. The v4 packet set the DF bit. Why should that preclude fragmentation of the v6 packet. Section 2.4 =========== Concur with Stephen Farrell's DISCUSS Section 2.6 =========== Does not offer advice to the party deploying DS-Lite. It offers advice to a much, much larger community of Internet users and application developers. Section 2.8 =========== Reminds the operator that he can't collect accounting information from an encapsulated packet (i.e., between the B4 and AFTR). Beyond that, it doesn't offer much helpful advice. Section 2.0 =========== Appears to be a feature request. Section 2.11 ============ Concur with Brian's DISCUSS Section 2.12 ============ Offers no advice beyond that offered by RFC 2983 Section 3 ========== Concur with Brian's DISCUSS
The Gen-ART Review by David Black on 15-Oct-2012 raised five issues, and the authors have agreed to make changes to address them. The revised I-D has not been posted yet.
`I stongly support Stephen's Discuss related to wiretap. I understand that the provision of wiretap is something that operatros may be required to think about by their regulators. However, with RFC 2804 in place, the IETF should not publish documents that "encourage" wiretap. --- In section 2.6 an abused user Is this an abusive user, or maybe an abusing user? --- I tried, but couldn't find any other issue that is not already caught by another AD's Discuss or Comment.
1) section 2.4 discusses lawful intercept but the IETF have a consensus (see RFC 2804) to not standardise wiretapping features. While this isn't a standards-track document, 2.4 is recommending how to do wiretap. I'd rather see 2.4 deleted since I think that's the simplest and cleanest way to follow 2804, but if the section remains then I think the language needs to be changed (e.g. s/should/could/) and a reference to 2804 should be inserted. 2) 2.5 is incorrect in talking about "users," what is being identified is really a B4 isn't it? And there could be many users/hosts in the customer premises. I think that is sufficiently important to fix since it has happened that people have been wrongly blamed for actions simply due to this confusion of addresses and users. 3) 3.1: Wasn't there some issue with DNSSEC here? (I don't recall right now) If so, I think that'd warrant a mention. If not, sorry:-)
- 2.6 is probably also a bit wrong in how it talks about users. I also wasn't sure what was meant by "an abused user"? - 2.11 could do with a reference to rfc 6280, since that represents our BCP for location and location privacy handling. - 2.13: Just checking, but does PCP base handle this with the simple security model? I can never recall. There was a recent thread on the pcp list about that and it might be worth a look to see if PCP-base is ok here. (The statement in this draft is true though, PCP-base was designed to handle this, the question is whether or not the security model in PCP-base does that well enough.) - secdir review [1] has a couple of nits [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03594.html
I ballot no objection, solely on the basis that the other DISCUSS ballots cover all of my issues that would be worth a DISCUSS or comments. One general concern: This document lacks a terminology section, e.g., that readers should be familar with certain other documents, e.g., RFC 6333 and the terminology of it.
While I agree with most of the DISCUSS and COMMENT (not all btw), I believe this "Deployment Considerations" draft is useful. I'm available to help the authors/ADs on this document, if necessary
I support Barry's discuss points.
(Sorry: re-doing this to move the DISCUSS comments up here, rather than referring to them down there.) 1. I have some questions where I think that this document is either giving implementation advice, rather than deployment advice, or making demands that are out of its scope: -- Section 2.3 -- the Tunnel-Entry Point and Tunnel-Exit Point should fragment and reassemble the oversized datagram. If the DF bit is set in the IPv4 header, the B4 element should send an ICMP "Destination Unreachable" with "Fragmentation Needed and Don't Fragment was Set" and drop the packet. If the DF is unset in the IPv4 header, the B4 element should fragment the IPv6 packet after the encapsulation. Fine, but what does that have to do with deployment and operation? This seems to be telling us how to implement DS-Lite, not how to deploy it. -- Section 2.6 -- Internet hosts such as servers must no longer rely solely on IP address to identify an abused user. The server should combine the information stored in the transport layer (e.g. source port) and application layer (e.g. HTTP) to identify an abused user [RFC6302]. I presume you mean an "abusive" user, not an abused one. But let me see if I understand this: you are giving deployment advice to DS-Lite deployments by trying to tell arbitrary Internet servers what to do -- servers that have no connection to any DS-Lite deployment, and that perhaps have never heard of DS-Lite and have no idea what it is? You see where I'm going with this? The deployment consideration you need to address here is exactly that these Internet servers will NOT be playing in your sandbox and will NOT accommodate your configuration in the way you're describing above, and they WILL block and blacklist your shared IPv4 addresses. Discuss that problem and perhaps give the deployments advice about what they might do to mitigate it. -- Section 2.11 -- Another possibility is that the applications could rely on location information such as GPS co-ordination to identify the user's location. Again, it's just not in the scope of this document to tell application developers how to re-code their applications. And most non-mobile applications have no GPS capabilities. Indeed, we're largely talking about applications provided as web services, so see my comment about Section 2.6. -- Section 2.12 -- Same comment as for Section 2.3: this is implementation advice, not deployment considerations. 2. Section 4, Security Considerations The security considerations are very fluffy: "The AFTR needs to protect against such abuse." and "The AFTR needs to ensure equitable access.", but nothing that talks about HOW. On the one hand, it's true that this document doesn't introduce those security issues. On the other hand, this document is about deployment and operational considerations, and those are exactly the sorts of security-related issues that need to be addressed when we're talking about deployment and operational considerations.
Given that this is about deployment considerations, I really want to see the OpsDir review that I'm told is expected early next week. It's entirely possible that, as a non-Ops guy, some of my concerns are off. That said, here we go: -- Section 2.1 -- Although an operator can configure a dual-stack interface for both functions, we recommend to configure two individual interfaces (i.e. one dedicated for IPv4 and one dedicated for IPv6) to segregate the functions. I rather hoped to see some explanation of why this is recommended. What are the advantages of such segregation? What is lost or adversely affected by not having them segregated? -- Section 2.7 -- Maybe it's just because I'm not a DS-Lite guy, but this section doesn't seem to be doing much in the way of discussing deployment considerations. It seems to be saying that there are a bunch of configuration options, and listing some of them. Shouldn't it be talking about consideratins for using those options? -- The AFTR can be configured to only accept B4's connections originating from the IPv6 prefixes configured in the AFTR. -- The AFTR can be configured to give priority to the packets marked by certain DSCP values. -- The AFTR can be configured to limit the rate of port allocation for a single B4's IPv6 address. Why might I want to do each of these things, and when are they contraindicated? -- Section 2.8 -- Question to the OPS ADs: Does this section really say enough to be useful? -- Section 2.9 -- Are there references for these standby modes? I expected citations to show me where to look to see how to do these, and there are none. -- Section 2.11 -- To minimize the impact, an operator could deploy AFTR closer to users so that existing location based assumptions of the clients source IP address by geographically aware servers can be maintained. Is "closer to users" really the best way to describe this? What you're really saying is that the operator could deploy AFTRs that each serve relatively small geographic regions, making the geolocation by IP address "accurate enough", right? -- Section 2.13 -- What advice are you giving to deployment and operations here? What are you suggesting that I *do*?
I agree with Stephen's discuss on Section 2.4, and the suggestion to remove the section. This is a special case considerations around "identifying the endpoint" that is already discussed elsewhere in the document.
Consider explicitly pointing to HELD (RFC5985) when discussing the effect this architecture has on determining geolocation based on an IP address, and to HELD's extensions as examples of ways to get better identifiers to use as input. I support Barry's discuss points.
1. In addition to Barry's list of sections that talk about implementation issues, rather than deployment issues, I would note that: * The last sentence of 2.2 certainly sounds like implementation guidance * Section 2.8 seems to mandate certain functions within implementations to support accounting * Section 3 is mandating features for a B4 implementation 2. The guidance in section 2.11 seems to imply that operators should put more exact information into Geo-IP databases in order to facilitate location-based services. If that is the intent, it should be stated more explicitly. In the long run, I don't see this advice being useful given the whole list of issues that arise with the maintenance of such databases.
1. I support both Barry's and Stephen's DISCUSS points. 2. The term B4 does not seem to be defined anywhere even though AFTR is defined. 3. In section 2.5 : s/Deny-of-Service/Denial-of-Service/ and s/Depedning/Depending/ 4. Section 2.7 : s/polices/policies/ 5. Section 3.2.1 : It would be good to add a reference for TR-069. 6. It is unclear why Section 5 even exists.
I support the discusses raised the other ADs and think these comments overlap with theirs, but just in case... In view of the volume of discusses, please can I suggest that the authors respin the document and it is returned to the IESG with a fresh ballot. ==== "DS-Lite is part tunneling protocol." does not scan. === the B4 element .. does not seem to be defined before use === I agree that section 2.4 should be deleted as its inclusion is a violation of IETF policy. === Depedning on the rate of NAT table changes Typo Depending === I agree: Internet hosts such as servers must no longer rely solely on IP address to identify an abused user. looks out of scope for this document, and should be in a host specification RFC. ==== Another possibility is that the applications could rely on location information such as GPS co-ordination to identify the user's location. This technique is commonly used in mobile deployment where the mobile handheld devices are probably usually behind a NAT device. "probably usually" is an odd combination, but in any case I can't see fixed and semi-fixed systems providing this information, indeed they have a strong incentive to lie about it. === An operator may assign the same IPv4 address (e.g. 192.0.0.2/32) to all AFTRs. This IPv4 address only used to respond to the requests from the B4 elements over the softwire. IANA allocates 192.0.0.0/29 [RFC6333] which can be used for this purpose. I am unclear if the two 192 addresses are supposed to be that same of not. The para could use rewording for clarity. === Some of the security issues result directly from sharing routable IPv4 addresses. Addresses and timestamps are often used to identify a particular user, but with shared addresses, more information (i.e., protocol and port numbers) is needed. This needs a back ref to where you discuss the issue in more detail. I am surprised that there is not more discussion of this problem in conjunction with the IPv4 CGN that is referenced here.
I support Barry's and Stephen's discusses.
draft-ietf-softwire-stateless-4v6-motivation
Concur with other abstentions
The Gen-ART Review by Joel Halpern on 5-Oct-2012 raised several issues. Based on the discussion that followed, I was expecting an updated I-D to pe posted to resolve those issues. So far, that has not happened.
I really appreciate the willingness of Service Providers to become involved in this debate. But I havesome real problems with this document. I find that several of the list of 15 "motivations which justify the need for a stateless solution", while being good and desirable things in a network, don't motivate the stateless solution unless you are able to show more clearly that a stateful solution prevents these features. I hoped that the subsections of section 3 would discuss these features one by one, but the subsections are organised differently and so bring the list into question. Furthermore, the discussions in Section 3 seem to treat statelessness as some kind of magic panacea. I am not sure that there is any real actionable solution to my concerns. Perhaps an entire re-write from a different perspective might resolve this, but it seems unreasonable to ask you to do this, so I have decided to Abstain so as to not block the progress of this work.
- I agree with other comments that the list at the start of section 3 needs work. Adrian's breakdown of that looks reasonable to me. - Some acronyms are used but not defined, e.g. OSS, ASBR - 3.1.3 says that abuse reporting requires traceability, and refers to rfc 6269, but the section there on traceability refers only (I think) to legal obligations that exist "in many jurisdictions." Given rfc 2804 I think the argument here either needs to be fixed or else better, the section removed. Note: I'm not saying here that operators don't have to meet legal requirements, but that the IETF have consensus not to standardise the wiretapping aspects of that, so its not that clear whether this argument works given that context. - 3.1.4 says that UPnP can be used. I don't know the security properties of such a solution, but I'd not be surprised if they were problematic. Are they? [1] would appear to imply there are ongoing issues at least. If so, then saying/admitting that would be better. [1] http://www.upnp-hacks.org/ - 3.3.1 - it seems odd to me that identifying a subscriber via IP addressing alone is really a good approach for offering many value added services so I'm not so sure this is a very good argument. - The above 3 points might or might not result in security related issues with some resulting stateless approach but I don't think any ought be DISCUSS level issues here.
I second Adrian's points. Section 3 is not motivating a stateless solution, as many claims are not proven in reality. This draft is good to have for the group's discussion, but I do not see why it must become an RFC. An editorial point: Section 2., paragraph 3: > Session state: refers to an information state as defined in Section > 2.3 of [RFC2663]. In particular, it refers to the state > maintained by the NAT so that datagrams pertaining to a session > are routed to the right node. Note, TCP/UDP sessions are > uniquely identified by the tuple of (source IP address, source > TCP/UDP port, target IP address, target TCP/UDP port) while ICMP > query sessions are identified by the tuple of (source IP > address, ICMP query ID, target IP address). The tuple for TCP and UDP, and also ICMP, is incomplete, as the protocol identifier is missing. It is sort of implicit that the text says TCP/UDP port, but a device would use the protocol fields listed and also the protocol identifier. Even though the text is written in RFC 2663, it is not correct as it is now.
I do not understand the purpose of this document.
I agree with many of Adrian's points and I don't see how section 3 could be cleaned up in any meaningful way.
The security considerations section reduces to "this might be better than some other approach". It would be much more useful to talk about the security properties if this kind of solution were deployed. The document seems to avoid highlighting some of the tradeoffs a stateless approach entails. For instance, if an element ended up inappropriately in a blacklist, some avenues for recourse available in a stateful solution would not be available here. Adding discussion of that kind of tradeoff would make a more useful document for motivating and guiding additional work.
1) This document is in the softwire charter so I can see publishing it, but I
tend to agree with Adrian that I expected s3 to better motivate the need. I
for sure thought you'd correlate the sections in s3.* with the numbers in s3.
2) s1: The word smithing that follows is non-blocking (obviously) ... but maybe:
OLD:
When the global IPv4 address space is exhausted, Service Providers
will be left with an address pool that cannot be increased anymore.
Many services and network scenarios will be impacted by the lack of
IPv4 public addresses. Providing access to the (still limited) IPv6
Internet only won't be sufficient to address the needs of customers,
as most of them will continue to access legacy IPv4-only services.
Service Providers must guarantee their customers that they can still
access IPv4 contents although they will not be provisioned with a
global IPv4 address anymore. Means to share IPv4 public addresses
are unavoidable [RFC6269].
NEW:
When the global IPv4 address space is exhausted, Service Providers
will be unable to obtain addition IPv4 addresses for their customers.
Service Providers can't simply provide their customers with IPv6
addresses because many services will likely be IPv4-only services for
the foreseeable future. Service Providers need to guarantee continued
access to the IPv4-only services for the customers.
3) s1: I think this is redundant:
There is nothing like a
"One size fits all" solution or one target architecture that would
work for all situations.
maybe just:
There is no one size fits all solution.
4) s1: word smithing alert:
OLD:
Current standardization effort that is meant to address this IPv4
service continuity issue focuses mainly on stateful mechanisms that
sharing of global IPv4 addresses between Customers is based upon the
deployment of NAT (Network Address Translation) capabilities in the
network.
NEW:
Current standardization efforts to address the IPv4 service continuity
issue focuses on stateful mechanisms that share global IPv4 addresses
between customers with NAT (Network Address Translation) capabilities
in the network.
5) s1: when you say "Because of some caveats of such" what do you mean? I
thought it's more that they're unhappy they're going to have buy/deploy/manage
another box (i.e., CGN) that they're (hopefully) not going to keep for very
long - in other words it's a low ROI. If I'm right can we say that?
OLD:
Because of some caveats of such stateful approaches the
Service Provider community feels that a companion effort is required
to specify stateless IPv4 over IPv6 approaches.
NEW:
Because the stateful approaches requires the deployment of additional
hardware that will be unnecessary once IPv6 is fully deployed, Service
Providers see a low return on their investment in a Carrier Grade NAT
(CGN) and are seeking to specify stateless IPv4 over IPv6 approaches.
6) s1: I don't think the solution is elaborated in this document:
OLD:
Note that the
stateless solution elaborated in this document focuses on the
carrier-side stateless IPv4 over IPv6 solution.
NEW:
This document focuses on carrier-side stateless IPv4 over IPv6.
7) s1: delete penultimate paragraph it's redundant if you accept #6.
8) s2 stateful 4/6 solution: Maybe more simply
Stateful 4/6 solution (or stateful solution in short): denotes a
solution where a NAT in the Service Provider's network
maintains user-session states [I-D.ietf-behave-lsn-requirements].
The NAT function is
responsible for sharing the same IPv4 address among several
subscribers and for maintaining user-session state.
9) s2 stateless: Maybe more simply:
denotes a
solution that does not require any per-user state (see Section
2.3 of [RFC1958]) be maintained in the Service Provider's network.
A dependency between an IPv6 prefix and IPv4 address is assumed.
In an IPv4 address sharing context, dedicated
functions are enabled in the CPE router to
restrict the source IPv4 port numbers. Within this document,
"port set" and "port range" terms are used interchangeably.
11) s3: If you're going to keep s3.4 should cost be in the s3 list? Maybe even
at the top?
12) s3.2.1: I think you could delete the 1st paragraph - of course they want to
preserve their practices because it's cheaper to do so.
13) s3.2.1: Maybe some common practices are preserved I can't believe all will
be preserved.
14) Please: expand CAPEX, OPEX, and CGN.
15) s3.2.4: I had a lot of trouble parsing this:
Deploying stateful techniques, especially when used in the Service
Providers networks, constrains severely deploying multi-vendor
redundancy since very often proprietary vendor-specific protocols are
used to synchronize state.
Maybe:
Deploying stateful techniques is problematic because often proprietary
protocols are used to synchronize state and with multiple vendors in
a Service Provider's network multiple protocols are needed.
and I had trouble parsing this:
OLD:
This criterion is very important for Service Providers having a
sourcing policy to avoid mono-vendor deployments and to operate
highly-available networks composed on multi-vendors equipment.
NEW:
This criterion is very important for Service Providers because they
want to avoid being locked into one vendor for their entire network
and they want to operate multi-vendor-supplied networks.
15) s3.4: Not sure the following is entirely true because I'm not sure you can
speak for all service providers:
From a
Service Provider perspective, stateless solutions are more attractive
because they do less impact the current network operations and
maintenance model that is widely based on stateless approaches.
Maybe:
From a Service Provider perspective, stateless solutions may be
more attractive because it impacts the current network operations
and maintenance model less than stateful solutions.
16) s5: Unsure s5 is needed - especially the last paragraph. It's already in
the charter to do this work so I don't see the point.
17) I also agree with Robert that discussing the security properties if this
kind of solution were deployed would be better than just saying we're just as
good but maybe a little better.
conflict-review-irtf-p2prg-mythbustering
Yes, no problem with the conflict review. But ISE, please note that a myth is a myth. Nearly every dictionary definition of "myth" strongly assigns falsehood to the myth. The only defintion that allows underlying truth is the one about folk stories. Probably the most relevant definition here is: noun - an unproved or false collective belief that is used to justify a social institution In summary - you cannot show a myth to be true!