Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Hi, Regarding the mode and capability discussion, please see if the following change can resolve the issue: Section 9.2 OLD: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. New: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. Capability TLVs with other combinations than the one specified by a mode are not allowed. Best regards, Jeong-dong From : Huub Van Helvoort huub.van.helvo...@huawei.com Sent : 2014-02-27 04:58:09 ( +09:00 ) To : Elwyn Davies elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Hello Elwyn, Thanks for your reply. See my responses in-line [Huub3]. = On Wed, 2014-02-26 at 16:39 +, Huub Van Helvoort wrote: Hello Elwyn, Please find my response in-line [Huub2] To avoid any confusion I have snipped the parts that do not need further expanation. Minor issues: s1, next to last para: This document describes the behavior of the PSC protocol including the priority logic and the state machine when all the capabilities associated with the APS mode are enabled. The PSC protocol behavior for the PSC mode is as defined in RFC 6378. APS mode involves five capabilities which can, apparently, be implemented and advertised indpendently, so presumably there might be reasons for either implementing or turning on just a subset. [Huub] There were originally separate drafts for each of the capabilities. However, it was very complex to define the effect on the state transition tables for each capability or combination of capabilities. [Huub] to resolve this issue it was decided that for any permitation of the possible combinations of capabilities a separate draft should be developed. RFC6378 is the one where none of the capabilities is used, and this draft is the one where all capabiliies are used. So far none of the other possible drafts is written. [Huub] This draft provides the behavior similar to APS used in ITU-T for other technologies. Are there any implications for the PSC protocol if only some subset of the the capabilities are available in a given node? (This may be a dumb question and I haven't tried to work out what might go wrong if you did have any of the available subsets.) [Huub] both nodes MUST support the same subset, if they don't the result will be unpredictable because the state machines are different. s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that the system can operate happily with some subset of the five capabilities turned on provided that both ends concur. However there is no mode name that would cover such a subset. [Huub] as indicated above, the mode name does not exist because the draft that describes that mode does not (yet) exist. Does this actually mean that turning on a subset doesn't really work? [Huub] indeed, not until there is a draft that describes it. And if it doesn't work why bother with five flag bits? [Huub] to give others the opportunity to write the missing draft(s), this was the agreed by the WG chairs. Also the phraseology used here could lead to future problems if more capabilities are defined: suppose some future new mode (FOO) adds more capabilities but the two 'modes' can be turned on independently - as currently expressed you would have to define three mode names for APS only, FOO only and APS + FOO.. and so on with more capability sets. Unintended consequence? Oh, and what if a capability is used in more than one mode? [Huub] it is up to the authors of additional drafts to come up with a name for the mode described in their draft. To be absolutely honest, my initial reaction to the above (i.e., right back to the beginning of Minor Issues) went something like ARRRHHH! Choke!! Splutter!!!. Be that as it may, if that is what is agreed then please could there be some explanation in the document. Please! [Huub2] the probability that there may be several solutions is IMHO very small. Personally I do not expect any other solution because RFC6378 is what IETF wants, and this draft is what ITU-T wants and will document in recommendation G.8131. Any other solution would be non-standard. Adding an explanation to this draft will give the impression that other solutions will be acceptable. Something neither IETF nor ITU-t would admit to. Politics! OK - How
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Huub, Unfortunately, I agree with Adrian in terms of why we would not claim that any other combination of bits is invalid generally, so I do not agree that the change suggested by Elwyn is a good idea. I also agree that the reasoning that the bit-combination match criteria makes it clear how any implementation of this specification would handle anything other than all-clear or all-set. The implementation will not try to perform OAM between two implementations that do not have a matching bit-set that is either one or the other. I am not sure where we indicate that any other set of bits is an error, so I do not really understand that part of Adrian's reply. At this point, I do not see any clear need for changes to the draft based on this particular comment-set. -- Eric -Original Message- From: Huub Van Helvoort [mailto:huub.van.helvo...@huawei.com] Sent: Wednesday, February 26, 2014 2:58 PM To: Elwyn Davies Cc: General Area Review Team; draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Hello Elwyn, Thanks for your reply. See my responses in-line [Huub3]. = On Wed, 2014-02-26 at 16:39 +, Huub Van Helvoort wrote: Hello Elwyn, Please find my response in-line [Huub2] To avoid any confusion I have snipped the parts that do not need further expanation. Minor issues: s1, next to last para: This document describes the behavior of the PSC protocol including the priority logic and the state machine when all the capabilities associated with the APS mode are enabled. The PSC protocol behavior for the PSC mode is as defined in RFC 6378. APS mode involves five capabilities which can, apparently, be implemented and advertised indpendently, so presumably there might be reasons for either implementing or turning on just a subset. [Huub] There were originally separate drafts for each of the capabilities. However, it was very complex to define the effect on the state transition tables for each capability or combination of capabilities. [Huub] to resolve this issue it was decided that for any permitation of the possible combinations of capabilities a separate draft should be developed. RFC6378 is the one where none of the capabilities is used, and this draft is the one where all capabiliies are used. So far none of the other possible drafts is written. [Huub] This draft provides the behavior similar to APS used in ITU-T for other technologies. Are there any implications for the PSC protocol if only some subset of the the capabilities are available in a given node? (This may be a dumb question and I haven't tried to work out what might go wrong if you did have any of the available subsets.) [Huub] both nodes MUST support the same subset, if they don't the result will be unpredictable because the state machines are different. s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that the system can operate happily with some subset of the five capabilities turned on provided that both ends concur. However there is no mode name that would cover such a subset. [Huub] as indicated above, the mode name does not exist because the draft that describes that mode does not (yet) exist. Does this actually mean that turning on a subset doesn't really work? [Huub] indeed, not until there is a draft that describes it. And if it doesn't work why bother with five flag bits? [Huub] to give others the opportunity to write the missing draft(s), this was the agreed by the WG chairs. Also the phraseology used here could lead to future problems if more capabilities are defined: suppose some future new mode (FOO) adds n more capabilities but the two 'modes' can be turned on independently - as currently expressed you would have to define three mode names for APS only, FOO only and APS + FOO.. and so on with more capability sets. Unintended consequence? Oh, and what if a capability is used in more than one mode? [Huub] it is up to the authors of additional drafts to come up with a name for the mode described in their draft. To be absolutely honest, my initial reaction to the above (i.e., right back to the beginning of Minor Issues) went something like ARRRHHH! Choke!! Splutter!!!. Be that as it may, if that is what is agreed then please could there be some explanation in the document. Please! [Huub2] the probability that there may be several solutions is IMHO very small. Personally I do not expect any other solution because RFC6378 is what IETF wants, and this draft is what ITU-T wants and will document in recommendation G.8131. Any other solution would be non-standard. Adding an explanation to this draft will give the impression that other solutions will be acceptable. Something neither IETF nor ITU-t would admit to. Politics! OK - How about we add to
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
It looks like we have convergence - in theory. The question is what text, if any, needs to change? -Original Message- From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: Wednesday, February 26, 2014 3:22 PM To: adr...@olddog.co.uk; elw...@folly.org.uk Cc: gen-art@ietf.org; draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Shwmae Adrian, You wrote: [snip] Politics! OK - How about we add to either s9.1.1 or s9.2 something like: I don't think it is politics at all, and I don't really like that Huub referenced this as IETF and ITU-T since both documents are IETF standards track work. Please excuse me for giving the impression that this draft is an ITU-T document. You are absolutely right that both are IETF documents. I should have used PSC in ITU-T mode to refer to this draft. There are some people who want to deploy one set of options (the empty set) and they have an RFC. There is another set of people who want to deploy a different set of options (all 5 of them) and they will have this RFC. Indeed. Only combinations of capabilities specified by a mode are allowed. Capability TLVs with other combinations will be treated as invalid PSC messages. But this is not true. What we have is: A node knows which options it supports, and those options are expressed as bundles (modes). A node that tries to communicate with you must offer a set of options (a mode). Either you support the mode or you don't. If you support it, off you go. If you don't support it, you reject the message saying unsupported as described in this document. Again: correct. I tried to simplify too much and used the wrong word (invalid, instead of unsupported). The message that offers a different set of options (i.e. a different mode) is not invalid, it is just that you don't understand it. You can't accept it because you don't know how to behave in that mode. Indeed (not supported). OTOH, when someone writes the new RFC describing that mode, you might enhance your implementation to support it as well. Yes, and initially advertise your own capabilities, compare to the capabilities received from the far-end and attempt to converge. (Hint: it really helps to think in modes. A mode is expressed as a bit-flag with plenty-bits of which five currently have meaning.) I agree with you that there is some distinction to be made between invalid message and protocol error. But no valid message does not mean protocol error or invalid message was received. It is a composite of possibilities that reflects the negation of receiving a message that was small and perfectly formed. OK. Cheers, Huub. -- * 请记住，你是独一无二的，就像其他每一个人一样 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Elwyn, Some missing background that really is just an amplification of part of Huub's reply below: There is no clear use-case, or any indication that there will be any use-case for any subset of the capabilities (bits) currently used to represent the two defined modes. However, we cannot know the future, so we did not (and do not) want to exclude the possibility that there may eventually be just such a use-case. A reasonable analysis of the state-machine logic in this draft will show that a lot of additional states and transitions, and a lot more complex mode negotiation would be involved in supporting arbitrary sub-setting of the capabilities that currently make up a mode. Based on the lack of a real use-case for it, I think we have to view any attempt to force us to explain exactly how such sub-setting would be supported as an effort to guide the work toward a rat-hole we can all see. If it does become clear at some point that other combinations of the bits are needed, then someone will take up the task to write one or more drafts as needed to explain how that will work (and interwork with any then-existing combinations). I really can't imagine why it is necessary to explicitly say this. The ability to do additional work is always there, except where some specific class of work seems a really bad idea (to folks with a crystal ball, to tell them when this is the case). If it was necessary to say this explicitly, we have a lot of work cut out for us in re-writing a ton of RFCs. :-) -- Eric -Original Message- From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Elwyn Davies Sent: Wednesday, February 26, 2014 1:24 PM To: Huub Van Helvoort Cc: General Area Review Team; draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Hi, Huub. Thanks for the responses: Agreed bits snipped again. On Wed, 2014-02-26 at 16:39 +, Huub Van Helvoort wrote: Hello Elwyn, Please find my response in-line [Huub2] To avoid any confusion I have snipped the parts that do not need further expanation. Minor issues: s1, next to last para: This document describes the behavior of the PSC protocol including the priority logic and the state machine when all the capabilities associated with the APS mode are enabled. The PSC protocol behavior for the PSC mode is as defined in RFC 6378. APS mode involves five capabilities which can, apparently, be implemented and advertised indpendently, so presumably there might be reasons for either implementing or turning on just a subset. [Huub] There were originally separate drafts for each of the capabilities. However, it was very complex to define the effect on the state transition tables for each capability or combination of capabilities. [Huub] to resolve this issue it was decided that for any permitation of the possible combinations of capabilities a separate draft should be developed. RFC6378 is the one where none of the capabilities is used, and this draft is the one where all capabiliies are used. So far none of the other possible drafts is written. [Huub] This draft provides the behavior similar to APS used in ITU-T for other technologies. Are there any implications for the PSC protocol if only some subset of the the capabilities are available in a given node? (This may be a dumb question and I haven't tried to work out what might go wrong if you did have any of the available subsets.) [Huub] both nodes MUST support the same subset, if they don't the result will be unpredictable because the state machines are different. s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that the system can operate happily with some subset of the five capabilities turned on provided that both ends concur. However there is no mode name that would cover such a subset. [Huub] as indicated above, the mode name does not exist because the draft that describes that mode does not (yet) exist. Does this actually mean that turning on a subset doesn't really work? [Huub] indeed, not until there is a draft that describes it. And if it doesn't work why bother with five flag bits? [Huub] to give others the opportunity to write the missing draft(s), this was the agreed by the WG chairs. Also the phraseology used here could lead to future problems if more capabilities are defined: suppose some future new mode (FOO) adds n more capabilities but the two 'modes' can be turned on independently - as currently expressed you would have to define three mode names for APS only, FOO only and APS + FOO.. and so on with more capability sets. Unintended consequence? Oh, and what if a capability is used in more than one mode? [Huub] it is up to the authors of additional drafts to come up with a
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Jeong-dong, If you change not allowed to not supported in this specification – I think we have it. -- Eric From: Ryoo, Jeong-dong [mailto:r...@etri.re.kr] Sent: Tuesday, March 04, 2014 12:38 PM To: Huub Van Helvoort; Elwyn Davies Cc: General Area Review Team; draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject: RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Hi, Regarding the mode and capability discussion, please see if the following change can resolve the issue: Section 9.2 OLD: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. New: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. Capability TLVs with other combinations than the one specified by a mode are not allowed. Best regards, Jeong-dong From : Huub Van Helvoort huub.van.helvo...@huawei.commailto:huub.van.helvo...@huawei.com Sent : 2014-02-27 04:58:09 ( +09:00 ) To : Elwyn Davies elw...@dial.pipex.commailto:elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.orgmailto:gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.orgmailto:draft-ietf-mpls-tp-psc-itu@tools.ietf.org draft-ietf-mpls-tp-psc-itu@tools.ietf.orgmailto:draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Hello Elwyn, Thanks for your reply. See my responses in-line [Huub3]. = On Wed, 2014-02-26 at 16:39 +, Huub Van Helvoort wrote: Hello Elwyn, Please find my response in-line [Huub2] To avoid any confusion I have snipped the parts that do not need further expanation. Minor issues: s1, next to last para: This document describes the behavior of the PSC protocol including the priority logic and the state machine when all the capabilities associated with the APS mode are enabled. The PSC protocol behavior for the PSC mode is as defined in RFC 6378. APS mode involves five capabilities which can, apparently, be implemented and advertised indpendently, so presumably there might be reasons for either implementing or turning on just a subset. [Huub] There were originally separate drafts for each of the capabilities. However, it was very complex to define the effect on the state transition tables for each capability or combination of capabilities. [Huub] to resolve this issue it was decided that for any permitation of the possible combinations of capabilities a separate draft should be developed. RFC6378 is the one where none of the capabilities is used, and this draft is the one where all capabiliies are used. So far none of the other possible drafts is written. [Huub] This draft provides the behavior similar to APS used in ITU-T for other technologies. Are there any implications for the PSC protocol if only some subset of the the capabilities are available in a given node? (This may be a dumb question and I haven't tried to work out what might go wrong if you did have any of the available subsets.) [Huub] both nodes MUST support the same subset, if they don't the result will be unpredictable because the state machines are different. s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that the system can operate happily with some subset of the five capabilities turned on provided that both ends concur. However there is no mode name that would cover such a subset. [Huub] as indicated above, the mode name does not exist because the draft that describes that mode does not (yet) exist. Does this actually mean that turning on a subset doesn't really work? [Huub] indeed, not until there is a draft that describes it. And if it doesn't work why bother with five flag bits? [Huub] to give others the opportunity to write the missing draft(s), this was the agreed by the WG chairs. Also the phraseology used here could lead to future problems if more capabilities are defined: suppose some future new mode (FOO) adds more capabilities but the two 'modes' can be turned on independently - as currently expressed you would have to define three mode names for APS only, FOO only and APS + FOO.. and so on with more capability sets. Unintended consequence? Oh, and what if a capability is used in more than one mode? [Huub] it is up to the authors of additional drafts to come up with a name for the mode described in their draft. To be absolutely honest, my initial reaction to the above (i.e., right back to the beginning of Minor Issues) went something like ARRRHHH! Choke!! Splutter!!!.
Re: [Gen-art] Partial Gen-ART review of draft-ietf-nfsv4-rfc3530bis-25
Hi Martin, In reviewing the Gen-ART reviews of 3530bis, I realized I had not responded to your review. We had been very focused on S12. I am sorry for the oversight and want to thank you for your review. I have answers in-line and have revised the draft with the necessary changes. Tom On 4/15/13, 5:41 PM, Martin Thomson martin.thom...@gmail.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-nfsv4-rfc3530bis-25 Reviewer: Martin Thomson Review Date: 2013-04 IETF LC End Date: too soon IESG Telechat date: ditto Summary: I have some confidence that this document is ready for publication. What I have seen is sufficiently well specified that it could be implemented, mostly. There are large parts of this document that I simply haven't read. I can't justify spending more time. (Sorry Jari, I tried.) Reviewing this document is especially difficult because the it relies heavily on context. A lot of this context is only gained by reading on and stumbling upon that context. Much of this could be addressed with appropriate forward references. I agree with you here, the focus is so narrow that it is assumed that everyone knows all. It's clear that Section 12 is largely new, or at least significantly changed from RFC 3530. Section 12 on its own would constitute a larger than average RFC. Yes and we have whacked it again to reflect reality. Going forward, I envision we no longer write these large drafts and instead break down the sections which are minor version independent. Both S12 and the minor versioning rules themselves are candidate for such RFCs. The work on the minor versioning is underway. If accessibility is a goal, the document could have been split and it probably should have been. However, I suspect that accessibility isn't that important to those working on this. No, it is. But it wasn¹t the mandate put forth at the start of this document. The goal was to get the document in tune with working code without breaking the minor versioning rules. And one interpretation of that was to not do anything which would impact RFC 5661. Believe me, I never want to do such a re-edit of this large a document again. The way forward is to break it up opportunistically. The document talks quite frequently about before, with reference to NFSv2 or NFSv3. This is almost always useless to a reader without context. I don't expect you to do anything about this, but I'd request that any future revision consider removing this. For one, in reviewing a -bis draft, I personally think of RFC3530 as the before to which is refered. On the whole, fewer history lessons and more real context would have made this a lot easier to read. General: The document uses lowercase must and may a lot. It's not clear whether these are intended to be interpreted as normative statements or not. To my eyes, most of these are. On the other hand, there are places where 2119 language is used to effectively specify implementation details that aren't observable at a protocol level. If the document weren't so large, I'd suggest that the editors go through and make sure that every 2119 keyword is in uppercase and then to check each and every instance. Nits: 1.5.3 - I realize that it might be premature to explain details when the draft hasn't yet described how to identify locations (that's a truly unfortunate choice of word). Maybe a short primer on that could be included. At this point, I'm relying on assumed knowledge about filesystems to understand concepts like: hierarchical ACLs, pseudo filesystems, attributes. Even the fact that a filesystem is a tree with terminal nodes that contain sequences of bytes. Non-terminal nodes (directories) and terminal nodes (files) are named (hence the UTF-8) and have attributes. Where it gets fuzzy is when it uses path name. Is path name an abstraction that encapsulates directory name and file name? Is a file name the name of the node, or is it the entire locator including the names of the directory above it (and some unspecified separator)? Going back to your earlier comments about context, the assumptions here are that the reader is familiar with Unix filesystems. 1.5.3.1 [...] The server provides multiple filesystems by gluing them together with pseudo filesystems. These pseudo filesystems provide for potential gaps in the path names between real filesystems. I don't know how to interpret this last statement. I'm using a fair bit of guesswork to infer how this works as it is, but that understanding does not result in gaps, just pseudo filesystems (with no actual files). I¹ve added wording to clarify both this and the one below. 1.5.3.3 - The description of namespaces is singularly unhelpful in conveying any information
Re: [Gen-art] Partial Gen-ART review of draft-ietf-nfsv4-rfc3530bis-25
On 4 March 2014 20:10, Haynes, Tom tom.hay...@netapp.com wrote: In reviewing the Gen-ART reviews of 3530bis, I realized I had not responded to your review. We had been very focused on S12. I thank you for taking the time. I honestly hope that I've helped in some way to improve the document. It's been too long since I did this for me to be able to respond usefully to your comments, but it appears as though you have covered most of the issues well. Regarding snake oil, I re-read the new 1.3.3.3 and I think that the minor additions you've made there help. I think that my objection may have been largely as a result of not having sufficient context to understand in combination with what is a somewhat abstract description. I appreciate the expansion of the text, it's more informative. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
