IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-09-26. These are not an official record of the meeting.
Narrative scribe: Susan Hares and Carlos Pignataro (The scribe was sometimes uncertain who was speaking.)
Corrections from:
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
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
2.2.3 For Action
Telechat:
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
Telechat:
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
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
Telechat:
3.4.2 Returning Items
Telechat:
?? EDT break
?? EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
Telechat::
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Agenda Working Group News
1413 EDT Adjourned
(at 2013-09-26 07:29:35 PDT)
draft-ietf-mpls-return-path-specified-lsp-ping
RFC Editor Note added to cover the issue raised by IANA
(1) 5: How can I check the MUST here? Can the source have an IP address but the reply path doesn't use IP? If so, how can the egress LSR make this check? Or am I reading something wrong? (2) 5: Doesn't this raise some new potential DoS attacks? 4379 has a good discussion of security but doesn't cover all that can be done here I think, especially if my discuss point 1 is real. (If my discuss point 1 is just me misreading stuff, then I think this goes away too.)
- 3.2: "A flag" - I didn't find the description here easy to follow. Setting this means "don't use the path you'd use if reply mode 2 or 3 was sent" but how does the egress LSR know what non-default path to pick? - 3.2: "B flag" - I don't get how the return path is known. Maybe the same problem (of my understanding) as the for the A flag:-) - 3.2: The reply paths sub-TLV seems underspecified. Maybe a ref to a bit of 4379 is needed? - 3.3: How can a sub-tlv with no typing carry any "future defined" type? (That is I support Stewart's discuss.) - 3.3: I can't parse this "One usage of these generic RSVP Tunnel sub-TLVs is when LSP Ping is used to periodically verify the control plane against the data plane [RFC5884], using Tunnel other than particular LSP can avoid the impact of LSP identifier changing when Make-Before-Break (MBB) is deployed." - 4: "the echo reply MUST carry the FEC stack information in a Reply Path TLV" huh? do you mean echo request? and don't you need to say which of 3.3.x is the one to use? (presumably 3.3.3)
The MTU issue should be checked.
I echo Stewart's Discuss about terminology and his Comment about whether there are any MTU size concerns that should be mentioned.
There is no benefit to using an IPv4-mapped IPv6 address to represent loopback addresses and there have been recommendations to not use them whenever possible. Given that the original specification (RFC 4379) defined the use of IPv4-mapped IPv6 addresses in the multipath information field, it is not the fault of this document for their use. In general, the use of IPv4-mapped addresses is very limited and the use-case here does not call for their use. The native IPv6 loopback would have been more appropriate.
I find the definition of the data structure very confusing. In Figure 1 you have "Reply Paths", but there is no definition of Reply Paths. I assume that you mean Tunnel sub-TLVs (section 3.3). If so you need to align the notations. Also "Reply Paths" implies multiple concurrent paths, but I don't think that is what you mean. This needs to be clarified and made consistent.
My guess is that it is now water under the bridge due to the allocation of currently assigned return codes, but it seems to me that 64K return codes (with 10 allocated) is rather a lot, whereas 16 flags is always too few. I am surprised that a more conservative allocation plan was not used. "The Reply Path TLV can carry any (existing and future defined)". My experience is that to be in a position to carry any future defined data structure is quite an ambitions undertaking :) Can I assume that the response message is so small that I do not need to think about MTU?
the use of ipv4 mapped address in lieu of the whole 0000::/8 0:0:0:0:0:FFFF:127.0.0.0/104 in section 4 kind of gives me heart burn. in general ipv4 transition-isms shouldn't make their appearance or be imparted special meaning when that's unnecessary. and it appears to be uneccessary in this case. e.g. The destination IP address of the echo reply message MUST never be used in a forwarding decision. To avoid this possibility the destination IP address of the echo reply message that is transmitted along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost label MUST be set to 255. e.g. ::2/128 has the same result.
draft-ietf-dime-realm-based-redirect
(1) I don't see any "authorization" checks in section 13 of 6733 so I don't know how to enforce the MUST in this draft's section 4. How does that work? (2) Just checking. Are there any Diameter applications where the client and server use the server's realm as input to a cryptographic calculation that could be broken by this form of re-direction? (Esp. if the re-direction happens at a proxy.) (3) Are you missing some security considerations? This form of re-direction could lead to a client sending a sensitive AVP to a new realm without the client knowing that. Or to a client receiving a sensitive AVP from a new realm withouth the client knowing that the re-direct has happened. If so, then shouldn't those be noted as risks that the client is unwittingly taking on? Why would that be ok? (Or maybe I'm misreading this.)
- (This is not for the authors, but for the IESG.) I note that the IPR declaration section III lists "Director of Licensing" as the IETF participant whose personal belief triggered the disclosure. That seems unlikely. Are we ok with that?
Thanks for writing this spec. One small issue: Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. I think the reference alone is probably not sufficient to specify the app, and is definitely not sufficient for the application software... I'd suggest rewording: A new application specification can incorporate the mechanism specified here by making it mandatory for the application, and referencing this specification normatively.
2: the restriction in [RFC6733] that the NAPTR replacement field SHOULD match the domain of the original query does not apply for realm-based redirect purposes. Strike "SHOULD". It is a 6733 requirement, and one that is overridden by this document. Having it here could lead to confusion. ...support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. ...it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node... These are not protocol requirements. Instead of "MUST", try "needs to".
Just one non-blocking comment here: The Abstract is way too long, and has lots of explanatory stuff that should be in the Introduction, not in the Abstract (having an Abstract that's longer than the Introduction is a good clue to this sort of thing). The Abstract should just be enough to understand whether this is likely the document one needs to look at, and shouldn't be giving all the background explanation. I suggest replacing the first three paragraphs of the Abstract with this, or something close to it, an moving the rest of the explanatory text to the Introduction (or eliminating it, because it's really covered in Section 2 anyway): NEW The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when S-NAPTR is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server". END A comment about the shepherd writeup (not for the authors): In answer to Q12 in the writeup, the shepherd gave this: This is a requirements document and as such has not need for MIB Doctor, media type, and URI type reviews. This is not a requirements document, and this was clearly copied from another writeup and not updated. It makes me question the rest of the writeup: how much else is not correct for this document, and was copied from another?
Is there an attack whereby the original domain is misconfigured to direct traffic to to a victim domain?
I support Stephen's discuss points. Note that on #2 I was worried that this redirection might somehow break the emu cryptobinding protocols wrt a) to keys made that use the realm but the emu protocols just use diameter as a transport and don't use diameter's realm when they make keys b) they'd be redirecting the inner methods somewhere different - but that doesn't seem to be happening.
draft-ietf-ccamp-gmpls-signaling-g709v3
IANA issues addressed in email and RFC Editor note
Just two minor, non-blocking things related to the use of "REQUIRED" as a 2119
key word along with the modifier "not":
-- Section 6.2 --
- In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit
Map information is not REQUIRED and MUST NOT be included, so
Length field MUST be set to 0 as well.
The "REQUIRED" there should not be a 2119 key word, and should be made lower
case. Otherwise, there's a conflict with the MUST NOT. And see below.
-- Section 9 --
o A node supporting both sets of procedures (i.e., [RFC4328] and
this document) is not REQUIRED to signal an LSP using both
procedures, i.e., to act as a signaling version translator.
Similar to the above. The problem is that "REQUIRED" means "MUST", but "not
REQUIRED" does not mean "MUST NOT". It's best to avoid "not REQUIRED" with a
2119 meaning. The easiest fix is just to make "required" lower case (or
another way to say "is not required" is "need not"). And I can't really think
of a good way to say what you want to say in 2119-ese, nor why you'd have to.
draft-ietf-netext-update-notifications
5.2: What happens if the IPsec SA is re-negotiated automatically? Isn't there a potential layering/sync problem so that these notifications couldn't ever be verified since a new SA would be in use? I think you just need to say the same or an automatically renegotiated SA (not sure what's the right terminology, sorry). I think 6.1 has the same issue and maybe other bits too. That kind of check also seems to imply that the interface between the MAG or LMA and the IPsec code needs to know that the right SA is being used which could be tricky. What's really done here?
- 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons need an explanation and/or (forward) reference.
Robert Sparks raised a clarity issue in the document in his Gen-ART review, and there has been discussion with the authors to correct the issue, and the correction has made it to a private version of the draft. I wish that version would be published so that we could deal with as clean document as possible, free of issues that have already been resolved. (If you had no other issues to resolve, I'd probably raise this as a discuss, because I'd want to avoid accidentally approving the document without the changes making it to the last version.)
For the record, here is Carlos Pignataro's feedback, part of OPS-DIR. It's been
worked on by Suresh
Minor comment:
This document specifies two configurable variables in Section 7. It clearly
specifies that these variables need to survive reboots, and also specifies what
it seems to be sensible defaults. However, it does not specify ranges or
considerations for these two values. I'd suggest adding some more details about
ranges.
The MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT default says it can be
retransmitted once. The MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY default is
the minimum value, which means that retransmission delay cannot be less than a
second. I expect this is OK, but would ask whether it makes sense to have the
variable in milliseconds and the default as 1,000. The answer can perfectly be
"no, does not make sense".
Also, a small nit in two IANA actions:
o Action-3: This specification defines a new registry for
Notification Reasons. Its called, "Update Notification Reasons
Registry". This registry should be created under "Mobile IPv6
Parameters" registry at (https://www.iana.org/assignments/
mobility-parameters/mobility-parameters.xhtml). The Notification
o Action-4: This specification defines a new registry for Status.
Its called, "Update Notification Acknowledgement Status Registry".
This registry should be created under "Mobile IPv6 Parameters"
registry at (https://www.iana.org/assignments/mobility-parameters/
mobility-parameters.xhtml). The status is a field in the Update
The URL should not point to the .xhtml pages, they should point to the
extension-less URLs.
A question:
If the Status Codes are partitioned as 0-127 as success and 128-255 as error,
why the error allocations start at 129?
0 - Success
129 - FAILED-TO-UPDATE-SESSION-PARAMETERS
130 - MISSING-VENDOR-SPECIFIC-OPTION
Should 128 be assigned?
Another protocol problem:
o If the local mobility anchor receives an Update Notification
Acknowledgement message with a failure Status and the value of
larger than 128, then it SHOULD log an error.
Why the status "larger" than 128 and not "larger than or equal to" 128? This
needs to be fixed (> 127 or >= 128)
Hope these are clear and useful!
Carlos.
Simple to resolve, and the authors are already aware of this: as raised in the IANA review, the IANA Considerations section uses the correct URI for the IANA registry in actions 1 and 2: http://www.iana.org/assignments/mobility-parameters ...but does not use the correct one for actions 3 and 4: https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml Please change the URIs in actions 3 and 4 to match the ones in actions 1 and 2 (it doesn't matter whether they use http: or https:, but please make all four the same).
draft-ietf-dhc-dhcpv6-solmaxrt-update
Thanks for the Discussion that resolved my concerns
This is going to be the easiest DISCUSS that Ralph's ever had to deal with: In the second OLD/NEW pair in Section 3, there's a typo in the NEW: it should be "INF_MAX_RT".
To the document shepherd: Thanks for the very good and useful shepherd writeup!
draft-ietf-ccamp-swcaps-update
- abstract: "updates any document that..." is an odd phrase. Aren't we sure?
The abstract bit about "updates any document" (and Barry suggestion of "all documents" doesn't change anything) is adding confusion where none is needed. On the one hand, it "Updates" in the sense of specifically updating particular documents such that the "Updated by" banner will appear on the top of the web page with that RFC. On the other hand, it is "updating" the protocol such that all uses of the fields noted in the document, whether in old documents or new ones, is changed. Combining these two uses of "updates" into the same sentence is bad form. Supposedly the reason we mention "Updates" in the Abstract is so that people notice that particular documents have been updated and can do the right thing. Saying that any (or all) documents that use this field are hereby updated isn't saying anything useful here.
Question: Since this document deprecates some values from IANAGmplsSwitchingTypeTC in http://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib, and since IANAGmplsSwitchingTypeTC was specified in RFC 4802, does this document update RFC 4802?
A fine document, this. Just two very minor editorial things, for which no email response is needed: In the abstract, I think you'll make Stephen (well, and me) happier if you change "any document that uses" to "all documents that use" (also in Section 1). :-) In the penultimate paragraph of Section 1, please change "and limit its use" to "and limiting its use" (parallel to "deprecating the use").
I was confused by 5. IANA Considerations IANA needs to deprecate and redefine the related registry. Should this be something like "deprecate some existing values in the related registry"? I'm not understanding why you deprecate a registry and redefine it in the same sentence ... Obviously this isn't blocking if IANA already thinks they know what to do, but if this needs to be changed to be clear to future readers, please consider changing it!
draft-ietf-spfbis-4408bis
I am balloting No Objection based on this work having no obvious impact on the Routing infrastructure, and the more detailed reviews and comment of the other ADs (who are more knowledgeable about this material).
- 4.1: given that recursion is allowed and that you have overall limits on how many DNS transactions can be done, is the "transactions-remaining" value also an implicit parameter of a check_host() call? This is only a comment since check_host is not a formal API but it'd seem to make it easier to get right if you make that implicit parameter explicit. Or do the limits apply to each call as you recurse? That wasn't entirely clear to me. - I didn't get appendix D at all - what's that do? - Appendix E.1, 2nd bullet: what's that? I think it needs a reference if you want it to be understood.
disclaimer: I've only reviewed the changes compared to the RFC 4088. Regarding "Appendix J. Change History": NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to publication) Personally, I like it when the new RFC has one section summarizing the changes compared to the initial RFC. This would be a mix of: Appendix J. Change History", but no needs to mention the editorial changes Appendix C. Changes in implementation requirements from RFC 4408 Regards, Benoit
I have two very small points that I think are unclear, and important enough that we have to get them right, both regarding the check_host() function. These should be really easy to clear up: -- Section 4.6 -- The check_host() function parses and interprets the SPF record to find a result for the current test. If there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. I think you're trying to say that syntax checking is done before any evaluation, but you aren't saying it. It matters, because implementations that make different choices in that regard won't get the same results from check_host() in all cases, as they're required to. Maybe this?: NEW The check_host() function parses and interprets the SPF record to find a result for the current test. The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation. END -- Section 5.5 -- I have to say that I'm not happy about the pseudocode here: what situation are we in when the pseudocode differs from the text? Which wins? I already see a case where they differ: the new pseudocode says "if more than 10 sending-domain_names are found, use at most 10", and there's nothing of the sort in the text. Does the working group really think there's enough value in having pseudocode there that it's worth saying the same thing twice and relying on them to be truly the same? And is it really worth it for mechanism that's not recommended for use? I strongly suggest making sure that the text says what you want it to, and removing the pseudocode.
I have a bunch of editorial comments that I'd like you to consider. They're
all non-blocking, but I think they'll improve the document, and I'll be happy
to chat about them if you like.
-- Section 2.5 --
Performing the authorization check other than using the MAIL FROM and
client address at the time of the MAIL command during the SMTP
transaction can cause problems, such as the following: (1) It might
be difficult to accurately extract the required information from
potentially deceptive headers; (2) legitimate email might fail
because the sender's policy had since changed.
I found that to be awkwardly worded and hard to understand. Please consider
this rewrite:
NEW
The authorization check is performed during the SMTP transaction
at the time of the MAIL command, and uses the MAIL FROM value and
the client IP address. Performing the check at later times or
with other input can cause problems such as the following:
* It might be difficult to accurately extract the required
information from potentially deceptive headers.
* Legitimate email might fail the authorization check because
the sender's policy has since changed.
END
-- Section 2.6 --
It would really read best if the subsections were worded to be parallel. As it
stands, subsections 1, 3, 4, 6, and 7 are worded as "result X means Y", and
subsections 2 and 5 are not. Can you re-word 2 and 5 to be parallel to the
others?
Also, why are "neutral" and "fail" called "explicit statements", but "pass",
for example, is not?
-- Section 3 --
Each SPF record is placed in the DNS tree at the owner name it
pertains to, not a subdomain under it, such as is done with SRV
records [RFC2782].
This looks like it's saying that SRV records are placed in subdomains, and I
don't think that's what you mean. Or is it? In any case, it's not clear (and
I know this text is from the original).
Maybe this (which also avoids the two different "it"s)?:
NEW
Each SPF record is placed in the DNS tree at the owner name it
pertains to, not in a subdomain under the owner name. This is
similar to how SRV records [RFC2782] are done.
END
The example in this section might be published via these lines in a
domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all"
What does "smtp-out" have to do with anything? It's not otherwise used, and it
seems to contradict what you say about subdomains in the previous paragraph.
-- Section 4 --
This description is not an API (Application Program Interface)
definition,
Two total nits on this:
1. You never use "API" other than here, so there's no need to define it, and
2. the usual expansion of "API" is application programMING interface.
I suggest, "This description is not an application programming interface
definition, [etc]."
-- Section 4.5 --
Starting with the set of records that were returned by the lookup,
discard records that do not begin with a version section of exactly
"v=spf1". Note that the version section is terminated either by an
SP character or the end of the record. A record with a version
section of "v=spf10" does not match and is discarded.
Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and.... Why
is it necessary or desirable to single out "v=spf10" here?
-- Section 4.6.4 --
SPF implementations MUST limit the total number of mechanisms and
modifiers ("terms") that cause any DNS query to 10 during SPF
evaluation. Specifically, the "include", "a", "mx", "ptr", and
"exists" mechanisms as well as the "redirect" modifier count against
this collective limit. The "all", "ip4", and "ip6" mechanisms do not
count against this limit. If this number is exceeded during a check,
a "permerror" MUST be returned. The "exp" modifier does not count
against this limit because the DNS lookup to fetch the explanation
string occurs after the SPF record evaluation has been completed.
When I read this, I start feeling like I'm being read the rules for Fizzbin
<http://en.wikipedia.org/wiki/Fizzbin#Fizzbin>. I would appreciate it if this
was re-worded so that there are two clear lists here: the terms that are
included in the "limit of 10", and the terms that are not (and are, presumably,
unlimited). Perhaps something like this:
NEW
Some mechanisms and modifiers (collectively, "terms") cause DNS
queries at the time of evaluation, and some do not. The following
terms cause DNS queries: <list goes here>. SPF implementations
MUST limit the total number of those terms to 10 during SPF
evaluation, to avoid unreasonable load on the DNS. If this limit
is exceeded, the implementation MUST return "permerror". The other
terms (<list goes here>) do not cause DNS queries at the time of
SPF evaluation, and their use is not subject to this limit.
END
If you think it's necessary (I don't):
NEW+
The other
terms (<list goes here>) do not cause DNS queries at the time of
SPF evaluation (the "exp" modifier causes a lookup at a later time),
and their use is not subject to this limit.
END
Then in the next two paragraphs, I think it would improve clarity to make a
change such as this:
OLD
When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. The evaluation of
each "MX" record MUST NOT result in querying more than 10 address
records,
NEW
When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. In addition to
that limit, the evaluation of each "MX" record MUST NOT result in
querying more than 10 address records,
END
(And similarly for the "ptr" paragraph.) I know you say this in a paragraph of
its own ("These limits are per mechanism..."), but it's helpful if people can
understand things as they read them, and then to emphasize it later... rather
than having them scratch their heads for a few paragraphs until they get to it.
-- Section 4.7 --
It is better to use either a "redirect" modifier or an "all"
mechanism to explicitly terminate processing. Although the latter
has a default (specifically "?all"), it aids debugging efforts if it
is explicitly provided.
I'm not sure what "the latter has a default" is trying to say. Do you mean
that "?all" is the default if you fall off the end, but you shouldn't rely on
that? Or do you mean that if you say "all", then "?all" is taken as the
default (I would think "all" would mean "+all")? Will you try re-wording this,
please?
-- Section 5 --
What does "(do not publish)" mean next to "ptr" in the sender mechanisms list?
Ah; I see; it matches the "do not use" in Section 5.5. You should probably
change this to "(do not use; see the note in Section 5.5)".
It would help, I think, to add to the end of the second paragraph, "The basic
mechanisms are as follows:", and to the end of the third paragraph, "The
designated sender mechanisms are as follows:". Otherwise, there are just these
disembodied lists, and the reader has to infer those introductions.
-- Section 5.1 --
Mechanisms after "all" will never be tested. Mechanisms listed after
"all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be
ignored when there is an "all" mechanism in the record.
This says that the redirect in the following record will be ignored:
v=spf1 redirect=_spf.example.com +all
That's sufficiently odd that it should be called out explicitly, perhaps by
adding "regardless of the relative ordering of the terms" to the last sentence
in the quote.
-- Section 5.2 --
3. The recursive evaluation returns either match, not match, or an
error. If it matches, then the appropriate result for the
include: mechanism is used (e.g. include or +include produces a
"pass" result and -include produces "fail").
4. If there is no match, the parent check_host() resumes processing
as per the table below, with the previous value of <domain>
restored.
A few things here:
1. Nit: "either" is for two things; for more than two, please remove the word
"either" (or replace it with "one of", but that seems awkward here).
2. "If it matches" is not parallel to "returns match", and similarly for "if
there is no match".
3. You don't say what happens if the recursive evaluation returns an error.
Unfortuately, "no match" and "not match" are sufficiently similar to be
confused.
I suggest this:
NEW
3. The recursive evaluation returns match, not match, or an
error.
4. If it returns match, then the appropriate result for the
include: mechanism is used (e.g., include or +include produces
a "pass" result and -include produces "fail").
5. If it returns not match or an error, the parent check_host()
resumes processing as per the table below, with the previous
value of <domain> restored.
END
The "include" mechanism is intended for crossing administrative
boundaries. For example, if example.com and example.org were managed
by the same entity, and if the permitted set of hosts for both
domains was "mx:example.com", it would be possible for example.org to
specify "include:example.com", but it would be preferable to specify
"redirect=example.com" or even "mx:example.com".
The text you eliminated here provided a buffer that's no longer there, making
the "For example," very odd. You talk about crossing admin boundaries and
immediately follow it with an example that does NOT. I think it would be
better to put a sentence in to restore that buffer -- perhaps, "When remaining
within one administrative authority, "include" is usually not the best choice."
-- Section 5.5 --
This mechanism SHOULD NOT be published. See below for discussion.
It's quite a bit below. I suggest "See the note at the end of this section for
more information." It might even be worth putting that note into a Section
5.5.1, so it's highlighted and more easily cited.
-- Section 6 --
Unrecognized modifiers MUST be ignored no matter where in a record,
or how often.
This is missing a couple of words:
NEW
Unrecognized modifiers MUST be ignored no matter where in a record
they appear, or how often.
END
For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record.
I don't usually recommend repeating things, but one thing from earlier probably
does bear repeating here:
NEW
For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record. Any "redirect" modifier MUST be ignored if there
is an "all" mechanism anywhere in the record.
END
I'm a No-Obj on the document itself, but I look forward to seeing the text mentioned in Pete's Discuss about how obsoleting Type 99 in favor of TXT records is not going to be a precedent for other protocols ...
I am voting no objection on the basis of a quick scan indicating that there are no implications for the routing system.
Should s11.3 also provide a mitigation via a reference for the spoofed DNS? Right now it just points to the DNS threats RFC. I guess the reader can infer they should use DNSSEC if they're worried but adding a pointer to the right RFC would be better. Something as simple as adding "... and see [RFCXYZ] for a countermeasure" or something like that.
draft-nandakumar-rtcweb-stun-uri
I have more or less the same comments on TURN. STUN has a username/password feature, right?. If a stuns URI is used in some protocol for some use-case, (e.g. webrtc) then shouldn't you REQUIRE that the username/password is also not sent in clear in that protocol?
- intro: are you saying that w3c goofed in soem draft of their webrtc spec? The phrase "non-uniform syntaxes proposed" could be read to mean that. - I'd have been interested in knowing if the stuns scheme is implemented in section 6. (And thanks for section 6 btw.)
3.1: Could you not have gotten some of this syntax from another document? 3.2: I suggest changing "MUST be" to "is" in both cases. The MUSTs are gratuitous. Then get rid of the reference to 2119. It's unnecessary.
I agree with Pete's comments about the ABNF, and share his dismay that these documents copy significant bits of standard ABNF productions from the URI document. I think that's a Bad Idea. Comment for the document shepherd: Thanks for a good, useful writeup!
My apologies for being completely confused. The text I was concerned about is not in this draft at all. I'm not quite sure why I was looking at RFC 5389 in the first place. I'm clearing - and I'm a yes - and then slinking off to file an errata against RFC 5389. Thanks for Benoit for letting me know that I REALLY need a vision test.
spencer: you should sit on it till we discuss it... ;)
draft-petithuguenin-behave-turn-uris
In 3.1, last paragraph: The <host>, <port> and <transport> components are passed without The ABNF says turn-host and turn-port, not host and port. This is not a major nit, but it would be good to be consistent here. This inconsistency is repeated further in the document.
I have more or less the same comments on STUN. TURN can inherit STUNs username/password feature, right?. If a turns URI is used in some protocol for some use-case, (e.g. webrtc) then shouldn't you REQUIRE that the username/password is also not sent in clear in that protocol?
- intro: are you saying that w3c goofed in soem draft of their webrtc spec? The phrase "non-uniform syntaxes proposed" could be read to mean that. - I'd have been interested in knowing if the turns scheme is implemented in section 6. (And thanks for section 6 btw.)
I agree with Pete's observation about restating ABNF in this document.
3.1: Could you not have gotten some of this syntax from another document? 3.2: I suggest changing "MUST be" to "is" in both cases. The MUSTs are gratuitous. Then get rid of the reference to 2119. It's unnecessary.
I agree with Pete's comments about the ABNF, and share his dismay that these documents copy significant bits of standard ABNF productions from the URI document. I think that's a Bad Idea. Comment for the document shepherd: Thanks for a good, useful writeup!
1. Introduction [RFC5928] defines a resolution mechanism to convert a secure flag, a host name or IP address, an eventually empty port, and an eventually empty transport to a list of IP address, port, and TURN transport tuples. I'm not understanding the use of "eventually empty" in this paragraph, and that's not a term I saw in [RFC5928]. Is it familiar to those skilled in the art of TURN?
draft-boucadair-rfc6153-update
I don't object to the use of an RFC to resolve this. Pete makes a good point that normally we would fix IANA bugs simply by telling IANA what needs to be fixed. However, in this case the bug was recorded in the RFC text and so is part of RFC 6153. So the fix is needed. It would not be appropriate to change this in an Erratum because it is not simply a typo. Moral - review the IANA action when they send you an email telling you to review their action. Double check in Auth48.
I'm ok with fixing this with or without an RFC.
As far as I can tell, the error is not in the spec itself (6153). The error was that nobody noticed that IANA allocated in the wrong registry for one of these codepoints. The IANA Considerations in 6153 is not crystal clear, but it's not obviously wrong. I don't see why we want to waste the RFC Editor's time on this. Why don't we just do a Management Item telling IANA to fix the registry according to the obvious intent of 6153? If something really needs to be changed in 6153, file an erratum. I don't see the point in publishing this thing.
I arrive to the exact same conclusion as Pete. Let's not create an RFC for this, when a management item on a IESG telechat could do the trick.
I fully agree with Pete's DISCUSS and the discussion that's followed. We should just fix the error in registration with a management item, and not publish a document for it. There's no real ambiguity in 6153, and once the registration is fixed this document has no value at all.
I'm a No Objection unless Ted hears from IANA that we don't need to publish an RFC before they can fix the error in the registry.
I fully support Pete's (and Barry's) point that this document is not needed.
On reflection, "no objection" is a closer fit to my position, i.e. I am OK with the RFC approach if that is the way that the sponsoring AD wishes to go, but I am equally OK with using another approach provided it fully conforms to IETF procedures.
All about fixing the mistake.
for the record... I don't mind if the draft is required to not. I am in favor of fixing this, hence my balloted position.
draft-ietf-dime-overload-reqs
I have no objection to the publication of this document. If I was to be picky I would say that the use of "route" (as in "route a request to a server") has the potential to cause some confusion. As far as I can see there isn't any network-wide routing going on here and what happens is that an Agent selects a Server to consume a request and dispatches the request to that Server. I suppose that is a form of routing, but unless the Agents can be arranged hierarchically towards the Server, and unless there is some sort of mesh connectivity between Agents, this is not really worthy of the term "routing". "Switch" or "Dispatch" or even "Forward" may be better terms. But this is a trivial point and you can completely ignore it if you like.
Good document, thanks. My only question was what the wg are going to do if they need to choose between two solutions, neither of which meets all the MUST conditions. You don't say here, and maybe that's for the best, but that is a long list of requirements.
I will attempt to finish my review before the telechat, but I wanted to send these out just in case I don't. Editorial silliness follows: Section 1.1: I quixotically suggest the following as a replacement for the first paragraph: The uppercased keywords "MUST", "MUST NOT", and "SHOULD" in this document are NOT used as defined in [RFC2119]. Instead, they are to be interpreted as follows: - "MUST" means that the item is an absolute requirement for a solution proposed for addressing the problem described in this document. - "MUST NOT" means that the item is an absolute prohibition for a solution proposed for addressing the problem described in this document. - "SHOULD" means that there may exist valid reasons in particular circumstances for the solution not to address the particular item, but the full implications must be understood and carefully weighed before choosing a different course. Section 1.4 and Section 2: Replace "the authors" with "this document", 3 occurrences total. This is a WG document; referring to "the authors" sounds weird.
I found this to be a good read, and I learned some things from it. On seeing Spencer's comments about "overload" vs "congestion", I looked for that, specifically. To me, it seems that you are using the two as you mean to, and you are making a clean distinction, while recognizing that they relate to each other. In particular, when you say that server overload can lead to congestion collapse, I think you mean exactly that, and are showing how the layers can interact. Of course, if I'm reading that wrong, then take this as support for Spencer's comments. :-) In Section 1.3, a tiny micronit, but this nit is a pet peeve of mine, so: Modern Diameter networks, comprised of application layer multi-node deployments of Diameter elements Correctly used, the whole comprises the parts (it's not "comprised of" them). Please change "comprised of" to "comprising". Hey, it shows that I really *read* it, yeh? In the first sentence of Section 7, I would say "with the goals of addressing the issues described in Section 5"; "improving the issues" sounds odd to this native-English ear. The requirements appear to be well thought out, and they fit together well. There's often a gap in that regard in requirements documents, so good work there.
I found this draft to be clear and well-written.
I have some comments that you might wish to consider, along with any other
comments you receive during the approval process.
This draft is distinguishing between overload and network congestion, but I'm
seeing the word "congestion" in places that seem to be talking about overload,
beginning in the Abstract (where the following text appears), and in the
Introduction:
When a Diameter server or agent becomes overloaded, it needs to be
able to gracefully reduce its load, typically by informing clients to
reduce sending traffic for some period of time. Otherwise, it must
continue to expend resources parsing and responding to Diameter
messages, possibly resulting in congestion collapse. The existing
^^^^^^^^^^
Diameter mechanisms are not sufficient for this purpose. This
document describes the limitations of the existing mechanisms.
Requirements for new overload management mechanisms are also
provided.
Given the distinction this draft is making between overload and network
congestion, is using "congestion" in this way helpful?
I'm not smart enough to suggest which term is appropriate in each case, but it
might be helpful to do a quick scan and make sure each usage of "congest" has
the intended meaning ...
In 1.2. Causes of Overload
External resources can include upstream Diameter nodes; for example,
a Diameter agent can become effectively overloaded if one or more
upstream nodes are overloaded. While overload is not the same thing
as network congestion, network congestion can reduce a Diameter nodes
ability to process and respond to requests, thus contributing to
overload.
Section 1.4. Overload vs. Network Congestion explains the difference, but
that's later in the document. Perhaps a forward reference here would be helpful?
In 7.2. Performance
REQ 11: The solution MUST be able to operate in networks of
different sizes.
it might be helpful to give some orders-of-magnitude clue on what this
requirement means at the high end (recognizing that all these networks are
growing).
In 7.3. Heterogeneous Support for Solution
REQ 17: In a mixed environment with nodes that support the solution
and that do not, the solution MUST NOT result in materially
less useful throughput as would have resulted if the
solution were not present. It SHOULD result in less severe
congestion in this environment.
it wasn't clear to me whether this requirement was talking about materially
less throughput during periods of overload, or at any time. REQ 21 is clearly
talking about periods of overload, but on REQ 17, I'm guessing.
Should "congestion" be "overload" in the last sentence?
Ignoring the part where we're talking about RFC 2119 language in a requirements
document, in 7.4. Granular Control
REQ 22: The solution MUST provide a way for a node to throttle the
amount of traffic it receives from a peer node. This
throttling SHOULD be graded so that it can be applied
gradually as offered load increases. Overload is not a
binary state; there may be degrees of overload.
I'm reading this as saying that a solution that cannot be applied gradually is
still acceptable (SHOULDs aren't MUSTs). Is that right?
In 7.6. Security
REQ 27: The solution MUST NOT provide new vulnerabilities to
malicious attack, or increase the severity of any existing
vulnerabilities. This includes vulnerabilities to DoS and
DDoS attacks as well as replay and man-in-the middle
attacks. Note that the Diameter base specification
^^^^
[RFC6733] lacks end to end security and this must be
considered. Note that this requirement was expressed at a
^^^^^^^^^^
high level so as to not preclude any particular solution.
Is is expected that the solution will address this in more
detail.
The point between "^"s is explained more clearly in the Security Considerations
section. I'd suggest either replacing this sentence with a pointer to Section 9
or (perhaps better) pulling the third paragraph from the Security
Considerations section into this requirement.
In 9.5. Compromised Hosts
A compromised host that supports the Diameter overload control
mechanism could be used for information gathering as well as for
sending malicious information to any Diameter node that would
normally accept information from it. While is is beyond the scope of
^^^^^ perhaps "it is"?
Just nits so take 'em or leave 'em: s1.2: r/it is dependent/it depends s1.5: r/other protocols/protocol other
draft-ietf-homenet-arch
I am glad that this work is being done by the IETF, and I think it is very important to the future of the Internet. However I have a number of comments some of which are at the level of Discusses. --- Section 3.1.1 It is desirable to reuse existing protocols where possible, but at the same time to avoid consciously precluding the introduction of new or emerging protocols. I am pretty sure this says "Use a protocol." If you are not precluding a new protocol when an existing one can be reused, then are you actually going to satisfy your desire? It is desirable to have cake. At the same time, we should not preclude eating it. However, I would also note that the homenet charter has something to say on this topic, and I don't believe this document should be at variance with what the charter says. I think the resolution of this issue is to remove this discussion from the document. It really has nothing to do with the architecture. --- Section 3.1.1 and 3.5 I am concerned by the drive towards "available" code and the requirement (you use "should") for open source implementations. Are we moving from being a standards body to a political one? While the existence of running code is a great way to demonstrate that a protocol is stable and works and has support (I did write 6972), I do not believe that having available code is part of the IETF philosophy. Probably a WG has the right to decide that this is a rule they wish to employ, although maybe it should be the subject of a more overt consensus call with careful discussion. Can the chairs assure me that this has been debated properly in the WG? [BTW, I am assuming that "available" is intended to imply open source or similar, and not "commercially available".] I think that the resolution of this issue is to remove this discussion from this document. it really has nothing to do with the architecture. --- BCP 38 is an important tool in the ISP's armoury. However, it is a real cause of loss of function and capability in the home network. RFC 6724 does nothing to ease this because, although it may give advice about selecting a source address, it doesn't handle the case where a device wishes to change its source address. A multi-homed home needs to be flexible and resilient. It also needs to support mobility within the home as well as from outside the home into the home. Such resilience and mobility need to be achieved without service disruption and at the network layer. SA-based routing is only a sticking plaster since, while it gets the packets to the right CER based on their SA, it doesn't help when the SA needs to be changed. The home should become part of the Internet, not a wart on the side, and IP packets should be dynamically routable without the need to ask the sender to change the source address. Otherwise, all the excitement about end-to-end communication is rather diluted. This debate could be quite wide and deep, and should surely involve the routing and operations communities. I think this issue could be resolved for this document by more clarity in the document about the required parameters of the homenet (e.g. is BCP 38 required at the ISP-CER boundary?), and less discussion about how solutions might be formed. The discussion of solutions will, of course, be needed - just not in this document. ---- And, following from the previous... I am disappointed by the discussion of routing requirements and solutions in this document. It would be better if the document was clearer about the solution model that needs to be applied (section 2.3) is pretty much clear enough, and if it left all resolution of the problem out of scope of this document. If routing changes are needed, perhaps these could be determined within the Routing Area. If operational changes are acceptable, perhaps the Ops Area could make a determination. In short, this document is too open to the passing opinions of how things might be done, and once that has been made into an RFC it will be really hard to do something different. This issue (of the document making suggested solutions) may be more general (for example, the end of 3.3.1, or the end of 3.4.3), I just feel it more around routing. I think this issue could be resolved by careful grooming of the text so that it describes the requirements (if they exist) such as a host must be able to choose between different addresses and BCP 38 must be assumed to be in use. But the text should not suggest how routing will achieve that (or even if it is a routing issue since tunnelling solves it without any modification to routing :-) --- When 3.3.3 says... Therefore protocols that avoid being 'chatty', do not require flooding, and enable isolation of traffic between subnets are preferable to those which burn scarce resources. ... it is being too simplistic. Different protocols have different plusses and minuses. What is best for one network type is not best for another. And then 3.5 goes on to say... As per prefix delegation, it is assumed that a single routing solution is in use in the homenet architecture. If there is an identified need to support multiple solutions, these must be interoperable. ...which is internally inconsistent (either there is one solution or not) and in conflict with the discussion of LLNs within the home. But I find some disconnect about whether an LLN is part of the homenet or not. 3.5 says: In general, LLN or other networks should be able to attach and participate the same way as the main homenet, or alternatively map/be gatewayed to the main homenet. Current home deployments use largely different mechanisms in sensor and basic Internet connectivity networks. IPv6 VM solutions may also add additional routing requirements. Noting that 3.7.6 is pretty sure that an LLN can be part of the homenet. Furthermore: what does "interoperable" mean?! --- 3.5 says some odd things It is desirable, but not absolutely required, that the routing protocol be able to give a complete view of the network, and that it be able to pass around more than just routing information. I should think it highly undesirable that the routing protocol be able to give a complete view of the network. That is neither something that is the job of a routing protocol, nor something that is good to do to low-capacity devices be they routers or hosts. We can also have a philosophical discussion if you like about whether a routing protocol should be employed to pass around non-routing information. Such a use, either by flooding or by more direct means, is likely to make the routing aspects of the routing protocol slower to converge and more expensive to run. This seems to be in conflict with 3.3.3's preference to avoid flooding and burning of scarce resources. This issue might be resolved by separating out the requirements/desires in terms of functions (we want to be able to get information between nodes in a p2p, p2mp, or broadcast way) from how it is achieved (through routing). --- 3.8.2 is an ambitious punt. While there is clearly no need for active configuration management, diagnostics will be required. It is very naive to assume that the self-configured network will never have a problem requiring someone (user or engineer) to inspect and rectify problems. I think 3.8.2 needs to be promoted beyond something that "this text is neutral towards".
I am curious to see the discussion of this document still rolling on
the homenet mailing list right up to IESG evaluation, but I trust the
responsible AD to make sure that the necessary changes are made to
reflect consensus, and that those changes will be brought back to the
IETF and/or the IESG as applicable.
---
Section 1.1
o FQDN: Fully Qualified Domain Name. A globally unique name space.
o LQDN: Locally Qualified Domain Name. A name space local to the
homenet.
A name is not a name space.
---
Section 2.4
The use of a 'master' router for the allocation of ULAs is fine until
that router is down. At that point it becomes impossible to add a device
(or renew a lease) in some subset of the home behind another router.
Not sure how big this issue is since if there was only one router it
would need to be up to get a ULA and to route packets. But it seems that
if you have multiple routers it is probably because your network is
large enough to have some regions that are largely self-sufficient.
Would you fall back to a second /48 or would you fail the allocation of
the ULA?
This seems to be particularly relevant considering 3.2.1 para 1
---
Section 3.1
The principles described in this text should be followed
when designing homenet solutions.
Not clear (to me) at whom this statement is targeted. At the IETF, the
standards community, the equipment manufactures, the home-owner?
---
Section 3.1.2.
Where possible, any requirement for changes to hosts and routers
should be minimised, though solutions which, for example,
incrementally improve capability with host or router changes may be
acceptable.
I think this doesn't say anything.
What are the real requirements?
- backward compatible
- not require ejection of equipment from the home?
- migration paths need to be written?
- acceptable if full function not available with old equipment?
---
Section 3.2.1 and 3.2.2.1
"Loop" may not be the best word to describe a topological construct
in which there are redundant paths. Loop tends to be used to describe
what happens when a packet is trapped. Such loops are not good :-)
---
Basic topologies and basic function
Notwithstanding network B(E) and network E(B) in figure 1, I don't find
enough discussion of hosts that are multi-homed to multiple separate
networks within the home.
Additionally, I don't find enough discussion of devices that are
mobile within the home (yes I see 3.5.2). Such devices may be multi-
homed to different networks in the home at the same time, and may
themselves be capable of routing. That makes some pretty bold statements
about topology.
You haven't discussed the case of a host with its own direct connection
to a service provider network. Such a host might likely not have router
function, but it might be capable of participating as a host on one of
the home networks as well as having a direct connection to the provider.
Now, if we combine some of these aspects we can consider:
- a device that enters and leaves the home, and moves around within the
home
- such a device that is capable of routing packets
---
Does the final paragraph of 3.2.2.3 really belong at the top of 3.2?
---
While there is some discussion of neighbouring homenets and also of
awareness of realms and borders, the document seems to miss the very
likely deployment of home networks that have connectivity to other
shared networks (maybe the network operators should close their ears).
This will result, at least, in a home having a /48 for ULAs within the
home, but also a collection of homes having a /48 (via a master router,
I guess) for traffic between the homes.
It is less likely that traffic from one home will be routed through
another homenet to reach the Internet (because that costs money) but I
can see it happening for a number of reasons, and this might be achieved
as a guest network or with wider address allocation. It is not clear to
me whether, at that point, they have just made one big homenet, or if
there is something more complex going on.
---
Does section 3.4.4 say anything?
It is part of 3.4 so I suppose it is meant to apply to specifically to
lifetimes/timers associated with addresses. Maybe it could be clearer
about what the issues are? Maybe "integrated" is not the right word?
---
Section 3.5
The routing environment should be self-configuring, as discussed
previously. An example of how OSPFv3 can be self-configuring in a
homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig].
Minimising convergence time should be a goal in any routed
environment, but as a guideline a maximum convergence time at most 30
seconds should be the target.
What is the value of the sentence about an example of how OSPF can be
made self-configuring? Why would you say this an not observe how IS-IS
is able to self-configure? Suggest deleting the solution-specific stuff.
---
There is no discussion in 3.5 of preferring links or path lengths. It is
sort of fundamental if you say routing is needed to say what paradigm
you hope will be employed. Should self-configuration include assigning
metrics according to node/link capabilities?
---
It is unclear to me whether 3.5.2 is a statement about routing (it is in
section 3.5) or about a more general attribute such that the section
should be placed elsewhere.
BTW, why say "(wireless)"? Surely the fact is true with wired subnets as
well, and particularly with a mixture.
---
Somewhere in 3.6 should probably refer back to 3.3.1
---
Section 3.7
The homenet requires devices to be able to determine and use unique
names by which they can be accessed on the network.
I suspect you mean that the names are not used by any other device, not
that the device must choose a single name.
See also 3.7.2
---
Section 3.7.1
"GUI interfaces"
Is that GUII? :-)
---
I think 3.7.3 (or 3.7.5?) glosses that each CER and each ISP may
generate a different globally unique name space such that devices in the
homenet have multiple fully qualified names. Not sure it has a
significant consequence.
---
Nothing in 3.8.1 about pushing ECN to the host?
This is a "DISCUSS-discuss", mainly a question I would like to have an answer to because service discovery is an important feature of homenets for applications. One challenge that we've run into, e.g., in GEOPRIV, ECRIT, and ALTO, is that it is sometimes necessary (or at least helpful) for the homenet DHCP server to pass along information that it gets from its upstream DHCP server. For example, DNS resolver addresses, or the options for LoST and HELD/ALTO [RFC5223][RFC5986] -- mostly service discovery sorts of things. Would this document be an appropriate place to discuss this sort of behavior? It would be good to get the above recommendation in writing somewhere, but it's not immediately clear what the recommendation would be for homenets -- do you pass on all options, some subset? I guess you could make recommendations in individual option definitions, but that seems laborious and error-prone.
I'll end up as a Yes for this, since I think homenet is important and potentially a real win. So sorry to pile on in the meantime. (1) general - its hard to have any confidence that all this zero-conf stuff can ever be secure. Can you tell me why I should be confident that security won't be constantly sacrificed at the altar of zeroconf in later work? (2) 3.3.4: this says that the default mode internally should be to share everything. I think that underestimates the problems that may occur when a user buys a nice new device which on first boot up and thereafter periodically scans the internal network and then sends all that nice marketing information back to the equipment vendor or application service provider. I'm not sure what this architecture can do about that but I do think it needs to be recognised, e.g. there's just as little reason to trust a new bit of h/w as a new Andoid or IOS app that a user has installed. (3) 3.4.5 - I'm not convinced that addressing is the only privacy issue here, and even if it were I don't understand why you cannot make some kind of recommendations about address privacy. For an example of another privacy issue if a globally unique name is chosen, couldn't that be very privacy unfriendly? Why are there no privacy requirements posed? (4) 3.7.4: Why is DNSSEC only "desirable"? I think it would have been better to say that if DNS is used then DNSSEC MUST NOT be broken by a homenet router or naming service. (5) Would it be reasonable to add a requirement that homenet devices MUST have good random number generation and that homenet specs MUST make it clear where good (P)RNGs are needed? There have been many failures in this respect in recent times so I think it'd be a fine addition to this document. But, if you tell me the WG thought about that and decided against then I'll make this a comment.
- "cloud-based" is used a couple of times. Seems like marketing language to me and better avoided. - 3.7.3 - if you do use a UniqueString "based on" something else, please make those unlinkable if possible (e.g. via application of a salt and hash function). Not sure if that's worth a note. The reason for that is to not add yet another way in which knowing one value, allows you to fingerprint someone based on the derived value. - 3.7.5 - why a "trust anchor"? Seems like too much or too little detail there.
A bunch of comments and a few questions follow. None of these rise to the level of requiring a DISCUSSion; t is, after all, just Informational. However, please take these into consideration, and I'd appreciate answers to the queries: 1.1: You define LLN here. But throughout the document, sometimes you use LLN to mean "home automation device network" (see 2.1 below), where the network might not necessarily be low-power or lossy, and sometimes you truly mean LLN. I suggest you look through the document and make sure you identify which are which. (For example, in 2.4, I don't think you're really talking about LLNs; you're talking about home automation networks.) There's no need for a definition for UPnP here. It is only cited once (in 3.6.1), and even there it's simply an example. (I'm not at all clear why this document, even in 3.6.1, has to advertise for UPnP, a non-IETF technology. I'd rather the example simply be removed from 3.6.1 and stick to PCP.) You refer to "guest" networks throughout the document, but don't define it here. I find the concept a bit odd myself; I know many corporations have a concept of a guest network, but it's rare for home networks to have such a thing. Can you explain why this is a useful construct in a home network? If it turns out to be, it's probably worth defining here. 2.1. Instead of "building control", please use the term "home automation" here. "Home automation" encompasses more than "building control" for homes, and "building control" includes things that are not part of home networking. By the way: It is a home automation (or building control) "network" or "subnet", not a home automation "extension", isn't it? The use of the word "extension" here and elsewhere (as in "corporate extension" or "extension network") is nothing I've heard used before and it is undefined in this document. In the context of a corporate network, don't you simply mean a "corporate virtual (private?) network"? Or are you really talking about the possibility of corporations providing a dedicated network in a home premise that might be interconnected with the user's ISP and home automation networks? 2.4: I think you're simply talking about home automation devices here, not LLNs. 2.5: (Tilting at a windmill) Zeroconf and simple naming are really only useful for ULAs. To avoid the need for manual configuration of GUAs, the ability to configure DDNS (i.e., giving the user the ability to type in a domain name and have it update the AAAA record with the auto-configured address) must be provided. (See also 3.7.3 below.) 3.1.2: This section seems a little thin, and frankly I can't figure out what it really means: Certainly few home CERs nowadays allow you to plug them into other home CERs from different providers and have anything useful happen, so saying that changes to routers needs to be "minimized" seems unrealistic. Sure, you won't be making wholesale changes to IPv6, but this section seems to be saying something different. What do you mean by "minimized"? 3.2.2.1: What's the interest of Link F? The Interior Router looks like it's linked to the CER through Network E already. Does having F separate mean anything in particular? You mention that B and E are "bridged". Is that any different than in figure 2, where the two CERs are bridged across a single network? 3.2.3: ...it is important not to introduce new IPv6 capabilities that would cause a failure if used alongside IPv4+NAT... Are there examples of what you're thinking of here? 3.3: The home network architecture should be naturally self-organising and self-configuring under different circumstances relating to the connectivity status to the Internet, number of devices, and physical topology. At the same time, it should be possible for advanced users to manually adjust (override) the current configuration. The architecture is not "self-configuring" or configurable. I think you mean that homenet (routing?) *devices* need to be self-configuring and that advanced uses be able to override their configurations. If not, please explain. 3.4.1: ...it is recommended that the receiving router instead enters an error state and issues appropriate warnings. That sure sounds like a recommendation designed to be ignored. You are either saying that manufacturers should make equipment that will fail to function in certain circumstances, or you're encouraging the creation of a "HOMENET certified" brand. Neither one seems like a good thing. The last 5 paragraphs of this section strike me as a bit odd: The norm for homenets (from the earlier discussion) seems to be that it must handle users plugging together of devices from different providers and removal of those devices from the network. It seems like handling *that* gracefully will make all issues of renumbering/prefix changes/new ISP/etc. simply degenerate cases of the bigger issue of dealing with networks being plugged together and unplugged randomly. 3.5.2: This seems a bit hand-wavy. Perhaps that's the best that can be done in this document. 3.7.3: This section is a bit thin on how global name spaces will work. If homenets are going to have global name spaces, the authoritative server you mention in the first paragraph is going to almost certainly be a DDNS server, and changes are going to be needed on the hosts to support this. We certainly *do* want printers and other services to keep their names up to date with different GUAs coming and going. I think a discussion of this would be useful.
DISCUSS The numerous comments from the IESG/directorates simply reflect the fact that you worked on an important piece of work. Thanks - zeroconf, which is mentioned throughout the document. It should be expanded in the "operations and management" section 3.8.2 Also, on that zeroconf topic, I agree with Brian Point 6 It is not practical to expect home users to configure their networks. Thus the assumption of this document is that the homenet is as far as possible self-organising and self-configuring, i.e. it should function without pro-active management by the residential user. - Regarding 3.8.2. Operations and Management, here is Jouni's feedback (part of OPS-DIR) JiK: I would like to see here also the other operational considerations spread out in the document like: subscribers config names for services, SSIDs, WPA2 keys, defining which nodes are "servers" etc.. Frankly compared to the high quality of the rest of the document, this section needs some considerable face lifting. Specifically, homenet envisioned by this architecture document can be a nightmare for the average Joe, if and when something breaks or malfunctions. I fully agree with Jouni. When I read .. It is not practical to expect home users to configure their networks. Thus the assumption of this document is that the homenet is as far as possible self-organising and self-configuring, i.e. it should function without pro-active management by the residential user. ... I expect a lot more from the "Operations and Management" section - The homenet should be self-organising and configuring as far as possible, and thus not be pro-actively managed by the home user. It seems to me that it conflicts with the notion of border, which will have to be configured , in all non trivial homenet deployments - Also, with the introduction of new 'dotless' top level domains, there is also potential for ambiguity between, for example, a local host called 'computer' and (if it is registered) a .computer gTLD. Thus qualified names should always be used, whether these are exposed to the user or not. http://www.icann.org/en/news/announcements/announcement-30aug13-en.htm
- I agree with other AD's concerns regarding the open source topic.
-
However, users may be interested in the status of their networks and
devices on the network, in which case simplified monitoring
mechanisms may be desirable.
Do you expect the management to be done over IPv6? This should be specified.
Clearly this is not the case in the industry today. Maybe add something in
section 2.6 IPv6-only operation, under the 3 bullets
o Ensure that the manageability information is available via IPv6
-
[RFC6204] defines basic requirements for customer edge routers
(CERs). This document has recently been updated with the definition
of requirements for specific transition tools on the CER in
[I-D.ietf-v6ops-6204bis], specifically DS-Lite [RFC6333] and 6rd
[RFC5969]. Such detailed specification of CER devices is considered
out of scope of this architecture document, and we assume that any
required update of the CER device specification as a result of
adopting this architecture will be handled as separate and specific
updates to these existing documents. Further, the scope of this text
is the internal homenet, and thus specific features on the WAN side
of the CER are out of scope for this text.
I don't understand if, in this architecture you expect all CERs to be compliant
with RFC 6204 or [I-D.ietf-v6ops-6204bis]? At least partly for the features on
the homenet side? You mentioned "Such detailed specification of CER devices is
considered out of scope of this architecture document", but I don't understand
what it means. Do you mean "irrelevant": "Such detailed specification of CER
devices is considered irrelevant for this architecture document"? But I guess
that the some features, which are required by 6204/6204bis are required. I read
the above paragraph multiple times, and could not get it.
-
For IPv6 homenets, the network models described in [RFC6204] and its
successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum,
be supported.
I searched networks in [I-D.ietf-v6ops-6204bis] . I guess that you mean:
3.1. Current IPv4 End-User Network Architecture . . . . . . . . 4
3.2. IPv6 End-User Network Architecture . . . . . . . . . . . . 5
Please call that Network Architecture
- Section 3.2.3 Dual-stack topologies
That said, it is desirable that IPv6
works better than IPv4 in as many scenarios as possible.
What does "works better" mean?
-
It seems that a big problem in home networks today is with WIFI, actually
multiple WIFIs and combination of (powerline, wifi). I'm surprised to see so
little about this aspects in the draft.
- I start to see home wifi routers that are forced by the service provider to
offer free hot spots for other customers of this ISP (for example:
http://www.voo.be/en/internet/wi-free/) Is this considered as a guest network
in your draft? Any specific requirements in that area. Or maybe this is outside
of the border of the homenet...
- Below is some more feedback from Jouni Korhonen (JiK), part of this OPS-DIR
review (I don't think I've seen a reply to this).
2.4. Unique Local Addresses (ULAs)
...
Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT
^^^^^^^^^^^^^^^^^^^^
JiK: Might be just me but what exactly is "host-based NAT"? I know what you
are after but is this term defined somewhere? I found at least two
interpretations for it.
3.2.2. Network topology models
...
For IPv6 homenets, the network models described in [RFC6204] and its
successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum,
be supported.
...
JiK: I would reword "successor RFC 6204-bis" to just "successor".
...
used for one or more providers, or multiple CERs. The presence of
multiple CERs adds additional complexity for multihoming
scenarios, and protocols like PCP that need to manage connection-
oriented state mappings.
...
JiK: Reading the document so far it is unclear to me how PCP (and without
expanding the acronym, nor giving a reference to it) relates to the number of
CERs.
3.2.2.2. B: Two ISPs, Two CERs, Shared subnet
...
example shows one shared subnet where IPv6 nodes would potentially be
multihomed and receive multiple IPv6 global addresses, one per ISP.
... ^^^^^^^^^^^^^^^^^^^^^^
JiK: I take prefix is meant here, not address.
3.2.4. Multihoming
...
routed to the proper egress to avoid BCP 38 filtering if exiting
...
JiK: I would reword "BCP 38 filtering" to "BCP 38 ingress filtering".
JiK: The discussion of multihoming seems to neglect the case where the CER
would actually speak some routing protocol to its upstream provider. I take
that is done purposely but I cannot find any text saying why it has been
neglected. I understand it does not fit the existing model of consumer
subscriptions but in Section 2.6. it is said that "IPv6-only networking will
be deployed first in 'greenfield' homenet scenarios", which would at least to
me imply some more freedom on choices how to deploy a service.
3.3.4. Homenet realms and borders
...
e.g. for some specific Grid or LLN-based network, and for these to be
... ^^^^
JiK: a reference or explanation about Grid is missing in the I-D.
3.4.1. Use of ISP-delegated IPv6 prefixes
...
prefixes longer than /64 (which would break SLAAC), use of NPTv6, or
...
JiK: SLAAC is never expanded.
Thus a homenet CER should request, for example via DHCP-PD, that it
^^^^^^^
JiK: First time occurrence.. not expanded nor reference given.
3.4.2. Stable internal IP addresses
...
filtering at the border(s) of the homenet, as mandated by RFC 6024
requirement S-2. ^^^^^^^^
...
JiK: Should be RFC 6204.
3.4.3. Internal prefix delegation
JiK: It seems that DHCP PD is used with and without '-' in other polaces
in the document . Choose one style.
3.5. Routing functionality
...
Multiple interface PHYs must be accounted for in the homenet routed
... ^^^^
Jik: PHY is used twice in the document. Never expanded or explained. Same
for MoCA..
3.5. Routing functionality
...
environment, but as a guideline a maximum convergence time at most 30
seconds should be the target.
...
JiK: For my curiosity.. how did we end up to this 30 secs convergence time
again?
networks. IPv6 VM solutions may also add additional routing
^^
JiK: Although explained in the terminology & abbreviations I would expand
VM on the first occurrence.
3.6.1. Addressability vs reachability
protocol such as UPnP or PCP [RFC6887]. In networks with multiple
^^^^
JiK: No reference given to UPnP. (well in terminology and abbreviations yes
but would add one here too). Maybe expand UPnP on the first occurrence also.
3.6.5. ULAs as a hint of connection origin
As noted in Section 3.6, if appropriate filtering is in place on the
CER(s), as mandated by RFC 6024 requirement S-2, a ULA source address
^^^^^^^^
JiK: Should be RFC 6204
3.7.1. Discovering services
...
Users will typically perform service discovery through GUI interfaces
...
an appropriate API for the discovery to be performed.
...
JiK: Expand GUI and API on the first occurrences.
3.7.3. Name spaces
...
Unique Locally Qualified Domain Name
...
JiK: give the abbreviation as well (for the similar style as in the
rest of the document is using).
...
Also, with the introduction of new 'dotless' top level domains, there
...
JiK: A reference to some document?
...
available by name via an Internet name space, and that a 'split view'
is preferred for certain devices.
...
JiK: A reference to a document that describes the 'split view' ?
3.7.4. The homenet name service
...
to support appropriate name service security methods, including
DNSSEC.
...
JiK: Add a reference to DNSSEC.
3.7.5. Independent operation
...
Having an independent local trust anchor is desirable, to support
secure exchanges should external connectivity be unavailable.
...
JiK: What is the local trust anchor? Reading so far it is not immediately
clear to me.
3.7.6. Considerations for LLNs
...
solutions for use by the Constrained Application Protocol (CoAP) in
...
JiK: Give a reference to CoAP?
3.7.7. DNS resolver discovery
...
local FQDN-derived zones should be included.
...
JiK: It is not clear to me what local FQDN-derived zones
are supposed to mean.
There's been a good discussion that's come out of the AppsDir review: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10404.html ...and I trust the authors to know what's appropriate to do as a result of that. In his GenART review: http://www.ietf.org/mail-archive/web/gen-art/current/msg08984.html ...Elwyn brings up a few minor points that are more than editorial, which I want to highlight: Section 2.4 begins with a discussion of ULAs "within the scope of a single site," and the fifth paragraph in Section 3.4.2 arguably belongs in 2.4, probably early in the section, rather than down in 3.4.2. The paragraph in Section 3.7.3 that discusses dotless domains probably needs a little work, at least to (1) be more fluffy about whether dotless domains are really upon us, and (2) say a word or two about what a dotless domain is, for readers who haven't been following the situation. It's probably true that a reference for WPA2 would be good, but I've checked around and can't find something suitable. There's some vague stuff on the WiFi Alliance pages: http://www.wi-fi.org/knowledge-center/glossary/wpa2%E2%84%A2 ...but otherwise, it's buried in the 802.11 specs. It's probably not worth spending a lot of time looking for a good reference, but if one turns up that's fine. And I'm sure the authors will address the editorial comments appropriately.
This is one big chunk of good work - thanks to the working group for putting it
together.
I have some comments, that I'd appreciate the authors looking at, along with
any other comments they consider.
About half of my comments involve name services, and telling a TSV AD to get a
clue about DNS might be a reasonable way to address those comments :-)
There are three places in the document where the word "cascaded" to describe
NATs. I'm pretty sure I know what you mean, but I didn't see a definition or
reference. Could one or both be provided?
In 3.3.4. Homenet realms and borders
It is expected that a realm would span at least an entire subnet, and
thus the borders lie at routers which receive delegated prefixes
within the homenet. It is also desirable, for a richer security
^^^^^^^^^^^^^^^^^^^^
model, that hosts are able to make communication decisions based on
^^^^^^^^^^^^^^
available realm and associated prefix information in the same way
that routers at realm borders can.
and in 3.6.4. Device capabilities
In terms of the devices, homenet hosts should implement their own
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
security policies in accordance to their computing capabilities.
They should have the means to request transparent communications to
be able to be initiated to them through security filters in the
homenet, either for all ports or for specific services. Users should
have simple methods to associate devices to services that they wish
to operate transparently through (CER) borders.
I wonder if the places where you have expectations about hosts could be
gathered into a single higher-level section ("considerations for hosts in
homenets", or something). In the current version of the draft, they're buried
in descriptions about homenets, and I wonder whether the people who need to see
them will actually see them. and you don't have very many of them. I wouldn't
expect much text to change (the expectations are clearly stated). But even if
that higher-level section just pointed to the sections where the material is
now ("hosts should do whatever, as described in Section 3.6.4"), I'd expect
more people who can influence host implementations to notice.
In 3.7.2. Assigning names to devices
Given the large number of devices that may be networked in the
future, devices should have a means to generate their own unique
names within a homenet, and to detect clashes should they arise, e.g.
where a second device of the same type/vendor as an existing device
with the same default name is deployed, or where two running network
elements with such devices are suddenly joined. It is expected that
^^^^^^^^^^^^^^^
a device should have a fixed name while within the scope of the
homenet.
I find myself wondering if anything else might need to take action where two
running network elements are suddenly joined - this is the only place in the
document where I saw the word "join", although I could easily have missed other
mentions using different wording.
In 3.7.3. Name spaces
Also, with the introduction of new 'dotless' top level domains, there
is also potential for ambiguity between, for example, a local host
called 'computer' and (if it is registered) a .computer gTLD. Thus
qualified names should always be used, whether these are exposed to
the user or not.
Is there a useful reference that could be provided for "dotless"? If there's
not a better one, perhaps
http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/?
Also in 3.7.3. Name spaces
It may be the case that not all devices in the homenet are made
available by name via an Internet name space, and that a 'split view'
is preferred for certain devices.
Is there a useful reference that could be provided for "split view" ("split
horizon")? I didn't see one during a quick poking-around, but if there's not,
perhaps a short definition would be helpful?
In 3.7.4. The homenet name service
To protect against attacks such as cache poisoning, it is desirable
to support appropriate name service security methods, including
DNSSEC.
Two things here. I'm curious about a useful reference for "cache poisoning",
but even more - you were allowing for the preference of "split view" in 3.7.3,
and in 3.7.4, you're saying support for DNSSEC is desirable. How well does that
work?
http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04#section-4.1 (expired) described several ways to do "split view DNSSEC", but each had disadvantages. Is there a requirement for work on DNS in support of what you think homenets will need?
And if you can come up with a reference that's not expired, that would be great
...
There are several items within this document that I think need discussing... 1. Even though this document is labeled an architecture, I am concerned when I see seemingly random requirements documented in various parts of the document. Are there a concrete set of requirements that can be documented in a standalone section (ideally with some justifications)? 2. Section 1.1 (and other parts of the draft) talks about borders & realms and their impact on forwarding unicast and multicast traffic. I am concerned that these two terms need to be scoped properly to bring them in line with the RFC 4007, specifically the definition of scopes & zones (section 5 of 4007). Of note, this draft says those types of boundaries need to be automagically created, yet 4007 specifically states that boundaries between zones must be configured by an administrator. 3. The introduction states that this draft is focused on the internals of the homenet "and thus specific features on the WAN side of the CER are out of scope". However, section 2.6 discusses transition scenarios that are already defined in RFC 6204 (6204bis). What is the purpose of having transition text in *this* draft? 5. Does the discussion of walled gardens in section 3.2.4 (next-to-last paragraph) need an explicit reference to section 4.2.1 of RFC 3002? The guidance provided in 3002 is very explicit and I would not want homenet to go against that consensus. 6. This is more of a general concern, but I am seeing a lot of zero-config magic being wished for in this document. While it is a noble goal, I don't see how it dovetails with other aspects such as home vs. guest subnets, device enrollments vs. unmodified hosts, and the need for policies in some scenarios. There are some aspects of a complex network that require some level of human intervention to get right. How would a router know that an attached subnet should be treated as the guest subnet? How does a router know that a particular upstream link is to a corporate VPN? 7. I think it is inappropriate to discuss IPv6 address allocation policies in section 3.4.1. The fourth paragraph in that section is on dangerous grounds trying to mandate what an ISP allocates to a customer. 8. Section 3.6.5 seems rather odd to me. Trusting a packet's source address to be correct and use it to affect security settings seems questionable. Especially if it is based on an assumption that border filters are in place and operational. What is the genesis/basis for this text?
1. I will channel some of my I* colleagues and say that section 2.2 should probably discuss privacy issues that may arise. 2. I think it would be useful if the discussion of ULAs in section 2.4 mentioned that the address selection policy in IPv6, by default, prefers using ULA source addresses when the destination is a ULA. 3. Section 2.5 uses the term "zeroconf" without any previous definition. 4. Section 3.4.4 makes no sense to me. Other sections have a copious amount of detail and this one just says "timers have different lifetimes, figure it out".
"The homenet unicast routing protocol should be based on a previously deployed protocol that has been shown to be reliable, robust, to allow lightweight implementations, and of which open source implementations are available. " To require an open standard is entirely within the ethos of the IETF and I would support it, but I am concerned that requiring open source is more of a political statement for which there is no IETF mandate. I am concerned about this statement and I would like to discuss it with the authors: "A routing protocol that can make routing decisions based on source and destination addresses is thus desirable, to avoid upstream ISP BCP38 ingress filtering problems." I agree with and support the need to steer the packet to the correct egress router, but for Figure 2 surely a default g/w mechanism would work, and for figure 3 a simple change to the forwarding code would work. For more complex networks (none of which you show) surely something less than a full routing protocol would suffice? Indeed I am wondering whether all that is needed is a simple change to the forwarder. My concern is that we may needlessly trigger the development of a whole new routing protocol unless this requirement is specified with greater clarity.
Having read through the text again and reviewed the comments from other members of the IESG, I am of the view that the long term interests of the Internet would be best served by the removal of the routing text from this draft and the definition of the routing components in a working group that will get better scrutiny by routing specialists, i.e. adopting of the routing protocol requirements and definition by a WG within the router area.
Thanks for slogging through the process to get here. Hopefully you won't find these too annoying and I too think this is a valuable effort. Can't wait to tweak my security settings at home to irk my wife when this all arrives in the wild :) 0) (sorry a hobby horse but I gotta ask) How come there's no recommendation on whether or not DHCPv6 authentication should be used in the home or between the home and the ISP? 1) This is something that I suspect will get cleared up on the call: How much of this is being driven by the belief that homenets will be multi-homed? I guess I'm asking whether we're designing a bunch of stuff for the power user or whether most folks can get along just fine without multiple subnets, multi-homing, etc.
I support my fellow AD's discuss points. 0) abstract: Is it that network is getting geographically larger or that it's getting more populated or both? This text describes evolving networking technology within increasingly large residential home networks. maybe in the abstract: This text describes evolving networking technology within residential home networks that are increasing in size and density of IP-enabled devices (e.g., toasters). Always want to give a nod to Jari's toaster. Did it ever get a name? 1) I support Brian's 1st point about this also being a requirements draft as well as an architecture. Maybe that can't be helped, but I did think that some uses of the term requirement could just be totally dropped. Further, s3 says: The aim of this text is to outline how to construct advanced IPv6- based home networks involving multiple routers and subnets using standard IPv6 addressing and protocols [RFC2460] [RFC4291]. But then you're not going to do that you're going to add requirements for new protocols - which fine in my mind I'd just like the words to match up. 2) s1: r/that we would like to avoid/that should be avoided 3) s1: Might also be good to say why you don't want these: Such networks also typically employ solutions that we would like to avoid, such as private [RFC1918] addressing with (cascaded) network address translation (NAT)[RFC3022], or they may require expert assistance to set up. e.g., private addresses leak and then we ended up with AS112 ... etc. 4) s1.1: Would have added subnet in the list. Add informative reference for WPA2? 5) s2.1: should this be "to Ethernet" as opposed to "from Ethernet": Constraining the flow of certain traffic from Ethernet links to much lower capacity links thus becomes an important topic. The idea being you'd want as much to run on ether as you could right to help with the poor constrained device bandwidth? 6) This might just be a wording thing so it might be easy to clear up: s2.1 contains the following Likewise, there may be a need to separate building control or corporate extensions from the main Internet access network, or different subnets may in general be associated with parts of the homenet that have different routing and security policies. The corp extensions part kind of threw me for a loop. Are those the ISP's extensions, a home user's employer's extension when they're using a VPN, some sensor gone rogue in my house ... ? 6) s2.2: I think it does a pretty good job of distinguishing between reachability and addressability. A back pointer to s3.6 would definitely help here because I originally thought out wait that's it but was later appeased somewhat. I do think the last sentence in the first paragraph should be changed to include the words "and possibly malicious traffic" because it's not just like you're being bothered by the traffic it's some script kiddie (or worse) trying to hack in to your new smarttv to watch you watch tv. 7) s3: Does this sentence line up with the new requirements being introduced: The aim of this text is to outline how to construct advanced IPv6- based home networks involving multiple routers and subnets using standard IPv6 addressing and protocols [RFC2460] [RFC4291]. Shouldn't it say and point out where we think tweaks need to added. 8) s3.6: I'd like to hear some more on the call about Joel's idea, but the mitigation discussed most is filter - firewalls are kind of glossed over. Should there be some kind of recommendation about having a default firewall turned on? 9) s2.2/s.6: Firewalls vs Filtering. I kind of tripped over this because it seems like in s3.6 a firewall is just a big filter, but in s2.2 it mentioned applications so I thought maybe an application layer firewall, but there's also stateful firewalls. I assume you're not discussing application layer firewalls at all in this draft, but it might be good to explain the difference between plain filtering and stateful filtering in the terminology section.
The secdir review revists the question of default allow/deny policy and the documents non-position, position, on that. I am actually aware of the discussion in the working group and the nuance of the respective arguments having been a contributor to the discussion. I personally would rather see: The document declare a lack of consensus with respect to which is more appropriate. Describe the policy as situationaly appropriate (e.g. there are consensus cases where one model is appropriate or the other model is appropriate). this is not strongly held but it's worth discussing.
draft-ivov-grouptextchat-purpose
I would need someone more clueful than I to pronounce on this, but don't we have better things to include in an example than: <uri>http://sharepoint/salesgroup/</uri>
Did the *content* of this document get any review at all in the IETF? I know that DISPATCH looked at it, but that's a "where should this be handled" review rather than a content review. I see no discussion of it on the IETF list. Is this actually an IETF consensus document? (The general subject is a current topic of conversation between the IAB and IESG, so shedding some light on this case might prove useful. It should not stop publication of this document.)
I did have one question, which you might consider along with any other comments you receive during the evaluation process. I'm reading (quickly) this specification plus RFC 4575 taken together as saying that a conference description with two grouptextchat purposes would be valid, so that a conference can advertise both an XMPP URI and an SIP URI with grouptextchat purpose, for instance. If that's valid, is there any expectation that if I type something into one of these group chats, it would show up for people in another chat advertised in the same conference description? You could also tell me that everyone uses XMPP for group chats, so this isn't an interesting question, of course :-)
I notice the following fragment in a couple of places: <subject>Agenda: This sprint's goals</subject> Given that Sprint is a service provider in this sector, it would be better to pick a neutral name.
s2: On the display the chatroom mitigation if there's no network security: a) exactly what gets displayed: host or host:port is? I guess I'm asking from where is the data to be displayed pulled? b) Is there anything the client should be checking for the user because leaving it up to the user is likely not a good idea - i.e., can the client do some normal matching to see if the fields in the request to join the conference match the ones in the response that said yeah you can join?
s2: I think here you meant to say 4575 recommends this things and so do we: OLD: Similar attacks are already possible with the "participation" <conference-uris> defined in [RFC4575] which is why it recommends "a strong means for authentication and conference information protection" as well as "comprehensive authorization rules". NEW: Similar attacks are already possible with the "participation" <conference-uris> defined in [RFC4575] which is why it and this document recommend "a strong means for authentication and conference information protection" as well as "comprehensive authorization rules".
conflict-review-joseph-pkix-p6rsshextension
I believe Pete's observation here is correct.
No objection modulo what Pete says
There is no secsh WG anymore, so the writeup can't be correct as it is. This sounds like it should get a straight "no conflict" message.
I agree that a straight "no conflict" is more appropriate.
conflict-review-morand-http-digest-2g-aka
I think Spencer has captured the correct resolution of Barry's questions, In addition to Spencer's proposal, I would suggest that we register the IESG's wish to be able to come back and add an IESG note at the time of publication. Best to put that request in now so that we don't fumble it when the document does get published.
- The httpbis wg are creating an IANA registry for HTTP auth schemes, e.g. see [1]. I think it'd be good for this document to be held until that registry is created and for it to add this scheme to that registry to save having to add it later. Note that [1] is apparently about to enter IETF LC, but the httpbis work hasn't been that quick (as its complicated) so that might impose some delay. I don't recall if the httpbis wg were asked about this recently. Note that I'm ok if this goes ahead and the schemes are registered later, but just want to check that the httpbis wg are ok with that, and I'd be happy to clear if someone says they will check or have checked. (Another approach might be to publish this and add this scheme to appendix A of [1].) [1] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-08
- The response message should maybe note that the httpbis WG is also relevant. - There were a couple of comments made when this was brought to the attention of the httpauth wg. It'd be a fine thing if the changes indicated were made. (The authors indicated that they're ok with some of 'em at least.) The thread for that is at [2] [2] http://www.ietf.org/mail-archive/web/http-auth/current/msg01544.html
This document has been submitted for publication as an Informational RFC through the RFC Editor. The IESG is doing a so called conflict resolution check on it, to make sure it does not conflict with ongoing IETF work, does not break IANA rules, and is otherwise not harmful for the Internet in some manner. But this is not a technical review. We generally let these types of documents through unless there is an issue. And having worked in this space before, I really like the work and welcome the new document. Thank you for working on it! However, I have a question mark and I think we should discuss an issue. The document is similar to previous specifications on EAP SIM/AKA (RFCs 4186-4187 and 5448) and HTTP Digest AKA (RFC 3310). It is also reminiscent of some work on the generic authentication framework at 3GPP (GBA). In those previous works, there was quite a bit of review of the crypto and protocol details before the specifications were published. What review has happened in this case? My e-mail search does not reveal much discussion, but my records do not go back very far. I do not remember seeing this earlier, but maybe my brain is in overload mode again. But I also asked the chairman of the 3GPP security group, SA3, Bengt Sahlin (Cced) if he had seen this, and he had not. So, what discussion & review has happened with the draft? Can you clarify? Note that while the IESG conflict review is not a technical review, I'm hesitant on what to do here, because at the same time we also want to be careful to not step on the toes of other organisations (3GPP in this case). I'd like publication of work affecting both organisations to be in sync. If such review has happened and enough people are aware of this, we should clearly move ahead. If not, perhaps this is something that SA3 (for instance) could review, just to make sure we are not creating some unexpected problems. Part of the reason that I am asking for this review is that when I looked (very quickly) at the document, it seemed to follow 3310 quite closely; the crypto is similar. However, in past work EAP SIM was somewhat different from EAP AKA in e.g., using n*Kc as opposed to Kc to use more key material. Similarly, GBA 2g version is different from 3g version. I have not done a deep enough review to understand whether similar differences exist/do not exist in this case or if they would be needed to begin with. But it was enough to cause me to ask the rest of you. Lionel, Bengt, can you say something about what kind of review has been going on wrt this document?
I wait with interest for the answer to Barry's DISCUSS.
I'm not the expert on this matter. I'll go with the consensus of the knowledgeable ADs on this matter. Regards, Benoit
I have a general issue with respect to this document that needs to be discussed: This is very clearly directly connected with the httpauth work. They are chartered to look at a set of "better than plain/digest" proposals, and pick one or more to publish as Experimental. And so: in what sense does this NOT conflict with work in httpauth? The answer on the surface is that the WG doesn't want to consider this one. OK... but that brings up a more general question: Can *all* of the proposals that they don't want to consider simply be published through the Independent Stream? How about the ones that they do consider, and then decide not to proceed with? They could all be published as Experimental through the ISE. In that case, what's the difference between the ones published as Experimental by the WG, and the ones published as Experimental by the ISE? And, so, what's the point of that part of httpauth's work at all, then?
With Stephen's assurance that publication now will not disrupt work in the HTTPAUTH working group, I'm OK with the proposed conflict review response. I'm still interested in Barry's question, and I'm still interested in Adrian's suggestion that we consider an IESG Note to be included when the document is published. Thank you for addressing my Discuss.
... but support the idea of an IESG note
conflict-review-alimi-decade
- The decade wg was closed. If there were a way to nicely explain that here, that could be good, in case some reader gets confused when they read this and see that there once was a decade wg.
I double-checked with François Le Faucheur. For the record, here is his message:
Hello Benoit,
We investigated the relationship between CDNI and the work of the former DECADE
WG a while back. The conclusions are captured in Appendix B.2.2 of RFC6707
(CDNI Problem Statement). From a quick scan of draft-alimi-decade-04, it seems
that the fundamentals of teh architecture/solutions have not changed so the
earlier conclusions would still apply.
So I would say this would be a 1. (in your 5 options below) , or possibly a 2.
HTH
Francois
PS: If you are aware of significant/sensitive changes (that I may have missed
from scanning the document) between draft-alimi-decade-04 and the earlier draft
work of the DECADE WG, let me know and I can have a specific look on such
changes.
PPS: below is teh relevant text from RFC6707
B.2.2. DECADE WG
The DECADE working group [DECADE-Charter] is addressing the problem
of reducing traffic on the last-mile uplink, as well as backbone and
transit links caused by peer-to-peer (P2P) streaming and file-sharing
applications. It addresses the problem by enabling an application
endpoint to make content available from an in-network storage service
and by enabling other application endpoints to retrieve the content
from there.
Exchanging data through the in-network storage service in this
manner, instead of through direct communication, provides significant
gain where:
o The network capacity/bandwidth from the in-network storage service
to the application endpoint significantly exceeds the capacity/
bandwidth from application endpoint to application endpoint (e.g.,
because of an end-user uplink bottleneck); and
o The content is to be accessed by multiple instances of application
endpoints (e.g., as is typically the case for P2P applications).
While, as is the case for any other data distribution application,
the DECADE architecture and mechanisms could potentially be used for
exchange of CDNI control plane information via an in-network storage
service (as opposed to directly between the entities terminating the
CDNI interfaces in the neighbor CDNs), we observe that:
o CDNI would operate as a "Content Distribution Application" from
the DECADE viewpoint (i.e., would operate on top of DECADE).
o There do not seem to be obvious benefits in integrating the DECADE
control plane responsible for signaling information relating to
control of the in-network storage service itself, and the CDNI
control plane responsible for application-specific CDNI
interactions (such as exchange of CDNI Metadata, CDNI request
redirection, and transfer of CDNI logging information).
o There would typically be limited benefits in making use of a
DECADE in-network storage service because the CDNI interfaces are
expected to be terminated by a very small number of CDNI clients
(if not one) in each CDN, and the CDNI clients are expected to
benefit from high bandwidth/capacity when communicating directly
to each other (at least as high as if they were communicating via
an in-network storage server).
The DECADE in-network storage architecture and mechanisms may
theoretically be used for the acquisition of the content objects
themselves between interconnected CDNs. It is not expected that this
would have obvious benefits in typical situations where a content
object is acquired only once from an Upstream CDN to a Downstream CDN
(and then distributed as needed inside the Downstream CDN). But it
might have benefits in some particular situations. Since the
acquisition protocol between CDNs is outside the scope of the CDNI
work, this question is left for further study.
The DECADE in-network storage architecture and mechanisms may
potentially also be used within a given CDN for the distribution of
the content objects themselves among Surrogates of that CDN. Since
the CDNI work does not concern itself with operation within a CDN,
this question is left for further study.
Therefore, the work of DECADE may be complementary to, but does not
overlap with, the CDNI work described in this document.
On 24 Sep 2013, at 12:47, Benoit Claise <bclaise@cisco.com>
wrote:
> Hi François,
>
> As explained in my voice mail, can you please review
http://tools.ietf.org/html/draft-alimi-decade-04, and let me know if there is
any conflict with your CDNI work at the IETF. This draft will be discussed
during the Thursday IESG telechat. > By conflict, I mean
http://tools.ietf.org/html/rfc5742 section 3. The IESG has to select one of the
5 standard actions: > > 1. The IESG has concluded that there is no conflict
between this > document and IETF work. > > 2. The IESG has concluded
that this work is related to IETF work done > in WG <X>, but this
relationship does not prevent publishing. > > 3. The IESG has concluded that
publication could potentially disrupt > the IETF work done in WG <X> and
recommends not publishing the > document at this time. > > 4. The IESG
has concluded that this document violates IETF procedures > for <Y> and
should therefore not be published without IETF review > and IESG approval.
> > 5. The IESG has concluded that this document extends an IETF protocol >
in a way that requires IETF review and should therefore not be >
published without IETF review and IESG approval. > > Regards, Benoit >