IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-04-26. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Barry, Pete, Robert, Adrian
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1246 EDT break
1253 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1430 EDT Adjourned
(at 2012-04-26 07:30:04 PDT)
draft-ietf-geopriv-policy
Maybe "Internationalization" is an IETF keyword for character set, but I was surprised that the section did not include a discussion on the datums use in different countries. The text only supports WGS84, but I understand that there are other datums and that WGS84 is tied to GPS but that there are other Sat Nav systems.
Minor editorial nits: section 4: The 'profile' attribute allows to indicate the location profile that is included as child elements in the <location> element and each profile needs to describe under what conditions each <location> element evaluates to TRUE. missing word in "allows to"? (also section 6.4) section 6.5.2 5. Let P = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p), lower case or upper case P? section 7.5 Suppose you want a to obscure s/a// ? section 7.5 In his way "In this way"? THe document lists 6 authors; you may get pushback as the guideline is 5.
I find the philosophical aspects of this work very hard to grapple with. Had the work been presented in a more abstract way (for example, as a policy language that could be used in a number of ways) I would have found it easier. But the text on motivation disturbs me and, while I can completely accept that many people are motivated in this way, the approach and ideas seem to me to be broken. I do not believe that I should enter a Discuss or stand in the way of this work because of my views, but I cannot offer a "No Objection" ballot position. === Additionally, the authors might like to consider the following: It is not clear to me why algorithms need to be standardised in this case. While they do affect what is sent on the wire, and while they provide useful examples to show that the results can be reliably achieved, it seems to me that the results of the algorithms (i.e. the outputs based on the inputs) are all that need to be contained in a Technical Specification. In short, I do not believe that the specification of the algorithms is necessary for interoperability.
Since the previous iesg discussions on this document pre-date me as an AD I might be commenting here on things that have already been discussed. If so, just send me a pointer if you can to the earlier discussion. - general: repeated queries are a threat here and are recognised as such in a number of places. I would like to have seen some guidanace to implementers as to when such repeated queries might be considered to be an attack, and when not, and if there's something you can do about that. Can such guidance be offered? If so, why not include it in the document? If not, perhaps saying why that's the case would be worthwhile? - 13.4: The last sentence is too vague IMO. I think you mean that if location is only obscured e.g. around the home, then the lack of location implies that I'm at home. You should say that more clearly.
abstract: "restrict access" in the abstract is ambiguous - it could mean "restrict access to a target's actual location" or it could mean "restrict access to something based on a target's location information." Not sure if that needs fixing or not but this is only addressing the former I think. 4.1: what does "within" mean here - does overlapping count or not? Seems like that could be made more precise, but maybe its defined elsewhere in which case a reference to the relevant section of the relevant RFC would be good. I think that's clarified later, but be good to be clear here too. 6.2: It'd maybe be good to explicitly state the meaning of setting this to the current date. I assume it means "don't retain." 6.4: CID URIs are mentioned here but not explained nor is the acronym expanded. Be nice to do that. - 13.2: says that "The quotient of the sizes A1/A should be, even in the worst case, larger than a fixed known number, in order that the user knows what is the maximal information leakage he has." Should that should be a 2119 SHOULD? In other words, is the "maximum leakage" referred to here really a parameter of the 6.5.2 algorithm? If so, then ought that not be called out with 2119 terms? - 13.2: I don't follow how the A1/A quotient is >0.13, can you explain that some more? (That may or may not need to be reflected in the document, not sure.) - 13.3: 1st para - What is an implementer supposed to do with or based on this paragraph? - 13.4: This seems to imply "uncertainty" is a parameter of the algorithm, but that's not explained. This is a similar point to that made for 13.2 13: the term "privacy region" is used but not defined 10.4: typo s/to defined/to define/ 13.2: a few typos at the end of 1st para, and more elsewhere, could do with an editorial pass really 13.3: "further checks are performed" seems wrong if you don't say what those are, maybe s/are/can be/?
-- IANA Considerations -- To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name. It would be nice to include the URL as well, to be absolutely sure. I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5. The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct? For the new registry in 11.3, I would like to see a rationale for the choice of registration policy. See draft-leiba-iana-policy-update, if you want to see where I'm coming from here. Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option. I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address. Discussion: should you be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual?
Substantive suggestions; please adopt or respond to these:
-- Introduction --
This document does not describe the protocol used to convey location
information from the Location Server to the Location Recipient.
What document does? Should it be noted here, with a citation?
----
OLD (unclear what part is "for example")
Transformations regulate in a location information
context how a Location Server modifies the information elements that
are returned to the requestor, for example, by reducing the
granularity of returned location information.
NEW (I think you mean...)
Transformations regulate in a location information
context how a Location Server modifies the information elements that
are returned to the requestor by, for example, reducing the
granularity of returned location information.
----
Both algorithms come with limitations, i.e. they
provide location obfuscation under certain conditions and may
therefore not be appropriate for all application domains.
It's not clear exactly what this means. Is the only limitation the one related
to the obfuscation? If there are other limitations, then it should be "e.g.",
not "i.e." If that's the only limitation, I suggest replacing "limitations,
i.e." with "limitations:". Also, it doesn't make sense that providing location
obfuscation would be a limitation; perhaps you mean *only* under certain
conditions? So maybe this is what you mean?:
NEW
Both algorithms come with
limitations: they
provide location obfuscation only under certain conditions,
and may therefore not be appropriate for all application domains.
-- Section 3.1 --
The preferred term now is "media type", not "MIME type"; please change it. Also
in Section 10.4.
-- Section 3.2 --
URL, not URI ?
-- Section 6.2 --
The value provided with the <set-retention-expiry> element indicates
seconds and these seconds are added to the current date.
If the <set-retention-expiry> element is absent then the value of the
<retention-expiry> element in the PIDF-LO is kept unchanged or, if
the PIDF-LO is created for the first time, then the value MUST be set
to the current date.
It looks like "current date" means "current date and time"; should you not say
that? Also, I guess absence then means that the retention expiry is
immediate... and I presume that's OK.
-- Section 6.4 --
If the <keep-rule-reference> element is absent, then the value of the
<external-ruleset> element in the PIDF-LO is kept unchanged when
available or, if the PIDF-LO is created for the first time then the
<external-ruleset> element MUST NOT be included.
This creates an interesting situation, in which the absence of a value has a
meaning that cannot be conveyed by any value that might be present. That's odd,
and possible troublesome, so I want to be sure you've thought about that.
-- Internationaliztion Considerations --
The content of the <label>
element is meant to be provided by a human (the Rule Maker) and also
displayed to a human.
Does this also mean that the information might need to be language-tagged and/or
translated (in addition to perhaps being in non-ASCII characters?
-- Section 13.3 --
The first paragraph is confusing, and doesn't seem to reach a reasonable
conclusion. It purports to talk about usability, but then seems to get into
information leakage, and never makes a point that seems to me to be clear and
useful. Please try to re-work that paragraph.
-- Section 13.4 --
Location obscuring attempts to remove information about the location
of a Target. The effectiveness of location obscuring is determined
by how much uncertainty a Location Recipient has about the location
of the Target.
As you note earlier (and later, two paragraphs down), this is oversimplified:
the effectiveness is not determined just by that, but is also strongly
influenced by what can be revealed by repeated queries over time -- how
aggregating responses can reveal more than a single response will.
Obscured locations can still serve a purpose where a Location
Recipient is willing to respect privacy.
It's not clear what value that paragraph has. It seems to say, basically, "If
the LR doesn't want to attack you, then whatever you've done will be fine."
It's true, but not very useful as a security consideration. You might just
want to remove this paragraph, and take the word "more" out of the subsequent
one.
This is an old document; please double-check the references to make sure they're
accurate, current, and correctly classified. The reference to RFC 2434 is
obsolete, replaced by 5226, for example.
========
Editorial suggestions. No need to respond to these; take them, leave
them, or modify them as you please. There are also numerous errors in
punctuation, number agreement, and the like; it would be good for one of the
native English speaking editors to go through the document source code and fix
those... or I guess we can let the RFC Editor deal with them.
-- Introduction --
(clarity)
Not all terminology is in one place, and Target isn't specifically
defined. I suggest the following structure for the introduction (and if you do
this, you can remove the second paragraph from section 2):
-----
1.
Introduction
First sentence as written. Second sentence.
1.1 Terminology for the model, as in RFC 3693
Location Generator (LG), [explain].
Location Server (LS), ...
Location Recipient (LR), ...
Rule Maker (RM), ...
Authorization Policy, ...
Location Object (LO), ...
Target, ...
1.2 Overview
The basic rule set defined [...]
-----
OLD (sounds awkward)
The basic rule set,
however, does not allow to control access to location information
based on specific Location Recipients.
NEW
The basic rule set,
however, does not allow access control for location information
based on specific Location Recipients.
OLD (clarity)
The rule set allows the entity that uses the rules defined in this
document to restrict the retention
NEW
The enhanced rule set allows the entity that uses the rules
defined in this document to restrict the retention
OLD (sounds awkward)
or that the resolution of parts of the Location Object is
reduced.
NEW
or that the resolution is reduced for parts of the Location
Object.
OLD (to read more smoothly)
The typical sequence of operations is as follows. A Location Server
receives a query
NEW
In the typical sequence of operations, a Location Server
receives a query
OLD (awkward usage)
determine under which circumstances the entity executing the rules,
for example a Location Server,
NEW
determine under which circumstances the entity executing the rules,
such as a Location Server,
-- Section 2 --
OLD (setting off defined terms)
The term permission refers to the action and transformation
components of a rule.
NEW
The term "permission" refers to the action and transformation
components of a rule.
OR
The term Permission refers to the action and transformation
components of a rule.
In general, please be consistent with how you set off defined terms, and avoid
using a term in a definition while making it look like it's just part of the
sentence.
OLD (bad usage)
as motivated in RFC 4079
This usage of "motivated" is made-up business jargon and will be difficult for
many non-native speakers (and quite some native speakers) to understand.
NEW
as explained in RFC 4079
[or "described in", or something like that]
-- Section 4.1 --
OLD (repetition)
reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the
European Petroleum Survey Group
NEW
Can you re-word this to avoid the "based on... based on" repetition?
-- Section 7.5 --
OLD
We will set up a grid not only for the continental US, but for the
whole earth between latitudes 25 and 50 degrees
You're not including Alaska. This is a total nit, but in order to avoid
arguments about whether "continental" U.S. includes Alaska, you might switch to
"contiguous US".
-- Section 13.1 --
First paragraph has a spurious ")" at the end.
OLD (unclear antecedent)
This algorithm for
geodetic location information obfuscation makes use of these
techniques.
NEW
The algorithm defined in this document for
geodetic location information obfuscation makes use of these
techniques.
-- Section 13.2 --
OLD
For example, when a transformation indicates that civic location is
provided at a 'building' level of granularity. Consequently, floor
levels, room numbers, etc. would be hidden.
The first sentence is not a complete sentence, and the second is not a very good
one. Merge these, and make a proper sentence. Maybe (assuming I understand
what you mean to say) something like this?:
NEW
For example, when a transformation indicates that civic location is
provided at a 'building' level of granularity, floor levels, room
numbers, and other detailed information would be hidden.
The paragraph that begins thus:
The algorithm presented in Section 6.5.2 has
some measures against
leaking information when moving, switching from one
privacy region to
another one
...is very long, and has quite a number of
grammatical errors. I suggest getting one of the native-English-speaking
editors to fix this and to split it into at least three paragraphs.
This document needs a great deal of editing for simplification and clarity. That said, none of these (or the other changes I suggest below) are enough for me to hold up the document. But I do wish you would address these issues before publication. First, the strictly editorial. There's a great deal of use of the passive voice that is making the text very complicated. Here are two paragraphs from section 4 that could be greatly clarified by editing, with some suggested replacements: This section describes the location-specific conditions of a rule. The <conditions> element contains zero, one or an unbounded number of <location-condition> child element(s). Providing more than one <location-condition> element may not be useful since all child elements of the <conditions> element must evaluate to TRUE in order for the <conditions> element to be TRUE. The <location-condition> element MUST contain at least one <location> child element. The <location-condition> element evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. "The <conditions> element contains zero or more <location-condition> child element(s). The <conditions> element evaluates to TRUE if all of its child elements evaluate to TRUE (and therefore multiple <location-condition> elements are not normally useful). The <location-condition> element MUST contain at least one <location> child element. The <location-condition> element evaluates to TRUE if any of its child elements evaluates to TRUE." The <location> element has three attributes, namely 'profile', 'xml: lang' and 'label'. The 'profile' attribute allows to indicate the location profile that is included as child elements in the <location> element and each profile needs to describe under what conditions each <location> element evaluates to TRUE. This document defines two location profiles, one civic and one geodetic location profile, see Section 4.1 and Section 4.2. The 'label' attribute allows a human readable description to be added to each <location> element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute. "The three attributes of <location> element are 'profile', 'xml:lang', and 'label'. The 'profile' attribute contains the type oflocation data in the <location> element. Two location profiles, one geodentic and one civic, are defined in Sections 4.1 and 4.2. The 'label' attribute contains a human readable description of the location. The 'xml:lang' attribute contains a language tag indicating the language of the 'label' attribute." I'm not going to go through and edit this entire document, but you get the idea; I hope the editors can have a proper edit of this document done, if not have the RFC Editor assist with this. These are just two examples. The entire document could use a good rewrite. From here on, I will point only out places where I think the language obfuscates meaning. 4: The <location-condition> and the <location> elements provide extension points. If an extension is not understood by the entity evaluating the rules then this rule evaluates to FALSE. Are you saying that if an unknown extension is used in a child of <location>, that <location> should evaluate FALSE if if another known child of <location> evaluates TRUE? That violates the logical OR of the <location> element. 4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That doesn't seem necessary. If you do need this, at least make it "octet-by-octet" or "byte-by-byte" if you must. "If the civic location of the Target is unknown": Do you mean "If the <civicAddress> element is missing"? This reads as if the <location> should evaluate to FALSE if the civic location is not understood, and I don't think that's what you mean. 6 (generally) Why does this section talk about when the PIDF-LO is first created? That has nothing to do with the transformations. That info belongs somewhere else. 6.1 (and forward) "This element asks...". The element does not "ask" anything. Please rewrite. 6.2 "<set-retention-expiry> element is an integer." I assume unsigned, yes? Probably best to say. 6.5.1 I can't get any more granular than the 6 choices? Why not?
Just trying to make this actionable (I understand this parenthetical bit isn't so much: the rest of the section needs a good editorial pass to make sure it makes sense -see my comments): The last paragraph in s13.2 seems like it might be missing a discussion about one of the three things listed in the 1st sentence. There's a discussion about the 1st and 2nd issue but not the 3rd and the 1st and 2nd issue both "the following", which I assume has something to do with Jack Torrance/Nicholson. Maybe it's just editorial, but I'd like to make sure nothing got dropped.
s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's
not really safe it's enabling.
s3.2: r/There are two ways how the/There are two ways the
s4: r/allows to indicate/indicates
s6.5.2: r/steps.The/steps. The
s6.5.2: I found this a little hard to parse:
The maximal distortion of the map may
not be too much (see notes below).
r/much/large?
s6.5.2, step 5: r/P/p
s6.5.2: Okay I'll bite what's the basis for picking those values for p and q?
s8/s9: I'm going with the thought that somebody verified the XML schema.
I agreed with many of the initial IESG reviews of early versions of this draft,
but I think the security considerations is great big step in the right
direction. But, I had a bunch of edits on the security considerations to make
it more understandable. Not sure that all my suggestions are correct though.
s13.1, 1st para:
r/This is accomplished through the usage of
authorization policies./This is accomplished
using authorization policies.
r/treated in [RFC4745])./addressed in [RFC4745].
s13.1, 2nd para:
r/In addition to the authorization policies mechanisms/
In addition to the authorization policies, mechanisms
r/makes use of these/uses these
s13.1, 3rd para:
what does this mean:
The requirements of location information with respect to privacy
protection vary.
requirements on the information or requirements on giving out the information?
r/While the two obfuscation algorithm/While the two obfuscation algorithms
I think you mean to protection against unauthorized disclosure of location
information:
r/protection/protecting against unauthorized disclosure of location information
This sounds odd:
There
are certainly applications that require a different level of
protection and for this purpose the ability to define and use
additional algorithms has been envisioned. New algorithms can be
specified via the available extension mechanism.
Maybe:
Applications requirements vary widely; therefore, an extension mechanism is
supported to allow for the definition of new algorithms.
s13.2, 1st para:
r/then it contains/it contains
r/is danger to reveal information over time/is a danger than information will be
revealed over time.
r/real/reveal ?
13.2, 3rd para: ?
OLD:
For this purpose the algorithm described in Section 6.5.2 uses a grid
that ensures to report the same location information whenever the
target remains in the same geographical area.
NEW:
For this purpose the algorithm described in Section 6.5.2 uses a grid
that ensures the same location information is reported whenever the
target remains in the same geographical area.
s13.2, 5th para:
r/measures/protections ?
r/is visiting regularly/is regularly visiting
r/The first issue is the following:/The first concern is the ability to be
followed:
The second issue is also the following? Isn't the 3rd concern listed in the 1st
sentence visiting places regularly?
r/If the reported obfuscated locations are all
randomly different, an analysis will probably soon reveal the home
location with high precision/
If the reported obfuscated locations are all
randomly chosen, an analysis can reveal the home
location with high precision.
all randomly different/all randomly chosen (it'd be funny if they were all
randomly the same) and will probably is wishy-washy - the point is you can do an
analysis.
r/may render a much precise location
information than desired./
may render a much more precise location
information than is desired.
once or in a regular repetitive way can non-regular samples help leak samples?
maybe r/once or in a regular repetitive way/once or multiple times
also is it or or and at the end of that sentence?
r/An opponent,/A stalker, ;) but probably better to say attacker
Oh and I support Stephen's discuss position.
draft-ietf-kitten-gssapi-naming-exts
I have no objection to the publication of this document, and just
three minor nits you may want to look at.
Section 2
This document proposes concrete GSS-API
extensions.
Should feel free to be more positive! s/proposes/defines/
---
Section 3
I suspect the RFC editor will ask you to expand "iff"
---
Please consider replacing the reference text used here for
[OASIS.saml-core-2.0-os] with the text used in RFC 6595 to include the
stable URL.
Please consider the editorial comments from the Gen-ART Review by Pete McCann on 24-Apr-2012. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07387.html
In section 5: Another aspect of context is encoding of the attribute information. An attribute containing an ASCII or UTF-8 version of an e-mail address could not be interpreted the same as a ASN.1 Distinguished Encoding Rules e-mail address in a certificate. All of these contextual aspects of a name attribute affect whether two attributes can be treated the same by an application and thus whether they should be considered the same name attribute. In the GSS-API naming extensions, attributes that have different contexts MUST have different names so they can be distinguished by applications. As an unfortunate consequence of this requirement, multiple attribute names will exist for the same basic information. That is, there is no single attribute name for the e-mail address of an initiator. I don't have the expertise to evaluate this document thorougly, but something in the above seems weird, if not incorrect. It is certainly the case that an email address encoded in ASCII or UTF-8 cannot be byte-for-byte compared to the same email address encoded as an ASN.1 Distinguished Encoding Rules e-mail address. But the words "could not be interpreted the same as" strike me as incorrect. You *can* interpret the two e-mail address as the same if, after doing the decoding, you compare the addresses to eachother. And it would, indeed, be very unfortunate for something that happens to use a different encoding to get a different name for each encoding and therefore have multiple non-comparable occurances of the item. It seems like you would want only one occurance of each item, marked with the encoding, and implementations would be responsible for the decoding. Maybe this is just a language issue. But something seems wrong about the above.
Only nits: s2: r/(eg an X509/(e.g., an X.509 s3/s5/s7.5/s7.6: r/iff/if X3 s5: Consider Kerberos PKINIT (RFC 4556). Isn't this an informative reference? so: Consider Kerberos PKINIT [RFC4556]. s5: r/certificate authority/certification authority X2 s5: references for ASCII/UTF-8/ASN.1?
draft-ietf-fecframe-raptor
4.1. Definitions This document uses definitions that apply to FEC Framework in general as defined in [RFC6363]. In addition, this document uses the following definitions: Not sure what "that apply to FEC Framework in general" means. Don't you want to say something such as The FEC-specific terminology used in this document is defined in [RFC6363]. In this document, as in [RFC6363], the first letter of each FEC-specific is capitalized along with the new terms defined here:
- Its not clear to me whether the "device" mentioned in the IPR declaration's licensing section really only means h/w devices or not, or could badly impact e.g. an OSS implementation of this draft. I assume the WG have considered this and are happy with the idea of the license being specific to a "device" or at least don't seem to care (as implied by the write-up). - 6.2.1.2 - if the last octet is omitted then all the reserved bits aren't sent. Would it be worth noting that it'd not be safe to omit that octet if someone defines meanings for some of those reserved bits in future? Would "MAY be omitted" be better (i.e. use a 2119 keyword)? Finally, it'd have been nice if you had said that that octet SHOULD be sent or SHOULD be omitted - why not do that? - 7.1 - Would it be better to be explicit here about how the padding with zeros is done? I.e., rfc6330 says that symbols K through K'-1 are the padding symbols, the same is true here I think but good to say so, if so rather than forcing the reader to check in rfc6330. - 8.1.3 - Similar question about padding, though here the answer is obvious I guess, but still maybe no harm saying. - Section 9 defers to 6363 for security considerations, but 6330's and 5053's (identical?) security considerations seem more concrete, e.g. they RECOMMEND using something like TELSA, whereas 6363 eventually says "implement IPsec" but doesn't say much about what to use. It'd be good to be clearer about what, if anything, is mandatory-to-implement or SHOULD be used here. (This isn't a DISCUSS because all those RFCs are normative references so in theory implementing this means doing all of the above I guess.)
Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 18-Mar-2012. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07284.html
In section 7.2.1.2 did you mean to point to 6.2.1.2 instead of 6.2.2?
This document got a DISCUSS due to the transition of your responsible AD and the
need to fix some parts of the documents before the DISCUSS is resolved into a
YES.
General:
- There are a number of fields which do not say what type they are,
e.g., integer or unsigned integer. On the other hand some fields are labelled as
decimal number which is not applicable to the wire representation anyhow.
- How
are the bytes ordered on the wire. I guess in network byte order, but that
should be noted somewhere.
Here are those fields:
- Section 6.2.1.2:
MSBL Value range: A decimal non-negative integer less than 8192 for
FEC Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units
of symbols
Remove decimal, as this is not applicable on the wire.
Encoding Symbol Size Name: "T", Value range: A decimal non-
negative integer less than 65536, in units of octets
Remove decimal, as this is not applicable on the wire.
Payload ID Format Name: "P", Value range: "A" or "B"
The flag P can only take the binary values '0' or '1', but never "A" or "B". How
is the symbolic value of 'A' reprented in P and how is the symbolic value of
'B' reprented in P?
- Section 6.2.2., below "Figure 2: Source FEC Payload ID - Format A"
Source Block Number (SBN), (16 bits): An integer identifier for the
source block that the source data within the packet relates to.
Encoding Symbol ID (ESI), (16 bits): The starting symbol index of
the source packet in the source block.
How is the index to be interpreted, e.g., as unsigned integer? Please specifiy
this here!
- Section 6.2.2., below "Figure 3: Source FEC Payload ID - Format B"
Source Block Number (SBN), (8 bits): An integer identifier for the
source block that the source data within the packet relates to.
Encoding Symbol ID (ESI), (24 bits): The starting symbol index of
the source packet in the source block.
How is the index to be interpreted, e.g., as unsigned integer? Please specifiy
this here!
- Section 6.2.3., below " Figure 4: Repair FEC Payload ID - Format A"
Source Block Number (SBN), (16 bits) An integer identifier for the
source block that the repair symbols within the packet relate to.
For format A, it is of size 16 bits.
Encoding Symbol ID (ESI), (16 bits) Integer identifier for the
encoding symbols within the packet.
Source Block Length (SBL), (16 bits) The number of source symbols in
the source block.
How is the number of source symbols to be interpreted, e.g., as unsigned
integer? Please specifiy this here!
The same for " Source Block Length (SBL)"
for Format B.
Section 8.1.3., below "Figure 6: Repair FEC Payload ID - Format A"
Initial Sequence Number (Flow i ISN) - 16 bits This field specifies
the lowest 16 bits of the sequence number of the first packet to
be included in this sub-block. If the sequence numbers are
shorter than 16 bits then the received Sequence Number SHALL be
logically padded with zero bits to become 16 bits in length
respectively.
How is the Flow i ISN to be interpreted, e.g., as unsigned integer?
Source Block Length (SBL) - 16 bits This field specifies the length
of the source block in symbols.
How is this to be interpreted, e.g., as unsigned integer?
[con't from page 17]
Encoding Symbol ID (ESI) - 16 bits This field indicates which repair
symbols are contained within this repair packet. The ESI provided
is the ESI of the first repair symbol in the packet.
How is this to be interpreted, e.g., as unsigned integer?
Section 8.1.3., below "Figure 7: Repair FEC Payload ID - Format B"
Initial Sequence Number (Flow i ISN) - 16 bits This field specifies
the lowest 16 bits of the sequence number of the first packet to
be included in this sub-block. If the sequence numbers are
shorter than 16 bits then the received Sequence Number SHALL be
logically padded with zero bits to become 16 bits in length
respectively.
How is this to be interpreted, e.g., as unsigned integer?
Source Block Length (SBL) - 16 bits This field specifies the length
of the source block in symbols.
How is this to be interpreted, e.g., as unsigned integer?
Encoding Symbol ID (ESI) - 24 bits This field indicates which repair
symbols are contained within this repair packet. The ESI provided
is the ESI of the first repair symbol in the packet.
How is this to be interpreted, e.g., as unsigned integer?
Section 2: - replace "Section 6defines an FEC Scheme" with "Section 6 defines an FEC Scheme2 - replace "Section 6but with optimisations for with "Section 6 but with optimisations for" - replace "over IP Based" Networks " with "over IP Based Networks" " (move ' " ') - Section 4.2: Add ADU to the list of abbreviations - Section 6.2.1.2, at the bottom of the page: replace "An encoding format for The MSBL and Encoding" with "An encoding format for the MSBL and Encoding S"
I guess I'm with Stephen on the security considerations it should really also point to RFCs 5053 or 6330.
draft-ietf-ipfix-psamp-mib
I don't think it makes sense to have DEFVAL clauses for read-only objects. They are really used for object creation and are not appropriate for describing the default beavior of protocol implementations. For example... psampSampCountBasedAvail psampSampTimeBasedAvail psampSampRandOutOfNAvail psampSampUniProbAvail psampFiltPropMatchAvail psampFiltHashAvail
Please remove the citations from the Abstract --- There are a couple of places where you should s/MIB/MIB module/ E.g. Section 5.1 --- I would have expected to see some discussion of psampSampUniProbProbability and the non-support of NaN and Infinity in the compliance clauses. --- Should psampFiltHashFunction also include a reference to RFC 1141?
draft-ietf-marf-as
Thanks for addressing my points
Forgive me, but doesn't section 8.2 say that forged abuse reports constitue a real problem and the two mechanisms available to protect against them may result in genuine abuse reports being discarded? Is the message here "chosse which you think might be the least worse problem" or is it "you should use DKIM and SPF, but be aware that you may lose some genuine reports"? I would have liked some clarification as to which message is being sent.
Just a bunch of nitty comments. Feel free to take 'em or leave 'em. 5.1 (1) - this has a MUST but there's no well-defined/standard way to satisfy the MUST, maybe make that an "ought"? 5.1 (2) - I think you mean that "they think will" pass SPF/DKIM checks, since they can't be sure 5.2 (1) - "the receiver" is a bit ambiguous in the 1st sentence, maybe s/the receiver/the report receiver/? (Or if handling is expensive for both, then maybe say that.) 5.3 (1) - what does "SHOULD make" mean? Same comment as above for use of SHOULD when there's no standard way to do it, i.e. maybe s/SHOULD/ought/ 5.5 (1) - is "bulk senders" at the end here ambiguous? I read it as referring to the sender of the message(s) that triggered the report. 6 - what is a "smaller" AS or use-case? Do you mean fewer people will do this or that its simpler? 6 - point (3), is the "MUST be constructed" there right? If everything needed to satisfy this MUST is later in point 3, then you could say "MUST be done as stated below" - as is, this looks like there's something else needed to satisfy the MUST but you don't say what. 8.3 - this is a little terse, maybe point back at those recommendations or say a bit more? 8.4 - might be better to say "larger volumes or higher frequency" 8.5 - I guess this means that report receivers ought not react to missing reports as if something was wrong. Not sure if that's worth noting explicitly or not.
Thanks for addressing my comments.
The MUST in section 4.5 item 1 may need clarification. Do you mean to say that the system MUST accept a report with a feedback type with any value that makes it into the (specification-required) registry? Or are you wanting to scope that to values that were registered with an RFC that Updates/Obsoletes 5965? Or something else? Is this effectively requiring implementations of automated report processing systems to be configurable with what feedback types it will accept? If so, would it make sense to say that explicitly? Also, consider more detail on what accept means here. Does it mean the system can't return a rejection response (what bad happens if it does?) or is the intent that it must _process_ the report.
In section 5.1 item 1, is there a typical unstandardized out-of-band mechanism for telling unsolicited reporters to please stop that you can call out as an example (an existence proof)? In Section 6, item 1, the sentence "Automatic feedback generators MUST select recipients based on data provided by the report recipient." is really hard to understand (it's almost circular). Is it trying to say something like "Automatic feedback generators MUST only send to addresses explicitly provided by willing recipients."?
draft-ietf-emu-chbind
Just happy that there is an "Operations and Management Considerations" section. It makes sense in many documents, IMHO. Thanks for that. Regards, Benoit.
Minor editroial nit: the affiliation for T. Clancy in the header should be fixed.
I am escalating part of Barry's Comment to a Discuss Please give the valid ranges for new code point registries. Is the value zero reserved, out of scope, or unassigned?
idnits reveals...
-- The document has a disclaimer for pre-RFC5378 work, but was first
submitted on or after 10 November 2008. Does it really need the
disclaimer?
I would prefer you to fix this (if it needs fixing) with a respin so
there is a copy of the document on file with the correct disclaimer.
---
Please expand acronyms on first use if they don't appear in
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt with an
asterisk.
I found...
NAS (In the Abstract and a bit too late in the Introduction)
SSID (seciton 1)
---
Section 3
o Enterprise Network: A corporate network may have multiple virtual
Lads (VLANs) running throughout their campus network
This is the most beautiful text I have read for a long time. Thank you!
BTW s/Lads/LANs/ is only part of the problem.
Does a LAN run through a network?
(Sorry, I ran out of time to properly consider the secdir review so I'll just trust that that's being handled correctly.) 1) cleared 2) p22, 9.1 says "derivation of keying material including a key for integrity protection of channel binding messages" but that doesn't say that it must be that the authenticator can't know the relevant key. There also seems to be a missing MUST in the lead in to that list. 3) cleared
1) The secdir review [1] has resulted in some changes that are already agreed and some that are being chatted about between reviewer and wg chair. This is just a discuss to hold things while that happens. (Not all the review comments are DISCUSS level, but a few are. We can figure out which if we get stuck on some if that's ok.) [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03271.html 2) Does this really work with ERP? Seems like it'd add more roundtrips, e.g. making ERP-AAK pointless. 3) Why can't the authenticator cheat on CB if the EAP method is based on symmetric crypto with a KDC like thing? In fig 1 the lying NAS could mess with i1 as sent from peer to server. Why not? 4) Does including attributes that were validated in the CB failure message not expose the server to someone probing the server's policy? E.g. the lying NAS could play about until it knows what cheating is possible? 5) What does "MAY be defined" mean in 7.1? By whom? Where? Does that need to be here? 6) What does "as thorough of a validation as possible" mean in section 8? That doesn't seem to be testable. 7) Is "typically contains" enough for User-Name protection if EAP method identity protection is employed? I expected to see a MUST there. 8) Is A.3 correct? If the selected method is breakable (if not why bid down to it?) then the bad NAS can probably change the i1 message so I'm not convinced by this argument. nits: - p10 - rfc5296bis is in IESG Evaluation, and obsoletes 5296 so you should update the reference - p11 - knowing that the client is using layer 2 crypto doesn't seem very compelling if concerned about a bad NAS, since its the often the case that the putative bad NAS that can see the plaintext, it could leak that back over the air in clear if it wanted. (Liable to be detected, but then so might lack of layer2 crypto in the client UI.) - p22 - the NAS identifier can expose the user's location, depending on how those are named and whether confid. is available for the peer/server i1 or i2 message. That might be worth a mention.
The Gen-ART Review by Francis Dupont on 7-Apr-2012 raised quite a few editorial comments. The authors have indicated that many of them are very useful, and they want to update the document to address them, but this has not happened as yet.
-- IANA Considerations -- The definitions for the two new EAP Channel Binding Parameters sub-registries specify numbers in column one of the tables, but do not specify a range for those numbers. Is it 0-255 (one byte)? Something else? Please specify, so IANA (and the rest of us) knows. Similarly for the new sub-registry in 11.1. I would like to see a brief rationale for the choices of Standards Action and IETF Review for the registration policies for the two new parameters sub- registries. See draft-leiba-iana-policy-update if you want to see where I'm coming from on this. Just something brief that shows that it was considered and discussed, and that explains why these were chosen. Note: the definition for the new registry in 11.1 does give a rationale; thanks.
draft-ietf-appsawg-greylisting
Thank you for the explanation.
Please expand MTA. I know that you wrote: "Readers need to be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]." We could help the reader a little bit, instead of searching into http://tools.ietf.org/html/rfc5598 to know what the acronym means Similarly, maybe it's obvious for people dealing with Email, but I had to lookup "MX record" ... OLD: Experience suggests that the, the vast majority of mail comes from NEW Experience suggests that the vast majority of mail comes from Regards, Benoit.
Thanks for addressing my comment.
I strongly support this effort which draws a line between blacklisting and more acceptable techniques. I hope this will serve as encouragement to service providers to move away from descriminatory and service-impacting blacklists. --- Section 1 s/for provider better service./for providing better service./
- intro: "a period of time" is usually measured in minutes here, might be worth saying that just in case - 2.3: Odd reference text: "refers to the [SMTP] command verb" I think it'd be better if the reference was handled differently and e.g. it said "refers to the 'SMTP' command verb in an SMTP [SMTP] session" (I prefer if the references are not part of the text but that's a different style issue). The "RFC5321.MailFrom" notation also shows as a reference on the tools page, not sure if that's desirable or not or if it can be avoided or not. - typo, section 3, s/the, the/the/ - section 5: Are there any 4yz errors that SHOULD NOT or MUST NOT be used here? I've no idea and suspect not based on this text, but if there were then that'd be worth saying.
This is a well-written document and describes a useful function. I do support Martin's DISCUSS about the status. It definitely reads like a BCP.
Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 23-Apr-2012. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07382.html
2.5
Some implementations do filtering here
I think you meant, "Some implementations do greylisting here". There's no
filtering described in this section.
o identifiers in the message, such as the contents of the
RFC5322.From or RFC5322.To fields;
Change "message" to "message header" or "message content" or equivalent. I think
there is the potential to confuse envelope here.
2.6
I think you mean "spam", or maybe "spam senders", but not "spamware" in this
paragraph. There is nothing about an IP address that identifies spamware, but it
certainly might identify a sender of spam.
4.2
Some clients do not retry messages at all.
and
Some SMTP implementations make the error of treating all error codes
as fatal;
I think it's worth adding "in violation of [SMTP]". It should be clear that you
are only losing email from clients that are already not playing by the rules.
This is a very clear and helpful document. Thank you for making the effort to assemble it. Greylisting has been widely deployed for several years, but a concise explanation of the concept and its consequences has been lacking - this will be a very good tool for administrators interacting with systems that are already greylisting as well as those that are just adopting the practice. I don't agree that this should be BCP - it seems a good candidate for re-review and progression on the standards ladder. (Updating the comment with this question/suggestion:) In the second paragraph of section 3, consider pointing to the sentence in section 2.1 of RFC5321 that says "SMTP clients that transfer all traffic regardless of the target domains associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable." and say more strongly here that the agent receiving this retry response can't distinguish this condition from a disk full or other temporary condition making the receiver unable to accept where the sender really has no business knowing the reason why it's being told to re-try with a 400-level response
Section 5. point 2: The minimum default window is one minute. This seems to be rather short in respect of clock skew between different hosts and when messages are re-scheduled for delivery on hosts. Has this been tested/checked in real deployments. One example: This can be troublesome if the SMTP server which does the greylisting is +30 seconds off and the other end is off by -30 seconds. The other end will re-send the message just too late.
- Section 1: "this can justify providing degraded service, until there is a basis for provider better service." I cannot parse the 'provider better service'. - Section 5: The text before the list of practices says those items are RECOMMENDED, but a number of items is about SHOULD and SHOULD NOT. Not a big issues, but logically not clean, i.e., are they RECOMMENDED or does SHOULD apply. Probably, it might be good to have two lists, one for RECOMMENDED and the other for the SHOULDs.
draft-ietf-sipcore-rfc3265bis
This DISCUSS position does not require any immediate action on the part of the authors. I have an issue with the state diagram in section 4.1.2 that I would like to discuss. In general, I/ve found it important to take care with state diagrams in protocol specifications to ensure that the state diagram is correct and, unless otherwise indicated, complete. I apologize for not having the time to work through the entire state diagram for correctness; I did notice that section 4.1.2.2 includes a message exchange - which, admittedly, does not result in a state change - that is not reflected in the state diagram. My suggestion would be to add a disclaimer to the effect that the state diagram is not normative and that there may be aspects of the protocol behavior that are not reflected in the statae diagram. I'm open to discussion of this suggestion.
Thanks for the detailed list of changes from 3265. --- Does this also update 3261?
Clarified my questions in a call with Robert. Be nice if we can document the reality sometime soon but this isn't the place to do it.
The Gen-ART Review by Alexey Melnikov on 10-Apr-2012 started a discussion that has not yet reached closure. At least 3 issues need to be resolved: (1) Section 7.2 defines "reason" codes for use in the "Subscription- State" header field, and new reason codes require a Standards Action. This prevents registration of new Reason Codes in Experimental RFC. Please double check that that is intentional. (2) IANA reason code registrations require a reference to a published document which describes the event package. Insertion of such values takes place as part of the RFC publication process or as the result of "inter-SDO liaison activity." However, Standards Action is not appropriate since other SDOs do not publish Standard Track RFCs. (3) Ordering of template packages needs to be explained.
Many thanks to Paul for an excellent and thorough PROTO writeup. A note here: the IPR and copyright stuff you note from the nits checklist is just the boilerplate that's automatically put in by xml2rfc (or manually put in otherwise; it's correct in this document). We should update the checklist to have current references, and to reflect the current position of that boilerplate in the documents. I also really like the "SHOULD" note in Section 1.2. On the IANA Considerations, thanks for retaining the context here, so the original document can be properly obsoleted. One suggestion: In the base section 7: OLD (This section is not applicable until this document is published as an RFC.) NEW The subsections here are for current reference, carried over from the original specification. The only IANA action requested here is to change all registry references that point to RFC 3265, and have them point to this RFC. ...or some such text, so that the registries now cite the new document.
This is an incredibly well-written protocol document, and so clear that I'm fine
with a Yes ballot.
I can't convince myself any of these comments are DISCUSSion worthy, but I do
think they all need addressing one way or the other.
1.2
It is inappropriate to fail to comply with
"SHOULD"-strength requirements whimsically or for ease of
implementation.
I think that can be strengthened: "It is violation of a requirement of the
specification to fail to comply with 'SHOULD' requirements whimsically or for
ease of implementation."
3.1.1
Here and elsewhere, you say that something "MUST be defined by the event
package". That's an odd use of MUST, since it's clearly not a protocol
requirement for the implementer of the protocol, but rather a requirement for
the protocol extension writer. I can see saying that "event packages will make
such-and-so REQUIRED" to put implementers on notice that they will find the
requirement in the event package, but I do wish you had a non-2119 way of
expressing requirements for event package writers.
A natural consequence of this scheme is that a SUBSCRIBE request with
an "Expires" of 0 constitutes a request to unsubscribe from an event.
Maybe this is obvious and implicit for someone familiar with SIP, but you do
mean "a SUBSCRIBE request *on the same dialog* with an 'Expires' of 0", right?
You don't actually get to the fact that a SUBSCRIBE is dialog-creating until
4.1.2.1, but I think you can still make it clear here. Or you can just skip it,
since it's covered in 4.1.2.3.
4.1.2.1
The "Expires" header field in a 200-class response to SUBSCRIBE
request indicates the actual duration for which the subscription will
remain active (unless refreshed).
This implies to me (though it's not stated explicitly here) that the response
MAY have a different Expires value than provided in the request. Is that true?
You say something about this in 4.2.14, but not here.
4.1.3 For 'probation', you say "the client SHOULD retry at a later time". Is
that really what you mean? What harm comes to me if I decide not to retry?
Couldn't I decide to not retry? Do you mean "MAY retry at a later time", or
perhaps "SHOULD NOT retry immediately". Some piece of information is missing
here. I suspect this has some parallel to 'deactivitated' and migration, but I
don't get it.
4.2.1 Why the out clause for 3515? If it's causing problems, why not just say
MUST NOT and update 3515 to deprecate the use?
4.2.2 Seems to me that if a NOTIFY receives a failure response and the
subscription is therefore removed, the notifier should *not* send an additional
'terminated' NOTIFY. But the state machine seems to indicate that it should. Was
that the intention?
4.5.2 Dialog sharing seems like a mess. Why is this not a SHOULD NOT?
5 Generally: It seems like this entire section might work better as an appendix.
It's not part of the protocol per se; it's extension documentation instructions.
Also, the 2119 language in this section seems weird, especially in 5.4.1 and
5.4.12. Those seem like inappropriate uses of 2119. The only one I can make a
case for is the one in 5.3.2, and even there I'm not convinced. (I notice that
for some reason you *didn't* use 2119 language in 5.4.6 and 5.4.7, and *never*
used MAY in this section.) Again, it would be nice if you could find a better
way to express this. I'm not convinced 2119 is useful or appropriate here.
7.1 2119 language in IANA Considerations sections always worry me. When you say,
"Registrations with the IANA MUST include...", are you putting a requirement on
IANA? On the Expert Reviewer? I would rather see these removed and instead
indicate that it is "required information in the template" or something like
that.
7.1.1 s/initial IANA registration for event types will be empty/initial IANA
registry for event types will be empty
7.2 Why is "Standards Action" required for this?
8.4
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
Do you really want to allow "...---..."? Are you sure you don't want:
token-nodot = alphanum *( ( "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" ) alphanum )
instead?
Section 4.1.2.4., paragraph 4: > Due to the potential for both out-of-order messages and forking, the > subscriber MUST be prepared to receive NOTIFY requests before the > SUBSCRIBE transaction has completed. + packet loss which can also lead to NOTIFY requests arriving before the SUBSCRIBE transaction to be completed.
draft-ietf-netmod-smi-yang
I found the text "config false" a bit out of context. Can you provide some explanation?
Just wanna check two things, they're probably ok already though... 1. An ASN.1 INTEGER can be multi-precision (e.g. 2048 bits). Not sure if that's allowed in SMIv2 but if so, worth a mention? Section 2 implies 32 bits is enough. 2. OID arcs can similarly be >32 bits long so if those were just mapped to 32 bit values that'd be bad.
s4.2: Is it worth having a default yang statement added to all converted MIBs that says this module was converted from SMIv2 to YANG using RFC X? Maybe it's called conversion?
draft-ietf-krb-wg-des-die-die-die
I cleared my Discuss after a conversation with the AD and WG chair on the understanding that they will close the loop with the WG on whether the code points in any IANA registries should be deprecated.
I am glad to see this draft and it is well-written. I am curious as to why the recommendation is limited to SHOULD NOTs and not MUSTs. Are there reasons to allow this wiggle room? If so, it would be good to give an example in the draft.
[Thanks for addressing my other DISCUSS comments] I do want to make sure that we send the right announcement for both this document *and* the moving of 1510 to Historic. I'm just leaving this DISCUSS point as a placeholder until we figure out how to do that.
I am not entirely clear why this is a BCP and not part of the standards track specification of Kerberos. This is a change to a protocol and therefore part of a technical specification, not a policy or operational guideline.
Like Pete, I don't understand why this should be published as a BCP (I support that portion of his DISCUSS).
This draft does not update RFC 1510 but aims to obsolete it , i.e. the header of the draft is not correct: "Updates: 1510, 1964, 4120, 4121, 4757" However, Pete's discuss covers this already.
Finally!
draft-ietf-appsawg-xdash
This text: 2. Recommendations for Implementers of Application Protocols Implementers of application protocols MUST NOT treat the general categories of "standard" and "non-standard" parameters in programatically different ways within their applications. while probably not harmful, is sufficiently vague and refers to undefined terms in a way as to contribute, perhaps, more confusion than value.
draft-dbider-sha2-mac-for-ssh
Congratulations! Shortest I-D on the telechat. I have no objection to the publiscation of this document and just two small nits. --- It doesn't really work to use RFC 2119 language in the Abstract. --- Section 2 This memo adopts the style and conventions of [RFC4253] in defining new data integrity algorithms. The following new data integrity algorithms are defined: I dare say I am overly pedantic, but I don't think the algorithms are actually defined here, just the identifiers for the algorithms.
- I'd like to see the -96 bit truncated variants disappear as per previous comments. I believe the authors are ok with that so this is just so's we all remember to do that.
draft-ietf-ecrit-lost-sync
I see from the charter that this I-D was planned as Experimental. Although it is in no way a requirement for publication, I would really like this document to provide some explanation as to why it is targeted as Experimental. I would also like to see some parameters of the "experiment" - what is the scope? how does the experiment need to be contained? what feedback are the authors/WG looking for from experimenters? how will the experiment be judged a success?
- typo: singed mappings - what TLS authentication is required if any? Are anon ciphersuites ok or not? Is TLS mutual auth required or not? Be good to say either way. - Is there any requirement that the TLS server/client certs map to anything associated with the service (e.g. its DNS name) or with anything in the payload? Again be good to say either way. - Maybe this is my ignorance of LoST and Relax NG, but where do the <Signature> elements go in this protocol and what elements are required to be signed?
I agree with Pete's feedback that there is a significant amount of fluff in this document that is not needed. Other comments: 1. The second paragraph of section 4.2 states: "A newly received mapping MUST update an existing one having the same 'source' and 'sourceID' and a more recent time in 'lastUpdated'. That seems rather confusing sentence structure, so I would recommend something like: "If a newly received mapping has a more recent time in its 'lastUpdated' attribute, it MUST update an existing mapping that has matching 'source' and 'sourceID' attributes.". 2. In section 4.1 (2nd paragraph) : s/SHOULD keep track to/SHOULD keep track of/. 3. Second sentence of section 4.3 should start with "Imagine" rather than "Image".
Please consider the editorial comments from the Gen-ART Review by
Wassim Haddad on 24-Apr-2012:
- Perhaps I missed it somewhere in the document, but I could not find
the meaning of "ESRPs" (page 5)
- Suggest re-writing the last paragraph on page 8
- Suggest re-writing the 3-line paragraph on page 9
Some minor, non-blocking comments: -- Section 7 -- Are there any ways to encounter or avoid synchronization loops other than what you say in the first two paragraphs here? What happens if a buggy node always modifies "last updated" to the current time before relaying a mapping? Would there be any way to stop a loop? It's more than a typo that singes things; this sentence is hard to read: OLD With digitially singed mappings mappings cannot be modified by intermediate LoST servers. NEW When mappings are digitially signed, they cannot be modified by intermediate LoST servers. -- Section 8 -- Just noting that the second paragraph seems oddly familiar...... :-) -- Section 9.1 -- The title and the first sentence each use different terms for what we now prefer to call "Media Type". It's not a big deal, but you might please switch to that term. -- Sections 9.2 and 9.3 -- IANA probably knows where you're registering these, but I don't, and I'm always worried about registration errors. I suppose as long as it's clear to IANA, it's OK... but can you specify exactly what registries (using the exact names and perhaps URLs, from https://www.iana.org/protocols/ ) you mean?
Section 9.1:
The ietf-types review pointed out specific language from RFC 3023 section 7.1
that should be used in the registration of application/lostsync+xml. Please fix:
Optional parameters: charset
Indicates the character encoding of enclosed XML.
Replace with "Same as charset parameter of application/xml as specified in RFC
3023."
[Just a reminder: None of the following cause me as an AD to hold up publication
of the document. They are just the (sometimes strongly held and expressed)
beliefs of yet another bozo in the IETF community. Take them as such.]
Section 1:
This is supposed to be a technical specification, not an academic paper. I find
the 6 pages of fluff in the introduction to be useless and distracting to the
reader. It is poorly written and never actually describes the purpose of the
document. I have to wait until the first full paragraph of page 8 to see:
This document defines two types of exchanges and those are best
described by the exchange between two nodes as shown in Figure 5 and
Figure 6.
Don't explain by pointing me to diagrams and examples. Explain in words. I think
this section should be completely rewritten and reduced to 2 paragraphs. The
current introduction diminishes the document.
Section 4.1:
The LoST Sync source SHOULD keep track to which LoST Sync destination
it has pushed mapping elements. If it does not keep state
information then it always has to push the complete data set.
In the first two sentences, do you really mean:
The LoST Sync source SHOULD only push new mapping elements which it
has not previously pushed to the LoST Sync destination.
Your current text is making a requirement about internal state of the
implementation. What I have above is a protocol requirement. I think that's what
you meant. You continue:
As discussed in Section 5.1 of [RFC5222], mapping elements are
identified by the 'source', 'sourceID' and 'lastUpdated' attributes.
A mapping is considered the same if these three attributes match. It
is RECOMMENDED not to push the same information to the same peer more
than once.
So, I must ask why is RECOMMENDED not to push the same information to the same
peer? Is it simply bandwidth considerations? Or processing on the peer? Why the
2119 imperative?
A <pushMappings> request sent by a LoST Sync source MUST containing
one or more <mapping> elements.
Do you mean, "A <pushMappings> request sent by a LoST Sync source MUST contain
at least one or more <mapping> elements" or "MUST NOT be empty" or something
like that? What is the requirement here? What are you trying to prevent?
Section 4.2:
A newly received mapping MUST update an existing one having the same
'source' and 'sourceId' and a more recent time in 'lastUpdated'.
Again, what's the protocol requirement here that requires the 2119 imperatives?
Don't you really mean, "A newly received mapping that has the same 'source' and
'sourceID' as a previous mapping with a more recent 'lastUpdated' time is an
update to the existing mapping."?
Similarly:
If the received mapping does not match with any existing mapping
based on the 'source' and 'sourceId' then it MUST be added to the
local cache as an independent mapping.
"Otherwise, it is a new independent mapping." Again, what bad behavior are you
trying to prevent with the "MUST"?
Section 5:
This document uses HTTPS as a transport to exchange XML documents.
No it doesn't. There is nothing in this document concerning the use of HTTPS or
any other transport protocol. I don't even think the document "assumes" the use
of HTTPS. I think this section can be struck from the document without any harm.
Section 9.1:
The ietf-types review pointed out specific language from RFC 3023 section 7.1
that should be used in the registration of application/lostsync+xml.
Encoding considerations: Identical to those of "application/xml" as
described in [RFC3023], Section 3.2.
Not that it makes a real difference, but you might as well replace with "Same as
encoding considerations of application/xml as specified in RFC 3023" to keep it
consistent with the precise language of 3023.
I echo Stephen's comments. s5: Not sure if it's worth it but maybe mentioning that only offering HTTPS is different than RFC 5222 because it offers HTTP as well. Maybe saying because this is exchanging authoritative data it's inappropriate to use HTTP? Maybe you could do this in the 1st paragraph of the security considerations: Hence, the protocol operations described in this document require authentication of neighboring nodes, which is why HTTPS is required.
draft-ietf-pkix-pubkey-caps
I am balloting No Objection on the assumption that the Security ADs are on top of this work. I do have a few nits I noticed along the way. --- Abstract s/define/defined/ --- Please expand acronyms not marked with an asterisk in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt --- Section 1 OLD but we did not currently have any way of doing so at the current time. NEW but we did not have any way of doing so. END --- Section 1 s/structure need/structure needs/
- I thought S/MIME capabilities were to allow a sender to know what a receiver wanted/could handle, this says it the other way around. - 1 s/need to be/needs to be/ in last para before 1.1
The appendix includes TBD values that need to be assigned.
Please reword the last sentence of the Abstract. It says: > > An example of where this is used is with the OCSP Agility draft. > Can this be worded in a way that points to an RFC? If not, can it be worded in a way that does not use "draft"? Section 2.1 says: > > RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 | > 4096 | 8192, ...) > The integer values appear in a surprising order. While this will not impact code or interoperability, why not put them in ascending order? Should the capabilities in section 3.1 provide an optional way to specify sizes of P, Q, and G that are supported? Similarly, should the capabilities in section 3.2 provide an optional way to specify sizes of P and G that are supported? In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves instead of the very rich structure that is currently specified. Several other documents have taken this approach. Any popular curve can be assigned an object identifier to name it. In addition to my comments above, please consider the comments from the Gen-ART Review by Mary Barnes on 23-Apr-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07383.html
[Update: the -05 version addresses all my substantive comments.]
draft-templin-aero
- It is impossible to evaluate this draft without more detail regarding the operational scenario in which it is to be deployed. If the reference scenario described in Section 4.3 were deployed by devices and links contained within a single campus, one might ask why the problem could not be solved by running an IGP on Routers A, B and D and by putting Host F behind a router. - This draft appears to use ICMP as a routing protocol. However, ICMP does not have all of the capabilities required by a routing protocol. You might want to explore the this issue in the next version of this draft. - The approach used in this draft seems to contradict the following statement from RFC 1812: "A router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. If a router is not using a routing protocol, a router MAY have a configuration that, if set, allows the router to consider routes learned through ICMP Redirects when forwarding packets." - Beyond these, there are many other comments. For example, Stephen's question regarding authentication is telling. However, it may not be worth discussing these until we understand the problem that you are really trying to solve.
Looking at the number of DISCUSS already, I would prefer to wait for the next version of the draft before reviewing the document in details. By spending 15 minutes on the draft, I have some questions already. Therefore, I reserve the option to come back and potential add a DISCUSS on the next document version.
1. In this text from the Introduction: For example, when an ingress link neighbor accepts an ordinary redirect message, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without involving an intermediate router. I don't think I see any description of a way for the egress node to explicitly notify the ingress node, either directly or through the intermediate node, that the egress node is unwilling "to accept packets directly", nor do I see how the intermediate node reacts to a NAK from the egress node. 2. Also in the text cited in point 1, I don't see any support for the assertion that an intermediate router is required. Isn't that what routing protocols do? On re-reading that text, I realize I may be confused: does "without involving an intermediate router" mean: a) the ingress node needs an intermediate router to learn whether the egress nodes will accept traffic from the ingress node or b) the egress node will not accept traffic directly from the ingress node but it will accept traffic forwarded from the ingress node forwarded through the intermediate node? 3. Do I have it right in section 4.4.7 that the Redirect response from D is sent to L3(B) (i.e., unicast to the ingress node), but the intermediate node A snoops that Redirect message and verifies the contents in various ways before forwarding it to B? And then it doesn't decrement the hopcount? Why are these exceptional forwarding rules necessary? Can't D send the Redirect to A, and then A send a corresponding Redirect to B? 4. Section 4.4.5 specifies that the AERO Predirect/Redirect message will use type 100, while Figure 4 shows the use of type 137. I include this as a DISCUSS point because Figure 4 needs to be fixed to show type 100 before the document is published to avoid problems with the existing ICMP Redirect message.
1. The document has many details about the operations of the various AERO nodes that are not germane to the specification of AERO. I would suggest editing out all of the provisioning and initialization details in, e.g., section 4.3, and simply describe the state of the various AERO nodes at the time of AERO operation. 2. In section 4.4.11, what prevents A from invoking the Predirect/Redirect mechanism for each datagram received from B destined for D, even if B has determined that B cannot send directly to D? 3. In the Security Considerations section, how does an Aero edge node know to trust an AERO intermediate router that advertises itself? I think the digital signature mechanism needs to be explored in more detail or data authentication more generally needs to be left for future work.
It is entirely unclear to me what real problem this work is designed to solve. It is clear that it is possible to construct a network where "triangular paths" could exist and where redirection can help resolve the issues. Only one brief paragraph is given to explain why "ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios" and it is unclear to me whether this represents a real problem. It would appear that the issue can arrise when the multi- access link has very large numbers of hosts and very large numbers of routers on the same link. Is this realistic? Do we not find this type of deployment in the wild because of these problems or because that is simply not how networks are usually built? So I would like to see several things called out more explicitly: - What are the deployments that motivate this work? - Is the model here that the Aero Edge Routers are acting as "PEs" in a sort of VPN like model? - What sort of scaling numbers are to be considered? - What are the operational problems with existing solutions and why can they not be solved using pre-existing protocol solutions? - Would the problem not exist if all nodes on the link were routers or if nearly all (i.e. except for a default and alternate router) were hosts? - How come spoofing of redirects is given as a motivation for this work yet called out as a security issue for Aero with a remediation offered that could be applied today? Other than that, I feel that there are so many significant changes needed to address the many Discusses already raised that I am cautious about drawing a line under my review and reserve the option to come back and add to my Discuss when a future version has been published. I hope the sponsoring AD will put the document back on a future telechat after it has been updated.
In Figure 5, I assume that nodes B and F are actually routers (i.e. AERO edge routers) since they provide acceess to hosts through IP clouds.
(1) 4.4.4 - I don't get the origin authentication check, you say that the source address is correct if a list of 4 things are ok, but then later that only one of them needs to be ok. Which is it? The latter case (any of the 4) seems broken since the 3rd bullet is just the easily spoofed MAC address. The last paragraph here is also odd, the two sentences seem to contradict one another. (2) the signature scheme in 4.4.4 is undefined, you need to either define it, or else fess up and say that there's no current scheme and AERO just depends on things that are easily forged and strong data origin authentication is for future work. (I'd be ok with the latter for an experimental draft like this I think.) section 3: no security requirements for strong authentication?
FWIW, I agree with a bunch of the the other discusses on this.
I am editing my DISCUSS points in order focus on the issues that still need resolving. Since a new document is not available, I have marked each point with the state I think they are in... This document is going to require some true DISCUSSion in order to resolve some obvious issues. 1. If this draft goes forward as Experimental, it needs more justification. What issues with AERO make it unsuitable for use on the Internet as a whole? What network characteristics are required to assess AERO's behavior? What issues will arise if non-AERO and AERO-capable nodes attempt to interact? Is AERO truly suitable for any multi-access network? 2. From the author, my understanding is that an AERO edge router will have a set of ACLs that only allow traffic to be forwarded to it that comes from its default router (router D only forwards traffic from router A by default). That implies that router D must trust the MAC-level information (e.g., src MAC address) contained in a forwarded frame. How is that accomplished? In general, multi-access networks require specific MAC-level functions to do that. Discussion of these issues and how they relate to the AERO messages is needed. 3. [Resolved pending a new version] Section 4.2.2 specifies AERO host behavior. Since that behavior does not differ from standard IPv6 host behavior defined in RFC 4861 and RFC 4862, what is the purpose? *IF* you need to say anything about host behavior, state that it acts as an IPv6 host (as defined in RFCs 4861, 4862, and 6434). 4.[Resolved pending a new version] Do AERO edge routers (Section 4.2.3) differ from the CPE routers defined in RFC 6204 (other than the added AERO functionality)? It appears that they should, but it is not specifically called out. 5.[Modified] I find the claim (section 4.4.1) that "...the ingress node has no way of knowing whether the egress is willing to accept its packets, ..." dubious at best. These packets are being transmitted as IP datagrams, which are best effort. It is not the job of layer-3 to build reliability into the packet forwarding paradigm. 6. [Resolved] Section 4.4.5 re-defines the structure of the ICMPv6 Redirect message by adding new bit fields. Given that, why does the document not list itself as updating RFC 4861? If that is the case, this change needs to be reviewed by the 6MAN working group. 7. [Modified] Sections 4.4.10-12 have convinced me that this specification is really a dynamic routing protocol using ICMPv6 Redirect (and the variant Predirect) messages. The incorporation of mobility concepts and periodic reachability logic makes this no different than existing MANET and scaled-down IGPs. In this light, the document does not clearly explain key functional behaviors or why those behaviors are not needed. In order to address these concerns, more detail is needed (per Russ' DISCUSS) on exactly what link types AERO is expected to work under. Single-link behavior for something like Ethernet does not make sense in the context of AERO.
1. [Resolved pending a new version] Section 4.2.2 states that the egress AERO router sends a Redirect message to the intermediate AERO router who then proxies that Redirect to the ingress AERO router. It would be good to include a forward pointer to sections 4.4.7 and 4.4.8 since that is where the sending and redirect rules are defined. 2. [Resolved pending a new version] The Acknowledgments section seems to have been truncated.
I understand that the AERO mechanisms were initially designed for NBMA tunnel virtual interfaces, but these mechanisms can also be applied to any multiple access link types that support redirection. That said, I think we need to better characterize the environments where AERO is appropriate, and maybe even more importantly the environments where AERO is not appropriate. This position seems to be supported by the Gen-ART Review by Pete McCann on 24-Apr-2012. Please consider the other comments that are include in this review. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07385.html
Lots of DISCUSS positions already, and I don't have anything new to add. I'll just say that I support some of the other AD's DISCUSS positions, particularly Brian's and Ron's.
I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems a bit odd. The document doesn't describe the circumstances under which you would want to experiment and why you wouldn't want to let this out on the Internet as a proposed standard. I think some more explanation, and perhaps an adjustment to status, is needed.
I'm supporting the other DISCUSSes which cover the issues of the draft.
Hate to pile on but there were a number of agreed changes as a result of the secdir review. This is just a placeholder discuss until fixes to those changes are agreed and incorporated.
I support the discusses from the other ADs.