Narrative Minutes of the IESG Teleconference on 2012-12-13. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Amy: next telechat is one week away, tools can't send preliminary agenda until midnight
-
Russ Housley: Comment [2012-12-13 06:54]:
I was expecting a reference to an IANA registry of keying-mechanisms
in Section 5.1.5.21. Without this reference, it is unclear to me
how the keying material needed for encryption is managed. Further,
when encryption is supported, it would be very useful for one
keying-mechanism to be mandatory.
-
Russ Housley: Comment [2012-12-13 06:54]:
I was expecting a reference to an IANA registry of keying-mechanisms
in Section 5.1.5.21. Without this reference, it is unclear to me
how the keying material needed for encryption is managed. Further,
when encryption is supported, it would be very useful for one
keying-mechanism to be mandatory.
-
Adrian Farrel: Comment [2012-12-13 04:36]:
I have reviewed this document for its impact on the routing system and have no objection to its publication.
I would caution all working in this area to be sensitive to the re-invention of wheels. Consider that "Media Server routing decisions" are routing decisions. Although they are relatively simple today, it is inevitable that they will grow more complex over time. Do not make the mistake of assuming that the diameter of your networks will always remain small and that routing can therefore be left as a simplistic process. Ensure that your architectures are forwards-compatible with future routing schemes.
Similarly, be aware that the resource brokering at this "network layer" is funcitonally similar to the resource brokering considered at other layers (TSV, RTG) and try to share your ideas as well as learn from others' work.
-
Adrian Farrel: Comment [2012-12-13 04:36]:
I have reviewed this document for its impact on the routing system and have no
objection to its publication.
I would caution all working in this area to be sensitive to the re-invention of
wheels. Consider that "Media Server routing decisions" are routing decisions.
Although they are relatively simple today, it is inevitable that they will grow
more complex over time. Do not make the mistake of assuming that the diameter
of your networks will always remain small and that routing can therefore be
left as a simplistic process. Ensure that your architectures are
forwards-compatible with future routing schemes.
Similarly, be aware that the resource brokering at this "network layer" is
funcitonally similar to the resource brokering considered at other layers (TSV,
RTG) and try to share your ideas as well as learn from others' work.
-
Stephen Farrell: Discuss [2012-12-12 07:23]:
To be honest, I'm not sure if these are easy or hard questions,
but that should become clear quickly as we discuss 'em;-)
(1) There are lots of places where zero or more child
elements are allowed, but no semantics is described for that
syntactically valid choice (e.g. 5.1.5.2). I don't get why
this is ok - can you explain? If it is, be good to say why
in the spec. If its not ok, then I guess that needs fixing.
(2) 5.1.5.4 - can the conferenceid attribute value be
sensitive? i.e. is confidentiality likely to be required for
this in transit, or obfuscation or masking of the value so
the MRB doesn't get it? Or is that just not a problem?
(3) Which part wins (i.e. is normative) if there are
differences, the schema or the descriptive text in earlier
sections? I noticed this because there is a fair amount of
duplication (thus maybe making such errors more likely) and
e.g. 5.1.5.20 doesn't state the name of the single attribute.
(4) 5.1.5.21 - where can I find a list of keying-mechanisms
that could be supported? If I cannot, then how do I get
interop with this element? (Same for 5.2.5.1.2.8 and
5.2.5.1.3.8)
-
Stephen Farrell: Discuss [2012-12-12 07:23]:
To be honest, I'm not sure if these are easy or hard questions,
but that should become clear quickly as we discuss 'em;-)
(1) There are lots of places where zero or more child
elements are allowed, but no semantics is described for that
syntactically valid choice (e.g. 5.1.5.2). I don't get why
this is ok - can you explain? If it is, be good to say why
in the spec. If its not ok, then I guess that needs fixing.
(2) 5.1.5.4 - can the conferenceid attribute value be
sensitive? i.e. is confidentiality likely to be required for
this in transit, or obfuscation or masking of the value so
the MRB doesn't get it? Or is that just not a problem?
(3) Which part wins (i.e. is normative) if there are
differences, the schema or the descriptive text in earlier
sections? I noticed this because there is a fair amount of
duplication (thus maybe making such errors more likely) and
e.g. 5.1.5.20 doesn't state the name of the single attribute.
(4) 5.1.5.21 - where can I find a list of keying-mechanisms
that could be supported? If I cannot, then how do I get
interop with this element? (Same for 5.2.5.1.2.8 and
5.2.5.1.3.8)
-
Stephen Farrell: Comment [2012-12-12 07:23]:
general - Using fewer words in a spec is better than more;
this draft doesn't do that. Not worth fixing now since it'd
be a huge job, but this could be a lot shorter and it'd IMO
have been clearer had that been the case.
abstract, intro: these are a bit opaque and assume the reader
knows what problem is being solved. You could usefully
clarify that.
5.1.2 - says that mrbpublish has zero or more of...version,
which MUST be present? And what would having two versions
look like or mean in an XML document? I think in this case
the additional words are getting in the way of clarity.
5.1.3 - so an empty mrbrequest is valid it seems, I hope you
tell me what that means somewhere:-)
5.1.3.1 - why MUST seqnumber start at 1? And does "start"
mean from 1st boot or every reboot? What happens if an
implementation's internal counter wraps around or is that not
allowed somehow? That's often IMO a bad plan as it allows for
guessing message field values which can open up
vulnerabilities. No idea if that applies here but generally
its better to start random IMO. (<seq> in 5.2.3 is handled
this way.)
5.1.3.1 - seqnumber description refers to session id but
sessions have not been described so far. (Two comments above
also apply to 5.1.5)
5.1.4 - last para - this is confusing, you say the media
server MAY include this if requested values are
uncacceptable. That sounds like it ought really be a MUST or
else the condition ("unacceptable values") should be an
example.
5.1.5.14 - I have no idea why country codes are relevant
here, but I guess its some convention that's known to RAI
folks. Might be worth explaining as it was surprising to this
reader.
5.1.5.15 - What is "HTTS"? Are you missing a P?
5.2.2.1 last para - what "lease" do you mean here? Do you at
least need a forward ref to 5.2.3?
5.2.5.1.1.1 - too many levels of TOC IMO, could be seen as a
sign that there's something wrong here with the writing.
5.2.5.1.1 - be good to expand IVR on first use
-
Stephen Farrell: Comment [2012-12-12 07:23]:
general - Using fewer words in a spec is better than more;
this draft doesn't do that. Not worth fixing now since it'd
be a huge job, but this could be a lot shorter and it'd IMO
have been clearer had that been the case.
abstract, intro: these are a bit opaque and assume the reader
knows what problem is being solved. You could usefully
clarify that.
5.1.2 - says that mrbpublish has zero or more of...version,
which MUST be present? And what would having two versions
look like or mean in an XML document? I think in this case
the additional words are getting in the way of clarity.
5.1.3 - so an empty mrbrequest is valid it seems, I hope you
tell me what that means somewhere:-)
5.1.3.1 - why MUST seqnumber start at 1? And does "start"
mean from 1st boot or every reboot? What happens if an
implementation's internal counter wraps around or is that not
allowed somehow? That's often IMO a bad plan as it allows for
guessing message field values which can open up
vulnerabilities. No idea if that applies here but generally
its better to start random IMO. (<seq> in 5.2.3 is handled
this way.)
5.1.3.1 - seqnumber description refers to session id but
sessions have not been described so far. (Two comments above
also apply to 5.1.5)
5.1.4 - last para - this is confusing, you say the media
server MAY include this if requested values are
uncacceptable. That sounds like it ought really be a MUST or
else the condition ("unacceptable values") should be an
example.
5.1.5.14 - I have no idea why country codes are relevant
here, but I guess its some convention that's known to RAI
folks. Might be worth explaining as it was surprising to this
reader.
5.1.5.15 - What is "HTTS"? Are you missing a P?
5.2.2.1 last para - what "lease" do you mean here? Do you at
least need a forward ref to 5.2.3?
5.2.5.1.1.1 - too many levels of TOC IMO, could be seen as a
sign that there's something wrong here with the writing.
5.2.5.1.1 - be good to expand IVR on first use
-
Martin Stiemerling: Comment [2012-12-10 12:10]:
Section 5.1.5.15., paragraph 4:
> <file-transfer-mode>: has two attributes, 'name' and 'package'.
> The 'name' attribute provides the scheme name of the protocol that
> can be used for file transfer (e.g., "HTTP", "RTSP", etc.): the
I do not know how RTSP is used for file transfer. The reference to RTSP is odd in this place.
-
Martin Stiemerling: Comment [2012-12-10 12:10]:
Section 5.1.5.15., paragraph 4:
> <file-transfer-mode>: has two attributes, 'name' and 'package'.
> The 'name' attribute provides the scheme name of the protocol that
> can be used for file transfer (e.g., "HTTP", "RTSP", etc.): the
I do not know how RTSP is used for file transfer. The reference to RTSP is
odd in this place.
-
Pete Resnick: Comment [2012-12-12 20:38]:
Overlapping Stephen a bit:
5.1.2:
The <mrbpublish> element has the following child elements, only one
of which is allowed to occur in a request.
First of all, referring to an <mrbpublish> "request" is confusing. Don't you instead mean "message"? Also, (and my IESG colleagues will surely drop dead of heart attacks to hear me say it), the word "allowed" sounds like it would be an interoperability problem if someone attempted to put multiple children in an <mrbpublish> message; that sounds like it should say instead:
The <mrbpublish> element has the following child elements, and there
MUST NOT be more than one such child element in any <mrbpublish>
message:
Did I get that right? (I wasn't clear on whether you could only have one child at all, or if you were allowed multiple occurrences of one *kind* of child.)
5.1.3.1 (as well as other uses of seqnumber):
The first subscription MUST have 1 as
'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value.
Really? Would any non-zero starting value suffice? Could it simply be any larger seqnumber rather than incrementing by 1? I'm basically wondering if the MUSTs are really all that MUSTy.
5.1.5.20:
The <media-server-address> element has a single attribute.
OK, I give up: What is it? (OK, I know, it's the URI, but that is written oddly.)
13 (for example, 13.1):
Person and email address to contact for further information: IETF,
MEDIACTRL working group, (mediactrl@ietf.org), Chris Boulton
(chris@ns-technologies.com).
For a registration from an IETF RFC, is a person and email address really required? Seems like the potential for this to become out of date (WG is shut down, Chris moves on, etc), and it seems like "IETF" would suffice.
-
Pete Resnick: Comment [2012-12-12 20:38]:
Overlapping Stephen a bit:
5.1.2:
The <mrbpublish> element has the following child elements, only one
of which is allowed to occur in a request.
First of all, referring to an <mrbpublish> "request" is confusing. Don't you
instead mean "message"? Also, (and my IESG colleagues will surely drop dead of
heart attacks to hear me say it), the word "allowed" sounds like it would be an
interoperability problem if someone attempted to put multiple children in an
<mrbpublish> message; that sounds like it should say instead:
The <mrbpublish> element has the following child elements, and there
MUST NOT be more than one such child element in any <mrbpublish>
message:
Did I get that right? (I wasn't clear on whether you could only have one child
at all, or if you were allowed multiple occurrences of one *kind* of child.)
5.1.3.1 (as well as other uses of seqnumber):
The first subscription MUST have 1 as
'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value.
Really? Would any non-zero starting value suffice? Could it simply be any
larger seqnumber rather than incrementing by 1? I'm basically wondering if the
MUSTs are really all that MUSTy.
5.1.5.20:
The <media-server-address> element has a single attribute.
OK, I give up: What is it? (OK, I know, it's the URI, but that is written
oddly.)
13 (for example, 13.1):
Person and email address to contact for further information: IETF,
MEDIACTRL working group, (mediactrl@ietf.org), Chris Boulton
(chris@ns-technologies.com).
For a registration from an IETF RFC, is a person and email address really
required? Seems like the potential for this to become out of date (WG is shut
down, Chris moves on, etc), and it seems like "IETF" would suffice.
-
Stewart Bryant: Comment [2012-12-13 07:19]:
I have reviewed this document for impact on the routing system and as far as I can tell there is no impact. I therefore have no objection to its publication.
-
Stewart Bryant: Comment [2012-12-13 07:19]:
I have reviewed this document for impact on the routing system and as far as I
can tell there is no impact. I therefore have no objection to its publication.
-
Sean Turner: Comment [2012-12-12 18:40]:
1) subscription says can seer or more of the following child elements and then it says they're all MAY so can subscription be empty or must at least one of the child elements be present? If none of the child elements are present should subscription just be omitted?
Actually this is true for a bunch of things.
2) Support Stephen's discuss on #4.
-
Sean Turner: Comment [2012-12-12 18:40]:
1) subscription says can seer or more of the following child elements and then
it says they're all MAY so can subscription be empty or must at least one of
the child elements be present? If none of the child elements are present
should subscription just be omitted?
Actually this is true for a bunch of things.
2) Support Stephen's discuss on #4.
-
Russ Housley: Comment [2012-04-24 02:29]:
Please consider the editorial comments from the Gen-ART Review by
Pete McCann on 24-Apr-2012. The review can be found at:
http://www.ietf.org/mail-archive/web/gen-art/current/msg07389.html
-
Russ Housley: Comment [2012-04-24 02:29]:
Please consider the editorial comments from the Gen-ART Review by
Pete McCann on 24-Apr-2012. The review can be found at:
http://www.ietf.org/mail-archive/web/gen-art/current/msg07389.html
-
Adrian Farrel: Comment [2012-12-12 11:08]:
I have no objection to the publication of this document that I found
readable.
The document title speaks of "redundancy" but the document is scoped to
"semi-redundant services" and makes a point of stressing how DHCPv6 does
not offer a redundancy protocol. It might be helpful to tune the title
to match the document.
-
Adrian Farrel: Comment [2012-12-12 11:08]:
I have no objection to the publication of this document that I found
readable.
The document title speaks of "redundancy" but the document is scoped to
"semi-redundant services" and makes a point of stressing how DHCPv6 does
not offer a redundancy protocol. It might be helpful to tune the title
to match the document.
-
Stephen Farrell: Comment [2012-12-09 16:25]:
Thanks for the exensive editorial work.
-
Stephen Farrell: Comment [2012-12-09 16:25]:
Thanks for the exensive editorial work.
-
Martin Stiemerling: Comment [2012-04-24 01:48]:
- There are too many places where the spelling isn't correct, i.e., some native reader should proof read it!
- I'm not sure how useful this document is for network operators, but if the WG is fine with the draft, I won't object.
The draft did not add much for me on how to configure DHCPv6 servers to have some level of redundancy.
-
Martin Stiemerling: Comment [2012-04-24 01:48]:
- There are too many places where the spelling isn't correct, i.e., some native
reader should proof read it! - I'm not sure how useful this document is for
network operators, but if the WG is fine with the draft, I won't object. The
draft did not add much for me on how to configure DHCPv6 servers to have some
level of redundancy.
-
Benoit Claise: Comment [2012-12-12 06:51]:
Nicely written. Thanks;
Minor editorial comments: please expand DUID and PD
Regards, Benoit
-
Benoit Claise: Comment [2012-12-12 06:51]:
Nicely written. Thanks;
Minor editorial comments: please expand DUID and PD
Regards, Benoit
-
Brian Haberman: Comment [2012-04-24 13:24]:
I have a few comments/questions on this draft, all of which are non-blocking.
1. I lied. I won't be sending along a list of editorial issues... There are a ton of linguistic/editorial issues that I don't have time to itemize. I strongly suggest an editorial pass through this document by another WG participant to clean this up.
2. In bullet #3 of section 2, the second part talks about getting configuration information or options. Is this information obtained via Stateful DHCPv6, Stateless DHCPv6, or a combination of the two?
3. I cannot cleanly parse the first sentence of bullet #4 in section 2.
4. Does the last paragraph of section 2 really refer to a DHCPv6 *redundancy* protocol being published?
5. Section 2.2 says that end-hosts will not use DHCP prefix delegation. Do you have considerations to offer for when they do make such requests?
6. This question may be due to a hole in my knowledge of DHCPv6, but iss there really any difference in the two scenarios described in sections 4.1 and 4.2, other than a possible difference in the prefix length?
7. In section 5, bullet #1 discusses the need for each DHCPv6 server to use the same allocation algorithm to ensure that each IPv6 address is only allocated to a single client. Does this require every DHCPv6 server to see all requests? If so, would that be feasible in the two target deployment scenarios?
-
Brian Haberman: Comment [2012-04-24 13:24]:
I have a few comments/questions on this draft, all of which are non-blocking.
1. I lied. I won't be sending along a list of editorial issues... There are a
ton of linguistic/editorial issues that I don't have time to itemize. I
strongly suggest an editorial pass through this document by another WG
participant to clean this up.
2. In bullet #3 of section 2, the second part talks about getting configuration
information or options. Is this information obtained via Stateful DHCPv6,
Stateless DHCPv6, or a combination of the two?
3. I cannot cleanly parse the first sentence of bullet #4 in section 2.
4. Does the last paragraph of section 2 really refer to a DHCPv6 *redundancy*
protocol being published?
5. Section 2.2 says that end-hosts will not use DHCP prefix delegation. Do you
have considerations to offer for when they do make such requests?
6. This question may be due to a hole in my knowledge of DHCPv6, but iss there
really any difference in the two scenarios described in sections 4.1 and 4.2,
other than a possible difference in the prefix length?
7. In section 5, bullet #1 discusses the need for each DHCPv6 server to use the
same allocation algorithm to ensure that each IPv6 address is only allocated to
a single client. Does this require every DHCPv6 server to see all requests?
If so, would that be feasible in the two target deployment scenarios?
-
Robert Sparks: Comment [2012-04-24 12:39]:
I don't object to publishing this document as BCP (so this is not a DISCUSS), but I would like to hear why this intended status was chosen over Informational. The document says it does not address a standards based solution (so it's not the kind of document described in the first paragraph of section 5.1 of RFC2026). It's not setting policy or defining the operation of an IETF function. It seems instead to say "here's a way you can do this thing, and here are some things to consider if you choose to do it". That really seems like an Informational document. What's in here that makes Informational the wrong choice? (Please consider paragraph four of section 5.1 in RFC2026 when answering that.)
Thinking forward, publishing this as BCP may make work harder for the IETF if/when it does produce a standard mechanism to address this problem.
-
Robert Sparks: Comment [2012-04-24 12:39]:
I don't object to publishing this document as BCP (so this is not a DISCUSS),
but I would like to hear why this intended status was chosen over
Informational. The document says it does not address a standards based solution
(so it's not the kind of document described in the first paragraph of section
5.1 of RFC2026). It's not setting policy or defining the operation of an IETF
function. It seems instead to say "here's a way you can do this thing, and here
are some things to consider if you choose to do it". That really seems like an
Informational document. What's in here that makes Informational the wrong
choice? (Please consider paragraph four of section 5.1 in RFC2026 when
answering that.)
Thinking forward, publishing this as BCP may make work harder for the IETF
if/when it does produce a standard mechanism to address this problem.
-
Adrian Farrel: Comment [2012-12-11 09:25]:
I am ballotting "Yes" on this document on the assumption that the
changes already suggested by Barry will be made. Additionally,
the resolution of the word "leadership" in the paragraph of
Section 1 as suggested by Pete Resnick.
The following Comments are provided as observations to the authors
and neither require action nor further discussion.
---
Note that the document title still includes the sensitive word
"leadership".
---
The last sentence of the Abstract is a little vague.
This
document updates RFC 3777 and clarifies those situations.
s/and clarifies/to clarify/
s/those situations/the rules as they apply to all members of the IAB,
IESG, and IAOC./
---
Table of contents bugbear alert!
Spending one page of a 4 page document on the ToC, is (IMHO) a waste of
e-paper.
---
Section 1 para 2
That said, it would be bad to eliminate people who have the
experience necessary to understand the IETF process: those
individuals can bring a broader perspective to the nominating
committee and will help ensure that the people it selects are better
prepared to fulfill the roles.
I completely agree with the sentiment of this paragraph, but I don't see
what relevance it has in this document. In fact, it seems that the point
of this document is to deliberately exclude some people with that
experience.
You could either delete this paragraph entirely (why not?) or
restructure the section so that this point is made before the points
about self-selection (i.e., the intention is to include as many with
experience as is possible, but to exclude those who are already
sitting).
---
Section 1 para 3
This document
updates RFC 3777 and clarifies those situations,
Comment as for Abstract.
---
Section 1
In order to allow the largest reasonable list of potential nominating
committee members, RFC 3777 does not exclude participation from
working group chairs, IRTF research group chairs, members of
directorates and special review teams, and members of other advisory
bodies.
I think the reason for non-exclusion is that it is not felt that the
inclusion compromises the self-selection concerns. To say "in order to
allow the largest reasonable..." questions the motives of the authors
and introduces consideration of "reasonable".
Why not delete the first clause?
---
Section 2
may not volunteer to serve
as voting members of the nominating committee
Do you mean "may not volunteer" or "may not be selected"?
That is (pedantically), putting your name forward is not something that
we can control.
-
Adrian Farrel: Comment [2012-12-11 09:25]:
I am ballotting "Yes" on this document on the assumption that the
changes already suggested by Barry will be made. Additionally,
the resolution of the word "leadership" in the paragraph of
Section 1 as suggested by Pete Resnick.
The following Comments are provided as observations to the authors
and neither require action nor further discussion.
---
Note that the document title still includes the sensitive word
"leadership".
---
The last sentence of the Abstract is a little vague.
This
document updates RFC 3777 and clarifies those situations.
s/and clarifies/to clarify/
s/those situations/the rules as they apply to all members of the IAB,
IESG, and IAOC./
---
Table of contents bugbear alert!
Spending one page of a 4 page document on the ToC, is (IMHO) a waste of
e-paper.
---
Section 1 para 2
That said, it would be bad to eliminate people who have the
experience necessary to understand the IETF process: those
individuals can bring a broader perspective to the nominating
committee and will help ensure that the people it selects are better
prepared to fulfill the roles.
I completely agree with the sentiment of this paragraph, but I don't see
what relevance it has in this document. In fact, it seems that the point
of this document is to deliberately exclude some people with that
experience.
You could either delete this paragraph entirely (why not?) or
restructure the section so that this point is made before the points
about self-selection (i.e., the intention is to include as many with
experience as is possible, but to exclude those who are already
sitting).
---
Section 1 para 3
This document
updates RFC 3777 and clarifies those situations,
Comment as for Abstract.
---
Section 1
In order to allow the largest reasonable list of potential nominating
committee members, RFC 3777 does not exclude participation from
working group chairs, IRTF research group chairs, members of
directorates and special review teams, and members of other advisory
bodies.
I think the reason for non-exclusion is that it is not felt that the
inclusion compromises the self-selection concerns. To say "in order to
allow the largest reasonable..." questions the motives of the authors
and introduces consideration of "reasonable".
Why not delete the first clause?
---
Section 2
may not volunteer to serve
as voting members of the nominating committee
Do you mean "may not volunteer" or "may not be selected"?
That is (pedantically), putting your name forward is not something that
we can control.
-
Stephen Farrell: Comment [2012-12-09 16:36]:
- I agree the the "leader" phrases in the intro are
better replaced. I guess Stewart's discuss relates to
the first paragraph and I support replacing that. However,
there is also a "lower levels" mention in the last para
of section that should go, I'd suggest:
NEW:
In order to allow the largest reasonable list of potential
nominating committee members, we do not want to exclude
participation from working group chairs, IRTF research
group chairs, members of directorates and special review
teams, and members of other advisory bodies.
-
Stephen Farrell: Comment [2012-12-09 16:36]:
- I agree the the "leader" phrases in the intro are
better replaced. I guess Stewart's discuss relates to
the first paragraph and I support replacing that. However,
there is also a "lower levels" mention in the last para
of section that should go, I'd suggest:
NEW:
In order to allow the largest reasonable list of potential
nominating committee members, we do not want to exclude
participation from working group chairs, IRTF research
group chairs, members of directorates and special review
teams, and members of other advisory bodies.
-
Benoit Claise: Comment [2012-12-12 01:33]:
I read http://trac.tools.ietf.org/group/iesg/trac/wiki/PendingUpdate
- OLD
Abstract
RFC 3777 specifies that "sitting members" of the IAB and IESG "may
not volunteer to serve on the nominating commitee". Since that
document was written the IAOC was formed, and that body is not
covered by RFC 3777.
NEW
Abstract
RFC 3777 specifies that "sitting members" of the IAB and IESG "may
not volunteer to serve on the nominating commitee". Since that
document was written before the IAOC was formed, that body is not
covered by RFC 3777.
Actually after reading it many times and reading the similar sentence in section 1, I finally understood: you're missing a coma for my non English native speaker background ;-)
So the new proposal.
NEW-NEW
Abstract
RFC 3777 specifies that "sitting members" of the IAB and IESG "may
not volunteer to serve on the nominating commitee". Since that
document was written, the IAOC was formed, and that body is not
covered by RFC 3777.
-
Section 1
those individuals can bring
a broader perspective to the nominating committee and will help
ensure that the people it selects are better prepared to fulfill the
roles.
better than what?
Isn't better to say?
those individuals can bring
a broader perspective to the nominating committee and will help
ensure that the people it selects are best prepared to fulfill the
roles.
-
As I mentioned in a different thread, I would keep the ToC
-
Benoit Claise: Comment [2012-12-12 01:33]:
I read http://trac.tools.ietf.org/group/iesg/trac/wiki/PendingUpdate
- OLD
Abstract
RFC 3777 specifies that "sitting members" of the IAB and IESG "may
not volunteer to serve on the nominating commitee". Since that
document was written the IAOC was formed, and that body is not
covered by RFC 3777.
NEW
Abstract
RFC 3777 specifies that "sitting members" of the IAB and IESG "may
not volunteer to serve on the nominating commitee". Since that
document was written before the IAOC was formed, that body is not
covered by RFC 3777.
Actually after reading it many times and reading the similar sentence in
section 1, I finally understood: you're missing a coma for my non English
native speaker background ;-) So the new proposal.
NEW-NEW
Abstract
RFC 3777 specifies that "sitting members" of the IAB and IESG "may
not volunteer to serve on the nominating commitee". Since that
document was written, the IAOC was formed, and that body is not
covered by RFC 3777.
-
Section 1
those individuals can bring
a broader perspective to the nominating committee and will help
ensure that the people it selects are better prepared to fulfill the
roles.
better than what?
Isn't better to say?
those individuals can bring
a broader perspective to the nominating committee and will help
ensure that the people it selects are best prepared to fulfill the
roles.
-
As I mentioned in a different thread, I would keep the ToC
-
Stewart Bryant: Comment [2012-12-13 07:07]:
Thank you for addressing my concern.
-
Stewart Bryant: Comment [2012-12-13 07:07]:
Thank you for addressing my concern.
-
Sean Turner: Comment [2012-12-11 05:16]:
Based on Barry's tentative -06 no comments from me.
-
Sean Turner: Comment [2012-12-11 05:16]:
Based on Barry's tentative -06 no comments from me.
-
Russ Housley: Comment [2012-12-12 15:02]:
Please consider the comments raised in the Gen-ART Review by
Suresh Krishnan on 11-Dec-2012. You can find the review here:
http://www.ietf.org/mail-archive/web/gen-art/current/msg07984.html
-
Russ Housley: Comment [2012-12-12 15:02]:
Please consider the comments raised in the Gen-ART Review by
Suresh Krishnan on 11-Dec-2012. You can find the review here:
http://www.ietf.org/mail-archive/web/gen-art/current/msg07984.html
-
Adrian Farrel: Comment [2012-12-12 12:25]:
I believe this is important work and I want to see the experimentation
progress, and feedback should be gathered to hopefully move this or
similar work onto the Standards Track.
So I am taking the peculiar position of balloting "Yes" while supporting
a Discuss from another AD.
---
I agree with Brian that this Experiment does not update 3390 and 5681,
but that were it to move to the Standards Track at some point, it would
update those RFCs.
I believe this is a simple editorial change.
---
I would really like that Section 12 enhances...
Further experiments are required before a larger initial window shall
be enabled by default in the Internet.
...with...
Larger window sizes MUST NOT be enabled by default in the Internet.
-
Adrian Farrel: Comment [2012-12-12 12:25]:
I believe this is important work and I want to see the experimentation
progress, and feedback should be gathered to hopefully move this or
similar work onto the Standards Track.
So I am taking the peculiar position of balloting "Yes" while supporting
a Discuss from another AD.
---
I agree with Brian that this Experiment does not update 3390 and 5681,
but that were it to move to the Standards Track at some point, it would
update those RFCs.
I believe this is a simple editorial change.
---
I would really like that Section 12 enhances...
Further experiments are required before a larger initial window shall
be enabled by default in the Internet.
...with...
Larger window sizes MUST NOT be enabled by default in the Internet.
-
Stephen Farrell: Comment [2012-12-10 17:55]:
- section 3, 2nd para says: "A larger initial window will
incentivize applications to use fewer concurrent TCP
connections." I don't see how that sentence follows from
those before it. Surely the logical conclusion from the
text so far is that browsers or other applications will
want to benefit from being (more) unfair to other
applications?
- section 12, para 2: would it be an idea to say that
implementers SHOULD provide a way to roll back deployment
of this change or that this is currently only suited for
applications where such a roll-back is possible? You
already say implentations SHOULD monitor and turn this off
sometimes, but that's different, it could be that the
implementation cannot detect the problem and it could also
be that some applications are such that e.g. s/w update is
not widely supported for some reason (perhaps sensors that
use TCP or something).
- If there were a de-facto sockopt for turning this on or
off that might be useful to note.
- Would running over TLS affect any of the results cited?
Either way, that would be useful to note since there are
proposals that HTTP/2.0 have TLS always turned on.
- Just wondering:-) Has anyone considered whether or not
this might make DPI easier and/or interact with traffic
analysis of ciphertext? (I expect the answer to be "no"
but would be interested if not.)
-
Stephen Farrell: Comment [2012-12-10 17:55]:
- section 3, 2nd para says: "A larger initial window will
incentivize applications to use fewer concurrent TCP
connections." I don't see how that sentence follows from
those before it. Surely the logical conclusion from the
text so far is that browsers or other applications will
want to benefit from being (more) unfair to other
applications?
- section 12, para 2: would it be an idea to say that
implementers SHOULD provide a way to roll back deployment
of this change or that this is currently only suited for
applications where such a roll-back is possible? You
already say implentations SHOULD monitor and turn this off
sometimes, but that's different, it could be that the
implementation cannot detect the problem and it could also
be that some applications are such that e.g. s/w update is
not widely supported for some reason (perhaps sensors that
use TCP or something).
- If there were a de-facto sockopt for turning this on or
off that might be useful to note.
- Would running over TLS affect any of the results cited?
Either way, that would be useful to note since there are
proposals that HTTP/2.0 have TLS always turned on.
- Just wondering:-) Has anyone considered whether or not
this might make DPI easier and/or interact with traffic
analysis of ciphertext? (I expect the answer to be "no"
but would be interested if not.)
-
Ralph Droms: Discuss [2012-12-12 18:53]:
In my opinion, it's not appropriate to specify explicit changes to a PS
document in an Experimental document and show that the
Experimental document updates the PS document. This document
is not making updates to the PS document that are to be added
to every implementation.
I will clear if the "Updates" metadata is dropped, and recommend that
some additional clarifying text be added that the modifications
described in this document may have a deleterious effect on other
Internet traffic and should be enabled only in controlled experiments.
-
Ralph Droms: Discuss [2012-12-12 18:53]:
In my opinion, it's not appropriate to specify explicit changes to a PS
document in an Experimental document and show that the
Experimental document updates the PS document. This document
is not making updates to the PS document that are to be added
to every implementation.
I will clear if the "Updates" metadata is dropped, and recommend that
some additional clarifying text be added that the modifications
described in this document may have a deleterious effect on other
Internet traffic and should be enabled only in controlled experiments.
-
Benoit Claise: Comment [2012-12-13 05:47]:
I'm pleased to see that you realized some experiments, and that you included the results in this document.
I'm with Adrian on his point:
I would really like that Section 12 enhances...
Further experiments are required before a larger initial window shall
be enabled by default in the Internet.
...with...
Larger window sizes MUST NOT be enabled by default in the Internet.
-
Benoit Claise: Comment [2012-12-13 05:47]:
I'm pleased to see that you realized some experiments, and that you included
the results in this document. I'm with Adrian on his point:
I would really like that Section 12 enhances...
Further experiments are required before a larger initial window shall
be enabled by default in the Internet.
...with...
Larger window sizes MUST NOT be enabled by default in the Internet.
-
Stewart Bryant: Comment [2012-12-12 06:53]:
I agree with the issues that Brian raises in his Discuss.
-
Stewart Bryant: Comment [2012-12-12 06:53]:
I agree with the issues that Brian raises in his Discuss.
-
Brian Haberman: Discuss [2012-12-12 05:51]:
I am happy to see this work progressing, but I have one concern that we should discuss...
I am troubled by seeing an Experimental document updating Standards Tracks RFCs (3390, 5681). If the WG really believes this work will improve TCP, then it should be a Proposed Standard. However, it is obvious that this proposal needs some experimentation to determine its fitness level. Given that, I would propose that this document NOT update 3390 and 5681. As Wes pointed out, we have precedence to allow a PS follow-on (if it is deemed useful) to this work to update the current standards track documents. Quoting Wes:
"If we want to use the 2414 -> 3390 example of how this was
done in the past, 3390 updates the standards track (2581)
and is on the standards track itself.
2414 was its experimental predecessor and does not update
2001, which would have been the relevant standards track spec
at the time."
So, I would propose dropping the Updates metadata and explicitly mention in the body of the document those functions/features that differ from 3390 and 5681.
-
Brian Haberman: Discuss [2012-12-12 05:51]:
I am happy to see this work progressing, but I have one concern that we should
discuss...
I am troubled by seeing an Experimental document updating Standards Tracks RFCs
(3390, 5681). If the WG really believes this work will improve TCP, then it
should be a Proposed Standard. However, it is obvious that this proposal needs
some experimentation to determine its fitness level. Given that, I would
propose that this document NOT update 3390 and 5681. As Wes pointed out, we
have precedence to allow a PS follow-on (if it is deemed useful) to this work
to update the current standards track documents. Quoting Wes:
"If we want to use the 2414 -> 3390 example of how this was
done in the past, 3390 updates the standards track (2581)
and is on the standards track itself.
2414 was its experimental predecessor and does not update
2001, which would have been the relevant standards track spec
at the time."
So, I would propose dropping the Updates metadata and explicitly mention in the
body of the document those functions/features that differ from 3390 and 5681.
-
Robert Sparks: Discuss [2012-12-12 09:09]:
(Based on a last call question from Magnus Westerlund)
Can the document point to studies on the impact on queue times
at intermediaries, and discuss how likely the transient spikes
in delays this might introduce are to become large enough to cause
real-time traffic to be held long enough to make its delivery
useless? (For many RTP uses, a packet that arrives too late is
discarded - the opportunity to render it has passed).
-
Robert Sparks: Discuss [2012-12-12 09:09]:
(Based on a last call question from Magnus Westerlund)
Can the document point to studies on the impact on queue times
at intermediaries, and discuss how likely the transient spikes
in delays this might introduce are to become large enough to cause
real-time traffic to be held long enough to make its delivery
useless? (For many RTP uses, a packet that arrives too late is
discarded - the opportunity to render it has passed).
-
Robert Sparks: Comment [2012-12-12 09:09]:
Magnus asked several questions during last call that have not yet
received a response.
--
It's not clear how this safety requirement will actually help
in many circumstances:
It is important also to take into account hosts that do not implement
a larger initial window. Furthermore, non-TCP traffic (such as VoIP)
should be monitored as well. If users observe any significant
deterioration of performance, they SHOULD fall back to an initial
window as allowed by RFC 3390 for safety reasons. An increased
initial window MUST NOT be turned on by default on systems without
such monitoring capabilities.
Does "systems" mean "hosts"? If so, the host using the larger initial
window is not going to see the harm its doing to its neighbor's real-time
streams? Or is the intent to restrict turning this on by default to hosts
in environements that have comprehensive (system) monitoring capabilities,
and the control mechanisms in place to affect the configuration of a host
when it is damaging its neighbors? Either way, please make the reqirement
more clear and be explicit about the limitations on how it will protect
real-time traffic.
--
In section 12, you require that a sender SHOULD cache information about whether
the larger initial window has created problems, and SHOULD not use the larger
window on new connnections that look like they might cause the same problems,
but then call out the design of such a cache (and the heuristic for whether a
new connection attempt will cause problems) as needing further experimentation.
That seems to reduce to "implementations SHOULD experiment". Since this is an
experiment in the first place, why not make those MUSTs (or better, encourage
the experimentation with explicit prose?)
-
Robert Sparks: Comment [2012-12-12 09:09]:
Magnus asked several questions during last call that have not yet
received a response.
--
It's not clear how this safety requirement will actually help
in many circumstances:
It is important also to take into account hosts that do not implement
a larger initial window. Furthermore, non-TCP traffic (such as VoIP)
should be monitored as well. If users observe any significant
deterioration of performance, they SHOULD fall back to an initial
window as allowed by RFC 3390 for safety reasons. An increased
initial window MUST NOT be turned on by default on systems without
such monitoring capabilities.
Does "systems" mean "hosts"? If so, the host using the larger initial
window is not going to see the harm its doing to its neighbor's real-time
streams? Or is the intent to restrict turning this on by default to hosts
in environements that have comprehensive (system) monitoring capabilities,
and the control mechanisms in place to affect the configuration of a host
when it is damaging its neighbors? Either way, please make the reqirement
more clear and be explicit about the limitations on how it will protect
real-time traffic.
--
In section 12, you require that a sender SHOULD cache information about whether
the larger initial window has created problems, and SHOULD not use the larger
window on new connnections that look like they might cause the same problems,
but then call out the design of such a cache (and the heuristic for whether a
new connection attempt will cause problems) as needing further experimentation.
That seems to reduce to "implementations SHOULD experiment". Since this is an
experiment in the first place, why not make those MUSTs (or better, encourage
the experimentation with explicit prose?)
-
Adrian Farrel: Comment [2012-12-12 05:43]:
I have no objection to the publication of this document. I have a
concern that the security considerations may need more work. For
example, ACLs seem to rely on well-known IP addresses. Those
addresses are often manually configured and the synchronisation during
renumbering is surely a vulnerability. I am sure there are plenty of
other issues that should be considered.
===
I also have some petty nits that you might want to address to improve
the document.
---
I would like it if for clarity the document title could reflect the
limitation of this document to entreprise networks.
---
ULA is used without expansion
---
Section 2.7
It is quite common practice that some such
addresses will have no corresponding DNS entry.
Jane Austen and I would like to know whether you mean "quite" in the
correct English sense as "completely", or in the modern sense of
"relatively" or "somewhat". Actually, I suggest you delete the word.
---
Section 3
The hanging rhetorical question in the first paragraph is disconcerting.
Is this a question that someone doing renumbering should consider, or is
it targeted at the reader of the document? Is the word "Alternatively"
really appropriate since it suggests that the choice is between telling
the NEs and NMS, and not disrupting the network.
---
Section 3
therefore this situation
should be avoided except for very small networks
I presume you do not mean the situation of renumbering such networks!
But how do we avoid the situation of networks that are numbered in the
way you describe? For most existing networks, the only way to avoid the
situation is to renumber! So I assume that you are giving advice to
people deploying new equipment and networks - please make this clear.
-
Adrian Farrel: Comment [2012-12-12 05:43]:
I have no objection to the publication of this document. I have a
concern that the security considerations may need more work. For
example, ACLs seem to rely on well-known IP addresses. Those
addresses are often manually configured and the synchronisation during
renumbering is surely a vulnerability. I am sure there are plenty of
other issues that should be considered.
===
I also have some petty nits that you might want to address to improve
the document.
---
I would like it if for clarity the document title could reflect the
limitation of this document to entreprise networks.
---
ULA is used without expansion
---
Section 2.7
It is quite common practice that some such
addresses will have no corresponding DNS entry.
Jane Austen and I would like to know whether you mean "quite" in the
correct English sense as "completely", or in the modern sense of
"relatively" or "somewhat". Actually, I suggest you delete the word.
---
Section 3
The hanging rhetorical question in the first paragraph is disconcerting.
Is this a question that someone doing renumbering should consider, or is
it targeted at the reader of the document? Is the word "Alternatively"
really appropriate since it suggests that the choice is between telling
the NEs and NMS, and not disrupting the network.
---
Section 3
therefore this situation
should be avoided except for very small networks
I presume you do not mean the situation of renumbering such networks!
But how do we avoid the situation of networks that are numbered in the
way you describe? For most existing networks, the only way to avoid the
situation is to renumber! So I assume that you are giving advice to
people deploying new equipment and networks - please make this clear.
-
Ralph Droms: Comment [2012-12-13 03:26]:
I'm entering Abstain for this document, because I think it has many
flaws, some important and some less important, but still may be
useful.
Here are some of the problems I see in the document.
DNS, mDNS and SLP are mentioned in the context of name resolution. Is
SLP deployed widely enough to warrant mention? What about LLMNR and
uPNP?
I don't understand why ULAs are identified as somehow affecting the
use or impact of static addresses.
DHCPv6 PD should be mentioned in the context of prefix assignment.
Is it really still common practice that " printers in particular are
manually assigned a fixed address (typically an [RFC1918] address) and
that users are told to manually configure printer access using that
fixed address"?
In section 2.3, addresses assigned through DHCPv6 are considered
problematic because the address might expire, but later DHCPv6 is
suggested as a way of assigning addresses to solve renumbering of
static addresses.
I don't understand the first sentence of 2.4. Isn't the requirement
for a static address based on the need to maintain transport sessions
over VM movement (which isn't really how I understand the first
sentence).
In section 2.5, if asset management is based on MAC addresses, why are
static IP addresses an issue?
I don't understand the connection between "If [...] a particular host
is found to be generating some form of unwanted traffic, it is urgent
to be able to track back from its IP address to its physical location"
and renumbering of static addressing.
How does "using addresses under an enterprise's ULA prefix for
software licensing" solve the renumbering problem? There may be a
clue in section 2.7, where addresses assigned from ULAs are suggested
as the solution for renumbering network elements. Perhaps the bit I'm
missing is that addressing from ULAs avoids forced renumbering when
the organization prefix changes due to external causes?
In section 2.7, this claim may be true:
In any case, when network elements are renumbered, existing user
sessions may not survive, because of temporary "destination
unreachable" conditions being treated as fatal errors. This aspect
needs further investigation.
but what is its connection to renumbering static addresses?
Section 2.8 makes a valid point about the relationship between static
addresses and asset management, but goes into solution space when it
talks about DHCPv6 for configuring static addresses.
I don't understand the first paragraph of section 3.
From section 3:
4. If external prefix renumbering is required, the RFC 4192
procedure is followed.
What about renumbering required by strictly internal topology changes
in the network? I.e., I think "external" can be dropped.
-
Ralph Droms: Comment [2012-12-13 03:26]:
I'm entering Abstain for this document, because I think it has many
flaws, some important and some less important, but still may be
useful.
Here are some of the problems I see in the document.
DNS, mDNS and SLP are mentioned in the context of name resolution. Is
SLP deployed widely enough to warrant mention? What about LLMNR and
uPNP?
I don't understand why ULAs are identified as somehow affecting the
use or impact of static addresses.
DHCPv6 PD should be mentioned in the context of prefix assignment.
Is it really still common practice that " printers in particular are
manually assigned a fixed address (typically an [RFC1918] address) and
that users are told to manually configure printer access using that
fixed address"?
In section 2.3, addresses assigned through DHCPv6 are considered
problematic because the address might expire, but later DHCPv6 is
suggested as a way of assigning addresses to solve renumbering of
static addresses.
I don't understand the first sentence of 2.4. Isn't the requirement
for a static address based on the need to maintain transport sessions
over VM movement (which isn't really how I understand the first
sentence).
In section 2.5, if asset management is based on MAC addresses, why are
static IP addresses an issue?
I don't understand the connection between "If [...] a particular host
is found to be generating some form of unwanted traffic, it is urgent
to be able to track back from its IP address to its physical location"
and renumbering of static addressing.
How does "using addresses under an enterprise's ULA prefix for
software licensing" solve the renumbering problem? There may be a
clue in section 2.7, where addresses assigned from ULAs are suggested
as the solution for renumbering network elements. Perhaps the bit I'm
missing is that addressing from ULAs avoids forced renumbering when
the organization prefix changes due to external causes?
In section 2.7, this claim may be true:
In any case, when network elements are renumbered, existing user
sessions may not survive, because of temporary "destination
unreachable" conditions being treated as fatal errors. This aspect
needs further investigation.
but what is its connection to renumbering static addresses?
Section 2.8 makes a valid point about the relationship between static
addresses and asset management, but goes into solution space when it
talks about DHCPv6 for configuring static addresses.
I don't understand the first paragraph of section 3.
From section 3:
4. If external prefix renumbering is required, the RFC 4192
procedure is followed.
What about renumbering required by strictly internal topology changes
in the network? I.e., I think "external" can be dropped.
-
Pete Resnick: Discuss [2012-12-11 15:58]:
Section 2.3: I think this really needs to be expanded significantly. First of all, it is not larger sites that are the only problem in this case. Any site that wishes to have devices on its network that can be connected to from outside (whether we want to call those "servers" or "peers") has to deal with this. And TTL is not the only problem with dynamic DNS. Rather, it's also a huge failure of deployment: The tools are simply not available to configure a DNS server from the get-go to allow dynamic DNS updates out of the box for any device that wishes to employ it, and domain registrars do not have dynamic DNS updates as a standard piece of technology for their registrants. Putting the burden on a common database with DHCP is a poor way to think about this problem. I fear that description of the problem in this section will cause the gap analysis to go looking for huge site-wide solutions instead of allowing for the possibility that this is a deployment and/or operational problem with dynamic DNS instead of a problem with the lack of combined DHCP/DNS databases. I think this section is presuming a solution space and hasn't fully explored the problem space.
-
Pete Resnick: Discuss [2012-12-11 15:58]:
Section 2.3: I think this really needs to be expanded significantly. First of
all, it is not larger sites that are the only problem in this case. Any site
that wishes to have devices on its network that can be connected to from
outside (whether we want to call those "servers" or "peers") has to deal with
this. And TTL is not the only problem with dynamic DNS. Rather, it's also a
huge failure of deployment: The tools are simply not available to configure a
DNS server from the get-go to allow dynamic DNS updates out of the box for any
device that wishes to employ it, and domain registrars do not have dynamic DNS
updates as a standard piece of technology for their registrants. Putting the
burden on a common database with DHCP is a poor way to think about this
problem. I fear that description of the problem in this section will cause the
gap analysis to go looking for huge site-wide solutions instead of allowing for
the possibility that this is a deployment and/or operational problem with
dynamic DNS instead of a problem with the lack of combined DHCP/DNS databases.
I think this section is presuming a solution space and hasn't fully explored
the problem space.
-
Brian Haberman: Comment [2012-12-11 09:11]:
1. In the introduction, shouldn't the list of reasons to use static addresses include their use within ACLs and other security mechanisms based on IP addresses? If so, a corresponding subsection in section 2 would be warranted.
-
Brian Haberman: Comment [2012-12-11 09:11]:
1. In the introduction, shouldn't the list of reasons to use static addresses
include their use within ACLs and other security mechanisms based on IP
addresses? If so, a corresponding subsection in section 2 would be warranted.
-
Russ Housley: Comment [2011-12-12 14:32]:
Please consider the comments provided in the Gen-ART Review by
Francis Dupont on 24-Nov-2011. The review can be found here:
http://www.ietf.org/mail-archive/web/gen-art/current/msg06935.html
-
Russ Housley: Comment [2011-12-12 14:32]:
Please consider the comments provided in the Gen-ART Review by
Francis Dupont on 24-Nov-2011. The review can be found here:
http://www.ietf.org/mail-archive/web/gen-art/current/msg06935.html
-
Adrian Farrel: Comment [2012-12-13 04:26]:
I appreciate the effort that the authors have put in to revise this
document after the previous evaluation by the IESG. This was a huge
task and they have gone a long way to improve the document.
At this point I do not believe it would serve any purpose to stand in
the way of this document. Therefore I will raise my concerns as Comments
and Abstain on the document.
I continue to believe that the use-cases are valuable material that will
help enable readers to understand the purpose of a streaming protocol.
---
The purpose of the document as stated in the Introduction is to propose
the development of a standardised protocol. I believe that we (the IETF)
understand the benefits of standardised solutions.
I would prefer that this document discussed (and claimed to discuss) the
functional requiremets that the proposed protocol must satisfy.
The introduction of section 6 certainly intends to meet my desires, but
I do not find the substance of the section convincing and I think that
its introduction at the end of the document, its brevity compared to the
rest of the document, and the issues raised by other ADs show that it is
not really the requirements section that the document needs.
===
Some of my comments from before have not been addressed...
---
I like that "chunk" is a unit of "block" with sub-unit "piece". What
is "block"? :-)
---
"key signaling protocol" may be unfortunate term because it is used
in other context to indicate a protocol that is used to signal "keys"
-
Adrian Farrel: Comment [2012-12-13 04:26]:
I appreciate the effort that the authors have put in to revise this
document after the previous evaluation by the IESG. This was a huge
task and they have gone a long way to improve the document.
At this point I do not believe it would serve any purpose to stand in
the way of this document. Therefore I will raise my concerns as Comments
and Abstain on the document.
I continue to believe that the use-cases are valuable material that will
help enable readers to understand the purpose of a streaming protocol.
---
The purpose of the document as stated in the Introduction is to propose
the development of a standardised protocol. I believe that we (the IETF)
understand the benefits of standardised solutions.
I would prefer that this document discussed (and claimed to discuss) the
functional requiremets that the proposed protocol must satisfy.
The introduction of section 6 certainly intends to meet my desires, but
I do not find the substance of the section convincing and I think that
its introduction at the end of the document, its brevity compared to the
rest of the document, and the issues raised by other ADs show that it is
not really the requirements section that the document needs.
===
Some of my comments from before have not been addressed...
---
I like that "chunk" is a unit of "block" with sub-unit "piece". What
is "block"? :-)
---
"key signaling protocol" may be unfortunate term because it is used
in other context to indicate a protocol that is used to signal "keys"
-
Wesley Eddy: Comment [2012-12-12 20:13]:
I think that given the protocol spec work PPSP is producing, this document is a helpful record for understanding some of the rationale behind protocol design decisions.
-
Wesley Eddy: Comment [2012-12-12 20:13]:
I think that given the protocol spec work PPSP is producing, this document is a
helpful record for understanding some of the rationale behind protocol design
decisions.
-
Stephen Farrell: Comment [2011-12-14 09:21]:
- Section 4 says that you can have pull, push or a hybrid but does
say if the PPSP wg is going to work on all of those or some of
those. (Its sort of implied that all will be done via different
"modes" but that's not clearly stated.) Since it'd be better to only
have one "mode," I think the document should justify choosing to do
all "modes." (If that's really what the PPSP WG are planning. If not
then the document should say what the WG is actually planning.)
- Section 5 really needs to say what sections 5.x are. They could
be use-cases the WG is going to tackle, or maybe the WG will decide
later, or whatever is the case. Without that, its hard to know why
sections 5.x are present.
- 5.1: "easily expand the broadcasting scale" just seems wrong. Is
that sales-pitch (in which case delete it) or do you mean something
else?
- Section 6 should mention that a malicious (or careless)
peer/tracker can leak private information about other peers or
trackers.
-
Stephen Farrell: Comment [2011-12-14 09:21]:
- Section 4 says that you can have pull, push or a hybrid but does
say if the PPSP wg is going to work on all of those or some of
those. (Its sort of implied that all will be done via different
"modes" but that's not clearly stated.) Since it'd be better to only
have one "mode," I think the document should justify choosing to do
all "modes." (If that's really what the PPSP WG are planning. If not
then the document should say what the WG is actually planning.)
- Section 5 really needs to say what sections 5.x are. They could
be use-cases the WG is going to tackle, or maybe the WG will decide
later, or whatever is the case. Without that, its hard to know why
sections 5.x are present.
- 5.1: "easily expand the broadcasting scale" just seems wrong. Is
that sales-pitch (in which case delete it) or do you mean something
else?
- Section 6 should mention that a malicious (or careless)
peer/tracker can leak private information about other peers or
trackers.
-
Pete Resnick: Comment [2012-12-12 18:25]:
Barry has done a much better job of identifying the issues in Section 6 than I ever could. In addition, I find the use of 2119 language in requirements lists downright silly. But like Barry, I don't think any of these are DISCUSS worthy.
I also find the information in sections 3, 4, and 5, while of marginal interest, of very little use to someone who will eventually be implementing the protocols that come out of this group. I understand that the WG was chartered to produce a problem statement, but I don't think this turned out to be a useful product for an RFC.
I therefore Abstain.
-
Pete Resnick: Comment [2012-12-12 18:25]:
Barry has done a much better job of identifying the issues in Section 6 than I
ever could. In addition, I find the use of 2119 language in requirements lists
downright silly. But like Barry, I don't think any of these are DISCUSS worthy.
I also find the information in sections 3, 4, and 5, while of marginal
interest, of very little use to someone who will eventually be implementing the
protocols that come out of this group. I understand that the WG was chartered
to produce a problem statement, but I don't think this turned out to be a
useful product for an RFC.
I therefore Abstain.
-
Benoit Claise: Discuss [2012-12-12 04:05]:
- There are no management and operation requirements in the document: a clear show stopper.
How do you plan on managing your beast?
From the charter, I see "operational requirements"
(2) A "requirements" document that details the specific functional,
operational and performance requirements of the two PPSP
protocols.
- What is the meaning of a SHOULD in a requirement document?
For example:
PPSP.TP.REQ-4: The tracker protocol SHOULD support the report of the
peer's chunk availability information to the tracker when tracker
needs such information to steer peer selection.
or
PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP
SHOULD be supported.
All requirements must be written with MUST, and it's up to framework to specify which of the options are MAY, SHOULD, MUST
-
Benoit Claise: Discuss [2012-12-12 04:05]:
- There are no management and operation requirements in the document: a clear
show stopper. How do you plan on managing your beast? From the charter, I see
"operational requirements"
(2) A "requirements" document that details the specific functional,
operational and performance requirements of the two PPSP
protocols.
- What is the meaning of a SHOULD in a requirement document?
For example:
PPSP.TP.REQ-4: The tracker protocol SHOULD support the report of the
peer's chunk availability information to the tracker when tracker
needs such information to steer peer selection.
or
PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP
SHOULD be supported.
All requirements must be written with MUST, and it's up to framework to specify
which of the options are MAY, SHOULD, MUST
-
Benoit Claise: Comment [2012-12-12 04:05]:
- I'm surprised not to see references to the CDNI work, RFC 6707 and 6770
CDNI is the use case in section 5.1, right?
-
Client: A client in general refers to the service requester in
client/server computing paradigm. In this draft a client also refers
to a participant in a P2P streaming system that only receives
streaming content. In some cases, a node not having enough computing
and storage capabilities will act as a client. Such node can be
viewed as a specific type of peer.
So what is a client?
In this draft a client is also ... So we have 2 definitions? A client in general, and a client in this draft?
I'm confused by the (3rd and) 4th sentence.
- My personal preference (up to your AD to enforce it or not) is to have the definitions capitalized.
Let me give an example:
Peer list: A list of peers which are in a same swarm maintained by
the tracker. A peer can fetch the peer list of a swarm from the
tracker or from other peers in order to know which peers have the
required streaming content.
I took my dictionary and looked up "swarm".
However, it's only later that I learned that swarm is actually a definition
- I don't understand
3) How to enable the tracker protocol light-weight, since a tracker
may need to server large amount of peers?
- missing "is"
OLD
1) How does the certain content be globally identified and verified?
Since the content can be retrieved from everywhere, how to ensure the
exchanged content between the peers authentic?
NEW
1) How does the certain content be globally identified and verified?
Since the content can be retrieved from everywhere, how to ensure the
exchanged content between the peers is authentic?
-
OLD
3) How to ensure the peer protocol efficient?
NEW
3) How to ensure the peer protocol efficiency?
-
Benoit Claise: Comment [2012-12-12 04:05]:
- I'm surprised not to see references to the CDNI work, RFC 6707 and 6770
CDNI is the use case in section 5.1, right?
-
Client: A client in general refers to the service requester in
client/server computing paradigm. In this draft a client also refers
to a participant in a P2P streaming system that only receives
streaming content. In some cases, a node not having enough computing
and storage capabilities will act as a client. Such node can be
viewed as a specific type of peer.
So what is a client?
In this draft a client is also ... So we have 2 definitions? A client in
general, and a client in this draft? I'm confused by the (3rd and) 4th sentence.
- My personal preference (up to your AD to enforce it or not) is to have the
definitions capitalized. Let me give an example:
Peer list: A list of peers which are in a same swarm maintained by
the tracker. A peer can fetch the peer list of a swarm from the
tracker or from other peers in order to know which peers have the
required streaming content.
I took my dictionary and looked up "swarm".
However, it's only later that I learned that swarm is actually a definition
- I don't understand
3) How to enable the tracker protocol light-weight, since a tracker
may need to server large amount of peers?
- missing "is"
OLD
1) How does the certain content be globally identified and verified?
Since the content can be retrieved from everywhere, how to ensure the
exchanged content between the peers authentic?
NEW
1) How does the certain content be globally identified and verified?
Since the content can be retrieved from everywhere, how to ensure the
exchanged content between the peers is authentic?
-
OLD
3) How to ensure the peer protocol efficient?
NEW
3) How to ensure the peer protocol efficiency?
-
Barry Leiba: Comment [2012-12-12 12:50]:
Overall, I'm not happy with this document, but I'm having trouble being specific enough to put my objections in as blocking comments (DISCUSSes). I find a lot of it harder to understand than I'd like. I hope the comments below can help, at least somewhat, in that regard, and I'll be happy to discuss these if you like.
-- Section 4 --
In Section 2, you define a "Tracker", and you say, "The tracker is a logical component which can be centralized or distributed." That makes sense. But in Section 4, you refer to the distributed version as "tracker-less architecture". If it's not too late, I'd like to urge you to use "centralized-tracker" and "distributed-tracker" instead of "tracker-based" and "tracker-less" -- the tracker function still exists in what you're calling tracker-less architecture, and I think the term is misleading.
But now I'm not sure that "architecture" is the right word here either:
PPSP.REQ-7: The tracker SHOULD be robust, i.e., when centralized
tracker fails, the P2P streaming system should still work by
supporting distributed trackers.
What you seem to be saying is that a P2P streaming system has to be able to shift back and forth from a centralized tracker function to a distributed one. So whether it's centralized or distributed is not part of the *architecture*.
-- Section 6 --
A minor point, but I think it would improve the readability if you used either hanging indents or a numbered list for the requirements, so it's visually clearer where each requirement begins and ends.
A more major point is that this seems to me to be a very incomplete list of protocol requirements. It doesn't feel like it gives much guidance toward developing the protocol, though that might just be because you don't really have many requirements that have to be documented in this way. But many of the requirements that are here are hard for me to understand as written. See below for some of that.
---
PPSP.REQ-1: Each peer MUST have a unique ID (i.e. peer ID) in a swarm.
It's a basic requirement for a peer to be uniquely identified in a
swarm that other peers or tracker can refer to the peer by ID.
The definition of "Peer ID" says this:
Peer ID: The identifier of a peer such that other peers, or the
tracker, can refer to the peer by using its ID.
The definition seems to mean that the peer ID is unique in a more broad universe than the swarm. Does a peer have a peer ID when it's not part of a swarm? Does its Peer ID change when it changes swarms? A peer can be in more than one swarm; does it have a different peer ID in each swarm? This isn't clear.
---
PPSP.REQ-3: The streaming content MUST allow to be partitioned into
chunks.
I can't parse this, and I don't understand it. It must allow *what* to be partitioned? How does streaming content "allow" anything? Is it that the peer or the swarm or the tracker allows something? As I say, I don't understand.
---
PPSP.REQ-4: Each chunk MUST have a unique ID (i.e. chunk ID) in the
swarm.
Each chunk must have a unique ID in the swarm so that the peer can
understand which chunks are stored in which peers and which chunks
are requested by other peers.
I understand the requirement -- that's fine -- but I don't follow the rationale: all peers in a swarm are serving up the same content, right? And how does the chunk ID tell anyone where the chunk is stored?
---
PPSP.TP.REQ-1: The tracker protocol MUST allow the peer to solicit
the peer list from the tracker with respect to a specific swarm in a
query and response manner.
The tracker request message may also include the requesting peer's
preference parameter (e.g. preferred number of peers in the peer list)
or preferred downloading bandwidth. The tracker will then be able to
select an appropriate set of peers for the requesting peer according
to the preference.
PPSP.TP.REQ-2: The tracker SHOULD support generating the peer list
with the help of traffic optimization services, e.g. ALTO
PPSP.TP.REQ-1 is written as "THE peer list from the tracker", but the explanation of REQ-1 and the wording of REQ-2 makes it seem like there isn't a fixed peer list that a particular tracker will give for a given swarm. It seems that when a peer requests *A* peer list from the tracker, the tracker is likely to return a list that's tailored to the requesting peer, and that probably doesn't just contain all the peers in the swarm. Is that right?
If that's what's expected, that should be made clearer.
---
PPSP.TP.REQ-5: The chunk availability information between peer and
tracker MUST be expressed in a compactable method.
The peers may report chunk availability digest information (i.e.,
compact expression of chunk availability) to the tracker when
possible in order to decrease the bandwidth consumption in mobile
networks. For example, if a peer has a bitmap like 111111...1(one
hundred continuous 1)xxx..., the one hundred continuous "1" can be
expressed by one byte with seven bits representing the number of "1",
i.e., "one hundred" and one bit representing the continuous sequence
is "1" or "0". In this example, 100-8=92 bits are saved. Considering
the frequency of exchange of chunk availability and the fact that
many bitmaps have a quite long length of continuous "1" or "0", such
compression is quite useful.
It seems to me that the real requirement here (and in PPSP.PP.REQ-7) is that the design of the mechanism for communicating chunk availability information has to take and frequency of requests and efficient use of bandwidth into account. A requirements document shouldn't be going into detail about compression.
---
PPSP.TP.REQ-7: The tracker protocol MUST allow the tracker to
authenticate the peer.
This ensures that only the authenticated users can access the
original content in the P2P streaming system.
Is "allow" correct here? You're saying that the tracker protocol MUST have a provision for authentication, but it doesn't have to be used? But then the description seems to say that authentication *does* have to be used. Again, I'm confused.
---
PPSP.PP.REQ-2: The chunk information exchanged between a pair of
peers MUST NOT be passed to other peers, unless validated (e.g.
prevent hearsay and DoS).
Unless *what* is validated? It sounds like it's the chunk information that has to be validated. Or is it meant to be the request for information? Validated how? This is the first use of the word "validated", so I don't know what it means in this context.
-
Barry Leiba: Comment [2012-12-12 12:50]:
Overall, I'm not happy with this document, but I'm having trouble being
specific enough to put my objections in as blocking comments (DISCUSSes). I
find a lot of it harder to understand than I'd like. I hope the comments below
can help, at least somewhat, in that regard, and I'll be happy to discuss these
if you like.
-- Section 4 --
In Section 2, you define a "Tracker", and you say, "The tracker is a logical
component which can be centralized or distributed." That makes sense. But in
Section 4, you refer to the distributed version as "tracker-less architecture".
If it's not too late, I'd like to urge you to use "centralized-tracker" and
"distributed-tracker" instead of "tracker-based" and "tracker-less" -- the
tracker function still exists in what you're calling tracker-less architecture,
and I think the term is misleading.
But now I'm not sure that "architecture" is the right word here either:
PPSP.REQ-7: The tracker SHOULD be robust, i.e., when centralized
tracker fails, the P2P streaming system should still work by
supporting distributed trackers.
What you seem to be saying is that a P2P streaming system has to be able to
shift back and forth from a centralized tracker function to a distributed one.
So whether it's centralized or distributed is not part of the *architecture*.
-- Section 6 --
A minor point, but I think it would improve the readability if you used either
hanging indents or a numbered list for the requirements, so it's visually
clearer where each requirement begins and ends.
A more major point is that this seems to me to be a very incomplete list of
protocol requirements. It doesn't feel like it gives much guidance toward
developing the protocol, though that might just be because you don't really
have many requirements that have to be documented in this way. But many of the
requirements that are here are hard for me to understand as written. See below
for some of that.
---
PPSP.REQ-1: Each peer MUST have a unique ID (i.e. peer ID) in a swarm.
It's a basic requirement for a peer to be uniquely identified in a
swarm that other peers or tracker can refer to the peer by ID.
The definition of "Peer ID" says this:
Peer ID: The identifier of a peer such that other peers, or the
tracker, can refer to the peer by using its ID.
The definition seems to mean that the peer ID is unique in a more broad
universe than the swarm. Does a peer have a peer ID when it's not part of a
swarm? Does its Peer ID change when it changes swarms? A peer can be in more
than one swarm; does it have a different peer ID in each swarm? This isn't
clear.
---
PPSP.REQ-3: The streaming content MUST allow to be partitioned into
chunks.
I can't parse this, and I don't understand it. It must allow *what* to be
partitioned? How does streaming content "allow" anything? Is it that the peer
or the swarm or the tracker allows something? As I say, I don't understand.
---
PPSP.REQ-4: Each chunk MUST have a unique ID (i.e. chunk ID) in the
swarm.
Each chunk must have a unique ID in the swarm so that the peer can
understand which chunks are stored in which peers and which chunks
are requested by other peers.
I understand the requirement -- that's fine -- but I don't follow the
rationale: all peers in a swarm are serving up the same content, right? And
how does the chunk ID tell anyone where the chunk is stored?
---
PPSP.TP.REQ-1: The tracker protocol MUST allow the peer to solicit
the peer list from the tracker with respect to a specific swarm in a
query and response manner.
The tracker request message may also include the requesting peer's
preference parameter (e.g. preferred number of peers in the peer list)
or preferred downloading bandwidth. The tracker will then be able to
select an appropriate set of peers for the requesting peer according
to the preference.
PPSP.TP.REQ-2: The tracker SHOULD support generating the peer list
with the help of traffic optimization services, e.g. ALTO
PPSP.TP.REQ-1 is written as "THE peer list from the tracker", but the
explanation of REQ-1 and the wording of REQ-2 makes it seem like there isn't a
fixed peer list that a particular tracker will give for a given swarm. It
seems that when a peer requests *A* peer list from the tracker, the tracker is
likely to return a list that's tailored to the requesting peer, and that
probably doesn't just contain all the peers in the swarm. Is that right?
If that's what's expected, that should be made clearer.
---
PPSP.TP.REQ-5: The chunk availability information between peer and
tracker MUST be expressed in a compactable method.
The peers may report chunk availability digest information (i.e.,
compact expression of chunk availability) to the tracker when
possible in order to decrease the bandwidth consumption in mobile
networks. For example, if a peer has a bitmap like 111111...1(one
hundred continuous 1)xxx..., the one hundred continuous "1" can be
expressed by one byte with seven bits representing the number of "1",
i.e., "one hundred" and one bit representing the continuous sequence
is "1" or "0". In this example, 100-8=92 bits are saved. Considering
the frequency of exchange of chunk availability and the fact that
many bitmaps have a quite long length of continuous "1" or "0", such
compression is quite useful.
It seems to me that the real requirement here (and in PPSP.PP.REQ-7) is that
the design of the mechanism for communicating chunk availability information
has to take and frequency of requests and efficient use of bandwidth into
account. A requirements document shouldn't be going into detail about
compression.
---
PPSP.TP.REQ-7: The tracker protocol MUST allow the tracker to
authenticate the peer.
This ensures that only the authenticated users can access the
original content in the P2P streaming system.
Is "allow" correct here? You're saying that the tracker protocol MUST have a
provision for authentication, but it doesn't have to be used? But then the
description seems to say that authentication *does* have to be used. Again,
I'm confused.
---
PPSP.PP.REQ-2: The chunk information exchanged between a pair of
peers MUST NOT be passed to other peers, unless validated (e.g.
prevent hearsay and DoS).
Unless *what* is validated? It sounds like it's the chunk information that has
to be validated. Or is it meant to be the request for information? Validated
how? This is the first use of the word "validated", so I don't know what it
means in this context.
-
Stewart Bryant: Discuss [2011-12-12 12:08]:
There is a fine line between providing evidence for a case to design something and delivering a commercial message. Unfortunately, even though the author does not appear to work for the companies mentioned the introduction sounds like a commercial. Additionally later in the document there is reference to at least one other company.
Please will the author look at each mention of a company name and re-write the text to provide the evidence in a more objective, vendor neutral, style.
-
Stewart Bryant: Discuss [2011-12-12 12:08]:
There is a fine line between providing evidence for a case to design something
and delivering a commercial message. Unfortunately, even though the author does
not appear to work for the companies mentioned the introduction sounds like a
commercial. Additionally later in the document there is reference to at least
one other company.
Please will the author look at each mention of a company name and re-write the
text to provide the evidence in a more objective, vendor neutral, style.
-
Robert Sparks: Comment [2011-12-13 07:11]:
It's not obvious how this document is going to help the working group with it's protocol work, or help document the work once it's complete. Is the set of use cases intended to be a set of motivating examples, or does it exhaustively cover every scenario the protocol is expected to handle? Please consider clarifying those points.
-
Robert Sparks: Comment [2011-12-13 07:11]:
It's not obvious how this document is going to help the working group with it's
protocol work, or help document the work once it's complete. Is the set of use
cases intended to be a set of motivating examples, or does it exhaustively
cover every scenario the protocol is expected to handle? Please consider
clarifying those points.
-
Adrian Farrel: Comment [2012-12-12 04:19]:
I have no objection to the publication of this document and would ballot "Yes", but I believe that Martin's Discuss needs to be addressed.
-
Adrian Farrel: Comment [2012-12-12 04:19]:
I have no objection to the publication of this document and would ballot "Yes",
but I believe that Martin's Discuss needs to be addressed.
-
Stephen Farrell: Comment [2012-12-12 07:12]:
- The authors responded to the secdir review [1] saying they
planned to modify the security considerations section, but I
didn't see any further response and don't see associated
changes in the security considerations.
[1] http://www.ietf.org/mail-archive/web/secdir/current/msg03538.html
- This cites RFC 4364 which calls for use of TCP-MD5 for
control plane security. [2] Given that this is an
experimental document, would it not be resaonable for it at
least mention that RFC 5925 obsoleted TCP-MD5?
[2] http://tools.ietf.org/html/rfc4364#section-13.2
-
Stephen Farrell: Comment [2012-12-12 07:12]:
- The authors responded to the secdir review [1] saying they
planned to modify the security considerations section, but I
didn't see any further response and don't see associated
changes in the security considerations.
[1] http://www.ietf.org/mail-archive/web/secdir/current/msg03538.html
- This cites RFC 4364 which calls for use of TCP-MD5 for
control plane security. [2] Given that this is an
experimental document, would it not be resaonable for it at
least mention that RFC 5925 obsoleted TCP-MD5?
[2] http://tools.ietf.org/html/rfc4364#section-13.2
-
Martin Stiemerling: Comment [2012-12-13 03:13]:
Thanks for addressing my DISCUSS -- cleared.
Comments:
This draft is going for experimental and I would like to know what the test for a successful or not successful outcome of this is. Especially since the drafts says that this should enable experimental research.
I would further add a more explicit clarification that this is only to be used within an operator. This is mentioned in several places, e.g., in Section 3.1.1 "The object MUST NOT be included in any RSVP-TE message that is sent outside of the provider's backbone." However, a particular section discussing this would be better. This section could also discuss possible impacts if the above rules is not followed.
-
Martin Stiemerling: Comment [2012-12-13 03:13]:
Thanks for addressing my DISCUSS -- cleared.
Comments:
This draft is going for experimental and I would like to know what the test for
a successful or not successful outcome of this is. Especially since the drafts
says that this should enable experimental research.
I would further add a more explicit clarification that this is only to be used
within an operator. This is mentioned in several places, e.g., in Section 3.1.1
"The object MUST NOT be included in any RSVP-TE message that is sent outside
of the provider's backbone." However, a particular section discussing this
would be better. This section could also discuss possible impacts if the above
rules is not followed.
-
Pete Resnick: Comment [2012-12-11 14:26]:
(For the IESG; no author action necessary.)
My "No Objection" position notwithstanding, I strongly agree with Barry's DISCUSS comments and would like to hear more about this. Even if we pass this document on for publication, I think the issue of almost entirely unsupported AD-sponsored documents needs to be dealt with. It is certainly within an AD's discretion to personally support the publication of a document he/she feels is important, but I would expect an extensive writeup of why the AD is using that privilege for a document that's gotten virtually no discussion.
-
Pete Resnick: Comment [2012-12-11 14:26]:
(For the IESG; no author action necessary.)
My "No Objection" position notwithstanding, I strongly agree with Barry's
DISCUSS comments and would like to hear more about this. Even if we pass this
document on for publication, I think the issue of almost entirely unsupported
AD-sponsored documents needs to be dealt with. It is certainly within an AD's
discretion to personally support the publication of a document he/she feels is
important, but I would expect an extensive writeup of why the AD is using that
privilege for a document that's gotten virtually no discussion.
-
Barry Leiba: Discuss [2012-12-04 10:48]:
This is a "DISCUSS-DISCUSS", for IESG action.
The bottom line first:
I see no evidence that there was substantive discussion of this document anywhere, and I don't see that it belongs in the IETF Stream, with any claim to IETF consensus.
The shepherd writeup mentions consideration by the l3vpn WG, but it appears not to have been substantively discussed there. The IETF 77 minutes show a discussion of what working group it belongs in, but no discussion of the substance of the document. With a little digging, one finds that it has a predecessor document, draft-kumaki-murai-ccamp-rsvp-te-l3vpn, which was proposed to the ccamp WG, but there's no evidence that it was discussed there either.
The only two substantive comments I can find are these:
1. From Ben Niven-Jenkins on the l3vpn list:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02706.html
In that post, Ben made some comments that were never responded to.
2. During IETF Last Call, on the IETF discussion list, Lou Berger had a brief exchange with an author (two messages from each), starting here:
http://www.ietf.org/mail-archive/web/ietf/current/msg75348.html
It's not clear that this resulted in a resolution of Lou's concern.
And that's all. I think that's light even for an Experimental document.
Given that both ccamp and l3vpn have looked at this and said that they don't want it (but apparently think it's not harmful), and that exactly two people other than the authors have made any comments at all about the substance of the document, I don't think it's reasonable to say that there's IETF consensus on it.
I do think it would be reasonable to send this over to the Independent Stream Editor.
-
Barry Leiba: Discuss [2012-12-04 10:48]:
This is a "DISCUSS-DISCUSS", for IESG action.
The bottom line first:
I see no evidence that there was substantive discussion of this document
anywhere, and I don't see that it belongs in the IETF Stream, with any claim to
IETF consensus.
The shepherd writeup mentions consideration by the l3vpn WG, but it appears not
to have been substantively discussed there. The IETF 77 minutes show a
discussion of what working group it belongs in, but no discussion of the
substance of the document. With a little digging, one finds that it has a
predecessor document, draft-kumaki-murai-ccamp-rsvp-te-l3vpn, which was
proposed to the ccamp WG, but there's no evidence that it was discussed there
either.
The only two substantive comments I can find are these:
1. From Ben Niven-Jenkins on the l3vpn list:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02706.html
In that post, Ben made some comments that were never responded to.
2. During IETF Last Call, on the IETF discussion list, Lou Berger had a brief
exchange with an author (two messages from each), starting here:
http://www.ietf.org/mail-archive/web/ietf/current/msg75348.html
It's not clear that this resulted in a resolution of Lou's concern.
And that's all. I think that's light even for an Experimental document.
Given that both ccamp and l3vpn have looked at this and said that they don't
want it (but apparently think it's not harmful), and that exactly two people
other than the authors have made any comments at all about the substance of the
document, I don't think it's reasonable to say that there's IETF consensus on
it.
I do think it would be reasonable to send this over to the Independent Stream
Editor.
-
Brian Haberman: Discuss [2012-12-12 06:58]:
Updated based on Adrian's correction...
I have no problems with the publication of this document, but I agree with Martin that the IANA Considerations section is wrong. The document is requesting several new RSVP Class Types, which are allocated using the rules defined in RFC 3936. Specifically, from section 2.3 of 3936:
For Class Numbers that pre-date this document (specifically, 0, 1,
3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the
default assignment policy for new Class Types is Standards Action,
unless a Standards Track or Best Current Practice RFC supercedes
this.
-
Brian Haberman: Discuss [2012-12-12 06:58]:
Updated based on Adrian's correction...
I have no problems with the publication of this document, but I agree with
Martin that the IANA Considerations section is wrong. The document is
requesting several new RSVP Class Types, which are allocated using the rules
defined in RFC 3936. Specifically, from section 2.3 of 3936:
For Class Numbers that pre-date this document (specifically, 0, 1,
3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the
default assignment policy for new Class Types is Standards Action,
unless a Standards Track or Best Current Practice RFC supercedes
this.
-
Sean Turner: Comment [2012-12-12 17:13]:
Updated after discussions with Adrian. This is about control plane stuff so my concerns don't apply.
This might be cleared up by addressing PHB's secdir review comment too, but I thought I'd throw this in:
Are there two different mechanisms defined in RFC 2747 and 3097? I thought 3097 updates 2747 to just clarify which values to use because of a double assignment. Wouldn't be clearer if you said:
To ensure the integrity of an RSVP request, the RSVP Authentication
mechanisms defined in [RFC2747], update by [RFC3097], SHOULD be used.
-
Sean Turner: Comment [2012-12-12 17:13]:
Updated after discussions with Adrian. This is about control plane stuff so my
concerns don't apply.
This might be cleared up by addressing PHB's secdir review comment too, but I
thought I'd throw this in:
Are there two different mechanisms defined in RFC 2747 and 3097? I thought
3097 updates 2747 to just clarify which values to use because of a double
assignment. Wouldn't be clearer if you said:
To ensure the integrity of an RSVP request, the RSVP Authentication
mechanisms defined in [RFC2747], update by [RFC3097], SHOULD be used.
-
Ralph Droms: Discuss [2012-12-12 18:59]:
Consistent with my Discuss position on draft-ietf-tcpm-initcwnd,
I object to an Experimental document listing itself as updating
a PS document.
I realize there are precedents for Experimental docs updating PS
docs. However, in this case, I would be happier with "is an experiment
based on" metadata. Lacking that option, I would like to see
the "Updates" metadata dropped from this document. And,
of course, if the experiment is successful and a PS spec
based on this doc is published, it would update RFC 5996.
-
Ralph Droms: Discuss [2012-12-12 18:59]:
Consistent with my Discuss position on draft-ietf-tcpm-initcwnd,
I object to an Experimental document listing itself as updating
a PS document.
I realize there are precedents for Experimental docs updating PS
docs. However, in this case, I would be happier with "is an experiment
based on" metadata. Lacking that option, I would like to see
the "Updates" metadata dropped from this document. And,
of course, if the experiment is successful and a PS spec
based on this doc is published, it would update RFC 5996.
-
Pete Resnick: Comment [2012-12-09 22:05]:
Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the below and fix.
There are 6 occurrences of MUST per 2119. 5 of them seem obviously wrong:
Section 3:
The IDi payload MUST have ID Type ID_RFC822_ADDR and the data field
MUST contain the same value as the KeyName-NAI TLV in the
EAP_Initiate/Re-auth message.
Section 4:
o Protocol ID (1 octet) MUST be zero, as this message is related to
an IKE SA.
o SPI Size (1 octet) MUST be zero, in conformance with section 3.10
of RFC 5996.
o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value
assigned for ERX. TBA by IANA.
Ask yourself in each case: What would happen if an implementation chose not to do what you say is something that they MUST do? If the answer is, "They wouldn't be implementing the protocol", then the MUST is not being used correctly; you should instead use "will". If the answer is, "They would be implementing the protocol if they did something different, but they fail to interoperate", then the MUST would be correct. In each of the 5 cases above, I cannot figure out how the MUST is justified.
The only other MUST is in section 3.1:
Section 3.16 of RFC 5996 enumerates the EAP codes in EAP messages
which are carried in EAP payloads. The enumeration goes only to 4.
It is not clear whether that list is supposed to be exhaustive or
not.
To clarify, an implementation conforming to this specification MUST
accept and transmit EAP messages with at least the codes for Initiate
and Finish (5 and 6) from RFC 6696, in addition to the four codes
enumerated in RFC 5996.
Here, the MUST would be appropriate if you are changing 5996, but if so, you have worded this poorly: Change "an implementation conforming to this specification" to "an implementation of IKEv2". You are saying that *any* IKEv2 EAP implementation MUST handle all 6. If you are not saying that, then the MUST is wrong and should be changed to "will".
-
Pete Resnick: Comment [2012-12-09 22:05]:
Not my area of expertise, so I'm going to simply not object on the document
itself. However, please take a look at the below and fix.
There are 6 occurrences of MUST per 2119. 5 of them seem obviously wrong:
Section 3:
The IDi payload MUST have ID Type ID_RFC822_ADDR and the data field
MUST contain the same value as the KeyName-NAI TLV in the
EAP_Initiate/Re-auth message.
Section 4:
o Protocol ID (1 octet) MUST be zero, as this message is related to
an IKE SA.
o SPI Size (1 octet) MUST be zero, in conformance with section 3.10
of RFC 5996.
o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value
assigned for ERX. TBA by IANA.
Ask yourself in each case: What would happen if an implementation chose not to
do what you say is something that they MUST do? If the answer is, "They
wouldn't be implementing the protocol", then the MUST is not being used
correctly; you should instead use "will". If the answer is, "They would be
implementing the protocol if they did something different, but they fail to
interoperate", then the MUST would be correct. In each of the 5 cases above, I
cannot figure out how the MUST is justified.
The only other MUST is in section 3.1:
Section 3.16 of RFC 5996 enumerates the EAP codes in EAP messages
which are carried in EAP payloads. The enumeration goes only to 4.
It is not clear whether that list is supposed to be exhaustive or
not.
To clarify, an implementation conforming to this specification MUST
accept and transmit EAP messages with at least the codes for Initiate
and Finish (5 and 6) from RFC 6696, in addition to the four codes
enumerated in RFC 5996.
Here, the MUST would be appropriate if you are changing 5996, but if so, you
have worded this poorly: Change "an implementation conforming to this
specification" to "an implementation of IKEv2". You are saying that *any* IKEv2
EAP implementation MUST handle all 6. If you are not saying that, then the MUST
is wrong and should be changed to "will".
-
Ronald Bonica: Discuss [2012-12-11 08:22]:
In the past, many RFCs have updated RFC 1350 by adding new TFTP Options. All of those drafts have a) explicitly updated 1350, b) been published on the standards track.
Why is this document different from its predecessors?
-
Ronald Bonica: Discuss [2012-12-11 08:22]:
In the past, many RFCs have updated RFC 1350 by adding new TFTP Options. All of
those drafts have a) explicitly updated 1350, b) been published on the
standards track.
Why is this document different from its predecessors?
-
Adrian Farrel: Comment [2012-12-12 12:08]:
I do not see any value in adding to the Discusses raised by other ADs.
-
Adrian Farrel: Comment [2012-12-12 12:08]:
I do not see any value in adding to the Discusses raised by other ADs.
-
Wesley Eddy: Discuss [2012-12-10 16:55]:
I do not think this document conflicts with IETF work. However, it may be harmful for those using it, and it clearly should not be used across the Internet.
In September, I sent these comments to the ISE, which do not seem to be addressed in the document:
"""
It is definitely missing text about what you do in the case of loss,
and probably completely pathologically broken, as currently written.
I say this because the window size is specified as any chosen value,
without any probing of what the network can actually support.
Further, on losses, the entire window is retransmitted. So, a single
packet loss (which could be signalling congestion) causes retransmission
of an entire window, and this is going to occur either at line rate or
probably the same rate that the last window was paced out at, which
caused loss.
It sounds like a great way to shoot yourself in the foot while trying
to improve performance!
"""
This is just clearly an unsafe algorithm since it fails to backoff in response
to loss. An overly aggressive setting will harm other traffic.
At minimum, it should:
1) halve the window size in-use on losses
2) encourage implementation of a "memory" such that if a window size
causes loss, you use a smaller size for subsequent transfers to the
same host
3) make it clear that host buffers can be a constraint on tiny devices
and that part of the TFTP 1-segment benefit is that it greatly simplifies
the resources and memory needed for reordering, etc., as this may be
taking place within a 1st or 2nd stage bootloader.
-
Wesley Eddy: Discuss [2012-12-10 16:55]:
I do not think this document conflicts with IETF work. However, it may be
harmful for those using it, and it clearly should not be used across the
Internet.
In September, I sent these comments to the ISE, which do not seem to be
addressed in the document: """ It is definitely missing text about what you do
in the case of loss, and probably completely pathologically broken, as
currently written.
I say this because the window size is specified as any chosen value,
without any probing of what the network can actually support.
Further, on losses, the entire window is retransmitted. So, a single
packet loss (which could be signalling congestion) causes retransmission
of an entire window, and this is going to occur either at line rate or
probably the same rate that the last window was paced out at, which
caused loss.
It sounds like a great way to shoot yourself in the foot while trying
to improve performance!
"""
This is just clearly an unsafe algorithm since it fails to backoff in response
to loss. An overly aggressive setting will harm other traffic.
At minimum, it should:
1) halve the window size in-use on losses
2) encourage implementation of a "memory" such that if a window size
causes loss, you use a smaller size for subsequent transfers to the
same host
3) make it clear that host buffers can be a constraint on tiny devices
and that part of the TFTP 1-segment benefit is that it greatly simplifies
the resources and memory needed for reordering, etc., as this may be
taking place within a 1st or 2nd stage bootloader.
-
Stephen Farrell: Comment [2012-12-13 06:34]:
I'm no-objection here but do think that the transport ADs
discuss points ought to be but have not yet been fully
discussed as they seem to me to be reasonable points.
-
Stephen Farrell: Comment [2012-12-13 06:34]:
I'm no-objection here but do think that the transport ADs
discuss points ought to be but have not yet been fully
discussed as they seem to me to be reasonable points.
-
Ralph Droms: Comment [2012-12-12 19:14]:
The previously entered Discuss positions articulate all of my concerns.
-
Ralph Droms: Comment [2012-12-12 19:14]:
The previously entered Discuss positions articulate all of my concerns.
-
Martin Stiemerling: Discuss [2012-12-11 07:36]:
In full support of Wes' DISCUSS and the response should be "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."
-
Martin Stiemerling: Discuss [2012-12-11 07:36]:
In full support of Wes' DISCUSS and the response should be "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."
-
Pete Resnick: Comment [2012-11-30 15:07]:
There is no current work in TFTP that I can see, and given that TFTP is almost exclusively used in local network environments nowadays, I have a hard time seeing how this could do any damage. Therefore, I am recommending a simple "No conflict" message. The only other choice is to decide that they are extending RFC 1350 in a sufficiently horrible way that it needs IETF Review. Transport folks should probably give the document a read.
-
Pete Resnick: Comment [2012-11-30 15:07]:
There is no current work in TFTP that I can see, and given that TFTP is almost
exclusively used in local network environments nowadays, I have a hard time
seeing how this could do any damage. Therefore, I am recommending a simple "No
conflict" message. The only other choice is to decide that they are extending
RFC 1350 in a sufficiently horrible way that it needs IETF Review. Transport
folks should probably give the document a read.
-
Benoit Claise: Comment [2012-12-13 05:55]:
I'll trust the transport ADs judgement on this draft.
-
Benoit Claise: Comment [2012-12-13 05:55]:
I'll trust the transport ADs judgement on this draft.
-
Stewart Bryant: Discuss [2012-12-12 07:58]:
Given the widespread use of TFTP in bootstrapping devices, and hence its importance to the Internet, I think that this needs to go for IETF review.
-
Stewart Bryant: Discuss [2012-12-12 07:58]:
Given the widespread use of TFTP in bootstrapping devices, and hence its
importance to the Internet, I think that this needs to go for IETF review.