IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-01-19. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
Section 2: "Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation)"
I don't see that RLOCs are any more amenable to aggregation than today's IP addresses. That is, the allocation scheme for RLOCs could be run such that RLOCs are aggregatable, but could equally be run such that it is hard to aggregate.
Maybe the points here are that:
- network attachment points are not (currently) mobile
- network attachment points are defined by the networks they attach to
- network attachment points, by definition, impose an aggregation of end points.
A way to solve this, if you wrote what you intended to write, would be a forward pointer to the section in the document that describes aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.
Section 2: "One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]."
Is the LISP working group undertaking controlled prototyping? Is the intention to state that "there are known protocotype implementations of [ALT]."
Similarly, what does it mean to say "have been described but not implemented"? I guess: "At the time of writing, the authors are unaware of any implementations of..."
Section 3: "When using multiple mapping database systems, care must be taken to not create reencapsulation loops."
What is this "care"? What about loops caused by transient conditions (or errors) in a single LISP mapping database? Shouldn't the payload TTL at least be decremented by one for each tunnel?
Note that reencapsulation is not the same as nested encapsulation. You are clear about avoiding the latter (although some form of DPI may be required to achieve it).
Step 7 of Section 4.1 doesn't make it clear what has happened to the first packet in the flow. I had assumed that it was buffered pending the Map-Reply, but I now suspect it was discarded as soon as the Map-Request was constructed. Can you add a clarification.
Telechat:
Telechat:
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat:
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
Item from the Secretariat
Item from the Secretariat
1344 EST Adjourned
(at 2012-01-19 07:30:04 PST)
draft-ietf-marf-redaction
I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there a plain text attack when encrypted material has a constant string included as seems to be the case here.
(Updated-discuss - thought about it a bit more;-)
(1) The construct here is output=H(redaction-key|sensitve-value).
I don't think that's ok. I think you want HMAC() and not H().
If I could supply a redactor with a zero length "private" string,
e.g. message with a header field like "To: @example.org" then the
redactor will send H(redaction-key) which can then allow (via
hash-continuation) checking if any value matches a value from an
output here.
If the alphabet for sensitive values has N characters
then I can also send "To: "+char[i]+"@example.org" for
each i and then play the continuation game on that.
Same for two character prefixes etc.
(2) I can also use this to validate guesses of the redaction
key value. I need to think about how one might avoid that
or if its possible to avoid that.
- I don't get why this is not informational - where's the interop consequence? - While the idea of only listing JD is laudable, I think having a concactable author is best so I'd suggest Murray be kept as an author. - Last para of section 1 - such correlation is not theoretical, delete that word.
Please reference RFC 4648, Section 4 for [Base64]. More than one alphabet is available in RFC 4648.
This is a rather short and aparently straight-forward document, but it raised a
couple of questions. None of them is that critical to deserve a blocking
DISCUSS, but yet I would be glad if these were answered and clarified before
approval and publication.
1. It is not clear why this document is on standards track. I do not know how to
establish interoperability of implementations and thus what the critieria would
be for advancement from Proposed Standard to Standard. Moreover the Abstract
describes the scope in a rather non-commital manner (suggests one method for ...
the report generator ... to redact or elide the sensitive portions of the
message) - so this looks like a recommendation about one (good way) to perform
redaction, but not the <standard way> of doing it.
2. I know too little about the operational model of configuring a report
generator, so I was left wondering how are the first two recommendations
implemented in practice:
> 1. Select an arbitrary string that will be used by an Administrative
Management Domain (ADMD) that generates reports. This string
will not be changed except according to a key rotation policy or
similar. Call this the "redaction key".
> 2. Identify string(s) (such as local-parts of email addresses) in a
message that need to be redacted. Call these strings the
"private data".
Some text that clarifies how this is supposed to be implemented and configured
in practice would be useful.
I agree with other IESG members that this document seems informational, not standards track.
Updated (add the last two) I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC. You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6194 for recent info on HMAC-MD5 and HMAC-SHA1. It would stop people from trying to do something over kill like HMAC-SHA256. If you're going to stick with the plain ole hash then pointing to 6151 and 6914 still is worth considering (i.e., MD5 bad). Probably worth a reference to RFC 4086 for the pseudo-random # issues.
draft-ietf-marf-authfailure-report
I have no objection to the publicaiton of this document as an RFC, but
here are a few trivial nits.
---
Please expand "AF" on first use in the Abstract, and show it as the
abbreviation of "Abuse Report Format" on first use in the Introduction.
---
Section 3.1
Delivery-Result: As specified in Section 3.2.2. This field is
OPTIONAL, but MUST NOT appear more than once. If present, it
SHOULD indicate the outcome of the message in some meaningful way,
but might be redacted to "other" for local policy reasons.
s/might/MAY/
---
Section 3.2.2
Please expand ADMD
---
Section 3.2.3
Please expand DKIM
---
Section 3.2.5
Please expand ADSP
---
Section 3.2.6
Please expand SPF
- Section 2.4 (esp the title) is a bit odd, I'm sure its there for a reason but its not at all clear to this reader. (But I don't mind) - 3.1 - who's SOURCE-IP is meant here? Might be clear from ARP but not so clear from here - same for REPORTED-DOMAIN. Better to be crystal clear really. - 3.2.1 - the "policy" value is a bit vague, but that's ok I guess. - I'm not 100% clear about the rule for handling DKIM and redaction. Is it that the sender just chooses whether to send the unredacted possibly-DKIM-valid value or the redacted version with no DKIM info, or are you just supposed to never (as in MUST NOT) send a redacted message if the message had DKIM header fields? That might be there but I missed it if so.
Section 2.3 states:
base64 is defined in [MIME].
Well, base64 is also defined in RFC 4648. :) Perhaps it would be better to say:
This specification mandates use of base64 as defined in [MIME].
Section 3.1 states:
Delivery-Result: As specified in Section 3.2.2. This field is
OPTIONAL, but MUST NOT appear more than once. If present, it
SHOULD indicate the outcome of the message in some meaningful way,
but MAY be redacted to "other" for local policy reasons.
I think "redacted" is not right here (causes confusion with the redaction I-D).
I suggest "set".
Section 3.1 also states:
For privacy reasons, report generators might need to redact portions
of a reported message such as the end user whose complaint action
resulted in the report. A discussion of relevant issues and a
suggested method for doing so can be found in
[I-D.IETF-MARF-REDACTION].
I don't think you can redact an end user. :) I suggest "an identifier or address
associated with the end user..."
Section 6.2 states: "These reports may be forged" and "DKIM failure reports may
produce reports". I suggest changing "may" to "can" and "might", respectively.
Section 6.3 states:
Limiting the rate of generation of these messages may be appropriate
but threatens to inhibit the distribution of important and possibly
time-sensitive information.
Do you mean "MAY"?
Section 6.5 states:
The use of this for "near-identical" incidents in particular causes a
degradation in reporting quality, however. If for example a large
number of pieces of spam arrive from one attacker, a reporting agent
may decide only to send a report about a fraction of those messages.
While this averts a flood of reports to a system administrator, the
precise details of each incident are similarly not sent.
Do you mean "MAY"?
I find it a little odd that the requirements language for what's optional/required in the different reports (s3.2.*) appear in the section titles but not in the text.
draft-ietf-netext-radius-pmip6
The security considerations section refers to 2865, 2866 and 3579
which do have pretty good security considerations. However, this
spec seems to me to introduce new things, such as sending the
interface ID, which I think raises at least new privacy
considerations. The ones that I think may be relevant here are the
Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the
PMIP6-Visited-Interface-ID, Calling-Station-Id and the
Chargeable-User-Identity. Since I'm not quite sure how these are
intended to be used, I'm also not sure what, if anything, needs to
be said about them in security considerations, so I'd like to
DISCUSS that.
How is the right policy store/profile selected? I suspect this is covered elsewhere (probably in 5213?) but it wasn't clear to me.
The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern
and several editorial suggestions. The authors and Elwyn seem to
agree that the following text will resolve the concern, but it is not
in the document yet:
When this bit is set the PMIP6_SUPPORTED flag MUST also be set,
and the IP4_HOA_SUPPORTED flag MUST NOT be set.
4.3. Service-Selection
The Service-Selection attribute (Type value TBD2) is of type UTF-8
text and contains the name of the service or the external network
that the mobility service for the particular MN SHOULD be associated
with [RFC5149]. The identifier MUST be unique within the PMIPv6
Domain.
I've got a question about being "unique". My understanding is that UTF-8 text is
normally used in Radius for "display to the user only" text and is not compared
to other pieces of text. Here you say it "MUST be unique". How "unique" does it
need to be? That is, if one identifier contains an "a" followed by a combining
acute accent (U+0061 U+0301), and another identifier contains the a-with-acute-
accent (U+00E1), are those "unique"? I guess the main question is: What are
these things being used for and will the above make a difference? I think either
way, some more information is needed in this paragraph to explain.
I concur with the DISCUSS position lodged by Pete Resnick.
draft-ietf-netext-bulk-re-registration
There are several uses of 2119 language in section 5 and 6 that are
inappropriate:
5.1: I have no idea why "The following considerations MUST be applied by the
mobile access gateway when supporting this specification" is at all useful. The
entire sentence should be deleted.
5.1.1: This is worded oddly. It's not that the data structure "MUST be
extended", it's that the new fields MUST be included. I think what you probably
mean is, "The conceptual Binding Update List entry data structure maintained by
the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to
include the following REQUIRED additional fields." Of course I assume that they
are now "required for interoperation" [2119] or that not having them "has
potential for causing harm". [2119] If not, then there shouldn't be 2119
language at all.
5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the
following considerations" adds. The requirements are in the paragraphs below. If
you don't want to strike the sentence, sufficient would be, "The following are
considerations for the mobile access gateway for requesting bulk binding update
support for a mobility session."
I think the "MAY" in the first bullet should be "can".
In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be
applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise,
what you're saying is "You MUST do everything in section 6.9.1 that says MUST",
which seems silly and redundant.
5.1.3: In the first and second bullet, s/MAY/can
Also, the last sentence of the first and second bullets have the same problem as
the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps
instead, say something like "The requirement of section 5.3.3 of [RFC5213] is
amended to allow a Mobile Node Group Identifier in place of the individual
session identifiers."
In the third bullet, the MUST seems useless. How could the gateway not
"consider the request as a bulk revocation request"?
5.2: Similar to 5.1.
5.2.1: First sentence similar to 5.1.1.
5.2.2: First sentence similar to 5.1.2. But I would simply move the first bullet
up into that first sentence so it says:
5.2.2. Enabling Bulk Binding Update Support for a Mobility Session
The local mobility anchor will process a received Proxy Binding
Update message as specified in [RFC5213]. However if the (B)
flag in the received Proxy Binding Update message is set to a
value of (1) and if it includes a Mobile Node Group Identifier
option with sub-type value of (1) (bulk binding update group), the
following processing takes place:
In sections 6.1 and 6.2, I am concerned about the statements containing "MUST
allow the following variables to be configured by the system management" since
that seems to go against 2119 where it says that the terms "must not be used to
try to impose a particular method on implementors where the method is not
required for interoperability." Is there an interoperability reason that these
variables MUST be configurable?
Also, the SHOULD and MUSTs in the definition of the variables doesn't seem
right. These are not protocol requirements; they are descriptions of the meaning
of the variables.
Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request is rejected. One place to do this is 5.2.3 bullet 4, where you could say "for any reason (including administrative)" instead of "for any administrative reason".
draft-ietf-ospf-multi-instance
I agree whole-heartedly with Adrian's Discuss regarding redefining fields from another RFC rather than referencing them.
I would be happy to ballot Yes on this document, but there are a couple
of minor areas where I think the document needs work.
---
I have a hot button about redrawing and redefining protocol fields.
There is a risk in this duplicaton, and problems for future extensions.
Your figure in Section 2 reproduces material from RFC 2328. How much of
this is necessary? Is it helpful to sometimes say that a field is "as
specified in [OSPFV2]" and sometimes write text that duplicates RFC 2328
without actually changing anything?
I think you might get away with the figure and text that says:
All fields are as defined in [OSPFV2] except that the Instance ID
field is new, and the AuType field is reduced to 8 bits from 16 bits
without any change in meaning. The Insatnce ID fiels is interpreted as
follows:
---
In Section 8 you need to inform IANA that you have reduced the available
range of values for AuType. This changes the registry.
---
The registry in Section 8 shows a number of instance ID value settings
(namely "Base IPv4 Multicast", "Base IPv4 In-band Management Instance",
and "Local Policy") without any discussion of the meaning in this
document. That will not do! You must add description of the meaning of
these settings somewhere in the body of the document.
---
Section 8 describes the allocation policy for the range 3-127 as
"Reserved for local policy assignment". There is no such allocation
policy in RFC 5226. Do you mean "Private Use"? It is hard for me to
guess given the totla lack of description of this range of settings as
noted in my previous point.
I have a few additional Comments that I think would improved the document and I hope you will consider incorporating them into a new revision. --- The Abstract is very dense. Nothing wrong with what you have written, but it's quite hard work. How about... OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilise such a mechanism in order to support multiple routing domains on the same subnet. This document defines the OSPFv2 instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where te instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 instnce ID is reserved for identifying protocol instances. This document updates RFC 2328. Note that I have left out of the Abstract the statementabout how a different funciton is supported by a diffenent protocol extension defined in a different document! --- You are inconsistent about whether to say "OSPF" or "OSPFv2" when refering to OSPFv2. Given that you keep comparing to OSPFv3, I think it would be helful to always say "OSPFv2". --- You use phrases such as "OSPFv2 currently doesn't offer" which are, of course, correct before this becomes an RFC, whereupon they become wrong. If you can avoid this sortof thing by saying "This document defines..." then the draft is future-proofed. --- Can you please replace the future tense with the present tense. For example, Section 3 OSPF [OSPFV2] describes the conceptual interface data structure in section 9. The OSPF Interface Instance ID will be added to this structure. The OSPF Interface Instance ID will default to 0. --- Section 3.1 When sending OSPF packets, if the OSPF Interface Instance ID has a non-zero value, it will be set in the OSPF packet header. Surely the zero value is also set in the packet header. That is, the field is not left uninitialised.
Yep, I agree with all the "what a hack" comments. OTOH, I do agree that its not likely that a 256th auth type will be needed here. I also agree that the abstract is very unclear and should be rewritten.
Although the authors appear to have documented the interoperability implications of reducing the AuType field from 2 octets to 1 octet, that still feels like a hack to me. However, I lack the context to judge whether the implications have been fully understood or documented. (Note also that this issue is not even mentioned in the shepherd writeup!)
The abstract (identical to the introduction except for references) doesn't actually describe what this document does.
I'm with Peter on this draft - I too lack the background and ultimately trust that the AD is doing the right. But, I am curious why this wouldn't be a version # change especially if it affects all implementations.
draft-ietf-kitten-sasl-saml
I cleared.
The Gen-ART Review from Ben Campbell was updated on 13-Jan-2012.
Ben provided a Gen-ART Review of -06 at Last Call, and this updated
review covers -08. Version -08 is considerably improved, and it
resolved most of Ben's comments. I would like to see responses to
these four comments;
1) section 3.2, last paragraph: "... needs to correlate the TCP
session from the SASL client with the SAML authentication."
Please elaborate on this correlation. The author added text, but
the new text is about correlating response with request. The text
that Ben mentioned was about correlating a TCP connection to a
SAML authentication.
2) section 4, 3rd and 4th paragraphs (paragraphs a and b) seem like
protocol affecting differences. If so, they need elaboration, such
as normative statements and formal definitions, or references to
such.
Ben did not see a response to this comment.
3) section 5, general: The section seems to need further elaboration
or references.
Ben did not see a response to this comment.
4) Also, this section compresses the interaction with the identity
provider. Why not show the details for those steps like the others?
(If you mean them to be out of scope, then why give as much detail
as you do?)
Ben did not see a response to this comment.
8.2. IANA OID The IANA is further requested to assign an OID for this GSS mechanism in the SMI numbers registry, with the prefix of iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to reference this specification in the registry. What the document is actually asking IANA is to assign a new entry in the sub- registry for SMI Security for Mechanism Codes whose prefix is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5)
This is a valuable document and I support its publication. However, in addition
to the comments provided below (some of which border on DISCUSS points), I'd
like to chat about internationalization. Section 3.1 states:
Domain name is specified in [RFC1035].
Does this technology have no support for internationalized domain names
(IDNs) as defined by RFC 5890 - RFC 5894?
Section 1...
s/is a modular specification that//
OLD
As currently envisioned, this mechanism is to allow the interworking
between SASL and SAML in order to assert identity and other
attributes to relying parties.
NEW
The mechanism defined in this document enables interworking
between SASL and SAML in order to assert identity and other
attributes to relying parties.
Question: in order for what to assert identity? An application? A client? A
user?
"This specification is appropriate for use when a browser is available."
When is it not appropriate? What are its limitations?
Section 1.2...
In Section 1 we find:
The mechanism assumes a security layer,
such as Transport Layer Security (TLS [RFC5246]), will continue to be
used.
However, here we find:
"the SAML mechanism MUST only be used over channels protected by TLS"
Therefore is the "such as" in Section 1 correct? If so, then I think the
text in Section 1.2 could be reworded as follows:
Because this mechanism transports information that should not be
controlled by an attacker, the SAML mechanism MUST only be used over
channels protected by TLS, or over similar integrity protected and
authenticated channels. In addition, when TLS is used the client
MUST successfully validate the server certificate.
Section 2...
This is hard to read:
2. The Relying Party redirects the browser via an HTTP redirect (as
described in Section 10.3 of [RFC2616]) to the Identity Provider
(IdP) or an IdP discovery service with as parameters an
authentication request that contains the name of resource being
requested, a browser cookie and a return URL as specified in
Section 3.1 of the SAML profiles 2.0 specification
[OASIS.saml-profiles-2.0-os].
I suggest:
2. The Relying Party redirects the browser via an HTTP redirect (as
described in Section 10.3 of [RFC2616]) to the Identity Provider
(IdP) or an IdP discovery service. When it does so, it includes
the following parameters: (1) an authentication request that
contains the name of resource being requested, (2) a browser
cookie, and (3) a return URL as specified in Section 3.1 of the
SAML profiles 2.0 specification [OASIS.saml-profiles-2.0-os].
In the paragraph following that one (bullet point 3), what does it mean
to "authorize the authentication to the Relying Party"? What entity is
the user authorizing here? The IdP?
s/Universal Resource Identifier/Uniform Resource Identifier/
This is a bit terse:
4. The SASL client now sends an empty response, as authentication
continues via the normal SAML flow.
You might consider citing the following paragraph from RFC 4422:
Where the mechanism specifies that the server is to return additional
data to the client with a successful outcome and this field is
unavailable or unused, the additional data is sent as a challenge
whose response is empty. After receiving this response, the server
then indicates the successful outcome.
(That is, in this case the server is waiting for information it will
receive via the SAML flow before it can indicate the successful outcome.)
We might want to expand a bit on this:
6. Next the client authenticates to the IdP. The manner in which
the end user is authenticated to the IdP and any policies
surrounding such authentication is out of scope for SAML and
hence for this draft. This step happens out of band from SASL.
For example, do any specifications provide guidance here (perhaps to use
basic or digest HTTP authentication)? Also, why say "client" in the first
sentence and "end user" in the second sentence? Does that difference have
meaning?
Section 3...
The mechanism is capable of
transferring an authorization identity (via the "gs2-header").
Does this mean that an authorization identity can be communicated only
when GS2 is used?
The third mechanism message is from client to the server, and is the
fixed message consisting of "=".
You might append "(i.e., an empty response)".
The SASL server now validates the response it received from the
client via HTTP or HTTPS, as specified in the SAML specification
That is a bit unclear -- are we assuming that the SASL exchange takes
place over HTTP? The examples (IMAP, XMPP) belie such an assumption. Or
do you mean that the SASL server (as SAML relying party) needs to make
a connection between (1) its application-specific SASL exchange with the
SASL client and (2) its HTTP-based SAML exchange with the IdP?
Section 4...
This is a bit underspecified:
The mutual authentication property of this mechanism relies on
successfully comparing the TLS server identity with the negotiated
target name. Since the TLS channel is managed by the application
outside of the GSS-API mechanism, the mechanism itself is unable to
confirm the name while the application is able to perform this
comparison for the mechanism. For this reason, applications MUST
match the TLS server identity with the target name, as discussed in
[RFC6125].
In particular, see Section 13.7.1.2.1 of RFC 6120 for an example of
the kind of thing you probably ought to specify.
Section 5...
At the least, citing RFC 5056 ("On the Use of Channel Bindings to Secure
Channels") seems appropriate here.
Section 6...
In the XMPP flow, I would change <incorrect-encoding/> to
<temporary-auth-failure/> for the error that occurs if no SAML
Authentication Request can be constructed.
Later in the flow, I would also change <temporary-auth-failure/> to
<not-authorized/> (e.g., because the credentials are wrong).
In the XMPP flow, I think you don't need Steps 8-11. That's post-auth
stuff specific to XMPP.
The IMAP example uses "xmpp.example.com" -- I assume you might want
to change that to "imap.example.com" or "mail.example.com".
Section 8...
The registration does not include all the information requested from
the template in Section 7.1.1 of RFC 4422 (e.g., intended usage).
f1, s2, and f2: If you're talking about the scheme isn't it HTTPS? r/HTTPs/HTTPS s6.1: If you're referring to 4648 then you need to specify which alphabet is to be used.
draft-ietf-idr-fsm-subcode
I intend to change this DISCUSS to a YES. However, I think that this draft
should UPDATE RFC 4271.
There was a last call comment from Ran Atkinson that said:
I have read this short document and am familiar with its
contents. I am not a BGP implementer, instead I am a BGP
user (as are several of my clients).
Summary: Security Considerations are missing
The absence of any substantive "Security Considerations"
is problematic and needs to be corrected prior to approval.
As an example, creating these sub-codes will greatly facilitate
active probing of remote routers for "OS fingerprinting" or
"BGP fingerprinting", which might be used in future to determine
the manufacturer, software-version, and possibly hardware model
of the remote router.
In turn, such fingerprinting can facilitate targeting attacks
against security issues present in certain software versions
or software+hardware combinations.
I do not object to the principle of adding these sub-codes,
but the practical operational security risks ought to be
fully and clearly documented before this draft proceeds.
Without agreeing or disagreeing with what Ran has said, I expect IETF
last call comments to be resolved through discussion on the IETF list
before te I-D is approved.
---
I am unclear whether this document is intended to update RFC 4271. Is
the plan that all future BGP implementations need to include this work,
or is the inclusion optional? As currently presented, it is optional.
I also support Adrian's first discuss point.
The IANA Considerations section states:
IANA is requested to create the registry "BGP Finite State Machine
Error Subcodes", within the "BGP Error Subcodes" registry, with
Registration Procedures "Standards Action process or the Early IANA
Allocation process".
As far as I understand it, "Standards Action" is a registration process (per RFC
5226) but there is no such registration process as "Early IANA Allocation". It
is true that RFC 4020 defines procedures for early allocation of code points,
but that does not mean that early allocation is a registration process. Given
that early allocation is always possible when the registration process is
"Standards Action", it is proper to remove the text " or the Early IANA
Allocation process" from the quoted paragraph. Alternatively, you could say
something like this:
IANA is requested to create the registry "BGP Finite State Machine
Error Subcodes", within the "BGP Error Subcodes" registry, with a
Registration Procedure of "Standards Action" as defined in [RFC5226]
(naturally, early allocation of such subcodes is allowed, in accordance
with [RFC4020]).
I support Adrian's discuss.
draft-ietf-mile-rfc6046-bis
I wonder how easy it is to find a HTTP client implementation that won't follow 3xx response codes. I don't know, just wonder:-)
The Gen-ART Review by Alexey Melnikov on 14-Jan-2012 lead to a
discussion with the authors. They seem to have settled on agreed
changes to the document, but the changes have not been made yet.
First, thank you for addressing the comments that Julian Reschke provided on behalf of the Apps Directorate. Section 3 states: RID systems MAY be configurable to listen on ports other than the well-known port; this configuration is out of band and out of scope for this specification. and: When performing RID callback, a responding system MUST connect to the host at the network-layer address from which the original request was sent; there is no mechanism in RID for redirected callback. This callback SHOULD use TCP port 4590 unless configured out of band to use a different port. What does it mean to configure a RID system out of band? As far as I can see there is no *in-band* configuration method (i.e., a RID system cannot be configured via RID messages), so the use of "out of band" here is confusing. I suggest removing this terminology in both instances. The ABNF reference is old; please change [RFC2234] to [RFC5234]. Section 3 states: RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual authentication for confidentiality, identification, and authentication, as in [RFC2818], when transporting RID messages over HTTPS. The phrase "as in [RFC2818]" makes it sound as if the rules specified in RFC 2818 are the kind of rules that might be used, not that those rules must be followed. If the intent is that the identity-checking rules in RFC 2818 always apply to RID systems, I suggest changing the text to: RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual authentication for confidentiality, identification, and authentication when transporting RID messages over HTTPS. RID systems MUST follow the rules specified in [RFC2818] regarding verification of endpoint identities.
draft-ietf-mile-rfc6045-bis
I found the first sentence of the Introduction confusing!
This document moves Real-time Inter-network Defense (RID) [RFC6045]
to Historic status as it provides minor updates.
While I can see that this document moves RFC6045 to Historic, I bet it
is not your intention to say that RID is Historic.
How about:
Real-time Inter-network Defense (RID) was previously defined in
[RFC6045]. This document makes some minor updates to the RID
specification and moves RID from an informational specification
onto the standards track. This, this document obsoletes RFC 6045
and moves it to Historic status.
(Maybe as a standalone paragraph and not running into the the main
text?)
I've a few things here that are easily fixable I hope after
which I'll be happy to ballot yes.
1) I'd like to understand why LawEnforcement is a good thing to
include here and why its not some form of slippery slope that ends
up going against IETF consensus as represented by rfc2804. This
protocol would contain LawEnforcement and Tracing. I realise
that's not wiretap, but its also not very different. It also
doesn't seem to be technically necessary. Perhaps a better label
might be "preserve evidence" or something which might also apply
between CSIRTs. (Following on from the response to Robert's
discuss.)
2) LawEnforcement, OfficialBusiness and AccrossNationalBoundaries
are odd. I'm not sure why an Internet protocol should distinguish
between different things like this. Wouldn't it be silly if there
were a value there for "DealingWithAGuySellingShoes" so I don't
see why any bit of any government is any different for this
protocol. What's done differently on the basis of these fields
that cannot be (maybe better) done based on the identity of the
peer and the transport endpoints used?
3) There seem to be a bunch of 2119 terms misused in 9.5, e.g.
"MUST be addressed" is too vague, ("Yeah, I thought about it, but
I figured I'd do nothing much. Ok I've addressed that";-), "MUST
be informed" is a little ambiguous (would page 99 of a legal
agreement meet the requirement?), "MUST be considered" is too
vague, "MUST ... adhere ... to goverment ... regulations" is
funny since no one piece of code can do that, etc. etc. And while
the sentiment behind "must ... not (be) used for ... censorship"
is laudable, I don't see how that can be done. I think most or
all of the 2119 terms in this section could be profitably
revisisted to be made something with which an implementer or
deployment could be made to conform. (I didn't notice the same
problem in other sections but it might be worth a pass to check.)
- Expand CSIRT on first use (and maybe include a reference?) - The FBI is not a good example and not really needed. Precede it with United States or something if you keep it. - What is an "intermediate party" (p32) shouldn't stuff like that be explained up front? What's the model for multiple hops here - are requests and responses supposed to be passed on without any controls on the intermediary or not? If not, then what controls and how do those impact on the protocol? - Corner case security consideration - related to figure 8, if I can monitor the n/w connections of SP3, then when SP3 receives a message from SP2 and then replies to SP2 *and* SP1 then I get to know for whom SP2 was forwarding the request. Not sure if that's significant really but I guess it could alert a bad guy to stop doing stuff before the final tracing stage happens. I guess the only mitigation would be traffic padding of some sort if (as I suspect) traffic volunes here are small. (Does RID support traffic padding?) If you ever allowed an insecure transport then this might get worse, if the bad guy could flip a bit in the request and then see the ack to SP1 connection being attempted, then the bad guy gets his warning but SP3 hasn't got the message. - 9.3.2 is oddly titled, seems like you're really talking about a signature being verifiable at many veryifiers. - I don't get what "In some situations, all network traffic of a nation may be granted through a single SP. " means. (p73)
First, I'd like to thank you for addressing the comments provided by Larry
Masinter in his Apps Directorate review.
There are a few topics I'd like to chat about.
1. The document does not pass ID-nits! You might need to fix the document in
order to address the following errors and warnings:
== Missing Reference: 'XMLschema' is mentioned on line 3519, but not defined
== Missing Reference: 'RFC5735' is mentioned on line 1811, but not defined
== Unused Reference: 'CVRF' is defined on line 3720, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 3741
** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)
** Downref: Normative reference to an Informational RFC: RFC 6046
2. This document inherits the definition of Node from the NodeName class in RFC
5070. Although the IODEF specification defines a NodeName as a fully-qualified
domain name, it does not provide a definition of that term and specifically does
not say whether internationalized domain names (IDNs) are allowed. This is a
significant oversight for a modern protocol.
3. The definition of AcrossNationalBoundaries is confusing. First it says that
this value must "MUST"?) be set if the message will cross national boundaries
(and how exactly is the sender to determine whether the the message will in fact
cross national boundaries?). Then it says that this value is ("MUST BE"?) used
when additional handling and protection restrictions based on the data type and
location, which is not the same thing as crossing national boundaries. Then it
says that this value must be set if the security requirements of the message
might not apply to all nations. Then it says that this value must be set if the
traffic is of a type that may have different restrictions in other nations. This
is such a muddle that I don't see how an SP could choose any value other than
AcrossNationalBoundaries.
4. In Section 7, some of the examples include XML comments. Are these allowed?
Are any other aspects of XML disallowed (e.g., processing instructions and
external DTD subsets)? Can conforming applications ignore or reject such data? I
think the processing rules and security considerations are underspecified here.
At the least, it would be helpful to cite RFC 3270 and RFC 3023 with regard to
the use of XML in IETF application protocols.
The Introduction would be easier to read if the summary of changes since RFC
6045 were moved to an Appendix.
Please expand "FBI" on first use, preferably via "U.S. Federal Bureau of
Investigations (FBI)".
Section 4.1.1 introduces the BOOLEAN data type, which is implemented as the
xs:boolean type from W3C XML Schema. It would be helpful to note that there are
two lexical representations of boolean in XML schema. I suggest changing the
text as follows.
OLD
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
the schema.
NEW
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
the schema. Note that there are two lexical representations for
boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false'
for FALSE.
In Section 5, why is this document defining a 'lang' attribute when any XML data
can include the 'xml:lang' attribute via inheritance from the core XML
specificiation?
The class definitions are inconsistent. I see several styles, such as:
One.
Zero or one.
One or more. REQUIRED.
REQUIRED. ENUM.
One or many. REQUIRED.
Zero or One. URL.
Zero to many.
It would help to make those consistent.
Section 5.1 states:
The RIDPolicy Class includes the ability to embed an IODEF or
other XML schema document in the ReportSchema element.
I don't think you're embedding XML schema documents, I think you're embedding
XML documents that conform to schemas other than IODEF.
Section 5.1 states:
PolicyRegion
One or more. REQUIRED. The values for the attribute "region" ....
Is that supposed to be "PolicyRegion"?
In Section 5.1.1, is "XMLDocumen" a typo?
In Section 5.3, why is the IncidentSource restricted to FQDNs (Nodes)? It seems
that the source of an incident might be an IP address, an email address, etc.
This text in Section 5.4 is confusing:
The RID schema declares a namespace of "iodef-rid-2.0" and registers
it per [XMLNames]. Each IODEF-RID document MUST use the
"iodef-rid-2.0" namespace in the top-level element RID-Document.
In fact the namespace is not "iodef-rid-2.0" but "urn:ietf:params:xml:ns:iodef-
rid-2.0". In addition, the "Namespaces in XML 1.0" specification says nothing
about registration of XML namespaces; perhaps you meant to cite RFC 3688?
In Section 5.5.1, do you really intend to include schemas, or documents defined
by other schemes?
The text in Section 6 is a bit misleading when it says that "The IODEF model
MUST be fully implemented to ensure proper parsing of all RID messages." That's
true only for RID messages that contain IODEF payloads, not RID messages that
contain payloads defined by other schemas.
In Section 8, the XML comment is quite distracting. Why not include this
information in the xs:annotation element?
Section 9.1 states:
o The originator of a Request MUST use a detached signature to sign
at least one of the original elements contained in the RecordItem
class to provide authentication to all upstream participants in
the trace or those involved in the investigation.
Is this required even in cases where channel encryption (e.g., TLS) is used
between the parties to a PeerToPeer exchange that doesn't involve upstream
participants? (By the way, it seems that some of the examples in the spec
violate the rule from SEction 9.1.)
In Section 9.1, do you mean "MAY" in the text "The IODEF/RID document may be
encrypted"? The same question applies to "The action taken in the Result message
may be encrypted". The difference between conformance and normal usage is
especially confusing in a sentence like this:
A Request, or any other message type that may be relayed through
RID systems other than the intended destination as a result of
trust relationships, may be encrypted for the intended recipient.
I encourage you to check all the text in Section 9.1 (and elsewhere) to make it
clear whether you intend your guidelines to have conformance force.
It's a bit confusing to say in Section 9.1 "See Section 9 for a discussion on
public key infrastructure (PKI) and other security requirements." I think you
mean Section 9.3. :)
Section 9.2 states:
The transport specifications are fully defined in a separate document
[RFC6046-bis].
I think you mean "A transport specification" because it seems that you are
leaving the door open to defining other transport bindings in the future.
Section 9.2 states:
The RID protocol must be able to guarantee delivery and meet the
necessary security requirements of a state-of-the-art protocol. In
order to guarantee delivery, TCP should be considered as the
underlying protocol within the current network standard practices.
There's a lot more to truly guaranteed delivery at the application layer than
simply using TCP as the underlying transport. Do you mean at least once
delivery, at most once, or something else? Do messages need to be persisted in
case the messaging system crashes? And so on. You might consider dropping this
paragraph, or clarifying what you really mean by guaranteed delivery.
I find this a bit confusing:
Consortiums may vary their selected transport mechanisms and thus
decide upon a mutual protocol to use for transport when communicating
with peers in a neighboring consortium using RID. RID systems MUST
implement and deploy HTTPS as defined in the transport document
[RFC6046-bis] and optionally support other protocols such as the
Blocks Extensible Exchange Protocol (BEEP) [RFC3080].
If consortia are allowed to decide upon their own preferred transport bindings,
why is HTTP/TLS a MUST-deploy technology?
As to "optionally support other protocols", clearly someone would need to define
bindings for those protocols (BEEP or XMPP or SIP or whatever) before they could
be used -- it appears that one can't simply start sending RID documents over
those protocols without some definition of the binding (as is already done for
things like SOAP). So the current text is a bit misleading.
Section 11 states:
Registrant Contact: See the "Author's Address" section of this
document.
However, RFC 3688 states:
In the case of IETF developed standards, the Registrant will be the IESG.
(Hit send too soon - sorry - there's an additional comment added at the end)
What motivated the addition of the LawEnforcement PolicyRegion? The other
PolicyRegion region definitions give some hint about how the mark might affect
processing. It's not clear how this marking this region is required for (or
helps) interoperability.
Possibly related - the definition of the OfficialBusiness TrafficType (inherited
from 6045) is vague. What an example of an "other official business request"
that's not a government request? Is there an example of a request that should
use this mark that's not related to a legal investigation?
Can the document make it clearer how either of those enumerated values will be
used (not just when a sender might
set them)?
As this is moving from Informational to Standards Track, should there be any
policy captured in the document around adding values to PolicyRegion and
TrafficType enumerations? (For example, someone may wish to mark messages
moving
across HEPA or FERPA controlled boundaries.)
draft-ietf-lisp-map-versioning
--------------------------------------------------------------------------------
-
Section 5.1, Bullet 2: Do you really want to drop this packet? Won't this
condition occur whenever the following are true:
- multiple ETRs serve the site
- a mapping update is in progress
- the ETR receiving the packet has not yet been updated
- another ETR has been updated
- the ITR received its mapping from the ETR that has been updated.
--------------------------------------------------------------------------------
--
Section 5.3, Bullet 3: Do you really want to drop this packet. Same argument as
above, but viewed from the other side of the tunnel.
--------------------------------------------------------------------------------
---
This document should have an up front (Introduction) statement recording the
issues stated in section 12, since without that statement the reader has the
impression for most of the document that this is a fully baked solution.
In particular the document seems to be saying that without the synchronization
problem being solved their are significant issues with this mechanism. That
would suggest that we ought to solve the synchronization mechanism at least in
some rudimentary way before publishing this element of the LISP specification
series.
There are many abbreviations that are used without expansion in the Introduction. Appendix A is confusing firstly because it is unclear as as to whether the 12 bits is right on the edge of acceptability, or is a realistic number that will be useful for the foreseeable future. Secondly it explains how wonderful it would be to have between 16 and 32 bits of version without providing any information on whether this is realistic to retrofit into the protocol.
In my opinion, draft-ietf-lisp-interworking should
be a normative reference in this document. All
of section 8.3 seems to depend on the details
of the interworking mechanisms in draft-ietf-lisp-interworking.
I've reviewed this document to the extent possible
without reviewing draft-ietf-lisp-interworking, which
has not yet come up for IESG review. This document
will require additional review once draft-ietf-lisp-interworking
has been reviewed, to ensure any changes in
draft-ietf-lisp-interworking are reflected in this document.
I am holding this Discuss until the resolution of my Discuss on the main LISP
specification that is a normative reference.
depending on how that is resolved, this document will need a pointer to the
disclaimer text added to the base LISP spec.
All other issues I raised on this document have been resolved.
If there's conflict in normative text between this and base, which takes precedence? I think you need to say, even if you believe there is no such conflict, just in case it turns out that there's some hidden conflict or the base draft changes after this one is done.
It's hard to imagine that anyone would treat values as other than big endian, but it might be worth being explicit in the document.
draft-ietf-pcn-signaling-requirements
"The representation of a PCN-flow identifier depends on the
surrounding environment, e.g., pure IP, MPLS, GMPLS, etc.
Examples of such PCN-flow identifier representations can be found in
[RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. "
The above text implies that it is a simple matter to identify
and represent an MPLS flow. I do not believe this to be the case.
The authors should either specify how they propose to
represent MPLS flows (as they do for IP) or note that this
is a problem that needs to be solved.
In Section 2 (and repeated in 3)
Signaling messages SHOULD have a higher priority than data packets to
deliver them quickly and to avoid that they are dropped in case of
overload.
Unless I am mistaken, there is a difference between priority and drop
precedence.
Can you also clarify whether you mean all data packets, or justdata
packets on the measured flow.
---
I have a point that is very similar to Stewart's...
The representation of a PCN-flow identifier depends on the
surrounding environment, e.g., pure IP, MPLS, GMPLS, etc.
Examples of such PCN-flow identifier representations can be found in
[RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804].
I don't find any mentiong of PCN in those documents, so I think you mean
"Identifiers for flows can be found in [foo]. These identifiers can be
used in PCN to identify the flows that are measured and reported on."
Thinking about it, the wider problem may be that the discussion in 2.1
is actually solution-oriented. The requirements are to be able to apply
PCN to a specific set of flows, and that the flow about which PCN is
being signaled should be unambiguously identified. Those requirements
are worth stating. You might even say tat there is a requirement that
the data packets not be encumbered by any additional fields used for
flow identification, therefore all flow identifiers must utilize only
fields already present in the data headers. [At this point you might
aslo comment on how deep it is acceptable to look - e.g., can you look
below a top MPLS label?]
But the discussion of which identifiers are suitable is surely not a
matter for a requirements document.
---
Section 4
[RFC5559] provides a general description of the security
considerations for PCN. This memo does not introduce additional
security considerations.
I agree with the statement about RFC 5559. But surely this requirements
document places security-related requirements on the PCN signaling.
These should be noted in this section.
You should remove the citations from the Abstract.
I just note that 5559 which is referenced here says "The signalling between the PCN-boundary-nodes must be protected from attacks." So I'm counting on the eventual protocol document meeting that goal.
A question for the responsible AD...
The PROTO writeup states:
The -03 version generated significant debate on the working group
mailing list during WGLC. The editor addressed the comments
to everyone's satisfaction. There are no vocal dissenters.
Just curious: what were the topics that generated significant debate? It would
be helpful to mention those in the ballot writeup.
rfc2874
draft-ietf-lisp
Holding a DISCUSS until IANA provides a review, that has not arrived yet but
should in a couple of days.
.
Success Criteria
============
Please be specific about success criteria for this
experiment. What outcome must an experimenter observe in order to consider the
experiment a success? Clearly, the experimenter must observe no significant
decrease in network performance or availability. However, that alone is not
enough to motivate the experiment.
The Introduction suggests that the experiment is motivated by a desire to
enhance the scaling characteristics of the global Internet. Having completed the
experiment, how will you determine whether you have achieved that goal? One
possibility is to make some predictions regarding the size of the global routing
tables versus the size of the routing tables carried in LISP ALT at various
points in the experiment (i.e., when only a few sites participate in LISP, when
half of the Internet participates in LISP, when most of the Internet
participates in LISP). The experiment could compare projected results to
observations.
Experiment Scoping
===============
Joel points out that the DISCUSS item below
is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending
resolution of Adrian's.
{Please scope the experiment. How many sites or prefixes must be carried by LISP
in order to yield meaningful results? Given the remote possibility that LISP
machinery may scale to a certain point and then fail dramatically, should the
document provide any guidelines regarding experiment participation (e.g., non-
mission critical).}
IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling
capabilities of the IPv4 routing system, in which it is impossible to allocate a
contiguous address block for EID use.
Having re-read the document and having reviewed some of the other LISP documents
I am updating my discuss.
The fundamental problem is understanding the LISP as presented in this base
specification is that there is an implicit rather than explicit architecture.
Understanding the architecture is important in understanding how the experiment
is (or is not working) and understanding how to modify/correct/extend the
protocol. Either this documents needs an architectural description up front
showing how all the components fit together and which precedes the protocol
definitions, or an architectural of framework document needs to be published
first.
In addition the definitions section really needs be split into a definitions
section (with care being taken over the
generic definition of terms vs the
unicast specific definition), and a section describing the protocol
operations
associated with those terms.
The document needs to be clearer on what happens when the traffic is a high
volume UDP source that only transmits occasionally. Say (but not limited to)
some form of remote IPFIX collector that is occasionally triggered.
My concern is
a) Do we see a large chunk of the flow dropped on the floor until the mapping is
learned - the conflict is between DOS attack and degradation of service WRT the
"legacy Internet".
b) Do we see a miss ordering of packets during as the system swaps from probe to
normal operation
c) Do we see a repeat of this as a result of cache aging.
========
I am also moving the following up to Discuss since it is related
to the need for a clear description of the impact of the cache
vs the existing behavior of the Internet.
5.4.2. A Stateful Solution to MTU Handling
SB> It looks like there needs to be some discussion about
SB> the state lifetime, and the issue of holding a stale
SB> MTU vs transienting a flow by flushing the cache.
Note that in both cases I am not requesting a change to the protocol,
just a clear explanation of the expected behavior.
"Tunnel Router". - should he in the definitions section as a generic type since
you say it is a fundamental component.
==========
5.1. LISP IPv4-in-IPv4 Header Format
SB> It would be helpful to the reader to put a forward ref to
SB> the definition of terms in 5.3 - same in 5.2.
==========
UDP Checksum: The UDP checksum field SHOULD be transmitted as zero
by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
[UDP-TUNNELS]. When a packet with a zero UDP checksum is received
SB> UDP-TUNNELS seems to be a normative reference to an expired
SB> individual draft. That seems to risk this (LISP) document going
SB> into limbo. The following text suggests that the reference
SB> should be changed to informative anyway.
.... The handling of UDP
checksums for all tunneling protocols, including LISP, is under
active discussion within the IETF. When that discussion
concludes, any necessary changes will be made to align LISP with
the outcome of the broader discussion.
=========
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SB> I cannot see a definition in this section of the terms
SB> Source Map-Version and Dest Map-Version
I: The I bit is the Instance ID bit. See Section 5.5 for more
details. When this bit is set to 1, the Locator Status Bits field
is reduced to 8-bits and the high-order 24-bits are used as an
Instance ID. If the L-bit is set to 0, then the low-order 8 bits
are transmitted as zero and ignored on receipt. The format of the
LISP header would look like:
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SB> s/LISP header would look like:/LISP header in this case is:/
SB> More importantly it is slightly confusing putting the 0 case
SB> rider before the format, since at first glance it looks like
SB> the format is only like this when L = 0.
=========
o The outer header Type of Service field (or the Traffic Class
field, in the case of IPv6) SHOULD be copied from the inner header
Type of Service field (with one caveat, see below).
SB> Given that you have separated the host domain from the
SB> ISP domain, I am not sure why this is a SHOULD.
==========
When doing ETR/PETR decapsulation:
o The inner header Time to Live field (or Hop Limit field, in case
of IPv6) SHOULD be copied from the outer header Time to Live
field, when the Time to Live field of the outer header is less
than the Time to Live of the inner header. Failing to perform
this check can cause the Time to Live of the inner header to
increment across encapsulation/decapsulation cycle. This check is
also performed when doing initial encapsulation when a packet
comes to an ITR or PITR destined for a LISP site.
SB> What LISP is doing is very similar in many respects to
SB> MPLS does, and MPLS found that it needed both copy TTL and
SB> not copy TTL. I am surprised that you did not follow that model.
========
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats
The following UDP packet formats are used by the LISP control-plane.
SB> They are not UDP pkt formats, they are UDP/IP packet formats.
========
6.1.1. LISP Packet Type Allocations
This section will be the authoritative source for allocating LISP
Type values. Current allocations are:
SB> Surely the section *is* the authoritative source?
SB> Are you sure you do not need a registry for this?
=======
9.2. IPv4 Traceroute
The solution we propose to solve this problem is to cache traceroute
IPv4 headers in the ITR and to match them up with corresponding IPv4
Time Exceeded messages received from core routers and the ETR.
SB> This sounds like quite a complicated mechanism. Did the authors
SB> consider having the ITR do proxy traceroute?
Updated to refer to rev -19
EIDs are defined to be "not routable on the public
Internet." What are the global uniqueness properties
required for EIDs, both among EIDs and between
EIDs and globally routable IP addresses? How
are EIDs with the appropriate properties chosen
and coordinated among LISP sites?
Updated to refer to rev -19 I'd like to see a mention of the complementary observation that using a single ID-LOC avoids the necessity of a separate step to bind an identifier to its location and a database to manage those bindings. A mention of the scale of the binding database would be appropriate, too. As I understand LISP, the EIDs are still ID-LOCs, not pure identifiers, within a LISP site. Outside any LISP site, an EID is a pure identifier. Which begs the question: exactly what is LISP providing, since it isn't providing a pure ID/LOC separation. E.g., a node can't move within a site without changing its ID, nor can it move between sites without changing its ID. Of course, this hybrid ID/LOC architecture helps with the scaling of the ID/LOC binding database. In section 4: first bullet of "basic rules": is it the case that end-systems are aware of LISP at all? I would write the first phrase of the third paragraph of section 5 as "Because EIDs and RLOCs can be either IPv4 or IPv6 addresses, ..." I don't understand the deployment method described in section 5.5. I think I understand the scenario, but I don't understand how RFC 1918 prefixes can be used as EID prefixes. How is an EID that has an RFC 1918 prefix disambiguated to do the EID-RLOC mapping? This question is related to the Discuss issue asking for clarification of the global uniqueness requirements for EIDs. In section 6.3, how does an ITR determine the original destination of an encapsulated datagram that triggers an ICMP Network or Host Unreachable message, so it can construct a meaningful ICMP Unreachable message to send to the original source of the datagram? In section 10.2, I understand how LISP can help avoid site renumbering, as described in RFC 4192, but I don't understand how it helps with renumbering a single node that moves within or between sites. What is the impact of host renumbering on LISP forwarding? What is the citation of RFC 4984 at the end of section 10.2 in reference to? I see that Jari has a Discuss waiting for IANA review. I think section 14 needs clarification - e.g., while section 14 includes the text "There are two name spaces in LISP that require registration," there appear to be four registries requested in section 14. How is the statement from the definition of EID-prefix: A globally routed address block MAY be used by its assignee as an EID block. compatible from this statement from sections 2 and 4, respectively: [...] (EIDs), which are assigned independently from the network topology, [...] [...] an EID is only routable within the scope of a site. I think the issue is that some additional caveats are required if "a globally routed address block [is] used [...] as an EID block"; spec. those addresses from the globally routed address block used as EIDs must not be allowed to be actually routed directly over the Internet. Well, maybe, as we'll need to see how the transition mechanisms provide interoperability between LISP and non-LISP systems.
If both the N bit and V bit MUST NOT be set in the same packet, then why would
there be any rule defined for processing such a packet rather than to DROP it?
It seems wrong to pretent that's okay and just treat it as if the V bit wasn't
set. What is the advantage of this, and is there any risk?
Section 5.4.1 is not clearly written, and seems fairly critical to proper
performance. For instance, what does it mean when it says S is the maximum size
of a packet that an ITR "would like to receive"? Is it the maximum that it
*can* receive, the maximum that it can send on a next hop without fragmenting,
etc.? From the description in the 2nd paragraph, the size would only be S/2 + H
if the incoming packet were size S, in which case after adding H, it would be
size L, NOT greater than L as the first sentence says. The definitions here
really need to be tightened up and clarified.
I believe the stateful solution in 5.4.2 is preferable to the stateless one
which seems like it could have very bad effects if it really sets DF=1 and isn't
keeping any state about whether smaller fragments need to be sent for a
particular destination. The 5.4.1 algorithm doesn't solve this at all, and
seems inadequate for providing a robust infrastructure.
RLOC probing has an impact on the network capacity in-use and there is no way to
sense when the overall rate of probing may simply be too great for some
bottleneck to handle (due to some combination of the number of RLOCs being
probed or the rate of probing). Losses can occur either of the probes or the
map-replies. Even in cases where it isn't a significant source of congestion,
the probing has to be implemented to avoid having bad things happen like
accidentally causing synchronization of sending the probes such that this
control traffic spikes periodically. Overall, unless the RLOC probing is better
specified so that the risks and necessary precautions are well understood, this
seems like a feature that could cause unexpected impact to data flows under some
conditions.
In Section 5.3, UDP Checksum discussion, the reference to draft-eubanks- chimento-6man should probably be to draft-ietf-6man-udpzero instead. In section 5.4.1, what is "an architectural constant"? Should this just say "a constant"?
I have updated my Discuss to remove the issues resolved in the -19
revision.
---
I'm inclined to agree with Russ that this is well-enough specified for
an experimental status document, but I have some concerns.
---
I don't see any statement of the scope of the experiment or how it will
be judged. Traditionally, experiments are not released into the Internet
but are operated in a controlled way in walled gardens. It appears that
the intention with this experiment is that it should be conducted in the
Internet, and that makes it important to examine the risks and
uncertaintes.
As part of the Discuss resolution on other LISP documents, and in
accordance with the LISP WG charter, we had agreed that this
specification would countain an upfront and clear statement of the
issues and concerns. To remind you, the charter says:
At this time, these proposals are at an early stage. All proposals
(including LISP) have potentially harmful side-effects to Internet
traffic carried by the involved routers, have parts where deployment
incentives may be lacking, and are NOT RECOMMENDED for deployment beyond
experimental situations at this stage. Many of the proposals have
components (such as the identifier to locator mapping system) where it
is not yet known what kind of design alternative is the best one among
many.
and
The LISP WG is NOT chartered to develop the final
or standard solution for solving the routing scalability problem. Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic. In addition, as these issues are understood, the
working group will analyze and document the implications of LISP on
Internet traffic, applications, routers, and security. This analysis
will explain what role LISP can play in scalable routing. The analysis
should also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on
I do not consider that this draft has adhered to the WG charter, and I
consider the active encouragement of "early deployments" to be both
against the spirit and the letter of the charter. If you believe that
the experiment needs to be conducted "in the wild" you need to spend a
bit more text explaining why this is safe and how the experiment is
contained.
I have proposed text on the LISP mailing list to address this part of my
Discuss.
---
Section 2
Routing Locators (RLOCs), which are topologically assigned to network
attachment points (and are therefore amenable to aggregation)
I don't see that RLOCs are any more amenable to aggregation than today's
IP addresses. That is, the allocation scheme for RLOCs could be run such
that RLOCs are aggregatable, but could equally be run such that it is
hard to aggregate.
Maybe the points here are that:
- network attachment points are not (currently) mobile
- network attachment points are defined by the networks they attach to
- network attachment points, by definition, impose an aggregation of
end points.
A way to solve this, if you wrote what you intended to write, would be a
forward pointer to the section in the document that describes
aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.
---
Section 2
One database design that is being developed
and prototyped as part of the LISP working group work is [ALT].
Others that have been described but not implemented include [CONS],
[EMACS], [RPMD], [NERD].
Is the LISP working group undertaking controlled prototyping?
Is the intention to state that "there are known protocotype
implementations of [ALT]."
Similarly, what does it mean to say "have been described but not
implemented"? I guess: "At the time of writing, the authors are unaware
of any implementations of..."
---
Section 3
When using multiple mapping database
systems, care must be taken to not create reencapsulation loops.
What is this "care"?
What about loops caused by transient conditions (or errors) in a single
LISP mapping database?
Shouldn't the payload TTL at least be decremented by one for each
tunnel?
Note that reencapsulation is not the same as nested encapsulation.
You are clear about avoiding the latter (although some form of DPI
may be required to achieve it).
---
Step 7 of Section 4.1 doesn't make it clear what has happened to the
first packet in the flow. I had assumed that it was buffered pending
the Map-Reply, but I now suspect it was discarded as soon as the
Map-Request was constructed. Can you add a clarification.
I have updated my Comment to remove those points that you have addressed
in revision -19 (thanks).
---
The architectural overview in Section 4 would be enhanced by a picture.
The example in 4.1 would similarly benefit.
---
Section 5.3
I agree with Wes about the N and V bits.
---
Section 5.3 LISP Nonce
When the E-bit is clear but the N-bit is
set, a remote ITR is either echoing a previously requested echo-
nonce or providing a random nonce.
"is clear/set" in what?
The original message sent, or the new message received?
This was a discuss, but on the basis that the lisp WG re-chartering will address the issue, I'm clearing. #12, It looks from 6.1.6 like a Map-Register can be replayed. That's not a good thing. There may be a similar replay issue with Map-Notify messages.
This is going for experimental, and I think it clears the bar for experimental. However, I think Section 6 could be much more clear.
LISP sounds like a serious protocol experiment. I would have liked there to be more discussion in either the document or in the writeup about how that experiment is going to conclude. That is, though I see the things in section 15 that indicate what it would take to really move this to the standards track, it would be nice to see some discussion about how interoperability is going to be measured as the experiment progresses.
1. I support Pete's COMMENT and Adrian's DISCUSS about the need to make more clear the goals of the experiment, the criteria of success and the limits of deployment while the document stays Experimental. 2. It would be more clear to split 14.1. into two sub-sections, especially as IANA is required to create a registry for LISP ACT if I understand correctly, while no action is required from IANA for the Flag Fields 3. I support Stewart's DISCUSS. One of the sources of UDP traffic that transmit occasionally may be SNMP agents in the core. When sending unaknowledged notifications (a.k.a. traps) these could be dropped on the floor and then if the cache is flushed they will be lost forever. Altough traps are not supposed to be used in critical applications, systematic loss in what would not be a meltdown situation could badly impact the manageability of the routing environment,
Experiments are good. Although I share Pete's and Adrian's concerns about the scope of the experiment and the parameters for evaluating its success, I agree with Russ that the document is specified clearly enough to be implemented in an experimental fashion (modulo Ralph's question about global uniqueness).
I'm clearing, trusting the shepherd and responsible AD to ensure that the informative references point to to appropriate places. In particular, please verify that it's possible to obtain [RPMD].
draft-ietf-lisp-multicast
This document defines a set of terms EID, RLOC etc which at first sight seem
identical to the unicast terms. However the description of their operation seems
to make them different objects, in which case they need different names. If the
names are to be common, there needs to be a separation of the name from the mode
of operation.
Where the object is identical to the unicast term (LISP Header?) the object
should not need to be redefined in this document since this invites issues of
subtle difference between the competing definitions.
"By using the traffic engineering features of LISP" needs a ref. The subtleties of different m/c paths surely belongs after the basic description rather than as the first item The protocols in section 7 need references Mpriority seems to lack a definition
Now that the base LISP protocol document has been published, I've cleared my Discuss on this document.
I have no objection to the content of this document, and I thank you
for spelling out (and calling out) the considerable complexity
expecially in Section 9.
---
As previously noted on other LISP documents, I would like a pointer
to the generic caveat text being added to the main LISP spec.
---
The answer to Ron Bonica's Discuss (now cleared) intimated that there
are actually no changes to the multicast protocols since "it is LISP-
Multicast that sends unicast PIM join and prune messages."
I am trying to understand whether this document does or does not make
any changes to (e.g.) PIM. In Section 2 I see bullet 3...
3. What protocols are affected and what changes are required to such
multicast protocols.
Is this rhetoric ("I will show you which protocols are affected. None!")
or is there some contradiction?
Since Section 2 goes on to say...
This specification focuses on what changes are needed to the
multicast routing protocols to support LISP-Multicast as well as
other protocols used for inter-domain multicast, such as Multi-
protocol BGP (MBGP) [RFC4760]. The approach proposed in this
specification requires no packet format changes to the protocols and
no operational procedural changes to the multicast infrastructure
inside of a site when all sources and receivers reside in that site,
even when the site is LISP enabled. That is, internal operation of
multicast is unchanged regardless of whether or not the site is LISP
enabled or whether or not receivers exist in other sites which are
LISP-enabled.
It really sounds like no changes are needed to any of the protocols. It
is just a question of how the individual routers use the protocols (i.e.
how they supply information to and extract information from the
protocols). Maybe this just needs a change in tone of the text to stop
me repeatedly going into a panic about changes to protocols when I read
Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
and PIM-SSM [RFC4607].
Section 7 (which really had me worried) appears to list each protocl and
then say "no changes needed" for *nearly* all of them. But for PIM-SSM
we have
In this case, there is a small
modification to the operation of the PIM protocol. No
modifications to any message format, but to support taking a Join/
Prune message originated inside of a LISP site with embedded
addresses from the EID namespace and converting them to addresses
from the RLOC namespace when the Join/Prune message crosses a site
boundary. This is similar to the requirements documented in
[RFC5135].
That is a change or not?
The title talks about "LISP for multicast environments" but the Abstract
is specific to "inter-domain multicast routing". Should the document
title be updated accordingly or is the Abstract wrong?
It is possible that the confusion is at bullet 2 of Section 2 where it
is implied that a "domain" is a LISP site such that "inter-domain" means
between LISP sites. It would be helpful not to re-use "domain" in ths
way (we are used to it meaning inter-AS and inter-area).
Since multicast between LISP sites is just a special case of multicast
using LISP, you could stike te text from the Abstract.
---
FWIW I found it premature to be reading about how to send a multicast
packet from a LISP site to a non-LISP site (and vice versa) when I have
not yet been told how to do this for unicast! There is nothing the
authors can do about this, butit is yet another case of the LISP
documents running through the system in the wrong order.
I am pleased to see [INTWORK] as a normative reference since ts does
help with the issue, and I wondered whether the LISP deployment I-D
should not at least show as an informational reference (perhaps from
Section 9.3).
---
Section 7 needs some polish on the English to avoid doubts.
PIM-SSM
No
modifications to any message format, but to support taking a Join/
Prune message originated inside of a LISP site with embedded
addresses from the EID namespace and converting them to addresses
from the RLOC namespace when the Join/Prune message crosses a site
boundary.
PIM-ASM
The ASM mode of PIM, the most popular form of PIM, is
deployed in the Internet today is by having shared-trees within a
site and using source-trees across sites.
Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 3-October-2011. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06774.html
draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations", which provides a good start toward understanding the parameters of the experiment we're engaging in here, and perhaps some dimensions for measuring success. It would be helpful for this document to contain a similar section. The terminology section repeats definitions from the base LISP spec. This seems like a bad idea. It would be better to reference those definitions and here simply provide the extended information that applies only to multicast environments. The Security Considerations section seems rather sparse. Does the use of LISP in a multicast environment truly have no security implications whatsoever?
draft-kompella-l2vpn-l2vpn
Nice documemnt, well positioned as complementary to the official IETF approach. Thanks. --- "PE" first appears in Section 1.1 without expansion.
A check that acronymns are expanded on 1st use would be good, e.g. DLCI was the one I noticed.
One non-blocking comment from the Gen-ART Review by Roni Even on 7-Sep-2011 has not been resolved. Please consider it: > > Section 4.2 refers to section 4 but I am not sure where this > mechanism in section 4 is.
Benson Schliesser reviewed the document (version 07) for OPS-DIR and sent hos
review to the authors on 9/29. His review was never answered. Please address the
following issues from Benson's review, or in case these were answered and
addressed in the meantime provide the appropriate pointers:
1) It is not clear to me whether L2-native end-to-end OAM mechanisms are
supported. It seems that the IP-based interworking proposed by this document
would be incompatible with native OAM. A discussion on whether this is true,
when and how native OAM is supported, etc, would be useful.
2) While there is a brief discussion of "adding" a new site, there is no
discussion of "removing" sites.
3) I'm also unclear about behavior during the transition timeframe. When label
blocks are growing or shrinking, and PEs might have mismatched label block
sizes, what is the correct behavior for label selection, dropping packets, etc?
Is there an implementation mechanism for managing label space correctly, to
ensure that blocks can grow? Are these behaviors something that should be
configured correctly by the operator?
4) The document doesn't clearly describe the AC-to-label-to-AC mapping,
specifically how egress frames are mapped to an AC's local identifier (e.g.
DLCI). The operator needs a way to know in advance and/or lookup the
local/remote VC identifier mappings for each AC. It seems pretty obvious to me,
but the text is not explicit on this point. (Section 3.2.1 talks about ingress
DLCI-to-CE mappings; section 5 para 3 says the label is used to determine egress
AC; section 6 reiterates these points, but says that the label identifies the CE
rather than the AC. Perhaps I overlooked some other text; otherwise the egress
mapping should be described explicitly.)
5) Section 4 includes n-to-1 encapsulation types. Given my comments in #4 above
regarding identifier mappings, it is even less clear how these types of circuits
would work.
6) On the ingress, what happens when the PE receives a frame addressed to
itself? In other words, if CE-N sends a frame to the DLCI associated with the
Nth index, does it get looped back? Is this a useful operational mechanism for
testing connectivity etc?
Supplementary to these please address the following:
1. In section 1: > It may be instructive to compare the approach in [RFC4447] and [RFC6074] (these are the IETF-approved technologies for the functions described in this document, albeit using two separate protocols) with the one described here. Devices implementing the solution described in this document must also implement the approach in [RFC4447] and [RFC6074]. This mislead me at first reading. I believe that it would be more clear if the non-capitalized 'must' is avoided completely, as [RFC4447] and [RFC6074] are supported as part of the L2VPN functionality and not as a reuirement for this document. 2. Expand at first encountered instance: DLCI, VPI / VCI, NLRI. 3. It makes sense to bring the Contributors and the Acknowledgments sections one near the other.
Where do the L2VPN TLVs go in the VPLS NLRI? Does the TLV(s) appear immediately after the VPKS NRLI when sent between the two PEs?
draft-ash-gcac-algorithm-spec
Agree with Robert's points in his discuss. I also found this document in general difficult to read, and hard to convince myself that it actually works as expected.
I concur with Robert's DISCUSS points
1) VARk = BWMck**2/VFck could be mis-read, suggest adding parenthesis or using another couple of lines like eq(2). 2) Surely there's a DoS vector here too - couldn't someone in principle provide bad inputs so that the algorithm denies service? Not sure how best to note that, but I'd say its worth a mention in the security considerations.
As with all Experimental specifications, it would be nice to define some parameters for the experiment (success criteria, guidelines for those who implement and deploy the technology, etc.).
(Updated to add point 3 below)
The document says that the algorithm might have negative effects on live
deployments (by implication, up to and including failing to complete an
emergenc call) but then says experimentation in production networks needs
to be treated with caution. Was "experimentation in production networks
is NOT RECOMMENDED", or even "expereiments MUST NOT be performed on production
networks" considered and rejected? If so, can the document explain why?
(Related - can the document explain what experimenting "in a controlled
manner" means?)
The security consideration section's discussion of the risks of using
possibly unprotected marks to identify emergency traffic should
incorporate or reference the related discussion from ECRIT and (if I
remember correctly) the RSVP document suite. This is much harder
problem than the current text signals.
Example A.2 needs to be updated to reflect that NSIS has concluded.
The document calls out VOIP as an example of traffic that might be used as an input to this algorithm, but the current language implies it's the ONLY traffic that's expected, and that the only things generating that traffic will be IP/PBXs and SIP/RTP end devices. Please make it clear that this traffic is only a motivational example. The interoperability issue exposed at the top of page 11 deserves more discussion. What goes wrong when different administrative domains use different constraint models? Are there symptoms that can be observed to know that somethings going wrong? Can the document make a stronger statement about the appropriate configuration of a experimental test bed? This sentence needs clarification: "Let DBWi be the additional bandwidth capacity needed to carry the flow with aggregate bandwidth DBWi." As written it defines a term in terms of itself. I'm skeptical of the brevity of the security consideration section, but yield to the shepherd to double-check that there is nothing beyond the marking of emergency traffic to discuss.
draft-jiang-a6-to-historic
As far as I can tell the purpose of this document is to obsolete RFC2874.
However this is not called out in either the meta-data or the Abstract.
RFC2874 says that it is Standards Track, so it is surprising that this is not a WG draft.
ID-nits flags:
-- Obsolete informational reference (is this intentional?): RFC 1886
(Obsoleted by RFC 3596)
Should the DNS record type 38 be deprecated (and marked so in the
registry?
---
This part of my Discuss is only for debate by the IESG and I will
clear it on or before the Telechat. The authors do not need to
take any action for this part of the Discuss.
It is a source of confusion to me that when I look at RFC 2874 in
the
repository, all of the lovely metadata says "Experimental" but
the RFC itself
says "Standards Track". Now, I know that the RFC
Editor
does not like tmake *any* change to the published RFC, but
this has got be a
source of confusion and, as this RFC moves to
Historic, the confusion won't get
any less
I would like it if the Abstract mentioned the RFC being moved to historic (viz. 2874)
Please make sure to incorporate the additional text agreed during the secdir review: http://www.ietf.org/mail-archive/web/secdir/current/msg03051.html
draft-yevstifeyev-disclosure-relation
I support the discusses, in particular the concern about pure patents vs. other general purpose IPR. The latter is the one that we use for IETF, for instance.
It is not clear to me why this is defined to indicate *only* patents (as it is
currently) or to indicate intellectual property claims more generally (e.g.
patent applications in-process are not patents).
AFAICS, new IANA registrations require a specification (this document)
and expert review. Have the experts looked at this request yet? I don't
see anything in the Write-up.
---
Last Call discussions seem to be still active, and I do not think we
should approve this document until all issues have been successfully
resolved.
I suspect the shepherding AD should move this onto a later telechat.
Moved from discuss to no-objection since this will come around again and who needs a spare discuss;-) Former discuss: On Dec 26th the author suggested a substantive change [1] so I don't know whether what I've read is final or not. Maybe this is not ready? [1] http://www.ietf.org/mail-archive/web/ietf/current/msg71211.html Former comment text: This seems almost harmless. (It'd be totally harmless if it didn't add to the IPR industry in a very, very minor way;-) The writeup says that W3C feedback will be sought during IETF LC - did that happen and were they (as the ostensbile users of this) ok with it? Examples like patent.gov seem like a bad idea as do "almost" realistic patent numbers. Suggest either using example.org style stuff or else URIs for real but expired patents. There were a bunch of IETF LC mails on this (mostly suggested nits from Julian Reschke) that looked like they'd be worth fixing. (And the author appeared to agree too.)
The Gen-ART Review by Martin Thomson on 17-Dec-2011 raised a
serious question that deserves further discussion. He questions
whether the IETF should publish the document at all.
>
> The semantics of the relation type are quite clear, though the
> introduction does not make a particularly compelling case for an RFC.
> The registration requirements of RFC 5988 require little more than the
> creation of a specification; that specification could be created
> anywhere (say, in [W3C-PUBRULES]). I find the motivations described
> in the introduction to be not compelling.
>
In response, the author suggests that an Informational RFC is the
ideal way to meet the requirements in RFC 5988. Martin was not
swayed by this suggestion.
- I think the MUST in section 2 is superfluous. s/MUST represent/represents - Though I agree with Dan that some more discussion of applicability might be interesting, I do not think it is necessary to include. The document does not tightly define "patent disclosure" or "IPR disclosure", and I don't think it should. Any particular group using this construct may decide that pending patents or patent applications are things that they want to point to, and in the current document they are allowed to. The document can explicitly say that, but I don't think it needs to.
This DISCUSS and COMMENT is based in part on the OPS-DIR review performed by
Juergen Quittek.
1. "Patent disclosure" is W3C terminology. The related term used in the IETF is
"IPR disclosure". I would object the document to be published without a clear
statement about the applicability of the new link relation type to IPR
disclosures.
2. This document is very short and most of the text deals with W3C document
requirements and HTML examples. More important would be discussing the the
applicability of the new link relation type in more detail: Is it applicable to
granted patents only or to patent proposals (pending patents as well? What about
other kinds of IPR, such as industrial design rights? I think they should all
be covered. At least the document should be clear about these issues.
3. The Introduction (section 1) exclusively discusses a single use case for the
new link relation type: meeting W3C documentation requirements. This gives the
impression that this draft is written for serving W3C purposes only. I don't
think that this is the case, but there is not indication of other purposes in
the draft. Please clarify that W3C documents are just an example use case and
that there are many others. Mentioning a few other use cases is probably not a
bad idea. One obvious use case may be links to IPR disclosures on IETF tools
pages.
1. The purpose of the draft is defining a the semantics of a new link
relationship type. This is done in section 2. But the four lines of text that
should serve this purpose rather confuse me:
> 2. 'disclosure' Link Relation Type
>
> Whenever the 'disclosure' relation is defined, the target IRI MUST
> either
What does precisely mean "Whenever the disclosure relation is defined"?
It is
defined in this document. The sentence should rather state something like
"Whenever the relation type attribute is used with value 'disclosure'".
> (1) designate a list of patent disclosures, or
>
> (2) refer to a particular patent disclosure made with respect to the
> material being referenced by context IRI.
Why does (1) designate and (2) refer to? Why is there a difference?
Where is
the difference explained? What are the semantics of "designating a list of
patent disclosures".
2. In the IANA Consideration section please be explicit that the registry to be
extended is the Link Relation Type registry.
3. Abstract:
> This document specifies the 'disclosure' Link Relation Type. It
> designates a list of patent disclosures or a particular patent
> disclosure itself made with respect to material for which such
> relation type is specified.
I had to read this two times until I could parse the second sentence correctly.
Less cryptic wording would be appreciated, particularly
in the abstract that should readers allow to quickly get an idea of the content.
I would suggest removing "itself" from the abstract, but I'm not a native
speaker.
The first sentence says "this document specifies the new type".
The last line says "for which the type is specified". This is confusing.
In both cases the "type" is "specified" but with different meanings.
In the first case it is indeed the specification of the type.
In the second case the type is assigned to (not specified for) "material".
Suggestion: replace "specified" in last line.
4. Section 1 (Introduction), first sentence: see comments on abstract
5. Section 1 (Introduction), second paragraph, line 1:
"Active use of 'disclosure' relation type has been identified."
- What is "active use" compared to just "use"?
- Why "identified"? What is "identification of use"?
You may want to replace "identified" by "observed" or something similar.
6. Section 1 (Introduction), line 4:
Suggestion: "defines" -> "mandates"
7. Section 1 (Introduction), last line:
"separate" -> "multiple"
8. Section 3 (examples), last example:
This example uses potentially real
domain names:
patent.gov, ipr.su, ftp.legal.va. They should be replaced with
domain names reserved for examples such as example.com, example.net, and
example.org, see RFC 2606.