Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))
At 13:39 29-10-10, Andrew Sullivan wrote:
Supppse we actually have the following problems:
1. People think that it's too hard to get to PS. (Never mind the
competing anecdotes. Let's just suppose this is true.)
2. People think that PS actually ought to mean "Proposed" and not
"Permanent". (i.e. people want a sort of immature-ish level for
standards so that it's possible to build and deploy something
interoperable without first proving that it will never need to
change.)
Some people view that level as an immature-ish level; some people may
view it as a mature as they have overcome the barriers to publication.
4. Most of the world thinks "RFC" == "Internet Standard".
Yes.
If all of those things are right and we're actually trying to solve
them all, then it seems to me that the answer is indeed to move to _n_
maturity levels of RFC, where _n_ < 3 (I propose 1), but that we
introduce some new document series (call them TRFC, for "Tentative
Request For Comment", or whatever) that is the first step. Then we
get past the thing that people are optimizing for ("everything stays
as Proposed Standard once it gets published") by simply eliminating
that issue permanently.
That's somewhat similar to the Working Group Snapshot proposal. Such
proposals are mainly about addressing point 4.
I don't think that this community would support having "Proposed
Standard" renamed to "Alleged Standard" or that such a change is in
accordance with the IETF's sense of humor.
Ah, you say, but now things will stick at TRFC. Maybe. But we could
on purpose make it easier to get TRFC than it is now to get PS (say,
by adopting John's limited DISCUSS community for TRFC, or one of the
other things discussed in this thread). Also, the argument about
everyone thinking that RFCs are "standard", and the resulting pressure
to make them perfect and permanent, would be explicitly relieved (at
least for a while), because nobody thinks that TRFCs are standards.
The RFC brand worked too well. The people who have to decide on the
issue are the same people who have authored documents which are
currently at Proposed Standard level. At a different level, this is
like asking the IETF to give up the RFC brand.
Note that this is not to denigrate SM's suggestion, which also doesn't
I view your comments as constructive criticism.
seem wrong to me. But since one of the issues appears to be that
anything called "RFC" is set in stone, then if we just stop calling
the early-publication documents "RFC" that and introduce something
after I-D (which is formally only on the _way_ to some consensus, and
not actually the product of it), the blockage might be removed.
People commented that there were not one issue but multiple
issues. RFCs published in the IETF Stream differ from RFCs from
other streams in one aspect; they go through the IETF Standards
Process. I am over-simplying here. The label is also about archival
of the consensus decision [1].
At 14:03 29-10-10, Martin Rex wrote:
Essentially, you seem to be asserting that IETF community feedback
should be considered harmful and delayed to much later in the process
where it can have even less impact.
I did not describe community feedback as "harmful". I prefer not to
provide an example here to avoid conflating this with matters that
are subject to appeal.
To me, that sound a little like giving up.
Maybe. I doubt that the ideal solution would gain
consensus. Anyway, what's ideal is subjective.
Changing solutions, fixing protocols and fixing documents is exhausting
and painful, so let's just skip all of that. Let vendors and implementors
I agree that it can be exhausting and painful. But then there is a
price to pay for getting free reviews. Authors who would like to
have their protocols and documents fixed should realize that it
cannot happen without effort on both sides.
wiggle out how to create interoperable products from shoddy specs
all by themselves -- which is what some of them have been doing for
some time -- implementing defective specs and shipping interoperability-
impaired products long before the standardization work has converged
on a moderately stable Proposed Standard.
We might call it shoddy specs; other view it as a matter of doing
business. "It works for me" is a bad idea if we are concerned about
interoperability and clarity.
At 01:39 30-10-10, John C Klensin wrote:
If that is true --and it may be-- it would indicate that not
even we can keep track of the difference between "RFC" and
"Standard". If that were to be the case, discussion of maturity
levels is basically a waste of time.
Yes, and the end result could be giving up.
I think there are other issues with your outline, but the key
one is that it would really, really, depend on "do or die"
working. If it didn't, the IETF would rapidly acquire a
reputation for producing garbage as Standards, and that would
be, IMO
Re: Alternate entry document model (was: Re: IETF processes (wasRe:
- Original Message - From: "Yoav Nir" To: Cc: "t.petch" ; Sent: Tuesday, November 02, 2010 5:08 PM Strange. I look at the same facts, and reach the opposite conclusions. The fact that there were many implementations based on drafts of standards shows that industry (not just us, but others as well) does not wait for SDOs to be "quite done". They are going to implement something even we label them "danger - still a draft pretty please don't implement" Everybody in our industry has heard of Internet Drafts. They know that these are the things that end up being RFCs, which are, as others have said, synonymous with standards. If we don't get the drafts reviewed well enough to be considered "good enough to implement" fast enough, industry is just going to ignore us and implement the draft. My conclusion is that we can't just ignore industry and keep polishing away, but that we have to do things in a timely manner. One thing we've learned from the TLS renegotiation thing was that it is possible to get a document from concept to RFC in 3 months. Yes, you need commitment from ADs and IETFers in general (IIRC you and I were among those pushing to delay a little), but it can be done. It's a shame that we can't summon that energy to regular documents, and that's how we get the SCEP draft which has been "in process" for nearly 11 years, and it's still changing. But that is partially because we (IETFers) all have day jobs, and our employers (or customers) severely limit the amount of time we can devote to the IETF. But that's a subject for another thread. Time to get back to that bug now... Perhaps we should step back a little further, and refuse to charter work that will become an RFC unless there are two or more independent organisations that commit to producing code. There is nothing like interoperability for demonstrating the viability (or not) of a specification, and likewise, two independent organisations are likely to bring two rival views of what should and should not be specified. Those not implementing can watch the two slugging it out, and provide a balanced judgement when something needs consensus. And two organisations with an interest might want to see a ROI sooner rather than later. Tom Petch Yoav On Nov 2, 2010, at 5:09 PM, Martin Rex wrote: > t.petch wrote: >> >> From: "Andrew Sullivan" >>> >>> Supppse we actually have the following problems: >>> >>>1. People think that it's too hard to get to PS. (Never mind the >>>competing anecdotes. Let's just suppose this is true.) >>> >>>2. People think that PS actually ought to mean "Proposed" and not >>>"Permanent". (i.e. people want a sort of immature-ish level for >>>standards so that it's possible to build and deploy something >>>interoperable without first proving that it will never need to >>>change.) >>> >>>3. We want things to move along and be Internet STANDARDs. >>> >>>4. Most of the world thinks "RFC" == "Internet Standard". >> >> I think that this point is crucial and much underrated. I would express >> slightly differently, That, for most of the world, an RFC is a Standard >> produced by the IETF, and that the number of organisations that know >> differently are so few in number, even if some are politically >> significant, that they can be ignored. > > > The underlying question is acutally more fundamental: > do we want to dillute specification so much that there will be > multiple incompatible / non-interoperable versions of a specification > for the sake of having a document earlier that looks like the > real thing? > > There have been incompatible versions of C++ drafts (and compilers > implementing it) over many years. HD television went through > incompatible standards. WiFi 802.11 saw numerous of "draft-N" > and "802.11g+" products. ASN.1 went through backwards incompatible > revisions. Java/J2EE went through backwards-incompatible revisions. > > > Publishing a specification earlier, with the provision "subject to change" > appears somewhat unrealistic and counterproductive to me. It happens > regularly that some vendor(s) create an installed base that is simply > to large to ignore, based on early proposals of a spec, and not > necessarily a correct implementation of the early spec -- which is > realized after having created an installed base of several millions > or more... > > > Would the world be better off if the IETF had more variants of > IP-Protocols (IPv7, IPv8, IPv9 besides IPv4 and IPv6)? Or if > we had SNMP v4+v5+v6 in addition to v3 (and historic v2)? > Or if we had HTTP v1.2 + v1.3 + v1.4 in addition to HTTPv1.0 & v1.1? > > > I do not believe that having more incompatible variants of a protocol > is going to improve the situation in the long run, and neither do > I believe in getting entirely rid of cross-pollination by issuing > WG-only documents as "proposed standards". > > > What other motivation could there be to publishing documents earlier >
Re: Alternate entry document model (was: Re: IETF processes (wasRe:
On Nov 3, 2010, at 1:42 PM, t.petch wrote: > > Perhaps we should step back a little further, and refuse to charter work that > will become an RFC unless there are two or more independent organisations that > commit to producing code. There is nothing like interoperability for > demonstrating the viability (or not) of a specification, and likewise, two > independent organisations are likely to bring two rival views of what should > and > should not be specified. Those not implementing can watch the two slugging it > out, and provide a balanced judgement when something needs consensus. > > And two organisations with an interest might want to see a ROI sooner rather > than later. > > Tom Petch > That's being a killjoy. Organizations never commit to producing code. Besides, sometimes people get ideas and would like to get them published even before they have convinced their management that implementing is a good idea. Now if someone produces an RFC just to convince management that it's a good idea to implement (because there's an RFC) that's a different thing. Anyway, I have followed three cases where there were competing proposals for doing the same thing, one in NEA, the other two in IPSECME. As it turned out, those not implementing watched the two slugging it out, and provided no judgement whatsoever. In all three cases. I get a feeling that working groups are much better at polishing a single proposal than they are at choosing between competing proposals. I think Martin pointed out a similar thing yesterday. The RI proposal was not the only one on the table, but it was essential to have just one proposal to get the process running. RFCs have one big advantage over all kinds of "blessed" internet drafts. The process of publishing an RFC gets the IANA allocations. Every implementation you make based on a draft will ultimately not work with the finished RFC because you have to use some "private" ranges of numbers. I have a feeling (not backed by any evidence) that part of the reason people rush to publish documents is the need to get IANA assignments for their implementations. If we could have some kind of "viable", "promising" or "1st review" status for an Internet Draft, where the IANA assignments can be done on a temporary basis, I think this could allow for better review later on. I have no idea, though, how to get rid of the "need to support legacy implementations" argument that will arise later on, if changes to the protocol are proposed as part of the review. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (wasRe:
Hi, Yoav, Recognizing that we all work in different parts of the IETF, so our experiences reflect that ... RFCs have one big advantage over all kinds of "blessed" internet drafts. The process of publishing an RFC gets the IANA allocations. Every implementation you make based on a draft will ultimately not work with the finished RFC because you have to use some "private" ranges of numbers. I have a feeling (not backed by any evidence) that part of the reason people rush to publish documents is the need to get IANA assignments for their implementations. I know that getting IANA allocations is a major consideration for one of the SDOs I'm liaison shepherd for, so my experience matches this (of course, there are various IANA policies - if a registry is first-come first-served, this isn't a consideration). If we could have some kind of "viable", "promising" or "1st review" status for an Internet Draft, where the IANA assignments can be done on a temporary basis, I think this could allow for better review later on. I have no idea, though, how to get rid of the "need to support legacy implementations" argument that will arise later on, if changes to the protocol are proposed as part of the review. Again, this depends on the instructions to IANA - some policies are easier to accommodate than others. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-c1222-transport-over-ip-07 -- more concerns
Hello, the recent discussion on draft-c1222-transport-over-ip-07 (regarding the clarification of the role of this specification) has also caused me to take a closer look at the draft text. (Unfortunately, I had not found the time to complete my review earlier and send comments.) I strongly suggest to address the observations below: (A) General, recurring (A.1) The most striking editorial flaw I found repeatedly is the annoying use of partial double-half-expansions of common acronyms, like "UDP protocol", where the "P" in the abbreviation already stands for "protocol". (A.2) Further, I'm confused a bit about the ISO terms. I'm almost a layman in this respect, but as far as I undedstand the ISO OSI stack, ACSE (Association Control Service Element) is part of the ISO *session* layer. Therefore, the equivalence (postulated in Section 1.1) of ACSE PDU and APDU (== Application Protocol Data Unit) seems very surprising. Maybe this can be clarified / resolved. Do you want to say that Session, Presentation, and Application Layer are collapsed to a single layer in the C12.22 model? Then please make that explicit. Otherwise, a lot of language in the memo is confusing, as it mixes Session Control and Application data terms. (A.3) Due to the well-known expected addressing requirements for the deployment of the subject protocol, I'm surprised of the lack of strong preference towards IPv6. IMHO, the memo should recommend that no significant deployments should be performed using IPv4. See also items (B.10) and (B.11) below for things that are architecturally insane and represent obstacles and/or unnecessary overhead in the migration to IPv6. (B) Sepcific Here's a more complete list of specific remarks (in textual order of first occurrrence); the item headlines contain a classification as "nit", "concern", or "major concern". (B.1) Section 1, 2nd para -- minor concern The draft says: ANSI C12.22, which is an application-level messaging protocol, may be transported over any underlying transport network. This RFC defines the requirements governing the transmission of ANSI C12.22 Messages | via the TCP and UDP transports and the IP networking protocol. The last line seems to be inbalanced in style, and it contains such unpleasant partial expansion. Suggestion for better wording: ANSI C12.22, which is an application-level messaging protocol, may be transported over any underlying transport network. This RFC defines the requirements governing the transmission of ANSI C12.22 Messages | via the TCP and UDP transports in IP networks. (B.2) Section 1.2 -- general (multiple instances) -- concern Please replace phrases like "the UDP protocol" by either "the User Datagram Protocol (UDP)" or simply "UDP"; (same for "the TCP protocol", "the IP protocol"). (B.3) Section 1.2 -- APDU and ACSE PDU -- concern Please clarify as indicated above in (B). (B.4) Section 1.2 -- C12.22 [Request/Response] Message definitions -- concern Given the definition of "C12.22 Message" as being an APDU carrying either a fully assembled, or a segment of, C12.22 Request Message of C12.22 Response Message, the term "C12.22 Message APDU" for a C12.22 Response Message does not make sense. The preceding definition of "C12.22 Request Message" uses "C12.22 APDU". The definitions as presented are circular. At one stage, C12.22 Request/Response Messages are said to be an APDU, but later the draft says that the latter *contain* an ACSE that includes an EPSEM service request/response. EPSEM is synonymous for C12.22 here, isn't it? This confusion is also related to (B). (B.5) Section 2.2, 1st para -- minor concern The draft says: | The term Native IP Address is a Native Address, which MAY be used to | reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP Address includes the binary IP address, and an OPTIONAL port number that MAY be followed by an OPTIONAL protocol identifier. The Native IP Address SHALL be encoded as described in Section 2.3. Encoding of Native IP Addresses. The first sentence is highly confusing. I suspect that you wanted to indicate: vvv vvv | The term Native IP Address denotes a transport address that can be used to reach a C12.22 Node on its C12.22 IP Network Segment. [...] (B.6) Section 2.3, 1st sentence in 1st para -- nit ... for storage in C12.19 Device Table. should say: ... for storage in the C12.19 Device Table. (B.7) Section 2.3, end of 3rd para -- nit ... using different ApTitle. should say: ... using different ApTitles. (B.8) Section 2.4, last para -- concern The draft says: Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22 device MUST be configured to forward UDP and TCP traffic destined to port 1153 and other ports that are assigned and registered by the Network administrator, in o
Re: draft-c1222-transport-over-ip-07 -- more concerns
We shall review the issues identified below and provide editorial corrections. We have two questions: 1) The subject line categorizes the concerns below as "-- more concerns". Are there any other concerns that we are not aware of or that were not brought to our attention since the upload of draft-c1222-transport-over-ip-07? if so, were are they listed? 2) Should the revised document that addresses the concerns below be uploaded as draft-c1222-transport-over-ip-08? or should it be mailed directly to the editor? Thank you Avygdor Moise On 11/02/2010 08:46 AM, Alfred � wrote: Hello, the recent discussion on draft-c1222-transport-over-ip-07 (regarding the clarification of the role of this specification) has also caused me to take a closer look at the draft text. (Unfortunately, I had not found the time to complete my review earlier and send comments.) I strongly suggest to address the observations below: (A) General, recurring (A.1) The most striking editorial flaw I found repeatedly is the annoying use of partial double-half-expansions of common acronyms, like "UDP protocol", where the "P" in the abbreviation already stands for "protocol". (A.2) Further, I'm confused a bit about the ISO terms. I'm almost a layman in this respect, but as far as I undedstand the ISO OSI stack, ACSE (Association Control Service Element) is part of the ISO *session* layer. Therefore, the equivalence (postulated in Section 1.1) of ACSE PDU and APDU (== Application Protocol Data Unit) seems very surprising. Maybe this can be clarified / resolved. Do you want to say that Session, Presentation, and Application Layer are collapsed to a single layer in the C12.22 model? Then please make that explicit. Otherwise, a lot of language in the memo is confusing, as it mixes Session Control and Application data terms. (A.3) Due to the well-known expected addressing requirements for the deployment of the subject protocol, I'm surprised of the lack of strong preference towards IPv6. IMHO, the memo should recommend that no significant deployments should be performed using IPv4. See also items (B.10) and (B.11) below for things that are architecturally insane and represent obstacles and/or unnecessary overhead in the migration to IPv6. (B) Sepcific Here's a more complete list of specific remarks (in textual order of first occurrrence); the item headlines contain a classification as "nit", "concern", or "major concern". (B.1) Section 1, 2nd para -- minor concern The draft says: ANSI C12.22, which is an application-level messaging protocol, may be transported over any underlying transport network. This RFC defines the requirements governing the transmission of ANSI C12.22 Messages | via the TCP and UDP transports and the IP networking protocol. The last line seems to be inbalanced in style, and it contains such unpleasant partial expansion. Suggestion for better wording: ANSI C12.22, which is an application-level messaging protocol, may be transported over any underlying transport network. This RFC defines the requirements governing the transmission of ANSI C12.22 Messages | via the TCP and UDP transports in IP networks. (B.2) Section 1.2 -- general (multiple instances) -- concern Please replace phrases like "the UDP protocol" by either "the User Datagram Protocol (UDP)" or simply "UDP"; (same for "the TCP protocol", "the IP protocol"). (B.3) Section 1.2 -- APDU and ACSE PDU -- concern Please clarify as indicated above in (B). (B.4) Section 1.2 -- C12.22 [Request/Response] Message definitions -- concern Given the definition of "C12.22 Message" as being an APDU carrying either a fully assembled, or a segment of, C12.22 Request Message of C12.22 Response Message, the term "C12.22 Message APDU" for a C12.22 Response Message does not make sense. The preceding definition of "C12.22 Request Message" uses "C12.22 APDU". The definitions as presented are circular. At one stage, C12.22 Request/Response Messages are said to be an APDU, but later the draft says that the latter *contain* an ACSE that includes an EPSEM service request/response. EPSEM is synonymous for C12.22 here, isn't it? This confusion is also related to (B). (B.5) Section 2.2, 1st para -- minor concern The draft says: | The term Native IP Address is a Native Address, which MAY be used to | reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP Address includes the binary IP address, and an OPTIONAL port number that MAY be followed by an OPTIONAL protocol identifier. The Native IP Address SHALL be encoded as described in Section 2.3. Encoding of Native IP Addresses. The first sentence is highly confusing. I suspect that you wanted to indicate: vvv vvv | The term Native IP Address denotes a transport address that can be used to reach a C12.22 Node on its C12.22 IP Network Segment. [...] (B.6) Section
Re: draft-c1222-transport-over-ip-07 -- more concerns
Dear Mr. HÎnes, I have queued a document that contains the STRICTLY EDITORIAL corrections documented below for the RFC Editor. I did not submit the document yet, because I am waiting for instructions from the RFC Editor regarding these late comments. List of Changes made to the document for the RFC Editor's consideration: Removed "Protocol" from all instances of "TCP Protocol" and "UDP Protocol", corrected commas, brackets and "s", etc. Also I applied the following specific specific changes: *** Replaced all instances of "ACSE PDU" with "ACSE APDU" *** In Introduction: *** Added missing sentence to the introduction which now informs of the obvious the that the Presentation, and Application Layers were collapsed in C12.22. ... "(whereby the OSI Session, Presentation, and Application Layers of ANSI C12.22 are collapsed into a single Application Layer)". *** *** Edtorial correction applied "via the TCP and UDP transports in IP networks" *** In definition of C12.22 Response Message *** Replaced "C12.22 Message APDU" with "C12.22 APDU" *** In section Standardized Port Numbers *** Replace the words ..."... shielding a C12.22 device"... with ... "shielding C12.22 Nodes and the IP network"... *** The following is a detailed account addressing each and every comment (may not be of interest to the RFC Editor). (A) General, recurring (A.1) The most striking editorial flaw I found repeatedly is the annoying use of partial double-half-expansions of common acronyms, like "UDP protocol", where the "P" in the abbreviation already stands for "protocol". See general statement above. (A.2) Further, I'm confused a bit about the ISO terms. I'm almost a layman in this respect, but as far as I undedstand the ISO OSI stack, ACSE (Association Control Service Element) is part of the ISO *session* layer. Therefore, the equivalence (postulated in Section 1.1) of ACSE PDU and APDU (== Application Protocol Data Unit) seems very surprising. Maybe this can be clarified / resolved. The Connectionless-mode ACSE defined by "Open Systems Interconnection - Connectionless-mode protocol specifications, Information technology - Open Systems Interconnection - Connectionless protocol for the application service object Association control service, ITU-T Recommendation X.237 bis" states the following "This Recommendation | International Standard is based on the concepts developed in ITU-T Rec. X.200 | ISO/IEC 7498-1 and makes use of the following terms defined in them. a) Application Layer; b) application-process; c) application-entity; d) application-service-element; e) application-protocol-data-unit; f) connectionless-mode presentation-service; g) connectionless-mode session-service; and h) (N)-connectionless-mode transmission." It is our view that these elements and their use in an ACSE APDU are fully described by ANSI C12.22 and additional discussion is outside the scope of this RFC. *** Replaced all instances of "ACSE PDU" with "ACSE APDU" *** Do you want to say that Session, Presentation, and Application Layer are collapsed to a single layer in the C12.22 model? Then please make that explicit. Otherwise, a lot of language in the memo is confusing, as it mixes Session Control and Application data terms. *** Added missing sentence to the introduction that informs of the obvious the that the Presentation, and Application Layers were collams in C12.22. ... "(whereby the OSI Session, Presentation, and Application Layers of ANSI C12.22 are collapsed into a single Application Layer)". *** (A.3) Due to the well-known expected addressing requirements for the deployment of the subject protocol, I'm surprised of the lack of strong preference towards IPv6. IMHO, the memo should recommend that no significant deployments should be performed using IPv4. This RFC does not have any preference toward IPv4 or IPv6. The purpose of this RFC is not to promote IPv6. As such no reccomendation is made. See also items (B.10) and (B.11) below for things that are architecturally insane and represent obstacles and/or unnecessary overhead in the migration to IPv6. See my response to B.10 and B.11 (B) Sepcific Here's a more complete list of specific remarks (in textual order of first occurrrence); the item headlines contain a classification as "nit", "concern", or "major concern". (B.1) Section 1, 2nd para -- minor concern The draft says: ANSI C12.22, which is an application-level messaging protocol, may be transported over any underlying transport network. This RFC defines the requirements governing the transmission of ANSI C12.22 Messages | via the TCP and UDP transports and the IP networking protocol. The last line seems to be inbalanced in style, and it contains such unpleasant partial expansion. Suggestion for better wording: ANSI C12.22, which is an application-level messaging pro
Re: draft-c1222-transport-over-ip-07 -- more concerns
> Dear Mr. Hönes, > > I have queued a document that contains the STRICTLY EDITORIAL corrections > documented below for the RFC Editor. > I did not submit the document yet, because I am waiting for instructions > from the RFC Editor regarding these late comments. Thanks for your efforts and elaborations. At this instant, I only would like to give a short clarifying response to a few details where I believe that you have misunderstood me. > [...] >> >> (B.5) Section 2.2, 1st para -- minor concern >> >> The draft says: >> >> | The term Native IP Address is a Native Address, which MAY be used to >> | reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP >>Address includes the binary IP address, and an OPTIONAL port number >>that MAY be followed by an OPTIONAL protocol identifier. The Native >>IP Address SHALL be encoded as described in Section 2.3. Encoding of >>Native IP Addresses. >> >> The first sentence is highly confusing. >> I suspect that you wanted to indicate: >> >> vvv vvv >> | The term Native IP Address denotes a transport address that can be >>used to reach a C12.22 Node on its C12.22 IP Network Segment. [...] > > Actually no. The original text is exacly right. This cannot be right. A phrase like "The term XXX Address _is_ an YYY address ..." is nonsensical, independent of technical intent; a _term_ (as used here) never *is* an _address_, it only can *denote* an address. > Native Address is a Definition in this RFC and used by C12.22. That's correct from a general view of the C12.22 layer(s), but the definition in Section 1.2 says "Native Address" is a *network* address, whereas from the subsequent text it becomes clear that with "Native IP Address" you want to designate a *transport* address, that is the triple consisting of an IP address, a selector for the transport protocol, and the transport protocol port number at that IP address (with default values for protocol and port that can be omitted). "Transport address", or colloquially, "socket" is the standing term in the IETF to designate the communication endpoint where an application (protocol) interfaces with the standard Internet Protocol suite, and it should be your goal to map the generic term from C12.22 to the established Internet terminology that you want to make use of, isn't it? > Native IP Address is also a Definition in this RFC that scopes its > use to an IP Network. But in this paragraph that aims at introducing this term, you can't also use it on the RHS of the definition, or it will become recursive and thus not useful. And yes, in the scope of an IP network you need a "transport address" for an application endpoint. Maybe the problem is that the term "network" has a generic, layer- agnostic meaning and a specific meaning: the IP layer bridging the underlying subnetworks (physical and virtual link layers). When used in combination with "address", IETF participants and most RFC readers will assume the latter meaning; but that's not what I assume that you want to do here. >> [...] > > >> (B.10) Section 2.6, 2nd-to-last para -- major concern >> >> The draft says: >> >>In the implementation of this technique, an administrative domain >>MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in >>the administrative domain SHOULD be configured with a TTL >> | sufficiently large to reach that C12.22 IP Relay. A TTL threshold >> | SHOULD be defined and configured on all border routers linking the >> | administrative domain to the global Internet such that the routers >> | forward on their Internet interfaces only those 224.0.2.4 multicast >> | packets that have a TTL exceeding the threshold value. >> >> This is an architecturally insane recommendation. Routers decrement the >> TTL / Hop Count field on the "fast path" -- frequently with dedicated >> hardware support. This protocol cannot expect to be successful in >> requiring a new kind of TTL / Hop Count processing by major (boundary) >> routers. The only property of TTL / Hop Count that routers should >> remain interested in is whether it counts down to zero. >> The GTSM (RFC 5082) purposely restricts checking of *lower* bounds >> for TTL / Hop Count to the communicating end systems (notwithstanding >> the case where the relevant end systems are routers themselves). >> >> Therefore, IMHO the advice given here is not a good idea. >> An application protocol should not request changes to on-path routers. > > Although I agree with you, this was introduced by another DISCUSS. > See RFC 2365 on Administratively Scoped IP Multicast. IIRC, that is based on counting TTL to 0 or address scope recognition, not on ensuring a lower bound on the TTL in packets being forwarded. NB: Routers typically are not aware of the transport protocol port usage and therefore, even if they implemented the mechanism suggested in the document, would not know to whic
Re: draft-c1222-transport-over-ip-07 -- more concerns
Dear Mr. HÎnes, Thank you for the clarifications. Now we see what you aimed at. In order to address your concerns we propose the following changes to the text (for complete details is the inline text). 1) a) Corrected definition of Native Address (now using the term transport address) b) Corrected definition of Native IP Address 2) Deleted the last sentence in each of the last two paragraphs of Section IP Multicast 3) Corrected the last sentence in Section IP Broadcast. Avygdor Moise - Original Message - From: "Alfred HÎnes" To: Cc: ; Sent: Tuesday, November 02, 2010 7:35 PM Subject: Re: draft-c1222-transport-over-ip-07 -- more concerns Dear Mr. HÎnes, I have queued a document that contains the STRICTLY EDITORIAL corrections documented below for the RFC Editor. I did not submit the document yet, because I am waiting for instructions from the RFC Editor regarding these late comments. Thanks for your efforts and elaborations. At this instant, I only would like to give a short clarifying response to a few details where I believe that you have misunderstood me. [...] (B.5) Section 2.2, 1st para -- minor concern The draft says: | The term Native IP Address is a Native Address, which MAY be used to | reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP Address includes the binary IP address, and an OPTIONAL port number that MAY be followed by an OPTIONAL protocol identifier. The Native IP Address SHALL be encoded as described in Section 2.3. Encoding of Native IP Addresses. The first sentence is highly confusing. I suspect that you wanted to indicate: vvv vvv | The term Native IP Address denotes a transport address that can be used to reach a C12.22 Node on its C12.22 IP Network Segment. [...] Actually no. The original text is exacly right. This cannot be right. A phrase like "The term XXX Address _is_ an YYY address ..." is nonsensical, independent of technical intent; a _term_ (as used here) never *is* an _address_, it only can *denote* an address. > Native Address is a Definition in this RFC and used by C12.22. That's correct from a general view of the C12.22 layer(s), but the definition in Section 1.2 says "Native Address" is a *network* address, whereas from the subsequent text it becomes clear that with "Native IP Address" you want to designate a *transport* address, that is the triple consisting of an IP address, a selector for the transport protocol, and the transport protocol port number at that IP address (with default values for protocol and port that can be omitted). "Transport address", or colloquially, "socket" is the standing term in the IETF to designate the communication endpoint where an application (protocol) interfaces with the standard Internet Protocol suite, and it should be your goal to map the generic term from C12.22 to the established Internet terminology that you want to make use of, isn't it? > Native IP Address is also a Definition in this RFC that scopes its > use to an IP Network. But in this paragraph that aims at introducing this term, you can't also use it on the RHS of the definition, or it will become recursive and thus not useful. And yes, in the scope of an IP network you need a "transport address" for an application endpoint. Maybe the problem is that the term "network" has a generic, layer- agnostic meaning and a specific meaning: the IP layer bridging the underlying subnetworks (physical and virtual link layers). When used in combination with "address", IETF participants and most RFC readers will assume the latter meaning; but that's not what I assume that you want to do here. 1) Changed the definition of Native Address from "Native Address The term Native Address refers to the network address that may be used to reach a C12.22 Node on its C12.22 Network Segment [1]. In this specification the Native Address refers to the Native IP Address." to "Native Address The term Native Address refers to the transport address that may be used to reach a C12.22 Node on its C12.22 Network Segment [1]. In this specification the Native Address refers to the Native IP Address." 2) Changed the first sentence in the definition of Native IP Address from "The term Native IP Address is a Native Address, which MAY be used to reach a C12.22 Node on its C12.22 IP Network Segment." to "The term Native IP Address denotes a Native Address that MAY be used to reach a C12.22 Node on its C12.22 IP Network Segment" [...] (B.10) Section 2.6, 2nd-to-last para -- major concern The draft says: In the implementation of this technique, an administrative domain MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in the administrative domain SHOULD be configured with a TTL | sufficiently large to reach that C12.22 IP Relay. A TTL threshold | SHOULD be d
Transitional RFC Series Editor recommendations Overview document to be distributed by Wednesday - background document for Monday Plenary
The Overview of Transitional RFC Editor Recommendations announced earlier this week is now available at http://www.rfc-editor.org/rse/RSE.html This document addresses all the high-level recommendations in draft-kowack-rfc-editor-model-v2-00. It provides just the right background for the TRSE recommendations presentation during Monday's Technical Plenary at IETF 79 in Beijing. The presentation will be from 7:00 to 7:30 in Valley Ballroom ABC. I look forward to your comments. For those of you attending IETF 79, I look forward to seeing and talking to you there. regards, Glenn Transitional RFC Series Editor ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
