IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2009-12-17. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pasi, Dan
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
3.3.2 Returning Items
Telechat:
Telechat:
3.3.3 For Action
Telechat:
Telechat:
Telechat:
Note: three Michelle mgmt items were discussed before the break
1317 EST break
1322 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
Telechat:
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1428 EST Entered Executive Session
draft-ietf-tsvwg-admitted-realtime-dscp
I support Dan's DISCUSS.
The Abstract says... ...for real-time traffic classes similar to voice... A nit, but the traffic class is not similar to voice. The Introduction says this much better. Any chance of polishing the Abstract? --- Section 1. Paragraph 3 begins... These applications... Which applications? Is this paragraph intended to be attached to paragraph 2, or is the whole context of paragraph 1 and paragraph 2 supposed to be applications rather than traffic classes? The second sentence of the same paragraph reads... Reserving capacity for them is important to application performance. I think you reserve capacity for traffic flows, not for applications? --- Section 1.1 Do you have a reference for your definition of UNI? It doesn't seem to conform completely with the definition I am used to in transport networks withint the ITU-T. I think that the main issue I have is that your definition implies that the use of a UNI indicates that the UNI-C and UNI-N do not trust each other. Maybe just needs a tweak on the wording. Should your NNI really be termed "E-NNI"? --- Section 1.2 s/may not be present/might not be present/ --- Section 2.3 says... It is the belief of the authors that either PHB implementation Is this not the work of the TSV Working Group with IETF consensus? Can this please be rephrased. Either "It is believed that..." or (preferably) a simple statement of fact. --- e-911 is used as a term without explanation or reference. --- Section 4 Rather obviously, you should ask IANA to asign from Pool 1
For a person not familiar with the underlying technology, I found the Security Consideration section to be insufficiently detailed about threats. While the list of threats seems to be adequate, it would be useful to have some pointers to documents describing possible remedies (for example how to achieve adequately strong proof of identity), or a clear statement that the protocol doesn't provide such facility.
Based on discussions between the authors and the secdir reviewer in Nov 2008, I
was expecting
to see references to 4542 and 4230 in the security considerations
section. I was also hoping
they would call out appropriate technologies for
"proof of identity" that are considered
"adequately strong", although that point
was still under discussion when the email thread
fizzled out.
I am wondering whether the recommendation to use RSVP in Section 2.3 is in place
and directly related to the core content of the document. I also see that it was
disputed in the WG without a clear resolution.
I am wondering why there is a need to recommend any specific protocol, given
that it specifies the requirements for the admission procedure.
Section 2.2 appropriately specifies:
The operator's choice of admission procedure MUST, for this DSCP,
ensure the following:
[...]
Then the first paragraph of Section 2.3 appropriately talks about
'...adequate AAA and capacity admission procedures as described in Section
2.2...'
But then the second paragraph of section 2.3 goes into saying:
On the point of what protocols and procedures are required for
authentication, authorization, and capacity admission, we note that
clear standards do not exist at this time for bandwidth brokers,
NSIS has not been finalized at this time and in any event is limited
to unicast sessions, and that RSVP has been standardized and has the
relevant services. We therefore recommend the use of RSVP at the
UNI.
I think this recommendation for RSVP is too strong, and I wonder whether a
recommendation for any specific protocol is needed at all in this document. Any
admission mechanism that meets the requirements of section 2.2 should be fine
for this DSCP service and sufficient in order to conform to this Proposed
Standard.
Hannes Tschofenig raised this concern in January 2009 in http://www.ietf.org
/mail-archive/web/tsvwg/current/msg09004.html. There was then some debate
between Hannes and Ken Carlberg but then the discussion died wihout any comment
from the authors and with no change in this section in version -06. Have I
missed any proposal for consensus on this?
draft-ietf-ipfix-mib
Just a couple of minor issues for you to think about if the I-D is revised or
during AUTH-48.
---
Use of citations within REFERENCE clauses.
I think you should not use square brackets for referenced documents
inside the MIB module itself. Just remove the [], but you may need to
fix up some text elsewhere to ensure that the referenced documents
are cited from somewhere int he document.
---
Section 5.3
Right at the end of the example in the section you have:
+- ipfixTemplateDefinitionEnterprise (5) = 0
+- ipfixTemplateDefinitionFlags (4) = 0
The OIDs are reversed.
---
ipfixTemplateDefinitionFlags
You have...
Thus we get the following values for an Information Element:
'0'H
The Information Element is neither used for scoping nor
as Flow Key.
'1'H (scope)
The Information Element is used for scoping.
'2'H (flowKey)
The Information Element is used as Flow Key.
'3'H (scope | flowKey)
This combination is not allowed."
I know what you are trying to say, but ipfixTemplateDefinitionFlags has
SYNTAX BITS and you can't convert that into hex (if you had wanted to
you could have used SYNTAX INTEGER).
I think you just have to rephrase this in terms of bits.
5.3. The Template Definition Table
ipfixTemplateDefinitionTable (4)
|
+- ipfixTemplateDefinitionEntry (1)
|
+- index (5) (ipfixTransportSessionIndex)
+- index (3) (ipfixTemplateObservationDomainId)
+ index (257) (ipfixTemplateId)
+- index (1) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 1
| +- ipfixTemplateDefinitionIeId (2) = 158
| | (flowStartDeltaMicroseconds)
| +- ipfixTemplateDefinitionIeLength (3) = 4
| +- ipfixTemplateDefinitionEnterprise (4) = 0
| +- ipfixTemplateDefinitionFlags (5) = 0
|
+- index (2) (ipfixTemplateDefinitionIndex)
| +- ipfixTemplateDefinitionIndex (1) = 2
| +- ipfixTemplateDefinitionIeId (2) = 159
| | (flowStartDeltaMicroseconds)
flowStartDeltaMicroseconds is listed twice (for 158 and for 159). This looks
wrong.
draft-ietf-rohc-ipsec-extensions-hcoipsec
In my opinion, including support for ROHC segmentation (Section 4.3) is misguided, and unnecessary complexity. While AH/ESP sequence numbers could be used in theory to reconstruct the correct segment sequence, I have doubts that anyone will actually implement this: ROHC is useful mostly for small packets (where the header is large part of the total packet) -- but those won't require fragmentation...
I suggest spelling out robust header compression once somewhere in the abstract. It should be relatively obvious given the document's title, but in isolation the abstract is difficult to sort.
The OPS-DIR review performed by Bert Wijnen on version 05 of the document included the following comment: > If I understand the document correctly, then a user of this protocol will have to add additional paramters in the SPD and SAD databases (as defined in RFC4301). > I do not see any discussion as to what implications (if any) that may have to existing entries in the databases?. Might that cause interupts to ongoing operations? Or can existing entries be left untouched and could one choose to just add these new paramters to new entries in the databases? > Answers to these questions are probably best added in the document itself. The answer from the document editor mentioned that: > Bert's understanding is correct; we are adding additional parameters to the SPD and SAD databases. Fortunately, I do not think that these new parameters will cause issues for existing entries in the SPD and SAD. The additional ROHCoIPsec SPD parameters are simply configured (e.g., along with the other parameters in the SPD). Based on the these SPD parameters, the ROHCoIPsec SAD parameters will be populated during the initialization/rekey of a child SA (e.g., along with the other SAD parameters). I am satisfied with the answer, but I believe that the issue should be documented in the future RFC.
draft-ietf-rohc-ikev2-extensions-hcoipsec
I have reviewed draft-ietf-rohc-ikev2-extensions-hcoipsec-10, and have
a couple of questions/concerns that I'd like to discuss before
recommending approval of the document:
- Section 5: the IANA policy here is quite unclear; the text first
says "Designated Expert" -- but then talks about requiring a published
RFC (which would suggest the policy is "RFC Required"), and then about
IETF Last Call (which would suggest the policy is "IETF Review", since
not all RFCs go through IETF Last Call).
- Section 3.1: "ROHC channel parameters MUST be signaled at either
the establishment or rekeying of a Child SA." The "either..or"
construct is a bit unclear -- if ROHC channel parameters were
signalled when the Child SA was established, do they have to be
repeated when rekeying it?
(Probably the intent is "yes"; in that case, I'd suggest phrasing like
"ROHC channel parameters MUST be signaled separately for each
ROHC-enabled IPsec SA. Specifically, a new Notify message type MUST be
included in the IKE_AUTH and CREATE_CHILD_SA exchanges whenever a new
ROHC-enabled IPsec SA is created, or an existing one is rekeyed.")
Section 3.1.2
I found the discussion of MAX_CID confusing. MAX_CID is two octets in length
and has values
0..16383 and "indicates the maximum value of a context
Identifier". It then notes that
zero indicates a single context. Does that
mean that one indicates two contexts, and the value
16383 indicates a maximum of
16384 contexts?
I support Pasi's discuss on the IANA considerations.
draft-ietf-l3vpn-2547bis-mcast
draft-ietf-ipsecme-traffic-visibility
I'm generally supportive of this type of an extension, but I had two
technical problems that I wanted to talk about before recommending the
approval of this specification.
The first issue is the design for extensibility. The design is
problematic, as acknowledged by the draft when it says that middleboxes
may have to drop traffic with unrecognized WESP version numbers or that
intermediate nodes dealing with unknown reserved bits are not necessarily
able to correctly parse packets. The design seems suspect, and I'd like
to understand why this design was chosen. Basic requirements for
extensibility in most protocols include the ability to add information
without endangering the ability of protocol participants to parse
existing information. I believe this could actually be achieved with
a different design. In one design you would simply have a flags byte
but no version number. The basic format would always have a pointer
to the offset where the cleartext packet begins, and this would never
be changed by extensions. New flags could define additional information
elsewhere in the packet (between the start of the WESP header and the
offset where the actual packet begins, for instance) and this wouldn't
affect intermediaries that have no need for the additional information.
Another design could use the same rules about the flags but add a version
number if truly incompatible changes have to be made. Then again, the
only truly incompatible change that I can think of is "there is no
cleartext packet", and IMHO, that's not a proper extension of WESP.
The second issue is that Section 2 claims that the WESP version numbers
should be negotiated over a control channel. However, Section 2.3 does
not negotiate WESP version numbers, only the use of WESP.
By the way, I agree with Russ' Discuss.
The primary motivation for this work is to allow a middlebox to peek
into integrity protected (but not encrypted) IPsec packets. Some
integrity-check algorithms use an IV, a middlebox cannot alway know
where the payload starts. Unlike the IPsec peer that negotiated the
algorithm in the IKE exchange, the middlebox does not know which
integrity-check algorithm is in use, and thus doe s not know if an IV
is present or how long it might be.
The document allows the encapsulation of encrypted IPsec traffic.
Why? I cannot see the justification for the use if WESP at all if
the IPsec traffic is encrypted.
The document says:
>
> ... by preserving the body of the existing ESP packet format, a
> compliant implementation can simply add in the new header, without
> needing to change the body of the packet.
>
The figures in Section 2.2.1 and 2.2.2 show otherwise. The ESP ICV is
replaced by a WESP ICV. ESP processing is changed, and I cannot see
the justification for it. This is explained by:
>
> In the diagrams below, "WESP ICV" refers to the ICV computation as
> modified by this specification. Namely, the ESP ICV computation is
> augmented to include the four octets that constitute the WESP header.
> Otherwise, the ICV computation is as specified by ESP [RFC4303].
>
So, in fact, WESP is not an optional encapsulation of ESP. It is an
alternative to ESP with some duplicated fields (such as Next Header)
and pointers into the actual integrity-protected payload.
When talking about IKEv2 negotiation, the document says:
>
> The notification, USE_WESP_MODE (value TBD) MAY be included in a
> request message that also includes an SA payload requesting a
> CHILD_SA using ESP.
>
USE_WESP_MODE MUST be included if one wants to use WESP, right? The
use of MAY here leads me to think that there are other ways to select
the use of WESP in the IKEv2 exchange.
4. IANA Considerations The USE_WESP_MODE notification number is assigned out of the "IKEv2 Notify Message Types - Status Types" registry's 16384- 40959 (Expert Review) range: TBD. I assume the Expert Reviewer Okeyed this registration already?
This is a discuss-discuss.
I was surprised to see that the IANA rules for the four reserved bits are
"Specification Required".
Given the small number of bits and the unlimited
imagination of the IPsec community, aren't
we in danger of using the bits up
rather quickly? I think that IETF consensus would be less
risky.
(1) The abstract states "there is no way to differentiate between encrypted and unencrypted payloads", but section 1.2 notes that this differentiation can be achieved using heuristics. This seems to be in conflict. (2) In section 1.2, the text preceding the list states "there are two ways ... to distinguish between encrypted and unencrypted ESP traffic". Something tells me there are other possibilities. (3) section 2, paragraph beginning "Padding Present (P), 1 bit". The following text is about the padding field rather than the flag. I think both are needed, and suggest moving the padding text to follow the discussion of the reserved bits. (4) a description of how the padding field will be used for extensibility, and any limitations on the use of that field, should be documented here. (5) Section 2, next to last paragraph: is it really optional to extend the standard ESP header by 8 octets for IPv6? (6) Security considerations, paragraph 1: s/should be used to in determining/should be used in determining/
I plan to clear this DISCUSS after the IESG debates the question I am raising:
The approval write-up includes the following:
> We are not aware of any implementations. Neither do we know of any
concrete vendor plans to implement this specification.
One ma wonder - whys is a document discussed and approved on standards track of
there are no known implementations and no known plans for implementation
I am entering an abstain position on this due to that it doesn't appear to be a well enough motivated usage of an protocol number. The protocol number space is quite limited and this is basically a duplication of the ESP one. Yes, it attempts to provide some additional functionality. Due to the expressed limited support and lack of implementation I would have no problem if this proposal skipped requesting an protocol ID of itself and instead always relied on the UDP encapsulation. That way it only consume one code point from a IPsec specific range, that also is almost not utilized at all today.
draft-ietf-ccamp-confirm-data-channel-status
1. I think that the header should indicate that the document updates RFC 4204
(if approved). Especially on the light of the fact that section 4.4 states that
in order to use this mechanism all nodes MUST have the extensions described in
this document for compatibility.
2. It looks to me that beyond mismatches termination of the data channel
confirmation procedure because the retry limit was reached (the other side of
the link did not respons in time) should also be reported to the control plane -
the reason being that potential stranded resources may exist on these links
draft-ietf-l3vpn-ospfv3-pece
[BGP-EXTCOMM-IPV6] should be [RFC5701] and should probably be a Normative Reference.
draft-ietf-morg-status-in-list
Time to remove the Note at the top of page 2? idnits suggests that you should have an Introduction section.
draft-ietf-rohc-rfc4995bis
8. IANA Considerations
Following the policies outlined in [RFC2434], the IANA policy for
assigning new values for the profile identifier shall be
Specification Required: values and their meanings must be documented
RFC 2434 has been obsolete by RFC 5226. The definition of the "Specification
Required" seemed to have changed between 2 documents.
RFC 5226 defines
"Specification Required" as implying "Expert Review", while RFC 2434 doesn't
include Expert Review.
Can you please clarify what is the IANA registration
policy to be used here.
in an RFC or in some other permanent and readily available reference,
in sufficient detail that interoperability between independent
implementations is possible. In the 8 LSBs, the range 0 to 127 is
reserved for IETF standard-track specifications; the range 128 to 254
is available for other specifications that meet this requirement
(such as Informational RFCs). The LSB value 255 is reserved for
future extensibility of the present specification.
Please address (or at least reply to) SecDir comments by Stephen Hanna.
draft-ietf-tls-renegotiation
I have some sympathy with Russ's Comment, and my initial reaction having read the problem statement was to ask whether we actually need the renegotiation feature.
As a protocol climbs the IETF standards-track maturity ladder, we sometimes drop features. I would rather see renegotiation dropped from TLS than see this complexity added to TLS protocol.
Updated as per revision -02:
Sorry about flipping back and forth between YES and DISCUSS. But I think the
following text is a bit confusing. (I am happy to clear if I misunderstood
something):
4. Renegotiation Protection Request Signalling Cipher Suite Value
In order to enhance compatibility with such
servers, this document defines a second signalling mechanism via a
special signalling cipher suite value (SCSV)
"TLS_RENEGO_PROTECTION_REQUEST", with code point 0xNN, 0xMM. This
SCSV is not a true cipher suite and cannot be negotiated. It merely
has exactly the same semantics as an empty "renegotiation_info"
extension.
and then later on in the same section:
Note that a minimal client which does not support renegotiation at
all can simply use the SCSV in all initial handshakes. Any compliant
server MUST generate a fatal "handshake_failure" alert and terminate
the connection when it sees any (apparent) attempt at renegotiation
by such a client. Clients which do support renegotiation MUST
implement Section 3 as well.
Does this mean that any use of SCSV means that the client doesn't support
renegotiation? And does this mean that the use of the new TLS extension and the
use of SCSV are not the same thing?
3. Extension Definition This requirement to validate any received RI extension still applies even after previous The acronym RI should be explained on first use. handshakes on the same the connection or session did not negotiate the use of RI. Every handshake must be treated independently in this respect because the attacker may attempt to make an initial handshake appear as a renegotiation handshake or vice-versa. 7. Security Considerations [...] By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation. I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph? A TLS library MAY provide a means for the application to allow identity and/or server_name changes across renegotiations, in which case the application is responsible for tracking the identity associated with data it is processing. This may require additional API facilities in the TLS library.
I am satisfied that this solution is workable and resolves the problem at hand. I understand that other solutions exist and have been discussed within the working group, but I am less concerned about the details of the solution than getting a solution completed in a timely fashion. Let's approve this one now.
draft-klensin-ftp-registry
In this test from section 2.2:
Command Name - The FTP command, either new or modified, used in the
extension or with which the extension is used.
what does "either new or modified" mean?
In section 3, s/marke/marked/
There has been discussion of the comments in the Gen-ART Review by Ben Campbell. I expected some changes to the document based on the discussion.
First some background ….
The INAA registration procedures are under specified. and will just add to
confusion without adding much to existing commonly used IANA terms.
1. The
extension is described in an RFC or other generally-available
publication
for which the fact of publication indicates some
level of peer review of
document quality.
The term peer review will generate debate any time it is applied. Large portion
s of the academic community does not consider stander track RFC to be peer
reviewed. I on the other hand consider something that I ran by 3 other epode and
posted on my blog to peer reviewed. The "National Enquirer", which considers
itself a journal, has considerable proof all this articles are peer reviewed by
experts. I will argue that for all practical purposes, the above will be about
the same as FCFS.
2. The extension is actually implemented in FTP client and server
systems that are generally available (not necessarily either free
or unencumbered, but available) and those systems are identified
as part of the documentation requirement above.
This seems to highlight that the documentations requirements don't include any
requirement of other people being able to implement the and purely a description
would be sufficient for registration. For example "My secrete compression
extensions that will compress any file by a factor or 2". Generally available is
also a very vague term. I regally have people incest that something meant for
over a billion cell phones is not for "general use" and I also hear people
claiming something is generally available when a few grad students and two
differ universities causes a message or two to interoperate.
Creating new registration process just causes extra work and head aches for the
people that have to deal with them for years to come. For that reasons I would
have preference to choose one of the existing commonly used registration
practices unless there was some really good reason they were not adequate.
Inventing news ones is not easy.
From my point of view, I do not understand the motivation for this draft to need
smoother than FCFS, or it could choose Spec Required. Or it could choose a
combination of requiring either of
1) Spec Required, or
2) Combination of FCFS
along with Running Code
It's not like we have a zillion people developing FTP extensions and the code
space does not look at any risk of running out.
Now to the heart of my actual
Discuss. Why can't we use one of the existing common registration procedures? If
there is a special reasons something new is needed, I'm willing to be convinced
but I'd rather not create new things if not needed as they are not easy to nail
down.
draft-nottingham-site-meta
Section 5.1., paragraph 4: > Registration requests should be sent to the [TBD]@ietf.org mailing > list for review and comment, with an appropriate subject (e.g., > "Request for well-known URI: example"). I question the need to involve a list here - do we really expect such a volume of requests? I think normal Expert Review is sufficient.
Section 1 You might usefully include a reference for the Robots Exclusion Protocol
I voted Yes for this document, but please consider if the following comments are
worth addressing:
1. Introduction
While there are several ways to access per-resource metadata (e.g.,
HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
associated with them often precludes their use in these scenarios.
I would personally like to see an expanded version of this statement.
In particular "perceived overhead for whom" and why is it perceived.
3. Well-Known URIs
Note that this specification also does not define a format or media-
type for the resource at located at "/.well-known/" and clients
I think the first "at" should be dropped.
should not expect a resource to exist at that location.
5.1. The Well-Known URI Registry
Before a period of 14 days has passed, the Designated Expert(s) will
either approve or deny the registration request, communicating this
decision both to the review list and to IANA.
Personally I prefer to have 2 periods - the expect review period and the maximum
review period after which the requester can complain. This is what
I used in
one of my documents (6 weeks is the upper bound in this case):
Expert Reviewer should strive for timely reviews. Expert Reviewer
should take no longer than 6 weeks to make and announce the decision,
or notify the mailing list that more time is required.
Decisions (or lack of) made by an Expert Reviewer can be appealed to
the IESG.
5.1.1. Registration Template
Change controller: For standards-track RFCs, state "IETF". For
other open standards, give the name of the publishing body (e.g.,
ANSI, ISO, ITU, W3C, etc.). A postal address, home page URI,
telephone and fax numbers may also be included.
Question: can a new well-known URI be registered by an individual person and not
an SDO?
I.e. is it Ok for a reviewer to say "you are not an SDO, publish an RFC
or go away"?
This document looks fine with me, and I will clear my DISCUSS if IANA is certain
that they know what to do, but I think that there two of the paragrasphs in the
IANA COnsiderations section are slightly unconsistent:
> Well-known URIs are registered on the advice of one or more
Designated Experts (appointed by the IESG or their delegate), with a
Specification Required (using terminology from [RFC5226]).
> Registration requests consist of the completed registration template
(see Section 5.1.1), typically published in an RFC or Open Standard
(in the sense described by [RFC2026], section 7). However, to allow
for the allocation of values prior to publication, the Designated
Expert(s) may approve registration once they are satisfied that an
RFC (or other Open Standard) will be published.
RFC 5226 does not refer to an Open Standard as per RFC 2026 (supplementary to an
RFC)when refering to a Specification, but rather uses the term "permanent and
readily available". Experts usually interprete this as accepting specifications
that are not issued by an SDO as ITU-T, IEEE, ANSI examples used by 2026. Is the
intention here to be more restrictive than 5226 and recommend using only SDO
issued 'Open Specifications'?
Before approving this document, I would like a short discussion
with the IESG on the points below.
This document represents a significant deviation from the
conventional wisdom and long standing consensus around where
control for the assignment of URIs to resources lives.
The change will have a huge impact on client, server, and
application code. It will also impact server and
application policy.
This will put us on course for a web full of
conventions and expectations like:
https://www.example.com/.well-known/login
https://www.example.com/.well-known/shopping-cart
My initial (very negative) reaction to the draft was informed by
the earlier consensus. That said, the draft presents an informed
discussion of the tradeoffs made by taking this path, and it
does appear to scratch a real and spreading itch:
(Anecdote: Adam points to Thunderbird's use of
https://autoconfig.(hostname)/mail/mozilla.xml
deep in it's non-user-configurable javascript code)
So, I am willing to ballot No Objection, but would like to first talk through
these points:
1) There is some legacy text capturing the earlier wisdom that
will have to be adjusted. Has there been any activity yet
to identify the places that need touching and to start the
change process? (I'm looking at things like
http://www.w3.org/TR/webarch/#uri-assignment
for example).
2) As a quick sanity-check, could we talk through whether the
review of this document so far has been sufficiently broad
that we are unlikely to surprise anyone here, in the w3c, or
elsewhere that we shouldn't have surprised with a statement
of IETF consensus?
draft-melnikov-imap-keywords
Section 3., paragraph 21: > Registration of an IMAP keyword intended for common use (whether or > not they use the "$" prefix) requires Expert Review [RFC5226]. After > allowing for at least two weeks for community input on the designated > mailing list (as described above), the expert will determine the > appropriateness of the registration request and either approve or > disapprove the request with notice to the requestor, the mailing > list, and IANA. Any refusal must come with a clear explanation. Is list input & the required delay really necessary? Don't we trust the experts to do the right thing? Section 3., paragraph 22: > The IESG appoints one or more Expert Reviewer, one of which is > designated as the primary Expert Reviewer. IMAP keywords intended > for common use SHOULD be standardized in IETF Review [RFC5226] > documents. What does "primary" mean? Nowhere else in this document is described what sets this experts apart from the others. (Suggest to simply remove this.) Section 3.2., paragraph 1: > Once an IMAP keyword registration has been published by IANA, the > author may request a change to its definition. Who is the "author"? Do you mean the owner? Section 3.2., paragraph 4: > IMAP keyword registrations may not be deleted; keywords which are no > longer believed appropriate for use can be declared OBSOLETE by a > change to their "intended usage" field. I believe HISTORIC would be more correct (whenever we say "obsolete" we usually saw obsoleted by *what*).
Section 3 > Keywords intended for common use SHOULD start with the "$" prefix. > (Note that this is a SHOULD because some of the commonly used IMAP > keywords in widespread use don't follow this convention.) As discussed, you could insist that all new keywords intended for common use MUST start with the "$" prefix as a definition of the registry. ======= Nits --- Through-out "IMAP Keywords" of "IMAP keywords" ? --- Section 2 "cross client interoperability" What have the clients to be cross about? Try "cross-client"
draft-ietf-rohc-hcoipsec
I have reviewed draft-ietf-rohc-hcoipsec-12, and have couple of
concerns about the security considerations that I'd like to see
addressed before recommending approval of the document:
- Section 6.1.4, 3rd paragraph, doesn't really say why the current
ROHC integrity mechanisms are not sufficient (they're intended for
random packet loss/reordering, not malicious behavior). Perhaps
rephrase the second sentence as "However, bits in the original IP
header are not protected by this ICV, only by ROHC's integrity
mechanisms (which are designed for random packet loss/reordering, not
malicious packet loss/reordering introduced by an attacker)."?
- Section 6.1.4, 1st paragraph, should note that reconstructing
erronous packets can also happen without reordering (perhaps add
"Significant packet loss can have similar consequences." to the
end of the paragraph)
The OPS-DIR review by David Black raised several issues which were discussed
with the authors. However, at least a couple of the problems seem to have
remained unresolved in this version.
(1) Add text describing the limited use of the new Internet Protocol
Number. Specifically, this new number never occurs in the outer
IP header and is encrypted when ESP encryption is in use, but
may nonetheless require additional policies on firewalls or
other filtering middleboxes to ensure that ROHCOIPsec traffic
is not dropped.
(2) Explain what happens (how ROHCOIPsec behaves) when the IPsec traffic
is UDP-encapsulated (UDP header is between the outer IP header and
the ESP header). UDP encapsulation is very common for IPsec NAT
traversal purposes.
draft-ietf-tcpm-early-rexmt
If this doc is to be published as "Experimental", it should include plans to monitor the effect of protocol deployment on the operation of the Internet, and plans for experiments to determine if the protocol meets the goals and requirements.
Section 2 s/less than four/fewer than four/ I agree with the Comment about providing more description of the Experiment. For me, this is close to being a Discuss. I would like to see the scope of the Experiment, how it is isolated from the rest of the Internet (or a statement about why that is not necessary), and how the results will be evaluated. (Note that section 3.3 gives some hints.) Given the number of options left as a "choice for the implementer" I would like to see some Experimental objectives that will help to reduce the number of implementation options in the future.
draft-cheshire-dnsext-multicastdns
Seems this was a bit premature on the IESG agenda.
Would like to wait for the
considerable number of Last Call comments to be addressed in a new revision
before reviewing this.
---
Please answer IANAs questions
It is clear from Last Call discussion there should be a
new version with major differences. Wait for it.
Also, the IPR Statement from Apple says, provides access to
patented technology only if the document is "a standard
adopted by IETF." Since the long-term goal for this
protocol is a standards track RFC, it is not clear that
publication as an informational RFC at this time provides
much value to the Internet community.
It appears from comments by the author that a new draft is planned to resolve
issues raised in
IETF LC. I want a chance to read that version before moving to
No Objection.
draft-weiler-rsync-uri
In section 2, should "rsyncurl" be "rsyncuri" ?
I have reviewed draft-weiler-rsync-uri-01, and have a couple of
concerns that I'd like to see addressed before recommending approval
of the document (an RFC editor note would be fine):
1) Since Rsync is commonly run over different transports, it would be
good to explicitly say that this URI scheme is for the direct TCP
transport only, and does not support any other transports (like SSH or
TLS).
2) Section 4 probably needs to say that security considerations
of the Rsync protocol itself are not covered in this document.
I commend the brevity of this I-D. The Abstract is, however, very terse. http://www.ietf.org/id-info/guidelines.html says... An Abstract will typically be 5-10 lines, but an Abstract of more than 20 lines or less than 3 lines is generally not acceptable. How about adding... An rsync URI describes a source or destination for the rsync application including a hostname, path, and optional user and port. --- There are several mentions of "the rsync application." While "we all know what resync is", it would be nice to include a couple of lines to say what it is.
Nit: This is missing a normative reference to RFC 5234 (ABNF).
Otherwise this looks good to me.
draft-spencer-usefor-son-of-1036
In this paragraph from the Preface: The technical content remains unchanged, including the references to the document itself as a Draft rather than an RFC, the presence of unresolved issues, The original section numbering has been preserved, is something missing^^^here? although the original pagination has not (among other reasons, it did not fully follow IETF formatting standards). Section 9: the phrase "First, do no harm", may not actually come from the Hippocratic Oath (depending on your interpretation of [and trust in] the following info): http://en.wikipedia.org/wiki/Primum_non_nocere http://en.wikipedia.org/wiki/Hippocratic_Oath
draft-hajjeh-tls-identity-protection
At the end of Section 1... The reader is expected to become familiar with the TLS standards ([RFC5246] and, if needed, [RFC4346] and [RFC2246] for its predecessors) prior to studying this document. Well, is it needed to become familiar with RFC 4346 and RFC 2246? --- As with all Experimental RCs, I would have liked to see some description of the experimental parameters; how the experiment is to be set up, kept isolated, and evaluated.
I concur that note #5 from RFC 3932 applies.
draft-zeilenga-ldap-txn
What's experimental about this protocol extension and why is it on the independent stream rather than going for PS?
I note the email exchange with Kurt about why this I-D is presented as
Experimental. However, this document really isn't phrased as an
Experiment. For example, the Abstract says "This document extends LDAP
to support transactions." An Experiment would be more likely to say
"This document defines experimental extensions to LDAP to support
transactions. It is intented that these extensions be used in a
controlled environment while the experiment is evaluated."
I would also expect a note somewhere in the document that describes the
scope of the Experiment and says how it will be evaluated.
On the other hand, Kurt's explanation makes this work sound more like an
Informational publication. In that case the Abstract and Introduction
might include some text along the lines of "This document describes
extensions made to LDAP to support transactions in a private
implementation. The extensions are documented to allow other
implementers to understand this work and to leverage it if they want."
I think the section in the write-up labelled "IESG Note" should be labelled "Note to RFC Editor". The intent is not to put the text in that section into the document.
>3.5. Miscellaneous Issues > > Transactions cannot be nested. Can you clarify what you mean here? Do you mean that the client can't issue several Transaction Start commands in a row (on a single LDAP association)? >5. Distributed Directory Considerations > > This mechanism defined by this document does not support client-side > chasing. Transaction identifiers are specific to a particular LDAP > association (as established via the LDAP Bind operation). Just to double check: does this mean that transaction identifiers can't be reused on other LDAP connections and that they don't have to be globally unique? >10.2. Informative References > > [DONTUSECOPY] Zeilenga, K., "LDAP Don't Use Copy Control", draft- > zeilenga-ldap-dontusecopy-xx.txt, a work in progress. Expired?
draft-dolmatov-cryptocom-gost34102001
draft-dolmatov-cryptocom-gost341194
draft-dolmatov-cryptocom-gost2814789