IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-10-10. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Barry, Benoit, Spencer
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
+-------------------------+----------+-------+---------+
| Parameter | Tunable? | Cisco | Juniper |
+-------------------------+----------+-------+---------+
| Withdrawal | No | 1000 | 1000 |
| Re-Advertisement | No | 0 | 1000 |
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
___|_______DNS-based____________|___
| load splitting |
| (if used) occurs |
| here
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
Telechat:
Telechat:
Telechat:
3.4.2 Returning Items
Telechat:
1346 EDT no break (despite objection from single scribe)
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat::
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
7. Agenda Working Group News
1407 EDT Adjourned
(at 2013-10-10 07:35:16 PDT)
draft-ietf-storm-iscsi-sam
- 4.2: what if something goes wrong in T10 and those changes don't happen?
I find the following text really confusing: This document is not a complete revision of [RFC3720]. Instead, this document is intended as a companion document to [draft-ietf-storm-iscsi- cons-xx]; this document may also be used as a companion document to the combination of [RFC3720] and [RFC5048], although both of those RFCs have been obsolete by [draft-ietf-storm-iscsi-cons- xx]. .. and will be mostly redundant the day draft-ietf-storm-iscsi-cons is published. So given that this draft will wait in the RFC editor's queue until draft-ietf-storm-iscsi-cons is an RFC, may I suggest that just say that it is a companion to draft-ietf-storm-iscsi-cons, and put the text about [RFC3720] and [RFC5048] in the to be deleted editor's note? ===========
The abstract and the introduction should say what is actually in the document and why this is a companion document (e.g. sections 4-7 are fine. the intro is just ambigious.
draft-ietf-sipcore-rfc4244bis
Section 5, after the ABNF:
The ABNF definitions for "generic-param" and "name-addr" are from
[RFC3261].
I think addr-spec is also from RFC 3261?
In section 9.3:
Step 2: Add Reason header field
The SIP entity adds one or more Reason header fields to the hi-
targeted-to-uri in the (newly) cached hi-entry reflecting the SIP
response code in the non-100 response, per the procedures of
Section 10.2.
But in 10.2:
A Reason header field is added to the "headers" component in an hi-
targeted-to-uri when the hi-entry is added to the cache based upon
the receipt of a non-100 or non-2xx SIP response, as described in
Section 9.3.
Section 9.3 seems to miss excluding non-200 responses, unless I misunderstood
it. I think that 9.3 and 10.2 should be mutually consistent.
Otherwise, looks good to my SIP-innocent eyes. :)
Added a 4-th discuss point - ignore the previous email (sorry;-) (1) section 13, last para: I don't understand the REQUIRED there - is it saying that if a UAC adds a Privacy header then a "Privacy Service" has to magically appear? What happens if one doesn't exist? Is the UAC's privacy request then ignored? (2) where is "how to anonymize" defined? Would using stephen.farrell@anonymous.invalid be ok for me? If so that's not very anonymous is it? (3) I don't get why its ok to change from mandating use of TLS to "strongly RECOMMENDED" on the basis that the implementations don't support TLS. If TLS was and is needed, then surely mandating it is still correct and was not "gratuituous." If TLS is not needed then why is it now "strongly RECOMMENDED"? (4) Having now looked at the callflows draft, section 3.2 I don't see what privacy is being provided - in those flows nothing is really anonymised at all if one looks at the messages - what am I missing?
- The diff from 4244 wasn't that useful for me so please feel free to tell me something I've commented on hasn't really changed when that's the case.
Section 3, list item 2: The terminology is not what email folks would use. Instead, "Email relaying whereby the recipient obtains a detailed "trace of the path" of the message from originator to receiver, including the time of each relay." You could get more complicated and talk about resent events, but I think the above is fine for just an example. Section 5: The ABNF definitions for "generic-param" and "name-addr" are from [RFC3261]. Also, HCOLON, COMMA, SEMI, EQUAL, and addr-spec. Section 6: That "MAY" is not a 2119 MAY. I suggest lowercasing, or changing it to "can". 6.1, 6.2, 7, 8, 9.1, 9.2: I find the forward references using "MUST follow the procedures defined in..." a bit weird. Seems like it would have been easier to follow if all of the MUSTs were collected together in the target section. No big deal; just editorial.
Thanks for these 2 sections, which I like very much for a bis document:
16. Changes from RFC 4244 . . . . . . . . . . . . . . . . . . . . 29
16.1. Backwards compatibility . . . . . . . . . . . . . . . . . 30
Thanks to my fellow ADs for helping me clear my Discuss Discuss. I had one minor comment, which is a comment because I think I understand the text. Please let me know if I don't understand the text. In 6. User Agent Handling of the History-Info Header Field A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP intermediary as an alternative to following the behavior of a user agent server (UAS) per Section 6.2 and a UAC per Section 6.1. In behaving as an intermediary, a B2BUA carries forward hi-entries received in requests at the UAS to requests being forwarded by the UAC, as well as carrying forward hi-entries in responses received at the UAC to the responses forwarded by the UAS, subject to privacy considerations per Section 10.1. I'm not seeing that the section title matches the contents - something like "Back-to-back User Agent Handling of the History-Info Header Field" would be closer. Given the current title, I'd expect this section to describe what's common between 6.1 and 6.2, but it's only saying that B2BUAs have the option of doing what's in 6.1 and 6.2. Also in this text, it would be helpful to have a reference for "behavior of a SIP intermediary", if there's an obvious candidate.
I understand that this header is just like the others except for one thing: isn't it a one stop shop for those that want to know where the message's history? Does this make it a slightly more valuable target?
draft-ietf-ecrit-psap-callback
I support Barry's Discuss wrt FQDN. note that town.com is an ongoing business and should not be abused in this way. There is no reasonable reason not to conform to RFC 2606
(1) This seems to scream out "I want stir!" and that confuses me. If this is meant as an interim solution until stir is available, then that should be stated. And that raises another question - if stir were available then I don't think you'd even need this indication, but maybe some people would want both and then would ask for the stir signture to cover this as well, which could complicate (and maybe damage) stir. So having this as an interim solution might have a downside. And if this is not an interim solution, then I don't get why it doesn't e.g. have its own (realistically usable, i.e. not 4744) signature scheme. All that leaves me wondering: why not just wait for stir and use that? (2) - The reference to 4744 is misleading since nobody does that. Does anyone do 3325? In any case, the text there should reflect reality.
- I think there's a missing security consideration. The Irish emergency calling service can accept a (voice) call where the caller says "I need to hang up now, please don't call back but send me an SMS - the burgler is in the other room and will hear." I think you could mention that that's a potential danger that would need to be mitigated via implementations and/or operational practices. - Question for the AD/shepherd: The IPR declaration was posted before IETF LC but (I think) after the draft left the wg. I assume that the wg are ok with that, since its more or less the same IPR declaration as was made on 6443. Is that correct? I note that the shepherd write-up says there's no IPR of which the shepherd was aware at that time, hence the question.
I share Barry's concerns regarding security. It sounds like that DISCUSSion is moving along. I implore you to take Barry's advice regarding the Introduction. Please shorten it.
While these are non blocking comments regarding the document publication, let's
have a discussion about those. Note: I already discussed those two points with
Hannes over the phone.
1.
In the case where the SIP
Priority header value, 'psap-callback', is supported by the SIP UA,
it would override user interface configurations, such as vibrate-only
mode, to alert the caller of the incoming call.
Is it a good idea?
I'm witnessing a crime: I call or page the police, put the silent mode, hide in
a corner while waiting for the police, and now the police calls me back: no
more silent mode. I'm now dead.
2.
In the SIP proxy case, what prevents the VoIP provider to use this mechanism
for support calls.
It's not emergency, but it will save the VoIP provider time and money. So they
might tempted to use it.
Richard's new sentence:
The indicator described in Section 4 can be inserted by any SIP entity,
including attackers. So it is critical that the indicator only lead to
preferential call treatment in cases where the recipient has some trust in
the caller, as described in the next section.
I've have some trust in my VoIP provider, but it doesn't mean that he should
get priority to call me back, by-passing all my policies.
What prevents some state/government to say: "I'm important. I want this
priority feature when I call one of my citizen".
I believe that you need to impose, that, even in the proxy case, this mechanism
only works in case of callback.
Editorial:
- Not sure what LoST is:
In
this scenario we consider a SIP UA that uses LoST to learn the next
hop destination closer to the PSAP.
I have two bits that I'd like to discuss, if you please: NOTE: All FQDNs used in the subsections below are used for illustrative purposes. They are examples to demonstrate the limitations of the technical solution outlined in RFC 6881. Notwithstanding that, I find it hard to understand how it would harm this document if you would use the reserved domain names from RFC 2606. That document *is* a BCP, and I'd like to discuss why you don't think you can follow it. It would be very easy to simply change all the TLDs in this document to "example" (except for the ones that use "example.com") and be in compliance with 2606. Please tell me why that won't work, or would harm the document. I find the Security Considerations unrealistic. Here: you have defined a header field value that anyone can use to try to get expedited handling. In Section 5.2 you say that you must treat failures to accept this value as though they were normal calls. And so: why shouldn't every telemarketer on Earth immediately start setting this in every one of their calls? At *worst*, their calls will be treated the same as if they hadn't. And at best, they'll get through with expedited treatment, as though they were emergency callbacks. What's stopping them from rampantly abusing this?
Opinion, with apologies if this comes off as abrupt: The Introduction is decidedly and unnecessarily long-winded. This is a small extension, which needs to describe particular situations only, and doesn't need to re-hash all the ECRIT stuff that's in the other docs. Almost all of the text before the paragraph that begins "Among the emergency services community" really seems unnecessary, as does much of the detail in that paragraph itself. What the introduction needs to say is that PSAP callbacks are part of the emergency services architecture and are described in [citations], that the callbacks as currently laid out in 6443 have [this limitation], and that there are important situation in which it does not work. This document describes those situations and defines a header field that can be used in such situations. Three paragraphs ought to be enough. Had I been a reader of this document, and not a reviewer, I'm sure I'd have lost interest long before I got to the punch line. This is, of course, entirely my opinion, and entirely non-blocking. So: please consider trimming the Introduction significantly... but there's no need to discuss this with me, and if you decide that I'm full of cow cookies and you like it as it is, then carry on.
I agree with Barry's Discuss concerns on Security Considerations. I'm not a Discuss because I think the problems Barry identified are more general than the problems ECRIT is chartered to solve. For example, a STIR Secure Telephony Identity would help prevent spoofed use of psap-callback, but is much more broadly applicable than just assisting with PSAP Callbacks. The conversations I've had with carriers make me think penalizing spoofed psap-callbacks by doing anything worse than treating them as ordinary calls is too risky to deploy. But I'd love to be wrong, and I look forward to learning during the discussion.
I support Barry's and Stephen's DISCUSS positions.
I'm going to support Stephen and Barry here.
One thought. When there is a local relationship between the VoIP provider and the PSAP then populating the whitelist is fairly simple. For SIP UAs there is no need to maintain a list of PSAPs. Instead SIP UAs are assumed to trust the correct processing of their VoIP provider, i.e., the VoIP provider processes the PSAP callback marking and, if it cannot be verified, the PSAP callback marking is removed. If it is left untouched then the SIP UA should assume that it has been verified successfully by the VoIP provider and it should therefore be obeyed. This seems to presume that UA's in fact have trust with respect to what their voip provider does when in fact that may not be the case. if this facility can be abused and can't be ignored it will become untenable rather quickly.
draft-ietf-dhc-option-guidelines
In general, this is a very nice document, but Section 8 seems wrong to me. I was very surprised to find that Section 8 recommends the use of addresses instead of FQDNs. From an application-layer perspective, I would have expected the guidance to be exactly the reverse. All of the "failure modes" listed at the end of the section are all things that applications have to deal with anyway, whether or not they're configured with DHCP. The only exception is the first (that the client might not have DNS servers configured), which for many options will cause the application-layer protocol to fail anyway. This section also fails to consider the drawbacks of using addresses for configuration. Most obviously, address-based configuration is brittle -- if I add a SIP server to my cluster, should I have to force all the DHCP clients to renew their leases? There's also a security benefit to using domain names, since it's much more common to have credentials tied to domain names than to IP addresses. I would strongly urge the WG to reconsider the advice in this section. The considerations listed are worth noting, but in practice, they are far outweighed by the benefits of using FQDNs.
I realize that v4 is old news, but since not everyone has turned off DHCPv4 yet, is there a reason that this document is v6-only? In section 5.3, it looks odd to see prefix6-Len in the math, where the "-" character would normally be subtraction. RFC 5986, 5223 could also be references for 5.10.
I also liked this document, thanks. I've a couple of things I'd like to discuss though: (1) There are no privacy considerations here - shouldn't there be? If some DHCP options (old or new) expose personally identifying information (PII) and are sent in clear or broadcast/multicast then that's presumably not a great thing. Shouldn't you tell people to avoid doing that unless there's a good reason or something? (If there are such options already then it might be good to list some of those and comment on them too as you've done in other cases.) (2) The security considerations recognises that DHCP is basically used in clear, but doesn't that mean you should recommend that DHCP options not contain values that are sensitive? E.g. presumaby it'd be dumb to try to define a new option that sent a client the key to a VPN except in some really weird circumstance?
- 5.7 supports 16 bit URI lengths - maybe you could note that that's a bit bigger than is likely to be useful - section 8: that made me wonder if you've any guidance on whether URIs should include FQDNs or addresses. Just a nit. - section 8, last para on p15: another nit - there's a case where an option might be an FQDN that's sent in another protocol (e.g. HTTP) to a proxy and only then resolved to an address. - section 23, 1st para: this should say clearly that the authentication stuff is hardly used. The 2nd para assume that but its not explicitly stated and should be.
As per my email, I am very interested in the result of the DISCUSSion with Richard. I am left wondering whether the document should loosen the language in section 8, or tighten the language elsewhere.
This is a very fine document, and a very good read. I think it's an important document. So, while all my comments below are non-blocking, I think most of them are important to clarity, and I ask you to consider them. Please chat with me about them if you think it'll help. (It's especially important to get the advice to the ADs clear; we tend to get all verblunget otherwise.) -- Section 5.2 -- Sometimes it is useful to convey a single flag that can either take on or off values. Instead of specifying an option with one bit of usable data and 7 bits of padding, it is better to define an option without any content. It is the presence or absence of the option that conveys the value. This approach has the additional benefit of absent option designating the default, i.e. administrator has to take explicit actions to deploy the opposite of the default value. First, a nit: the "either" is misplaced; it should say "that can take either on or off values." Now, the substance: The intent of this is to say that the absence of the option represents the default value and the presence of the option represents the other value, but that this does *not* necessarily mean that absence is "off" (or "false") and presence is "on" (or "true"). That is, if it's desired that the default value for a bistable option is "true"/"on", then the presence of that option would turn it off (make it false). That seems a potentially confusing point that should be made extremely clear, and I think a bit more text here to clarify it would really help. It's too easy for someone who doesn't read carefully enough to assume that, naturally, the presence of the option always means "on", and the absence, "off". If you're saying otherwise, I think that glaringly clear text is needed. -- Section 5.8 -- A string must not enclude any terminator (such as a null byte). Misspelling: "enclude". There's one thing I find unclear about this sentence: is it trying to say that certain characters (such as U+0000) are not allowed in strings? Or is it simply saying that the representation here is of the string itself, and does not include any applicable termination characters? It would be good to make this clear, either way. -- Section 8 -- I'd like to see the conversation from Richard's DISCUSS. I agree that addresses are better than FQDNs for lower-layer, shorter-term information -- perhaps how to contact VPNs, and such, where the address will be used and then discarded, to be re-obtained next time. But for options that are used to configure app-layer things (SIP or IMAP server addresses, say), where clients will retain the information and use it long-term, FQDNs are much more appropriate. -- Section 9 -- I see that Brian's DISCUSS might cause a significant change here, but in case some of this remains I want to point this out: "SHOULD NOT under any circumstances" makes no sense in a 2119 context. "SHOULD NOT", by definition (see RFC 2119) allows that there might indeed be circumstances when you might choose to do otherwise. -- Section 13 -- This is true whether the new fragment type has the same structure as an existing fragment type, but has different semantics. It is equally true when the new format has a new structure. This misuses "whether", to the point that I find it confusing. "Whether" requires alternatives: "This is true whether <case A> or <case B>." I don't understand what this means to say. Does it, perhaps, mean this?: This is true whether the new fragment type has the same structure as an existing fragment type but has different semantics, or the new format has a new structure. (And, are "new fragment type" and "new format" meant to be different?) Perhaps some re-wording would be better. Responsible Area Directors for working groups that wish to add a work item to a working group charter to define a new DHCP option should get clarity from the working group as to whether the new option is a simple DHCP option with no new fragment type or new fragment semantics, or whether it in fact will require new fragment types. This is a long, involved sentence, so let's be sure it's clear. Do you mean "no new fragment type and no new fragment semantics"? The "or" seems unclear. Then the next part, "or whether it in fact will require new fragment types," leaves me to question what the case should be if it might require new semantics -- that case isn't covered. Maybe this will work better, and will put the focus in the right place?: NEW Responsible Area Directors for working groups that wish to add a work item to a working group charter to define a new DHCP option should get clarity from the working group as to whether the new option will require a new fragment type or new semantics, or whether it is a simple DHCP option that fits existing definitions. END If a working group needs a new fragment type, it is preferable to seek out a working group whose members already have sufficient expertise to evaluate the new work and try to come up with a new format that generalizes well and can be reused, rather than a single- use fragment type. I'm again confused, and I think this and the subsequent text could use some factoring out. You have a few ideas intermixed here: 1a. Try to find another working group with the right expertise. 1b. Failing that, look for DHCP experts to help. 2. The new option should be defined in a separate document. 3. In defining the new option, it's important to look for a generalizable format, not a single-use thing. How about if we tease these apart and reorganize two paragraphs? Maybe this?: NEW If a working group needs a new fragment type, it is preferable to see if another working group exists whose members already have sufficient expertise to evaluate the new work. If such a working group is available, the work should be chartered in that working group instead. If there is no other working group with DHCP expertise that can define the new fragment type, the responsible AD should seek help from known DHCP experts within the IETF to provide advice and frequent early review as the original working group defines the new fragment type. In either case, the new option should be defined in a separate document, and the work should focus on defining a new format that generalizes well and can be reused, rather than a single-use fragment type. The working group that needs the new fragment type can define their new option referencing the new fragment type document, and the work can generally be done in parallel, avoiding unnecessary delays. Having the definition in its own document will foster reuse of the new fragment type. The responsible AD should work with all relevant working group chairs and DHCP experts to ensure that the new fragment type document has in fact been carefully reviewed by the experts and appears satisfactory. END -- Section 15 -- Pet peeve alert: In general, if a lot of data needs to be configured (i.e. large option lengths) Is "i.e." really what you want here? Are large option lengths the *only* reason that a lot of data might need to be configured? Or could there be other reasons (maybe a large number of short options)? I think you mean this: NEW In general, if a lot of data needs to be configured (for example, some option lengths are quite large) END Make "an URI" be "a URI" (or the RFC Editor will). People don't really say, "an oo-ree", do they? Everyone I know says, "a yoo-are-eye". And, by the way, strictly speaking, the URI specifies where (not "how") to obtain the actual configuration information. -- Section 16 -- Allowing multiple option instances often leads to confusion. Consider the following example. Considered. But wasn't the failure there not that there could be multiple instances, but that no one had defined what multiple instances *meant*? Might it be good here to say that you should avoid multiple instances, but that if you do have to use them it's important to clearly document what to do with them? -- Section 17 -- Option order, either the order among many DHCPv6 options or the order of multiple instances of the same option, SHOULD NOT be significant and MUST NOT be assumed. What does that sequence of 2119 key words mean? I think my confusion comes from the second one being orphaned in some way here. What you're saying is this: 1. Option order SHOULD NOT be significant. 2. Option order MUST NOT be assumed. 1 is fine, and it makes sense. For 2, I don't know what it means; it's missing something. And even if I guess, I don't know what the combination of SHOULD NOT and MUST NOT is trying to tell me. Perhaps you can re-word this? By the way, a related anecdote: the IMAP email protocol has a number of situations in which things are almost always sent in a certain order by all servers, but the protocol definition doesn't require that ordering. Someone once wrote an IMAP server that spit those things out in arbitrary order, which differed from response to response. That server uncovered a lot of client bugs. :-)
This one of the most helpful IETF documents I've seen in a long time. Please thank the working group for producing it. It's clearly written and was a pleasure to review.
This document provides some useful advice and I completely support the publication of this document modulo the derogatory example given in section 9 wrt RFC 5908. We have been around this sinkhole before and the characterization in section 9 does not reflect what really happened with the publication of RFC 5908. I think the point of the section can be made clearly without embedding a clouded view of the history of 5908.
typo: participates in leasequery protocol This an excellent document with a utility that transcends its primary purpose. One surprising omission from the security section is the need to clear padding to prevent the inadvertent transmission as a result of buffer reuse.
Brian's point is germain and should be corrected. 5908 is for better or worse a standards track document which the community approved and the IESG reviewed.
draft-ietf-idr-rfd-usable
False flap attack? Groan.
Thanks for this simple and sensible document. I'm an insufferable pedant :-( In Section 6 you say "The following changes are recommended" I don't think it matters whether these are changes or not. Maybe "The use of the following values is recommended."
Along the same lines as Barrry's DISCUSS...
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1.
Table 1 mentions
+-------------------------+----------+-------+---------+
| Parameter | Tunable? | Cisco | Juniper |
+-------------------------+----------+-------+---------+
| Withdrawal | No | 1000 | 1000 |
| Re-Advertisement | No | 0 | 1000 |
It's fine to say that Cisco and Juniper SHOULD NOT change their default values,
but you also have to say what another new vendor must be doing for the
Re-Advertisment parameter. The choices are:
1. 0 as default value
2. 1000 as default value
3. 0 or 1000 as default value
Let's not forget that this is a Standards Track document, to which all vendors
want to be compliant.
Proposal:
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1. New implementations MUST select either 0
or 1000 for the Re-Advertisment parameter default value.
This is surely an issue of my barely knowing how to spell BGP and RFD, much less fully understand them, and so perhaps this just requires a little education: 1. Where are the RFD parameters in Table 1 in Section 3 defined? Where can I find their meanings? They aren't mentioned in RFC 2439 (nor in 4271, but I didn't expect to find them there). The mao2002 and pelsser2011 references have similar tables, but also don't define these parameters. 2. Section 6 says that implementations SHOULD NOT change the default values in Table 1. But the default value for Re-Advertisement is vastly different, depending upon whether I get my router from Cisco or from Juniper. I don't understand what this SHOULD NOT is telling me. If I'm someone else building a router, am I supposed to use 0 for Re-Advertisement, or 1000?
riff on benoit's comment
Default Configurable Parameters: In order not to break existing
operational configurations, BGP implementations SHOULD NOT change
the default values in Table 1.
This is what I'd call the phenomena of least surprise. e.g. don't change
unspecifed (and therefore default values). I'd personally prefer that it say
something like:
Default Configurable Parameters: In order not to break existing
operational configurations, existing BGP implementations inclusive
of the examples in Table 1 SHOULD NOT change default values.
other than that I'm an un-equivocal yes to this.
draft-ietf-6man-ext-transmit
Thanks for the work on this document. I have no objection to its publication and just two minor observations. --- Section 1.1 A couple of points about the following paragraph: In this document "standard" IPv6 extension headers are those specified in detail by IETF standards actions. "Experimental" extension headers are those defined by any Experimental RFC, and the experimental extension header values 253 and 254 defined by [RFC3692] and [RFC4727]. "Defined" extension headers are the "standard" extension headers plus the "experimental" ones. My reading of the IANA registry (http://www.iana.org/assignments/ protocol-numbers/protocol-numbers.xhtml) is that allocations can be made by IESG Approval or Standards Action. I think both of those are covered by what you call "standard". I am not convinced that an experiment that uses an experimental code point needs to be documented in an Experimental RFC. Are 253 and 254 intended solely for experimental extension headers? Couldn't the experiment be an experimental payload protocol? --- I find myself in I-wouldn't-have-done-it-this-way land, so this is, of course, just a Comment for you to chew on and accept or reject according to how it strikes you... It seems to me unwise to create a new registry that duplicates information held in another registry. By adding a column to the "Assigned Internet Protocol Numbers" registry you are making it completely clear which are the IPv6 Extension Headers. Rather than risk having this registry out of step with your new "IPv6 Extension Header Types registry", I would have had the existing, empty "IPv6 Next Header Types" registry redirect users to the "Assigned Internet Protocol Numbers" registry and mention the existence of the specific column that identifies extension headers.
Could you provide any citations on the middle box behaviors, e.g., lack of
support for all of 2460?
10 points to the INT area for the cite to Heller :)
"... Not just a failure to recognize such a header".
Isn't this another Catch-22? If a node doesn't recognize a header, how does it
know if it's standard or not? This also seems in contradiction to later
guidance that unrecognized extensions may be dropped by default.
A flow chart or pseudo code might be useful in Section 2.1, like "if (known &&
standard) { /* policy */ }"
- 2.1 says nodes SHOULD forward rfc4727 experimental headers, but earlier said that its ok (nodes MAY) default to not forwarding packets with experimental headers. I think you need to add an "unless otherwise stated here" to the statement about defaults for experimental headers. - section 4: Is it wise to ask IANA to "redirect" users from one (empty) registry to another? That could be the start of a slippery slope turning IANA registries into a miasma of hypertext;-) Maybe it'd be better to ask that IANA mark that registry as having being replaced by this new one. Also - what if someone else asks IANA to add an entry to the currently empty registry but not the new one - is it clear what should happen in that case?
As "Catch 22" is one of my favourite books ( http://staringatemptypages.blogspot.com/2007/10/you-must-read-this.html ), it pleases me to know that there'll be an RFC with a reference to it. -- Section 4 -- Additionally, IANA is requested to make the existing empty IPv6 Next Header Types registry redirect users to a new IPv6 Extension Header Types registry. It will contain only those protocol numbers which are also marked as IPv6 Extension Header types in the Assigned Internet Protocol Numbers registry. Two small points here: 1. "It" in the second sentence is ambiguous: it could refer to either of the registries mentioned in the first sentence. I suggest making it "The IPv6 Extension Header Types registry will contain...". 2. Is it your intent that the (empty) IPv6 Next Header Types registry also be closed to new registrations? Whether or not, it would be best to make that clear.
Comment: In section 2.1, I think that it would be helpful to the reader to use the option name, as well as the number.
This is a dicuss because I'd like to see if I'm in the rough in this. Devices generally considered to be IP routers in fact are able to or find it necessary to forward on the basis of headers other than the IP header e.g. the transport header. By the definition applied in the problem statement all ipv6 capable routers in the internet that I'm aware are or are capable of being middleboxes. I would welcome the existence proof of an ipv6 capable router which is not capable of being a middlebox by the definition applied in the problem statement. I'm not sure that's a glaring flaw in the document but it certainly is with our vocabulary around taxonomy if true.
If you need to find the transport header due to configured policy and you can't due to being unable to parse the extensions chain your configured action will be to drop. That perhaps weasels it's way through section 2.1 requirements but it's still quite ugly.
draft-yusef-dispatch-ccmp-indication
Is there an intention to retain Appendix A following publication? It seems unnecessary, although I am sure it was useful during the lifetime of the document as an internet draft.
I am tightening up the text of my Discuss: The shepherd write-up and datatracker say "Proposed Standard." The document was last called on the standards track. The document header and says "Informational" These need to be fixed to be consistent one way or another. Personally, I would have expected the document to be standards track since it appears to describe interoperable procedures, but I understand that there is a "feeling" that there is no need for this to be a standards track document.
Thanks for addressing all of my Comments
Support Barry and Sean's comments.
It sounds like there was agreement to make this document Informational, but it is not reflected in the datatracker. Gonzalo: Please update. 2.1: The Call-Info header consists of two parts: a URI and a parameter. The purpose of the URI is to provide the XCON-URI of the conference focus, and the purpose of the parameter is to indicate that the conference focus supports CCMP. Talking about "the purpose of the parameter", when the parameter *is* the "purpose parameter" is bound to be confusing. I suggest rewording to not use the word "purpose" here. How about just "The URI provides the XCOM-URI..., and the parameter indicates..."?
Version -07 addresses my comments. Thanks.
I had one comment you might want to consider: In 1 Introduction This document describes two options to address the above limitation, depending on the need of the UA. The first option uses the Call-Info [RFC3261] header, and the second option defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package [RFC4575]. If I keep reading, I find out what the target audience is for both options, but the first clues I get are in 2.1 and 2.2, and both explanations are buried pretty deeply in those sections. Could you add something in the Introduction, or even in Section 2, that tells implementers which option they should look at first? I agree with the resolutions you've worked out with Barry on his Discuss and his Comments, so thank you for that, too.
What Barry said. And, don't you have to pick one as the MTI?
draft-resnick-retire-std1
I agree with the intent, but shouldn't RFC2026 be updated to include text saying how to get an official list of standards?
draft-ietf-pwe3-vccv-impl-survey-results
A good piece of work, thank you. I am a little disappointed that there are no conclusions about what can safely be deprecated and what could be made Historic. But perhaps the WG will pick that out of the survey and work on it.
I understand this is just survey but could we start asking questions about whether the MTI security mechanisms are actually implemented. Were there some PWs where no security was implemented?
draft-ietf-hip-reload-instance
I know that the HIP charter curtails the WG to work on Experimental documents, but I would have liked this document to be clearer about the parameters of the experiment that it describes. What are the walls around the garden? How does it avoid impacting "the Internet"? What things are the experimenters asked to look out for? What explicit experimentation should be attempted (e.g., varying parameters)? How will the WG judge the success or otherwise of the experiment? It is by no means mandatory to include such a commentary, but it would make the document so much more valuable.
I'm not sure I follow how this works entirely but it seems like a fine thing with which to experiment. Am I right that an application running on a RELOAD HIP BONE couldn't easily interoperate with an application using a "standard" RELOAD configuration, i.e. that uses TLS to secure its connections to the RELOAD servers? If so, that seems a pity but it'd be good to explain that in the draft maybe (and why that's ok). I agree with Sean and Spencer's discusses. Couldn't you make the use of ENCRYPTED mandatory and not just RECOMMENDED?
I'm confused about the story on encryption. Please help unconfuse me!
In 6. Securing Communication, I'm reading
With a RELOAD HIP BONE, instead of using TLS connections as defined
in [I-D.ietf-p2psip-base], all HIP overlay messages SHOULD be either
sent using encrypted connections (such as IPsec ESP tunnel between
two peers [RFC6261]) or the contents of the messages SHOULD be in an
ENCRYPTED parameter (see Section 5.2.15 of [RFC5201]). Use of
encrypted connections is RECOMMENDED since that provides
confidentiality also for the HIP headers.
as roughly
you SHOULD use encrypted connections,
but that might not happen, and if you don't,
you SHOULD use an ENCRYPTED parameter,
but that might not happen, either
If I didn't mess that up ... I'm reading 11. Security Considerations
The option to send overlay messages unencrypted makes it possible for
hosts that are not part of the overlay to inspect the contents of the
messages and thus should be avoided when possible.
and I'm wondering why the specification creates an option and then says that
option should be avoided when possible.
Could you say anything to help the reader understand why at least the payloads,
and maybe even the HIP headers, might be sent "in the clear"?
Would a sending application know when a payload could be sent "in the clear"?
Would a HIP overlay know what payloads could safely be sent "in the clear"?
In 4. Node ID Generation In the other Node ID mode, namely "RELOAD", all 128 bits are generated as defined in [I-D.ietf-p2psip-base] resulting in a larger usable address space. The downside of not using the ORCHID prefix is that such Node IDs can not be used with legacy applications and APIs, as discussed in Section 5.1 of [RFC6079]. this text took a few reads to parse, and part of my problem was an explicit "downside" that I had to match with an implicit upside. I could more easily have understood this text if it was something like this: In the other Node ID mode, namely "RELOAD", all 128 bits are generated as defined in [I-D.ietf-p2psip-base]. This results in a larger usable address space than using the ORCHID mode, but the resulting Node IDs cannot be used with legacy applications and APIs, as discussed in Section 5.1 of [RFC6079].
I agree with Sean and Spencer that the security model/approach should be clearer.
To the responsible AD - when do you anticipate the completion of normative reference I-D.ietf-p2psip-base ?
There's two options listed for a security solution. Which one is the MTI?
draft-ietf-l2vpn-pbb-vpls-interop
I have no objection to the publication of this document, but I have some observations... --- From the Shepherd Write-up... > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > When the WG meeting at IETF74 was asked for consensus on the draft > about 6 people were in favour (the same number as had read the draft). > 5 people (including 3 non-authors) indicated support for the draft on > the mailing list poll and none objected. In March 2009 6 people were in favour of an I-D with 4 authors? And this merits being a working group document on the strength of that? --- I think a number of acronyms need to be exapnded. Compare with http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt --- I find Section 10 hard to believe. Compared with VPLS/H-VPLS scenarios, this document is considering interoperating two network types. Surely in this case, the security of the whole is only as good as the weakest security of any of the component networks. Doesn't that mean that at the very least you need a reference to PBB security mechanisms? Are there no vectors for attacking the IP/MPLS network via the PBB network?
What Adrian said.
Further to Adrian's point: 1. The document shepherd tells us that two or three people besides the authors have indicated support for this, and perhaps only two have actually read it. 2. An IPR statement was filed in 2008 on the individual-submission version of the document. Two of the authors are inventors on the two patents mentioned in the statement. The working group adopted the document in early 2010. And, according to the shepherd writeup, the working group was first informed of the IPR statement in July 2013 (presumably as part of WGLC)? I don't see how we can really say there's working group consensus on this document. <cynical-mode> And it really looks to me like it's authors getting their patents into working group technology on the basis that no one cares enough to object. </cynical-mode> (I realise that my cynical-mode statement may be unfair to well-meaning authors, and that I have no real basis for it. Please take it with many grains of salt.) I'm not going to block this document on these points, but I can't in good conscience support it either. Hence, my ABSTAIN position.
Given my read of the document and the author's response to points raised in Barry's ballot, this appears to be a case of publishing for publishing's sake. I can't support the publication of this document, unless it was being published as Historic.
draft-ietf-intarea-flow-label-balancing
This is a fine document, but I have concluded (see below) that it is not the document it says it is. That causes me to place a Discuss that I think can be very easily fixed by some minor changes to the text... In Section 1 Load distribution is a slightly more general term than load balancing, but the latter is more commonly used. Both terms refer to mechanisms that distribute the workload of a server farm among different servers in order to optimize performance. In the context of server farms, the terms definitely apply as you describe, but it is not right to say that load balancing means a mechanism used to the distribute workload of a server farm. Please reword to not curtail other people's use of the term. It may be enough to say "Both terms can be used to refer to..." or "In this document, both terms are used to refer to..." or "In the context of a server farm, both terms refer to..." Similarly, Section 3 is headed "Summary of Load Balancing Techniques" but appears to be about load balancing techniques for server farms. So maybe that should be rebranded. Which leads me to ask the main meat of the Discussable point: is the document title correct? Shouldn't it be "Using the IPv6 Flow Label for Server Load Balancing in Server Farms"?
Only one piece of text to comment on: Section 2., paragraph 4: > A careful reading of RFC 6437 shows that for a given source accessing > a well-known TCP port at a given destination, the flow label is, in > effect, a substitute for the source port number, found at a fixed > position in the layer 3 header. Where do you read this in RFC 6437? The text above sounds a bit mysterious in that respect. Anyhow, even if RFC 6437 can be read in this way, your text is not correct as it stands. The flow label is in general not a substitute for TCP port number, as the port numbers are used at the end hosts to demultiplex the incoming traffic. Here is a text proposal from my side to make your point much clearer: A careful reading of RFC 6437 (according to Section X) shows that for load balancers relying on the flow label, the flow label is a substitute for the source port number, found at a fixed position in the layer 3 header, for a given source accessing a well-known TCP port at a given destination.
I see
If the flow label of an incoming packet is non-zero, layer 3/4
load balancers can use the 2-tuple {source address, flow label} as
the session key for whatever load distribution algorithm they
support.
And later on
The association between the flow label value and
the server is stored in a table (often called stick table) so that
future connections using the same flow label can be sent to the same
server.
Isn't it?
The association between the source address/flow label value and
the server is stored in a table (often called stick table) so that
future connections using the same flow label can be sent to the same
server.
One thought I had on reading this document is that it would seem to make sense as an Applicability Statement, rather than as Informational. However, the answers to questions 5 and 6 in the shepherd writeup convinced me that Informational is all that's appropriate at this time.
this started as a comment. it's bloomed into a discuss because I think there's
a lot of issues to be dicussed.
(sorry, one minor edit, read the second discuss email rather than the first)
If the flow label is in fact set to zero, it will not
affect the information entropy of the IPv6 header.
certainly it will, since your assumption vis-a-vis label balancing is that it
does augment (an l3 only hash) or substitute for entropy that might otherwise
be found elsewhere, e.g. in the transport header.
Assume the case of load balancing a small number of sources to a single or
small number of destination IPs (this is common for API services for example or
lots of front-end --> back-backend application communication).
host 1 first tcp connection to dest 1 with a zero flow label using a source,
dest, flow label, xor hashes to the same host behind dest 1 as host 1 second
connection to dest 2 with a zero flow label. That's peachy if that's what you
want, but not if you don't.
so as you note if you're using zero you probably want to do something else.
...
these two:
o Another method, for HTTP servers, is to operate a layer 7 reverse
proxy in front of the server farm. The reverse proxy will present
a single IP address to the world, communicated to clients by a
single AAAA record. For each new client session (an incoming TCP
connection and HTTP request), it will pick a particular server and
proxy the session to it. The act of proxying should be more
efficient and less resource-intensive than the act of serving the
required content. The proxy must retain TCP state and proxy state
for the duration of the session. This TCP state could,
potentially, include the incoming flow label value.
o A component of some load balancing systems is an SSL reverse proxy
farm. The individual SSL proxies handle all cryptographic aspects
and exchange unencrypted HTTP with the actual servers. Thus, from
the load balancing point of view, this really looks just like a
server farm, except that it's specialised for HTTPS. Each proxy
will retain SSL and TCP and maybe HTTP state for the duration of
the session, and the TCP state could potentially include the flow
label.
are simply variations of application aware proxy they could just as easy be
imap(s) or smtp(s) or sip. The operative issue being that for the purposes of
connection termination they are hosts not routers and they have to find the
upper layer header (and potentially go as far as application protocol
implementation).
...
In all cases, the layer 3/4 load balancer has to
recognize incoming packets as belonging to new or existing client
sessions, and choose the target server or proxy so as to ensure
persistence.
I get what you're trying to say but I think this is a a mis-statement. As you
go on to deal with stateless load balancing correctly... A stateless L3+L4 load
balancer doesn't care whether a connection is new or preexisting, persistence
is product of the values associated with the hash being immutable over the
duration for which they are required and no other condition.
...
1. Balancers use various techniques to redirect traffic to a
specific target server.
- All servers are configured with the same IP address, they
are all on the same LAN, and the load balancer sends directly
to their individual MAC addresses. In this case, return
packets from the server to the client are sent back without
passing through the balancer, a technique known as direct
server return, but we are not concerned here with the return
packets.
- Each server has its own IP address, and the balancer uses an
IP-in-IP tunnel to reach it.
- Each server has its own IP address, and the balancer
performs NAPT (network address and port translation) to
deliver the client's packets to that address.
The choice between these methods is not affected by use of the
flow label.
You missed one that is rather common which is that there are multiple L3
next-hops for the same destination IP (Layer-3 ECMP the same as is used to
hash across router links). that's anycast in it's simplest form, and it's a
pretty common technique using either bgp or an IGP of your choice.
...
jjaeggli@ca2-b2-re1# run show route 2620:102:8003:211::1/128
inet6.0: 14896 destinations, 59622 routes (14896 active, 0 holddown, 29172
hidden) + = Active Route, - = Last Active, * = Both
2620:102:8003:211::1/128
*[BGP/170] 17w6d 23:34:12, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
to 2620:102:8003:200::13 via ae0.1721
to 2620:102:8003:200::14 via ae0.1721
to 2620:102:8003:200::15 via ae0.1721
to 2620:102:8003:200::16 via ae0.1721
to 2620:102:8003:200::18 via ae0.1721
to 2620:102:8003:200::19 via ae0.1721
> to 2620:102:8003:201::8 via ae1.2721
to 2620:102:8003:201::9 via ae1.2721
to 2620:102:8003:201::a via ae1.2721
[BGP/170] 7w4d 01:55:21, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::13 via ae0.1721
[BGP/170] 7w4d 01:55:28, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::14 via ae0.1721
[BGP/170] 7w4d 01:55:06, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::15 via ae0.1721
[BGP/170] 7w4d 01:55:08, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::16 via ae0.1721
[BGP/170] 7w4d 01:55:27, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::18 via ae0.1721
[BGP/170] 1d 05:58:20, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::19 via ae0.1721
[BGP/170] 17w6d 23:34:38, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:201::9 via ae1.2721
[BGP/170] 17w6d 23:33:43, MED 50, localpref 200
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:201::a via ae1.2721
[BGP/170] 17w6d 20:20:44, MED 50, localpref 200, from
2620:102:8003::1
AS path: 64999 I, validation-state: unverified
> to 2620:102:8003:200::16 via ae0.1721
...
2. A layer 3/4 balancer must correctly handle Path MTU Discovery
by forwarding relevant ICMPv6 packets in both directions.
This too is not affected by use of the flow label.
icmp messages (this applies to v4 and v6) emitted by devices on the path from
the server --> client that are sent back to the server IP are really
problematic because the probability of them hashing to a different server is
rather high, icmp messages emitted towards the client by path elements
inclusive of the server ip are generally no problem. There are techniques to
address that e.g. multicasting them towards the servers but that's rather
non-scalable.
One could snarf the flow label and the destination off the offending packet
(the one that's going back in the icmp6 type 2 payload to the sender) and use
those as the source and flow label for your icmpv6 ptb message since
label-balance would insure delivery but that makes diagnostics kind of sketchy.
...
diagram in section 3
___|_______DNS-based____________|___
| load splitting |
| (if used) occurs |
| here
dns based sever selection is actually something that occurs on a nameserver
(the GTM) the client (e.g. when more than one record is served) or both e.g. by
a GTM serving more that one RR.
mb-aye:~ jjaeggli$ host www.google.com
www.google.com has address 173.194.33.18
www.google.com has address 173.194.33.16
www.google.com has address 173.194.33.20
www.google.com has address 173.194.33.19
www.google.com has address 173.194.33.17
www.google.com has IPv6 address 2607:f8b0:400a:800::1010
....
However, usage by the proxies seems unlikely to be cost-effective,
because they must in any case process the application layer header,
so in this document we focus only on layer 3/4 balancers.
As you note previously the flow label is in a fixed location in the ip header,
so cost isn't really that germain. They do have to look all the way in-to the
application so it may not be that relevant.
...
o We are only concerned with IPv6 traffic in which the flow label
value has been set at or near the source according to [RFC6437].
I can't see that it matters so long as it doesn't change midflow, it's hard to
know this with certainty since it's not immutable.
...
section 4
2-tuple {source address, flow label}
What would be the gain in not using the source/dest/flow label on a stateless
LB? you may be asserting that the dest has low entropy and maybe it does if you
only have one, but if you have hundreds or thousands it may well.
The destination is required for the forwarding decision your might as well
xor-across it too (and traditional layer-3 only load balancing in v4 typically
used at least source/dest and generally protocol number). doing so has no state.
...
A stateful layer 3/4 load balancer would apply its usual load
distribution algorithm to the first packet of a session, and store
the {2-tuple, server} association in a table so that subsequent
packets belonging to the same session are forwarded to the same
server. Thus, for all subsequent packets of the session, it can
ignore all IPv6 extension headers, which should lead to a
performance benefit. Whether this benefit is valuable will depend
on engineering details of the specific load balancer.
This strikes me as a bit odd, as described it would be trivial to multiplex
another connection over this state entry (which might be desirable for some
applications) simply by using the same source/dest/flow label which sounds like
a huge DOS risk e.g. because you now have a fixed state entry pinned to a
server so long as you keep sending packets. It might also allow you bypass
controls that you could apply to the first packet of each session, like for
example initiating a new connection to a different destination port number. The
other question is how do you know when the session ends. since you're not
looking for fin/ack/fin/ack or RST your basically stuck keeping state with a
timer or this state table will always be full.
This is not as the security considerations section states:
The flow label does not significantly alter this situation.
with regard to dos/bypass risk. Rather techniques used today by stateful l3/l4
load balancers to mitigate dos risk statelessly to protect servers from large
packet flows e.g. TCP syn cookies or apply gross security controls e.g. only
port 80 connections for example) become ineffective because the attacker
generating valid connections can know in advance what source/dest/flow label(s)
will be used by to create connections through which packets can be delivered to
servers (which is a rather different problem then it being hard to guess what
someone else is using). ...
Since the
only state to be stored is the 2-tuple and the server identifier,
storage requirements will be reduced.
and a timer apparently, either the 2 minute one from 3697 if we consider that
still in force since 6437 doesn't mention it, or some other one. ...
The association between the flow label value and
the server is stored in a table (often called stick table) so that
future connections using the same flow label can be sent to the same
server.
This presumes the reuse of flow labels by a client. while 6437 presumes the
existence of stateful flow label usage models, state entries that last a long
time relative to the tcp connections that use them are an expensive proposition
for a network device.
draft-ietf-sipcore-rfc4244bis-callflows
Minor editorial point: OLD: The term "retarget" is used as defined in [I-D.ietf-sipcore-rfc4244bis]. The terms "location service", "redirect" and "AOR" are used consistent with the terminology in [RFC3261]. NEW: The term "retarget" is used as defined in [I-D.ietf-sipcore-rfc4244bis]. The terms "location service", "redirect" and "address-of-record (AOR)" are used consistent with the terminology in [RFC3261].
Thanks for producing this document. Having co-chaired a RAI working group that
produced a callflows spec, I know they don't just fall out of your laptop and
roll across the floor - they're a lot of work..
I have a small number of comments. Most are editorial.
I guess the comment on 3.11 is, too, but it's beyond a nit. Please look it over
and see if my suggestion would improve it. I'm happy to help if that's needed.
Why does one occurence of "Home" have asterisks around it ("*Home*)?
I salute the authors for the use of "blah, blah, blah..." in an RFC, when
approved :-)
There are two instances of this text:
Note that some VMSs may also (or instead) use the
information available in the History-Info headers for custom handling
of the VM in terms of how and why the call arrived at the VMS.
^^^^^^^^^^^
"in terms of" wasn't clear to me. I might sugget "based on".
In Section 3.6. PBX Voicemail Example, there's one instance of rfc4244bis used
as a reference that's not bracketed (all the other instances are). The RFC
Editor will almost certainly find it to replace it with an RFC number, but if
it matched all the others, that might help them.
In Section 3.10, "to invocate a service" might be more easily understood if it
were "to invoke a service".
The shepherd writeup recommended removing a reference to ietf-enum-cnam which
expired in 2009. I'm just mentioning that, too.
In 3.11. Toll Free Number
Once such a translation has been performed, the call needs to be
routed towards the target of the request. Normally, this would
^^^^^^^^
happen by selecting a PSTN gateway which is a good route towards the
^^^^^^^^^^^^^^
translated number. However, one can imagine all-IP systems where the
^^^^^^^ ^^^^^^
8xx numbers are SIP endpoints on an IP network, in which case the
translation of the 8xx number would actually be a SIP URI and not a
phone number. Assuming for the moment it is a PSTN connected entity,
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
the call would be routed towards a PSTN gateway. Proper treatment of
the call in the PSTN (and in particular, correct reconciliation of
billing records) requires that the call be marked with both the
original 8xx number AND the target number for the call. However, in
^^^^^^^
our example here, since the translation was performed by a SIP proxy
^^^^^^^^^^^
upstream from the gateway, the original 8xx number would have been
lost, and the call will not interwork properly with the PSTN.
History-info would come in play here to assure original 8xx number is
not lost.
Furthermore, even if the translation of the 8xx number was a SIP URI,
^^^^^^^^^^^^^^^^^^^^
the enterprise or user who utilize the 8xx service would like to know
whether the call came in via 8xx number in order to treat the call
differently (for example to play a special announcement..) but if the
original R-URI is lost through translation, there is no way to tell
if the call came in via 8xx number.
I understood every sentence in this text, but flipping back and forth between
PTSN gateways and all-IP systems made the paragraphs difficult to follow. Any
chance that this could be split into a PSTN case and an all-IP case, with only
one transition?
draft-worley-service-example
I've realized upon reflection that some of the comments I've made in the comments section are actually DISCUSS-worthy. I don't want to block forward motion on this document, and if the resolution on the telechat today is that nobody else cares about this, I will clear the DISCUSS on that basis, but: 1. I _really_ think this is a standard, not informational, and consequently 2. I think the point I raised in the comment section about section 2.8.1 is actually an interoperability problem that needs to be addressed. So, I will clear this DISCUSS if any of the following happen: 1. There is no consensus on the telechat that this needs to be addressed. 2. The hack described in section 2.8 is made mandatory (that is, the language in 2.8.1 that says it's not mandatory is removed). 3. There is consensus that the requirement that's mentioned in 2.8.1 really is unnecessary, in which case the hack should just not be documented.
I think the text in the introduction about why people want on hold music is better than the text in the Abstract; I mention this because several other ADs commented on the abstract text, which I too found to be excessively exuberant on the topic of how much people like on hold music. No need to change it unless you take all this whining to heart. I agree with Pete that if this document lives up to its sales pitch, it ought to be either experimental or proposed standard, not informational. The motivation for calling it informational seems to be that it isn't intended to supersede other methods, but that's not a reason for it to be informational. That's just a reason not to put "Obsoletes RFCxxxx" on the title page. I'm curious to know if you talked this over with Richard, or if it just passed under the radar. In section 2, the links to RFC 4566 and RFC 3264 are broken, but the link to RFC 6337 is working. I don't know what happened here, but you should fix this in your source so that they all work, assuming it's not a bug in xml2rfc. In section 2.5, it looks like what's happening here is that Alice has transferred the call to Carol. Is that correct? If so, you might want to say that. I suppose a reader who's experience with SIP will understand this, but it was a bit mysterious to me, and I think saying what is happening makes it clearer. Not all readers are wizards. (If I _knew_ that I'd understood it correctly, I would not have made this comment; the problem is that the text does not confirm my supposition, so I don't know whether or not it is correct.) Actually, reading section 2.6 suggests to me that I haven't got it right. I think 2.5 and 2.6 would benefit from an explanation of what user action triggered the described protocol behavior. Section 2.7 has another broken external reference, to RFC 5245. It's possible that I've missed other such references on the way through the document—if you figure out why this is happening, you should probably check for instances I've missed. You also have several broken cross-document section references in 2.8.1. This suggests to me that it's the tools HTML reader that's at fault here, but if you are using xml2rfc, it would be good if you could use the xml2rfc technique for doing cross-document section references, so that these do the right thing when the reader clicks on them. If you aren't using xml2rfc, this can be left to the RFC editor. BTW, the link to section 6.3 of RFC 3264 that immediately precedes the 2.8.3 section header is rendered correctly, so one way to address this comment would be to reformat the other cross-document section references so that they look like this one. Also, it occurs to me that the broken references elsewhere in the document may be broken because there is no whitespace before the opening square bracket: foo[RFCxxx] rather than foo [RFCxxx]. The conclusion of section 2.8.1 is a bit unhelpful. It seems to me that the implementor of a user agent can't really know whether or not the solution described in later portions of section 2.8 is needed, and indeed there's no way to tell from the protocol either. So the document should either recommend always implementing the solution you describe here, or shouldn't recommend it. It seems to me that you, an expert in the field, think that this hack is unnecessary, and are including it merely for completeness. If that's the case, it would be good to say so. It would help to understand why the requirement you are working around here was stated in the first place. If you really can't be sure this hack is not required, then it should probably be required, even if in most cases it's unnecessary. In 5.2: The executing UA and the MOH server will usually be within the same administrative domain and the SIP signaling path between them will lie entirely within that domain. In this case, the administrator of the domain should configure the UA and server to apply to to the dialog between them a level of security that is appropriate for the administrative domain. You have a doubled "to" toward the end of the fourth line. All in all a very readable and understandable document—thanks for doing it!
Delightful document although I take issue with the very first statement: > The "music on hold" feature is one of the most desired features of > telephone systems in the business environment. I get pretty annoyed by it. Especially bad music on a short loop with poor quality audio. :-) --- A number of key fields have not be filled in to the data tracker. Of particular importance is the "IETF consensus" field
- abstract: Music on hold? Sorry, but yuk, so "most desired" is not something I find credible unless you care to say who desires it any why. "Fully effective" is also just marketing. And "standards compliant" is also an odd thing to say - why should we note that? - I recently used some concall service that told me "if you don't want the music, hit 1" which is nice. If that isn't the content of someone's really dumb patent, it'd be a service to humanity to include that feature here. - The security considerations are very thorough, thanks. However, it'd be better if you said "this will break any security setup for the call unless the MOH and executing UA are in the same domain and indistinguishable from the remote UA's perspective." It'd be a real shame for this feature to be something the precluded introducing some e2e security into SIP. (This isn't a discuss only because it seems e2e security for SIP calls seems mythical right now and this is informational. If this does need to be standards track I might promote this to a discuss calling for there to be a way to ensure that MOH doesn't weaken whatever security is in place for the call).
I'd like to understand why this document is not being put forward as either Proposed Standard or Experimental. This document does describe protocol. It may be updated in the future if there are certain parts of the protocol exchange that need to be changed or clarified. It might become the one and only standard way that people do MOH. It doesn't matter that there are other ways to to MOH; it's that this is one good (maybe the best) way to do it. Section 1.1 doesn't really explain why you didn't go for PS or Exp. (I certainly agree that this ought not have been BCP.) If it goes forward as Informational, the world doesn't end. But it seems like a non-ideal choice. I agree with Barry that either way, 1.1 probably doesn't need to be in the final RFC.
A couple of very minor, non-blocking comments; please consider them, and there's no need to reply. -- Section 1.1 -- Much discussion of the intended status, and why this isn't a BCP or whatever, may have been useful during the development of the document and its review by the community and the IESG, but probably doesn't have archival value. I suggest adding the last paragraph, minus the word "however", to the end of the second paragraph of Section 1. I suggest moving the second paragraph to be a new third paragraph of Section 1. That will leave the first paragraph, to which I suggest you add a note to the RFC Editor to remove this section on publication. -- Section 6 -- The citations to mailing list messages are interesting. I'm not sure I've seen it done before, but I think it's probably useful. That said, I think it'd be more useful if the references contained URIs for the messages, rather than just the message numbers.
I agree with Adrian's note, as MoH is my most unfavorite feature, reminding me of the time and money I am wasting due to the lack of call center capacity at the called party. Don't some codecs require "speech on hold"? I neither require nor anticipate any change based on the above comments.
conflict-review-hausenblas-csv-fragment
Pete's point seems valid.
Section 6 is pretty uninformative, which is a pity. Might be a good test for whoever's tooling up to handle drafts with 6982 sections though:-)
Pete has raised the point already.
I apologize for the waffle. I think I still do want to DISCUSS this. The lynch pin of what I wrote below is that we're OK updating an IETF registration to point to a non-IETF document. But we've never officially gotten buy-in from the IETF that *they* think this is the right way to to fragment identifiers. Are we willing to say that this is OK? I may go right back to YES on the call, but I want to DISCUSS.
I previously noted that in light of the IANA comment [IANA #712726],the No Conflict message was not appropriate. After conversations with Barry, I now believe the following the following: - An update to this registry requires IESG Review, either in the form of an IETF document (which would get IESG Review) or an overt action by the IESG. - This document preserves entirely the existing registration. It simply adds "fragment identifier" information. The fragment identifier field was not available when the original IETF registration took place, so the present document is filling in a new blank. - This document probably should have gone through IETF processing. However, the change to the registration is just to add fragment identifier semantics to the existing registration; it doesn't change the format at all. The document could have been published without updating the registry and it *clearly* would have been "No Conflict". So I think updating the registry to point to this method of using the fragment identifier is reasonable. - We should decide the management item first to confirm that the IESG is OK with the registration update. Then, approving "No conflict" makes sense. I think this is a one off. I think it's reasonable to let it through, assuming the rest of the IESG is on board with updating the registry entry.
I'll trust Pete on that one.
The change to the text/csv media type registration requires separate IESG approval, as the IESG is the change controller for that registration. I have requested a management item for that on the same telechat. The updated text/csv registration template is in Section 5.1 of the document.
I agree with Pete's suggested conflict review text.
I agree with Pete.
conflict-review-vandesompel-memento
No objection, but building on Barry's point to ask about IANA Expert Review. I know Mark has reviewed the document and is one of the designated experts for one of the registries. It is not clear to me how the overlap of ISE and Expert Review works, and a note saying that the reviews have already been done would be comforting.
I'm just wondering if the httpbis wg have looked at this and if not, why that's ok? I see two mails in my local archive for httpbis annoucing drafts (in may 2012 and may 2013) but no reaction at all so its not clear to me if there would or would not be objections to this from the wg.
Comment on the document: The IANA Considerations section really needs to be fleshed out. I suggest separate subsections for each of the four actions, which clearly separates them and allows you to say what needs to be said in a way that's clear to IANA. I suggest that you be clear about which registry each item is being registered in (rather than saying "the appropriate IANA registry"), so that IANA doesn't have to guess, and perhaps guess wrong (it's bad news when things get put into the wrong registries). And we can't just say, "IANA, stick this in that registry," because the registries generally have templates with which we provide the required registry information -- if it's just a name and a reference, being terse is OK, but when there are three or four or five columns in the registry table, we have to be careful to provide all the information. For the first action, the registry you want is the "Permanent Message Header Field Names" registry, and the registration template is in RFC 3864, Section 4.2.1. For the second action, it's the "Link Relation Types" registry, and the registration template is in RFC 5988, Section 6.2.1. For the third and fourth actions, I think you're looking for the "Link Relation Application Data" registry, though I'm not entirely sure. For that registry, the template is in RFC 5988, Section 6.3. If you have questions about this, you can contact Mark Nottingham.
conflict-review-hoffine-already-dotless
The abstract says: Recent statements from the Internet Architecture Board and ICANN's Security and Stability Advisory Committee have discussed the problems that the DNS is likely to experience with top-level domains that have address records in them (so-called "dotless domains"). However, these statements spoke of the problem mostly as theoretical, when in fact there are such TLDs today. Actually, the current IESG web page that talks about this mentions that existing TLDs have published dotless domains, so it would be good to update the abstract to reflect that. I've also mentioned to the authors that I am concerned that the document as written may lead readers to think that the status quo described in the document is okay. I would like the document to give the reader clear guidance on that topic so that they don't get the wrong impression. Benoit's suggestion for how to handle this would satisfy my concern here. I realize that the authors do not want to make their own policy statement because that would be inappropriate in an ISE document, but this document touches on a very important policy issue, and I do not want the ISE status to accidentally accomplish the opposite of what I think the authors were trying to do.
I would prefer that the ISE could work with the authors so that the point of
concern is added to the text of the document and does not need to be present as
an IESG note. That said, if the authors are unwilling, I would support an IESG
note.
But some typos and clarification might help...
1. Give a reference for the IAB statement.
2. s/the the/the/
3. Give a reference for the IETF consensus on the operation of the
root zone and expected behaviour of resolvers.
4. s/The authors of hoffine-already-dotless-01 do not take/This document does
not state/ 5. s/they are harmful/dotless domains are harmful/ 6. s/should
remove them/should stop publishing them/ (not sure about this change)
I agree strongly enough with Barry's DISCUSS that I am willing to hold it as my own at the moment. At this point, I object to the inclusion of an IESG Note.
Leaving aside the corrections that Adrian made (I agree with them, save the fact that I don't think the statement should be included at all), I want to disagree with one thing: I initially said that the second sentence needed references. However, the IAB statement shows why doing so is quite fraught; we don't have a nice clean consensus statement about how resolvers should behave; all statements seem to go back to claims about search lists in RFC 1536. Not exactly a crystal clear consensus. And as far as root server operation, do we *really* want to reference RFC 2870?
I concur with the position that no IESG note should be added.
I don't see the need to add an IESG statement here, but I will trust that the other DISCUSS positions will be enough to take care of this.
Agree that text in doc is better than IESG note. Assuming the text would be strong enough. The current IESG note is strong enough.
After a discussion with Joel, I now understand and support his point of view.
Wanted to vote YES, but I'm not sure what it means for a conflict review.
Joel gave me two good arguments why this IESG note is a good thing:
- ccTLD operators (the ones who created the dotless domains) have no
obligations to ICANN. They can do what they want, regardless of the ICANN
guidelines. - As the authors don't state an opinion, this document might be
perceived as: here is a way to "search" dotless domains, have your own opinion
for yourself, we don't state ours. The topic is too important. The IESG should
stress the message: published dotless domains should not be used.
The document already contains:
This document
lists data about dotless TLDs, but does not address the policy and
technology issues other than to point to the statements of others.
...
The Internet Architecture Board (IAB)
issued a statement called "Dotless Domains Considered Harmful"
[IAB-DOTLESS] in July, 2013.
...
This document lists the known dotless domains; it does not express an
opinion whether or not there are security considerations with the
existence of dotless domains.
What the ideal (for me) would be:
1. The authors refers to [SAC053] ICANN Security and Stability Advisory
Committee, “SSAC Report on Dotless Domains”, SAC053. 23 February 2012.
Retrieved from SAC053, and cut and paste the recommendation.
Recommendation: Dotless domains will not be universally reachable and the
SSAC recommends strongly against their use. As a result, the SSAC also
recommends that the use of DNS resource records such as A, AAAA, and MX in
the apex of a Top- Level Domain (TLD) be contractually prohibited where
appropriate and strongly discouraged in all cases.
2. An IESG note expressing that the IESG supports the Recommendation in
[SAC053], and that published dotless domains should be removed.
Updated for -02, and the re-worded IESG note. > The IAB has stated that dotless domains are considered harmful. The document already cites the IAB statement, with a reference; see the first paragraph of the Introduction. Why does anyone think we need to repeat that in an IESG note? > There is IETF > consensus on the the operation of the root zone and the expected behavior of > resolvers. General standards about operation of DNS zones, or whatever, are not related to this. Unless I see a citation that shows a connection to dotless domains, I don't see how any of that is relevant to an IESG note on this document. > The author of hoffine-already-dotless-01 do not take a position > as to whether they are harmful or not, The last sentence of the abstract already says: This document lists data about dotless TLDs, but does not address the policy and technology issues other than to point to the statements of others. Why does anyone want an IESG note that says more about what the authors do or don't say? > however the IESG believes that operators > who currently publish these records should remove them. The IESG should not be making any statements nor recommendations about how dotless domains should or should not be handled, and whether they should or shouldn't be removed. We do not have community consensus on what to say in that regard. If someone has specific things they'd like the authors to consider adding to the document, please say so and the authors can consider it. But I don't see any reason for our putting in *any* IESG note in.
I trust that the right thing will happen, based on discussion so far ...
I strongly oppose the inclusion of the IESG note.
This is *not* my area of expertise, but as far as I can see the draft is factually reporting the existing dotless domains, and describing how to generate a list of the current set. I cannot see any harm in reporting the results of a measurement on the Internet, or a method of generating a list, and thus I cannot see the reason to include the IESG statement.
conflict-review-irtf-samrg-common-api
Once again, thanks very much to the document authors for working with me on the URI issues. They have been resolved, and this version is, indeed, ready to publish in the IRTF stream.